สรุป DE Meetup #3 : Common Data Engineer Nightmares

Data Engineer Thailand ได้จัด Meetup ครั้งที่ 3 ในหัวข้อ “From Hero to Headache: Common Data Engineer Nightmares” ที่พูดคุยกันถึงเรื่องปัญหาและ challenge ต่างๆที่เจอในสายงาน Data engineer (DE) โดยเชิญ speaker 4 ท่านมาเล่าปัญหาที่เจอในการทำงานจริงให้ฟัง มีทั้งเรื่องทาง technical เรื่องการเลือกงาน เรื่องการสื่อสาร เรียกได้ว่าเห็นปัญหาหลากหลายที่ DE ได้เจอเลยทีเดียว

บทความนี้เป็นการสรุปเนื้อหาจาก speaker ทั้ง 4 ท่านจากที่เราได้ฟังใน meetup หากตกหล่นประเด็นไหนไปต้องขออภัยด้วยค่ะ

1. Session #1 : Pain ของ Junior DE
2. Session #2 : Challenge in Streaming Processing with ksqlDB
3. Session #3 : Pain การสื่อสารของ DE
4. Session #4 : Pain ของ DE ที่เป็นตัวกลางระหว่าง Dev และ Business
5. Networking
6. Data Clinic

---

Session #1 : Pain ของ Junior DE

คุณนอร์ท Junior Data Engineer จากบริษัท CJ Express ได้มาเล่าถึงปัญหาของตัวเองและเพื่อนๆที่เป็น Junior DE เจอมา โดยคุณนอร์ทสรุปปัญหาออกเป็น 2 ข้อพร้อมทั้งแนะนำวิธีการที่น่าจะช่วยหลีกเลี่ยงปัญหานี้ได้

1. การเลือกบริษัท

คุณนอร์ทเล่าว่าจริงๆปัญหาที่เกิดอาจจะเกิดตั้งแต่การเลือกบริษัทผิดแล้วก็ได้

การที่เข้าไปในทีมที่มีแต่ junior หรือถึงทีมจะมี senior ก็ยุ่งมากๆจนไม่มีเวลามาแนะนำน้องๆ เวลาเจอปัญหาตอนการทำงาน ในฐานะ junior บางทีก็ไม่รู้ว่าจะแก้ไขยังไง ไม่มีคนมาคอยแนะนำ บางทีก็ได้แต่นั่งมองตากันปริบๆ

งานที่ได้ทำอาจจะไม่เหมือนกับที่เรียนเอาไว้ เช่น เรียนคอร์สออนไลน์เขียนโค้ดมามากมาย แต่เข้าไปแล้วอาจจะเป็นแค่การเขียน config ทำทุกอย่างแบบ manual หรือได้ไปทำแค่ excel ก็ได้

Culture ของบริษัทไม่ตรงกับที่ต้องการ เช่น เราอยาก WFH แต่บริษัทให้เข้าบริษัททุกวัน แบบนี้ก็อาจจะไม่โอเค หรือเข้าไปเจอทีมที่ไม่โอเคก็มี

แล้วจะทำยังไงให้เราเลือกบริษัทที่จะไม่เจอปัญหาเหล่านี้?

คุณนอร์ทบอกว่าให้ลองถามคำถามตอนช่วงท้ายของสัมภาษณ์งานดู โดยลองถามเกี่ยวกับเรื่องเหล่านี้

