เวลาที่มีคนมาปรึกษาว่าอยากจะลงมือสร้าง data pipeline จะเริ่มสร้างอย่างไร ส่วนใหญ่ผมมักจะชวนให้ลองทำ data pipeline แบบ minimal ขึ้นมาก่อน โดยการเขียน script ประมาณนี้
- ดึงข้อมูลอะไรก็ได้ที่ดูน่าสนใจจากอินเตอร์เนท หรือจากเว็บ Open Government Data of Thailand ออกมาเก็บอยู่ในฟอร์แมตสักฟอร์แมตหนึ่ง เช่น CSV
- จัดการทำความสะอาดข้อมูลสักเล็กน้อย เช่น คอลัมน์ปีเกิด อาจจะเก็บค่าปีเป็น พ.ศ. บ้าง ค.ศ. บ้าง เราก็แปลงให้เป็นปีแบบเดียวกัน หรือพวก timestamp ก็จัดฟอร์แมตให้เราเอาไปใช้ต่อได้ง่าย
- สร้างฐานข้อมูลขึ้นมาสัก 1 เครื่อง แล้วโหลดข้อมูลเข้าไป
- กำหนดให้ script ถูกรันทุกๆ วันตอนเที่ยงคืน หรือทุกๆ 5 นาทีก็ได้นะ
ที่ว่ามาด้านบนนี้คืออยากให้คนที่เพิ่งเริ่มต้นได้ feeling เบื้องต้นของสายงานด้าน data engineering เรียกได้ว่ามันคือการสร้าง data pipeline แบบ happy path เฉยๆ ทีนี้ถ้าเราจะต่อยอดไปจากนี้ แล้วสร้างให้ดีๆ เราจะเจอความท้าทาย 5 อย่างประมาณนี้ลองไปดูกัน
1. Schema เปลี่ยนแปลงอยู่ตลอด
อันนี้น่าจะเป็นปัญหาอันดับ 1 ที่ทุกคนต้องเจอ ยิ่งในยุคปัจจุบันที่โลกของซอฟต์แวร์นั้นเปลี่ยนแปลงไปเร็วมาก disrupt กันเป็นว่าเล่น ธุรกิจเราก็ evolve ตามไป และแน่นอนว่าจะส่งผลให้ schema ของข้อมูลนั้นเปลี่ยนแปลงไป เราก็ต้องปรับ data pipeline ของเราตาม
วิธีการก็มีอยู่หลายวิธีขึ้นอยู่กับสถานการณ์ เช่น ถ้าข้อมูลเราไม่เยอะเท่าไหร่ แล้วการวิเคราะห์ข้อมูลก็ไม่จำเป็นต้องเป็น real-time เราอาจจะ drop table ทิ้ง สร้างใหม่ แล้วโหลดข้อมูลตามไปก็ได้อยู่นะ แต่ถ้าข้อมูลเราเยอะมากขึ้น การทำแบบนี้ก็อาจจะเสียเวลาไปเป็นวันๆ เราก็ต้องหาวิธีอื่นมาแก้ปัญหา เป็นต้น
ระบบ monitoring กับ logging ดีๆ จะช่วยให้เรารู้ตัวได้ไว และการทำ schema version management ก็สามารถช่วยได้เช่นกัน 💪
2. Machine Failure เป็นเรื่องปกติ
งาน data pipeline ไม่ได้มีแค่ส่วนโค้ดที่เราต้องดูแล ยังมีเรื่องของ infrastructure ที่เราใช้อยู่ด้วย ระบบหรือตัวเครื่องเซิฟเวอร์ก็จะมีปัญหาประมาณว่า disk เต็ม เขียนไฟล์ไม่ได้บ้าง เครื่องค้างต้องรีสตาร์ท ระบบ network หรือ DNS ล่ม แล้วยังต้องอัพเกรด patch อีก สิ่งเหล่านี้เกิดขึ้นเป็นเรื่องปกติ 🤣 หาวิธีรับมือไว้เลยแต่เนิ่นๆ
3. การ Scale เพื่อรองรับข้อมูลที่มีขนาดใหญ่ขึ้นเรื่อยๆ
ช่วงแรกๆ ตอนที่มีข้อมูลน้อยๆ เราก็ happy ดีแหละ data pipeline อาจจะใช้เวลาไม่ถึง 10 นาทีก็ทำงานเสร็จ 😊 แต่หลายๆ คน รวมถึงตัว business เอง เรื่องการ scale ตัว data pipeline อาจจะไม่ใช่ priority ขององค์กร เลยไม่ได้นึกถึงเรื่องการ scale เท่าไหร่ ตรงนี้ผมมองว่ามันจะเป็นหลุมพลาง (pitfall) เนื่องจากข้อมูลที่ไหลเข้ามา และเพิ่มขึ้นเรื่อยๆ การทำงานของ data pipeline ก็จะใช้เวลานานขึ้นเรื่อยๆ เช่นกัน ยังไม่จบแค่นั้น.. แต่ละองค์กรก็คงไม่ได้มีแค่ pipeline เดียวแน่ ยิ่งปล่อยทิ้งไว้มันก็ยิ่งเหมือน technical debt ที่สะสม ไปจนวันหนึ่งเราจะไม่สามารถแก้มันได้อีกแล้ว เพราะ cost ของ effort ที่จะลงแรงไปปรับปรุงให้ดีขึ้นมันสูงเกินไป
ดังนั้นให้นึกถึงการ scale เอาไว้ด้วยเลย ยิ่งองค์กรไหนมีข้อมูลเยอะอยู่แล้ว เรื่องการ scale เป็นเรื่องที่สำคัญมาก ตรงนี้จะรวมไปถึงการเลือก technology ที่เหมาะสมมาใช้ด้วยเช่นกัน ใช้แค่ script อย่างที่กล่าวไว้ตอนต้นอย่างเดียวคงจะไม่พอล่ะ
4. Batch vs. Real-Time
เรื่องนี้ก็ตาม business เลย ขึ้นอยู่กับ context ของแต่ละที่ และแต่ละงาน ถึงแม้ว่าตลาดส่วนใหญ่จะเป็นเรื่อง batch processing แต่ก็อยากให้ระลึกไว้เสมอไว้ว่างานในหลายๆ ที่มีแบบ real-time processing เข้ามาแล้ว การทำ data pipeline แบบ batch กับแบบ real-time ก็มีการพัฒนาและการดูแลที่แตกต่างกัน พวกเราชาว data engineer ควรที่จะศึกษาและลองเล่นไว้ทั้ง 2 แบบนะ 🤓
5. การทำ Data Catalog และ Data Lineage
หัวข้อนี้มีความเกี่ยวข้องกับการทำ data lake ด้วยนะ ซึ่งหลายคนมักจะมองข้าม เอาไว้ทำทีหลังก็ได้ แล้วสุดท้ายก็จะลืม.. หรือไม่ก็เกิดอาการ curse of knowledge ของคนทำข้อมูล ที่ว่ามองแว๊บเดียวก็รู้ว่าอะไรคืออะไร อย่าไปตกหลุมพลางเข้าล่ะ ระลึกไว้เสมอเลยว่าเราไม่ได้ทำงานคนเดียว 🙂
ก็อยากจะมาเขียนย้ำครับว่าให้นึกถึงการทำ data catalog (เก็บ metadata ไว้เพื่อให้ค้นหาข้อมูลได้สะดวกและรวดเร็ว) กับ data lineage (รู้ที่มาที่ไปของข้อมูลว่ามาจากไหน ได้มาได้อย่างไร โดน transform มาแบบไหน) ด้วย
สรุปช่วงท้าย
ที่เขียนไว้ด้านบนน่าจะเป็นความท้าทายที่คนทำงานทางด้านข้อมูล โดยเฉพาะสายงาน data engineer 👷🏻♀️👷🏻♂️ น่าจะต้องเจอกัน งานสร้าง data pipeline ให้ดีๆ ก็จะมีหลายอย่างที่ต้องคิด แล้วก็จะมีอีกหลายอย่างที่เราอาจจะต้องไปเจอหน้างาน แล้วแก้ไปตาม context ณ ตอนนั้นด้วย 😅
คนที่แวะเข้ามาได้เจอความท้าทายอะไรกันบ้างเอ่ย? เล่าให้อ่านกันได้นะ 😘
ปล. ขอบคุณรูป cover สวยๆ จาก JJ Ying
Top comments (5)
ดู 4 ข้อแรกแล้ว น่าสนใจครับ มีข้อสงสัยเล็กน้อย
ถ้าเรามี job ไม่ได้เยอะเท่าไหร่ก็จะ host กันไว้ที่เครื่องนั้นๆ เลยครับ แต่ส่วนใหญ่จะเป็นแยกเครื่องออกมาสัก 1 เครื่อง แต่จะเริ่มมีปัญหาตอนที่มี job มากขึ้นเรื่อยๆ แล้วมี dependency เกิดขึ้นระหว่าง job ตรงนี้เอา technology อื่น อย่างเช่น Airflow เข้ามาใช้น่าจะช่วยแก้ปัญหาได้ครับผม
มีค่าใช้จ่ายครับ ถ้าอยากใช้ฟรี ตอนนี้ผมนึกออกแค่ Heroku Scheduler
ถ้าใช้พวก cloud provider ก็อาจจะไม่ค่อยบ่อยได้ครับ 3 วันครั้งก็พอไหวอยู่ หรืออาทิตย์ละครั้ง แล้วค่อยๆ ปรับเอา แต่ถ้า host เองผมว่าช่วงแรกน่าจะบ่อยหน่อยครับ
ถ้าไปใช้ data warehouse แล้ว จะไปท่า distributed ซะเป็นส่วนใหญ่ครับ (ขนาดของข้อมูลใหญ่พอประมาณ ช่วยเรื่องประมวลผล แล้วก็กัน single point of failure) เรื่อง host นี่ไป host ที่ cloud provider ดีแล้วใช้เป็น managed service ครับ จะลดความปวดหัวไปได้เยอะ
นิยม NoSQL ครับ cost ต่ำสุดทำเป็น JSON แล้วจัดการเองอาจจะพอได้อยู่ครับ ผมเห็นส่วนใหญ่เค้าจะใช้ Apache Avro หรือไม่ก็ Protobuf ครับ ปกติผมจะเขียน script ง่ายๆ เช็ค column ถ้าเจอการเปลี่ยนแปลงก็แจ้งเตือนไรงี้ แต่ถ้าเป็นแนว Kafka ก็ใช้ schema registry ของมันเอง (Avro)
อันนี้ตอบลำบากเลยครับ เป็นแชร์ประสบการณ์ดีกว่า ผมอยู่ในสถานการณ์ที่ต้องคิดเรื่องนี้ คุยเรื่องนี้กับ business อยู่บ่อยๆ ส่วนใหญ่จะลงเอยด้วยปรับเป็น low priority เรื่องนี้ค่อนข้างยากถ้าฝั่ง business ไม่เข้าใจเรื่องพวกนี้ การคุยเรื่องพวกนี้ที่ผ่านมาถ้าผมอธิบายเริ่มจาก data pipeline ขึ้นไป drive business ก็ไม่ค่อย work เท่าไหร่ แต่ถ้าพูดคุยเรื่อง business โดยตรงเลย แล้วค่อยพูดถึง data ที่จำเป็นต้องมี ก็จะคุยง่ายขึ้น ทีนี้ก็จะคิดเรื่อง profit คิดเรื่อง cost กันต่อได้ครับ
ที่ผมคิด cost คร่าวๆ ก็ประมาณ technology อะไร? ใช้คนประมาณกี่คน? มี timeline เป็นอย่างไร นานแค่ไหน ถึงจุดไหนที่จะเริ่มเห็น data ไหลเข้ามา แล้วเค้าเริ่มเอาไปตั้งคำถามได้ จุดที่จะ turn to profit สำหรับผมคิดเมื่อ business ได้รู้อะไรใหม่ๆ จากข้อมูลที่ไหลเข้ามาครับ
ไม่แน่ใจว่าตอบคำถามบ้างไหม >_< ร่วมพูดคุยกันต่อได้นะครับ ขอบคุณครับบ~
ถ้าเป็น platform ของ google cloud สำหรับ data lineage มี service ไหนแนะนำไหมครับ
ของ GCP น่าจะชื่อ Cloud Data Fusion ครับ แต่ผมไม่เคยใช้นะ >_<
ส่วนถ้า open source ที่ผมรู้จักก็จะมี
เคยพยายามจะเซต Amundsen มาใช้ แต่ยังไม่ประสบความสำเร็จครับ ตอนนี้เลยใช้ Airflow เป็นหลัก ดูภาพรวมจาก ตัว DAG แล้วก็คอยอัพเดท metadata ต่างๆ พยายามทำ doc ให้เคลียร์ๆ ครับตอนนี้
ขอบคุณมากเลยครับ