Data Pipelines
รูปแบบในการสร้าง Data Pipeline
มีรูปแบบ ETL และ ELT ซึ่งทั้ง 2 patterns นี้ใช้กันอย่างกว้างขวางมากที่สุด ความแตกต่างของทั้ง 2 แบบ อยู่ที่ลำดับของตัวอักษร 2 ตัวหลัง (Transform กับ Load)
- Extract (E) การดึงข้อมูลจากแหล่งข้อมูลต่างๆ
- Load (L) การโหลดข้อมูล ไม่ว่าจะเป็นข้อมูลดิบ หรือข้อมูลที่ถูกแปลงแล้ว ไปที่ปลายทาง เช่น Data Warehouse หรือ Data Lake หรือระบบอื่นๆ
- Transform (T) เป็นการแปลงข้อมูลดิบจากแหล่งข้อมูลต่างๆ หรือจากระบบต่างๆ ให้มาอยู่ในรูปแบบที่เราสามารถเอาไปวิเคราะห์ได้ หรือเอาไปทำ Visualization ได้
ขั้นตอน E กับ L อาจจะเรียกรวมๆ ได้เป็น Data Ingestion เพราะว่าดูแล้วมีอะไรที่คล้ายๆ กัน และมีความสามารถเหมือนๆ กันอยู่ แต่อย่างไรก็ดี ตอนที่เราออกแบบ Data Pipeline เราควรที่จะแยกออกจากกันดีกว่า เพราะว่าความซับซ้อนของ E กับ L ต่างกัน
ความท้าทายในการสร้าง Data Pipeline ที่ดี
ตอนที่เราสร้าง Data Pipeline เรามักจะเจอความท้าทายหลักๆ ประมาณ 5 อย่างนี้
- Schema เปลี่ยนแปลงอยู่ตลอดเวลา
- Machine Failure เป็นเรื่องปกติ
- การ Scale เพื่อรองรับข้อมูลที่มีขนาดใหญ่ขึ้นเรื่อยๆ
- Batch vs. Real-Time
- การทำ Data Catalog และ Data Lineage
1. Schema เปลี่ยนแปลงอยู่ตลอด
แทบจะเป็นปัญหาอันดับ 1 เลยที่ทุกคนต้องเจอ ยิ่งในยุคปัจจุบันที่โลกของซอฟต์แวร์นั้นเปลี่ยนแปลงไปเร็วมาก ธุรกิจเราก็ปรับตัวตามไปด้วย และแน่นอนว่าจะส่งผลให้ Schema ของข้อมูลนั้นเปลี่ยนไป เราก็ต้องปรับ Data Pipeline ของเราตาม
วิธีการก็มีอยู่หลายวิธีขึ้นอยู่กับสถานการณ์ เช่น ถ้าข้อมูลเราไม่เยอะเท่าไหร่ แล้วการวิเคราะห์ข้อมูลก็ไม่จำเป็นต้องเป็น Real-Time เราอาจจะ Drop Table ทิ้ง สร้างใหม่ แล้วโหลดข้อมูลตามไป แต่ถ้าข้อมูลเราเยอะมากขึ้น การทำแบบนี้ก็อาจจะเสียเวลาไปเป็นวันๆ เราก็ต้องหาวิธีอื่นมาแก้ปัญหาให้เหมาะสมกับสถานการณ์
ระบบ Monitoring กับ Logging ดีๆ จะช่วยให้เรารู้ตัวได้ไว และการทำ Schema Version Management ก็สามารถช่วยได้เช่นกัน
2. Machine Failure เป็นเรื่องปกติ
งาน Data Pipeline ไม่ได้มีแค่ส่วนโค้ดที่เราต้องดูแล ยังมีเรื่องของ Infrastructure ที่เราใช้อีกด้วย ระบบหรือตัวเครื่องเซิฟเวอร์ มักจะมีปัญหาประมาณว่า Disk เต็ม ทำให้เขียนไฟล์ไม่ได้บ้าง หรือเครื่องค้างต้องรีสตาร์ท รวมไปถึง การที่ระบบ Network หรือ DNS ล่ม แล้วยังต้องมาคอยอัพเกรด Patch อีก (โดยเฉพาะ Security Patch) ซึ่งสิ่งเหล่านี้เกิดขึ้นเป็นเรื่องปกติ เราหาวิธีรับมือไว้เลยแต่เนิ่นๆ เลย
3. การ Scale เพื่อรองรับข้อมูลที่มีขนาดใหญ่ขึ้นเรื่อยๆ
ช่วงแรกๆ ตอนที่มีข้อมูลน้อยๆ Data Pipeline อาจจะใช้เวลาไม่ถึง 10 นาทีก็ทำงานเสร็จแล้ว พอทำเสร็จ เราก็อาจจะไม่ได้เข้ามาดูแลสักเท่าไหร่ แต่นั้นอาจจะเป็นหลุมพราง (Pitfall) ของหลายๆ คน เนื่องจากข้อมูลจะไหลเข้ามาเรื่อยๆ อยู่ตลอดเวลาอยู่แล้ว Data Pipeline ของเราก็จะใช้เวลานานขึ้นเรื่อยๆ เช่นกัน แล้วแต่ละองค์กรก็คงไม่ได้มีแค่ Data Pipeline เดียวแน่ ดังนั้นให้นึกถึงการ Scale เอาไว้ด้วยเลย ตั้งแต่เนิ่นๆ ยิ่งองค์กรไหนมีข้อมูลเยอะอยู่แล้ว เรื่องการ Scale เป็นเรื่องที่สำคัญมาก ตรงนี้จะรวมไปถึงการเลือก Technology ที่เหมาะสมมาใช้ด้วยเช่นกัน
อยากเน้นย้ำเพิ่มเติมว่าให้คิดไว้ตั้งแต่ช่วงแรกๆ เพราะถ้าเรายิ่งปล่อยทิ้งไว้มันก็ยิ่งเหมือน Technical Debt ที่สะสม ไปเรื่อยๆ จนวันหนึ่งเราจะไม่สามารถแก้มันได้อีกแล้ว เพราะค่าใช้จ่ายที่จะลงแรงไปปรับปรุงให้ดีขึ้นมันสูงเกินไป
4. Batch vs. Real-Time
การเลือกว่าจะเป็นการประมวลผลแบบ Batch หรือ Real-Time ให้ลองทำความเข้าใจธุรกิจ และ Use Case ต่างๆ ก่อน ตรงนี้จะขึ้นอยู่กับบริบทของแต่ละองค์กร และแต่ละงาน ถึงแม้ว่าตลาดส่วนใหญ่จะเป็นเรื่องการประมวลผลแบบ Batch แต่ก็อยากให้ระลึกไว้เสมอไว้ว่า งานประเภท Real-Time ก็สามารถสร้างคุณค่าให้กับองค์กรได้เช่นกัน และการสร้าง 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 Pipeline ควรโหลดข้อมูลมาเก็บลง Storage หรือ Data Lake ก่อน?
เป็นคำถามที่ได้ยินอยู่บ่อยๆ ว่าตอนที่สร้าง Data Pipeline ขึ้นมา เราควรที่จะเก็บข้อมูลลงไว้ที่ Storage สักที่หนึ่ง หรือเก็บลง Data Lake ก่อน?
แน่นอนว่าตอนที่เราเขียนโค้ดสร้าง Data Pipeline ขึ้นมานั้น จังหวะที่เราดึงข้อมูลมา ไม่ว่าจะทั้งทาง API หรือจากทาง Database ต้นทาง เราสามารถที่จะปรับเปลี่ยน หรือทำ Transform รูปแบบกับข้อมูลนั้นๆ ได้เลย พอเสร็จแล้วก็โหลดเข้าไปเก็บไว้ที่ Database ปลายทาง หรือ Data Warehouse เลยก็ได้ ในแง่ประสิทธิภาพ เราจะได้เรื่องความเร็ว เพราะว่าเราไม่ต้องมาเขียนลงไฟล์ และอ่านจากไฟล์ขึ้นมาอีก ทำไมเราถึงควรโหลดข้อมูลมาเก็บลง Storage หรือ Data Lake ก่อน?
มีอยู่ 2 เหตุผลหลักๆ
ในหลายๆ ครั้งที่เราโหลดข้อมูลมาใช้งาน มักจะมีคนอื่น หรือระบบอื่นมาร่วมใช้งานด้วย ดังนั้นการที่เราเอามาเก็บไว้ที่ Storage หรือ Data Lake ก่อน ทำให้เราสามารถที่จะแชร์ให้กับคนอื่น หรือระบบอื่นเข้ามาหยิบข้อมูลไปใช้งานได้ และเราก็สามารถนำข้อมูลนี้ไปใช้ซ้ำในงานอื่นๆ ได้อีกด้วย โดยไม่จำเป็นต้องไปโหลดข้อมูลมาใหม่จากต้นทาง
หรือการที่เรานำข้อมูลไปทำ Transformation แล้ว คนอื่นอยากจะมาขอหยิบไปใช้งาน ก็สามารถมาหยิบได้ที่ Storage หรือ Data Lake ของเราได้เลย ไม่ต้องไปทำ Transformation เอง
ซึ่งข้อนี้ก็เป็นจุดเริ่มต้นของเราที่จะทำเรื่อง Data Democratization ในองค์กรให้เกิดขึ้นได้อีกด้วย 👍
ข้อนี้เป็นข้อที่สำคัญมากคือ เราอยากที่จะทำให้ Data Pipeline ของเราสามารถทำซ้ำได้ (Reproducible) เนื่องจากว่าเราอาจจะไม่สามารถปักใจเชื่อได้ว่าระบบต้นทางที่เราไปดึงมา ไม่ว่าจะเป็นหน้าเว็บที่เรา Scrape ข้อมูลมา หรือจะเป็น API ที่เราเขียนโค้ดไปดึงข้อมูลมา จะไม่มีอะไรเปลี่ยนแปลง และจะคงอยู่กับเราตลอดไป ยิ่งถ้า API ที่ไม่มีให้เราเลือก Date Range ได้เนี่ย 😅 ยิ่งมีความจำเป็นที่เราจะต้องเอาข้อมูลมาเก็บไว้ในการดึงแต่ละครั้ง
ดังนั้นการที่เราเก็บข้อมูลเอาไว้ที่ Storage หรือ Data Lake ก่อน เป็นการทำให้เรามั่นใจได้ว่าข้อมูลที่เราดึงมาเก็บ จะอยู่กับเราและเราสามารถหยิบเอาไปใช้เมื่อไหร่ก็ได้ตามที่เราต้องการ จะเอาข้อมูลย้อนหลังมาประมวลผลใหม่อีกรอบก็ได้! 🤩
โดยข้อมูลที่เราเก็บควรจะเป็น Copy จากแหล่งข้อมูลต้นทางเลย (หรือเรียกว่า Raw Data) ซึ่งตรงนี้ก็จะส่งผลให้ Data Pipeline อื่นๆ ที่มาหยิบข้อมูลนี้เอาไป Transform ก็จะมีคุณสมบัติ Reproducible ได้