• ทีมที่จะเข้าเป็นทีมที่ตั้งขึ้นมาใหม่ไหม – ถ้าเป็นทีมตั้งใหม่ก็มีโอกาสที่จะเป็น One man DE ที่ทำทุกอย่างแบบไม่มีใครช่วย
• ทีมที่จะเข้าไปมี doc หรือ material ให้เรียนรู้ไหม – ถ้าไม่มีหรือเป็นแบบที่ความรู้อยู่ที่คนๆเดียว ก็อาจจะเรียนรู้ได้ช้าหรือไม่รู้จะแก้ปัญหาอย่างไร
• Community หรือเพื่อนร่วมงานเป็นอย่างไร – ทีมทำกิจกรรมที่เราสนใจไหม เช่น ไปกินข้าวด้วยกัน ไปปีนเขาหรือเที่ยวด้วยกันวันหยุด
• Career growth – ลองถาม use case งานที่ทำ ถามว่าใช้เครื่องมืออะไรบ้าง หรือมีโปรเจคอะไรบ้าง จะได้ดูว่ามีโอกาสได้ทำส่วนที่เราสนใจไหม
• เป้าหมายขององค์กร – ลองถามว่าบริษัทใช้ data ทำอะไรบ้าง หรือถามถึงเป้าหมายองค์กร แล้วดูว่าเราสนใจแนวทางที่บริษัทจะไปไหม

โดยคุณนอร์ทยังได้แชร์ว่า ลองทำตารางให้คะแนนเวลาที่ได้ไปสัมภาษณ์งานกับหลายๆบริษัทดูตามรูปด้านล่าง โดยสีเหลืองคือ weight ที่เราให้กับหัวข้อนั้นๆ พอรวมคะแนนออกมาอาจจะทำให้เราตัดสินใจได้ง่ายขึ้น (ขอโทษด้วย ลืมครอปหัวมา)

2. ถ้าทำงานไปแล้วรู้สึกไม่พอใจกับงานล่ะ

ถึงแม้จะเลือกบริษัทได้ถูกตามที่ตั้งใจไว้ ก็มีโอกาสที่ทำงานไปแล้วอาจมีการเปลี่ยนแปลง ทำให้เกิดความไม่สบายใจหรือไม่พอใจในการทำงานได้

คุณนอร์ทแนะนำให้คุยกับหัวหน้าก่อน โดยปกติทุกบริษัทจะมี 1-1 meeting กับหัวหน้าทุกเดือนอยู่แล้ว เป็นช่วงเวลาที่จะได้เล่าความไม่สบายใจหรือความไม่พอใจให้หัวหน้าฟัง ซึ่งพอหัวหน้าได้ฟังแล้ว หัวหน้าอาจจะช่วยแก้ปัญหาหรือทำอะไรบางอย่างที่แก้ปัญหาเหล่านั้น โดยที่เราอาจจะไม่ต้องหางานใหม่ก็ได้ แต่ถ้าพูดกับหัวหน้าแล้วไม่มีอะไรดีขึ้น ก็เป็นสิทธิ์ของเราที่จะพิจารณาหางานใหม่เช่นกัน

สุดท้ายคุณนอร์ทฝากบทความแนะนำสำหรับการเตรียมสัมภาษณ์ไว้ให้ลองไปอ่านกันค่ะ

ฟังดูแล้วนี่คงไม่ใช่แค่ปัญหาเฉพาะ junior แล้วแหละ เป็นปัญหาของทุกคนเลย

Session #2 : Challenge in Streaming Processing with ksqlDB

คุณต้น Senior Data Engineer จากบริษัท Honest ได้มาเล่า technical challenges ในการทำ streaming processing ด้วย ksqlDB ที่สามารถ connect และทำ transform ข้อมูลจาก kafka ได้ง่าย และมี connector ต่อกับ sink หลายเจ้า

คุณต้นเล่าถึงที่มาที่ไปของการใช้ ksqlDB ก่อน เพราะถ้าพูดถึง streaming แล้วก็มี tool ตัวอื่นๆ เช่น Spark streaming, Flink, Apache Beam ให้เลือกอีกเยอะ ทำไมถึงใช้ ksqlDB?

ksqlDB ถูกเลือกมาใช้ก่อนที่คุณต้นจะเข้าบริษัท ตอนที่เลือก บริษัทยังไม่มีคนที่มีความรู้ทางด้าน DE มาก พอมี use case ที่ต้องใช้ streaming แล้ว Confluent cloud ที่เป็น fully managed service มาขายของ บริษัทก็เลยตัดสินใจใช้ (การใช้ fully managed service จะทำให้ไม่ต้องกังวลเรื่องดูแล infra มาก)

แต่ระหว่างที่ใช้ ksqlDB คุณต้นก็เจอปัญหามากมาย

อย่างแรกเลยคือเรื่อง Service limitation

คุณต้นบอกว่า CI เป็นส่วนสำคัญของการทำ pipeline มากๆ แต่ตัว ksqlDB ไม่ CI friendly เลย จะทำอะไรต้องผ่าน cli หมด แต่ cli ก็มีข้อจำกัด เช่น deploy stream ผ่าน cli ได้ แต่ remove ผ่าน cli ไม่ได้ ไม่เหมือนกับ terraform

อันต่อไปคือเรื่อง Manage schema changes ที่โดยปกติเราสามารถรัน alter ได้ แต่ cli มี limit ที่ทำให้ alter ไม่ได้ เลยต้อง drop stream แล้ว create stream ใหม่

อีกทั้งเรื่องของ Query syntax ที่ไม่เหมือนชาวบ้าน ที่ไม่มีคำสั่งบางอย่างทำให้การทำ transform ข้อมูลยาก ไม่เหมือนใน Redshift หรือ BigQuery

นอกจากเรื่อง Service limitation แล้ว ยังมีปัญหาเรื่องของ Data duplication ที่ถึงแม้ Confluent จะเคลมว่าเป็น Exactly-Once processing ที่การันตีว่าจะไม่มี duplication แล้ว แต่ก็ยังเจออยู่ดี

จริงๆคุณต้นยังพูดถึงปัญหาเรื่อง Backfill และ Schema evolution ด้วย ที่ตัว ksqlDB สามารถทำได้ยาก แต่เราหลุดไป (ถ้าใครจดไว้ทักมาอัพเดตได้นะคะ TT)

หลังจากจบ session มีคำถามที่น่าสนใจถามว่า ถ้าจะเปลี่ยนจาก batch ไป streaming อะไรเป็นปัญหาที่ challenge ที่สุด เพราะเข้าใจว่าหลายๆบริษัทกำลังเบนไปทำ streaming กัน

คุณต้นตอบว่าสิ่งที่ challenge ที่สุดสำหรับคุณต้นคือการทำ backfill เพราะถ้าเป็น batch จะมี interval ในการอัพเดตข้อมูลที่ตายตัว ทำให้สามารถ backfill ข้อมูลได้ง่าย แต่พอเป็น streaming ที่ข้อมูลอัพเดตตลอดเวลาการทำ backfill เลยยากขึ้น วิธีหนึ่งที่แนะนำคือแยก pipeline สำหรับการ backfill ออกไปเป็นแบบ batch อีกอันหนึ่งเลยก็ได้

นอกจากนั้น คุณต้นยังแนะนำให้กลับมาดูที่โจทย์ของการทำ streaming ว่า จำเป็นต้องทำไหม จำเป็นต้องเป็น realtime ไหม หรือจริงๆทำเป็น batch ก็ได้ เพราะการทำ streaming ยุ่งยากกว่าและ cost สูงกว่า batch มาก

Session #3 : Pain การสื่อสารของ DE

คุณโต Senior Business Analyst จากบริษัท Data Cafe Thailand มาเล่าถึงปัญหาที่คุณโตเจอมาตั้งแต่การเป็น DE คนเดียวในทีมจนมาถึงการเป็น BA

คุณโตเปิดด้วยปัญหาที่สำคัญมากคือ Office syndrome ที่งาน DE ต้องใช้ความถึก อึด ทน ถ้าเรา transform ข้อมูลไม่ดีก็ต้องกลับมานั่งทำใหม่กันยาวๆ แล้วคนฟังก็ตั้งใจฟังมาก แต่ไม่ใช่! คุณโตพูดเล่น

เรื่องที่ปวดหัวมากๆสำหรับคุณโตคือภาษาที่ใช้ในการสื่อสาร ด้วยความที่เป็น DE คนเดียวในทีมทำให้ต้องออกไปคุยกับทุกคนไม่ว่าจะเป็น dev หรือฝั่ง analyst

ภาษาที่คุยมีปัญหามากพอสมควรเวลาที่คุยกับ analyst เพราะคุณโตเป็นสาย technical แต่ต้องมาแปลงให้อยู่ในรูปแบบที่ analyst ฟังรู้เรื่อง เวลาไปรับบรีฟมาก็ต้องทำความเข้าใจให้ได้ว่าสิ่งที่ analyst ต้องการครบไหม แต่ถ้าอยู่องค์กรใหญ่ๆที่มีการทำงานเป็นระบบ มีทีมที่ครบ ก็จะมีตำแหน่งที่คอยสื่อสารกับคนอื่นๆให้ DE อาจจะไม่ต้องไปรับหน้า

เรื่องต่อมาคือเรื่องเอกสารหรือ doc ที่ต้องทำและควรจะทำ แต่จะทำให้ดีก็ยาก กลับกันบางที่ก็ไม่มี doc อะไรให้เลย ก็เป็น pain หนึ่งอย่างเหมือนกัน (ในแชทบอกว่า คน = doc)

อีกเรื่องคือเรื่องของ technology ที่คุณโตมักจะเจอตอนที่น้องๆ junior เข้ามาถาม น้องๆหลายคนจะตามศัพท์ technical ไม่ค่อยทัน พอมีเครื่องมือหรือ tool ใหม่ๆก็มักจะมีศัพท์ใหม่ๆที่กำหนดขึ้นมาโดยเฉพาะ tool นั้น แต่ถ้าไปศึกษาดีๆ concept ไม่ต่างจากของที่มีอยู่เลย คุณโตเลยแนะนำให้ไปศึกษาคำศัพท์และวิธีการทำงานของ tool นั้นๆให้ดี

คุณโตแนะนำส่งท้ายโดยเฉพาะกับ junior ทั้งหลายว่า อย่าหยุดที่จะเรียนรู้ ไม่ว่าจะเป็นความรู้ฝั่ง tech หรือฝั่ง business domain ทุกๆทีมมีปัญหาด้วยกันหมด แต่ปัญหาอาจจะแตกต่างกันไปตามงานของแต่ละทีม ถ้าเราเข้าใจ business domain และปัญหาของเขาก็จะสื่อสารกันง่ายขึ้น สิ่งที่เรียนรู้ในวันนี้อาจจะไม่ได้ใช้ในวันนี้ แต่ถึงเวลาต้องใช้จริงๆในอนาคตก็จะเอามา apply กับงานได้ทันที

Session #4 : Pain ของ DE ที่เป็นตัวกลางระหว่าง Dev และ Business

คุณหน่อง Data Engineer จากบริษัท NocNoc ได้มาเล่าถึงการทำงานของ DE ที่เป็นเหมือนตัวกลางระหว่างทีม dev กับทีม business

คุณหน่องเล่าว่า DE จะทำหน้าที่ดึงข้อมูลจาก source ซึ่งส่วนใหญ่คือ database ที่ต่อกับเว็บและแอปที่ dev เป็นคนรับผิดชอบ แล้ว transform ข้อมูลสำหรับการทำ analytic ให้ทีม business ต่างๆ เวลาที่ business เจอว่าข้อมูลมีปัญหาจะเข้ามาหา DE ก่อน แล้ว DE ก็ต้องไปหาว่าปัญหาเกิดจากอะไร

ซึ่งบางทีก็พบว่าเป็นปัญหาที่เกิดมาจากฝั่ง dev ไม่ใช่ DE แต่ DE ต้องหาวิธีแก้ปัญหาให้ business ทำงานต่อได้

คุณหน่องยกตัวอย่างเรื่องข้อมูลของหมวดหมู่สินค้าที่ใน database มีข้อมูลไม่ตอบโจทย์การทำ report ของฝั่ง business เช่น สินค้าที่เป็นโคมไฟ business คิดว่าควรอยู่ในประเภทเครื่องใช้ไฟฟ้า แต่ใน database ดันเก็บเป็นของใช้ในบ้าน พอได้รับปัญหามา DE ก็ต้องไปคุยกับ dev ขอให้แก้ไขข้อมูลที่ database แต่เมื่อไปคุยกับ dev แล้ว dev มองว่ากระทบหลายส่วนและเมื่อเทียบกับงานอื่นแล้วมีความสำคัญน้อยกว่าจึงไม่แก้ให้ในทันที

แต่ทาง business ก็รีบและต้องการข้อมูลที่ถูกต้องไปทำ report ทำให้ DE ต้องหา workaround เพื่อช่วยฝั่ง business โดยการสร้างข้อมูลชุดใหม่ที่ถูกต้องขึ้นมา

ปัญหาของ DE ต่อมาก็คือไม่อยากเป็น owner และคิดว่า business ควรเป็น owner ของข้อมูลชุดนี้ เพราะ business จะรู้ว่าสินค้าไหนควรอยู่หมวดหมู่ไหน แต่ DE ไม่มีความรู้ตรงนี้

DE ก็เลยใช้วิธีให้ business ใส่ข้อมูลใน google sheet แล้วให้ business เป็นคนดูแล google sheet นั้นเอง โดย DE แค่สร้าง pipeline ingest ข้อมูลจาก google sheet เข้ามาใน warehouse แล้วให้ business ไป map ข้อมูลที่ถูกต้องเอง

คุณหน่องสรุปว่าจริงๆแล้ว Soft skill เป็นสิ่งสำคัญสำหรับงาน DE ไม่ว่าจะเป็นการหา root cause ของปัญหาที่เกิดขึ้น การพูดต่อรองทั้งกับ dev และ business หรืออธิบาย solution ที่ DE คิดมาให้ business เข้าใจ และคุณหน่องคิดว่าการเข้าใจข้อมูลและความรู้ทาง business domain ก็เป็นส่วนสำคัญในการทำงาน DE

Networking

โดยปกติหลังจบ meetup session หลัก จะมีการพูดคุยเล่นกัน โดยครั้งนี้มีคนเปิดประเด็นระหว่าง meetup ว่า DE จำเป็นต้องรู้เรื่อง data governance ไหม? เลยคุยกันยาวๆเลยตั้งแต่เรื่อง data govenance, data mesh, data contract, data fabric, semantic layer และอีกมากมายที่เราไม่สามารถสรุปได้หมด คุยกันยาวจนถึง 4 ทุ่ม

จาก meetup และ networking ครั้งนี้ทำให้เราเห็นปัญหา ได้ความรู้และมุมมองจากหลายๆคนที่มาพูดคุยกันใน meetup ครั้งนี้

Data Clinic

ตอนนี้ทาง Data Engineer Thailand มีกิจกรรมที่ชื่อว่า Data Clinic ที่เปิดให้ทุกคนใน community มาร่วมแชร์ปัญหาที่เจอในสายงาน DE ไม่ว่าจะเป็นปัญหาทางด้าน technical หรือปัญหาอื่นๆที่เจอในระหว่างการเรียนรู้และการทำงาน แต่ไม่ถูกแก้ไขสักที โดยสามารถกรอกได้ในแบบฟอร์มนี้เลย

ส่วนรายละเอียดสามารถอ่านได้จาก FB post ในเพจ Data Engineer Thailand ค่ะ

---

สำหรับ Meetup ครั้งต่อไปและกิจกรรมอื่นๆสามารถติดตามได้ใน FB page : Data Engineer Thailand ค่ะ