Journey of TILDI Data Engineer in 2023 — การพัฒนา Data Platform อย่างต่อเนื่อง
ในปีที่แล้วเราได้อธิบายว่า Data Engineer ในทีม TILDI ทำอะไรบ้าง ทั้งด้าน tech stack, เครื่องมือที่เราใช้, security และอธิบายถึงคอนเซปต่างๆใน Data Platform ไม่ว่าจะเป็น Data Observability, Data Validation/ Data Quality, Data Monitoring, Data Lineage และ Data Discovery/ Catalog ที่ช่วยให้คนดึงข้อมูลและคนใช้ข้อมูลเองมั่นใจในตัวเนื้อข้อมูลและใช้งานอย่างมีประสิทธิภาพ
There’s always a room for improvement
เรามาดูกันว่าปีนี้ มีอะไรบ้าง โดยขอแบ่งออกเป็น 4 หัวข้อใหญ่ๆ
- Data and Pipeline related feature
- Practice improvement
- Cost and Resource Optimization
- Analytics Engineer
💡 คำแนะนำ: วิธีการอ่านแบบมีประสิทธิภาพคืออ่านบทความนี้เสร็จแล้วจึงกดเข้าบทความย่อยที่แนบลิ้งค์ให้ ไม่งั้นจะยาวมากๆ
Data and Pipeline related feature
พาร์ทนี้จะเป็นส่วนที่ช่วยให้เราดู overall ของการ deliver ด้าน data และการทำงานของ pipeline
1. Auto Recovery
อย่างที่ทุกคนทราบว่าเราใช้ Airflow เป็น orchestrator ในการควบคุม pipeline ต่างๆ โดยที่เรา install, host และ maintain เองบน Kubernetes
ดังนั้น Airflow นั้นเปรียบเสมือนหัวใจหลักของเรา หากวันใดวันหนึ่ง pipeline failed ขึ้นมา เราต้องรีบเข้ามาปั๊มหัวใจแก้ไขเพื่อให้ pipeline ทำงานได้ดังเดิม เพื่อยังคงส่งมอบข้อมูลให้กับ end-user ได้
เบื้องต้นเองเราก็มี on-call duty ที่ผลัดกันช่วยดูแลและ monitor Airflow ซึ่งหลายครั้งสิ่งที่เราเจอ กลับพบว่าช่วงเข้าไปเช็ค pipeline ที่ fail ตอน on-call นั้น สาเหตุเกิดจาก Resource ช่วง process ไม่พอบ้าง บางครั้ง Kubernetes pod แย่งกันทำงาน หรือบาง service down ไปชั่วขณะ ซึ่งสาเหตุนั้นเกิดจาก infrastructure มากกว่าจะเป็น data issues ด้วยซ้ำ
solution เบื้องต้นจึงกลับหายแค่เพียงการ rerun ตัว process task อีกรอบ เพื่อให้ process task รีเซ็ตการใช้ infrastructure ใหม่ แล้ว pipeline ก็กลับมาเขียวอีกครั้ง
เราจึงหาทางออกเพื่อไม่ให้ on-call ต้อง waste time เพื่อมานั่งกด restart แบบ manual :D เอาเวลาไปทำอย่างอื่นกันดีกว่า ฟีเจอร์นี้เราจึงเรียกว่า
Auto-Recovery
Auto-recovery จะใช้จากการต่อยอดของ callback ตัว [on_failure_callback] โดยหากมี task failed ขึ้นมา Auto-recovery จะพยายาม re-trigger airflow task นั้นอีกครั้งแบบในระยะเวลาหนึ่งถัดมา
Auto Recovery Dashboard
แน่นอนว่าเราก็อยากรู้ว่าส่วนใหญ่แล้วสาเหตุการตายของ task มีอะไรบ้าง หรือผลลัพท์ของ Auto-recovery ที่ช่วยเราไม่ให้ต้องเหนื่อยช่วยได้มากเพียงใด เราจึงเก็บ stats ต่างๆที่ track จาก Auto-recovery และสร้างออกมาเป็น dashboard
ในระยะเวลาเพียง 5 เดือน pipeline run ทั้งหมดที่ failed มีจำนวน 595 แต่ถูก auto-recovery ช่วย trigger ใหม่จนสำเร็จถึง 467 pipeline run คิดเป็น 78.49% นับว่าเป็นตัวเลขที่น่าพอใจทีเดียว หมายความว่ามัน save เวลาเราได้ระดับหนึ่ง เพื่อเอาเวลาไปใช้กับ 21% ที่ตายเพราะสาเหตุอื่นๆที่ critical มากกว่า
อย่างไรก็ตาม Auto-recovery ยังอยู่ในเฟสแรกๆของการ implement และยังต้องพัฒนาอีกเรื่อยๆ
2. Data Downtime Monitoring
💡 Data downtime refers to the period during which an organization’s access to critical data is disrupted or unavailable. — Atlan
ในขณะที่ Auto-recovery ช่วยชีวิตชาว data engineer ในการช่วยฟื้น pipeline แล้ว ขณะเดียวกันเราก็มี Data Downtime ที่ช่วย confirm เรื่องระยะเวลาที่เราไม่สามารถ deliver ข้อมูลถึง end-user
เพราะแน่นอนว่า pipeline ที่ failed ไป ก็จะทำให้เกิด delay ในการส่งข้อมูล เราเองก็อยากรู้เช่นกันว่ามันใช้เวลานานเท่าไรในแต่ละ incident ที่เกิดขึ้น ซึ่งเราจะเก็บข้อมูลจาก OpsGenie เพื่อดูระยะเวลาก่อน-หลัง acknowledge incident จนซ่อมและ close incident นั้นๆไปด้วย
คอนเซปและการคำนวน Data Downtime นั้น ทุกคนสามารถศึกษาจากบทความนี้แบบละเอียดได้เลย
บทความเรื่อง Data Downtime Monitoring โดย Watcharee Skr:
3. Data Reconciliation
💡 Data Reconciliation is a process that involves comparing and matching data from different sources, such as databases, files, or systems, to identify discrepancies, resolve conflicts, and ensure consistency and accuracy. — Dremio
เมื่อเราทำ pipeline เสร็จสิ้นและปล่อยรันเพื่อส่งข้อมูลถึง data users ตัวเราเองจะมั่นใจได้ยังไงว่าการ logic ดึงข้อมูลของเราถูกต้องครบถ้วน แม้ว่าจะมั่นใจจากการทดสอบช่วงแรกแล้ว ในเวลาผ่านไปก็มีโอกาสที่ data source ต้นทางมีการปรับเปลี่ยน logic หรือแม้แต่ bug ที่เราวางไว้โดยไม่รู้ตัว 😕
Data Reconciliation เป็นอีกหนึ่ง process ที่เราเพิ่มเข้ามาเพื่อรักษา Data Quality เทียบข้อมูลจาก Source และ pipeline ด้วยกันและส่ง output เพื่อดูว่าสิ่งที่แตกต่างมีเช่นไรบ้าง แล้ว alert หา Data Engineer
ตรงนี้คนที่ได้ประโยชน์ไปเต็มๆคือทุกคนที่เกี่ยวข้องกับ pipeline ตั้งแต่ต้นน้ำยันปลายน้ำเลย
4. Improving PySpark
💡 ในปี 2021–2022 เราสร้าง DP-PySpark ที่เป็น PySpark ที่เราสร้างขึ้นมาแบบ customly เป็น template ในการ process ดาต้าที่ทำให้เราสามารถลดเวลาการเขียนโค้ดและสร้างมาตรฐานให้การ process ข้อมูลอย่างเป็น modularity และทำให้เรา debug สิ่งต่างๆได้อย่างรวดเร็ว
แน่นอนว่าปีนี้เราพัฒนาเครื่องมือเราให้แข็งแกร่งและเพื่อรองรับหลาย usecase มากขึ้น อาทิเช่น
- เพิ่ม Iceberg เป็นอีกประเภทของ Data Lakehouse
ซึ่งแต่เดิมเราใช้ Hudi แต่เนื่องจากเราพบว่า Hudi ไม่รองรับ usecase ของเราหลายอย่าง เช่น
- ส่วนใหญ่ pipeline เราจะเป็น batch ซึ่ง hudi จะเหมาะกับ streaming ingestion
- การ rerun pipeline จึงสร้างความปวดหัวกับเราไม่น้อย เราจึงหยิบ Iceberg ที่ค่อนข้างชูข้อดีเรื่อง concurrent write > 1 และ engine หลายๆเจ้าอย่าง Spark, Flink, Presto, Hive ก็สามารถต่อ Iceberg ได้พร้อมๆกัน
สามารถอ่านบทความ What is Apache Iceberg: Iceberg คืออะไร ทำอะไรได้บ้าง ?
2. เพิ่มความสามารถให้ PySpark อ่านจาก BigQuery โดยตรง
สามารถอ่านรายละเอียดได้ บทความเรื่อง PySpark to read data from BigQuery โดย Nitit Taepant
Practice Improvement
ปี 2023 นับว่าเป็นปีที่เรารับสมาชิก Data Engineer มากขึ้นชนิดที่ว่าตั้งทีมฟุตบอลได้
ซึ่งหมายความว่าเมื่อสมาชิกเพิ่ม — ความท้าทายคือจะทำยังไงให้เรายังคงรักษาความเร็วการวิ่งให้ดีเท่าเดิมหรือวิ่งให้เร็วขึ้นซะด้วยซ้ำ ดังนั้นเราจำเป็นต้องปรับปรุง collaboration และ integration ร่วมกัน รวมถึง knowledge sharing ด้วย
1. Dag Document
เมื่อสมาชิกเพิ่มขึ้น เราสามารถ deliver domain data มากขึ้น จำนวน pipeline ใหม่จึงมีมากขึ้นเช่นกัน
ยิ่งมีมากขึ้น ทำให้เราถือ knowledge ต่างๆมากขึ้นไปด้วย ต้องเข้าใจทั้งเนื้อ data และการทำงานของ pipeline
ดังนั้นเพื่อสร้าง context ให้กับทุกคนในทีม เราจึงใช้ฟีเจอร์ Dag Doc ของ Airflow เพื่ออธิบายการทำงานของ pipeline แบบละเอียดที่ให้มากกว่า code และตอบด้าน business requirement มากขึ้น
เช่น สมมติว่า pipeline task ตรงส่วน transform ข้อมูล failed ขึ้นมา เราจะค่อยๆ debug ได้อย่างรวดเร็วว่า table ที่ failed เป็น type อะไร เป็น hudi หรือ parquet, เป็น master table หรือ transaction table, มี zone อะไรบ้าง ในแง่ของ communication เช่น data source ต้นทางส่งข้อมูลผิด เราต้องการรู้ที่มาของข้อมูล สามารถติดต่อใครบ้าง ใครเป็น PM ในเคสที่ต้องประสานงาน, ใครเป็น DA หรือ end-user ในแง่ผู้ที่ได้ผลกระทบ
และสุดท้ายในแง่ของการซ่อม pipeline เราก็มีส่วน troubleshooting ที่คนสร้าง pipeline จะให้ trick เบื้องต้นมา
แน่นอนว่าข้อดีอีกอย่างของฟีเจอร์ dag doc คือมันเป็น markdown ที่ต้องเก็บใน dags code ของ airflow เช่นกัน ทำให้ track และ versioning ได้
2. Chaos Engineering
💡 Chaos Engineering is the discipline of experimenting on a system in order to build confidence in the system’s capability to withstand turbulent conditions in production.
เนื่องจากเรา initiate และ maintain หลาย service ไม่ว่าจะเป็น Airflow, Kafka, Airbyte, DataHub, Spark, Trino, Kubernetes Cluster ทั้ง network, storage และ database
ความท้าทายของเราคือจะสร้างความมั่นใจในระบบและ service ของเราได้ยังไงเมื่อมี ‘chaos’ เกิดขึ้นจริงๆ
ดังนั้นทีมจึงพยายามยึดเหนี่ยว discipline นี้ ในหลายด้าน
- Infrastructure as Code
- Network as Code
- Policy as Code
- Configuration as Code
- Security as Code
Refactor existing config, yaml ต่างๆเข้าไปใน Terraform, encrypt sensitive config ผ่าน blackbox, และลบ dead code ออก
ทั้งนี้เราพยายามกระจายความรู้ infra โดยคายตะขาบรายคนเป็นทอดๆ เพื่อมั่นใจว่าทุกคนได้ on-the-job training จริงๆ
3. GitFlow workflow
สมัยแรกของ Data Platform เรามีเพียงสมาชิกแค่ 3 คน ดังนั้นการ release หรือ code review จึงทำไปด้วยง่าย แต่เมื่อเวลาผ่านไปจาก 3 คนเป็น 5, 7, 9, 13 จนกระทั่ง 15 คน
จึงสมควรแก่เวลาในการทำ code integration ที่เป็น global standard มากขึ้น
เราจึง apply เรื่อง GitFlow workflow เข้ามาเพื่อควบคุม release ให้ดีขึ้นและปรับ steps การ code review เพื่อสอดคล้องการ pace ที่มีอยู่
Cost and Resource Optimization
1. FinOps for BigQuery Cost Optimization
💡 “FinOps is an evolving cloud financial management discipline and cultural practice that enables organizations to get maximum business value by helping engineering, finance, technology and business teams to collaborate on data-driven spending decisions.” — FinOps Foundation
FinOps คือ practice หนึ่งที่ทำให้คนในทีมสามารถจัดการเรื่อง cost ที่เกิดขึ้นได้ โดยเฉพาะ cost ที่เกิดขึ้นบน cloud
โดยผลลัพท์ที่ทำให้เห็นชัดของ FinOps คือ การนำข้อมูลเรื่อง spending มาดู เช่น ดูว่าที่ผ่านมาโปรเจคนี้มีค่าใช้จ่ายประมาณเท่าไร ทำไมอยู่ๆ cost ก็พุ่งขึ้นมานะ นี่ยังปกติอยู่รึเปล่า
หรือบางโปรเจคที่มีการ query เยอะ เราสามารถจัดสรรการซื้อ service อีกแพคเกจดีไหมเพื่อราคาที่ถูกลงในระยะยาว ทั้งนี้การนำข้อมูลมาดูก็เพื่อ control, optimize, predict ผลที่เกิดเพื่อสร้างผลลัพท์ที่ดีกว่าการปล่อย waste money ไปเฉยๆ
FinOps นับว่าเป็นหัวข้อมหากาพย์มากๆ ซึ่งพาร์ทที่เราพยายาม optimize กันคือ BigQuery ที่ถูกใช้งานมากที่สุดเนื่องจากการใช้ด้านทำ insights และ visualization
Journey นี้ถูกแบ่งออกเป็น 2 phases
เฟสแรก เราพยายามทำ pipeline เพื่อเก็บข้อมูล usage มาดูรายวัน เพื่อดู cost การใช้งาน query แบบในหลายมุมมอง ทำให้เห็น cost ที่ตั้งใจและไม่ได้ตั้งใจ ซึ่งเราก็มี save ไปได้บางส่วน
ในเฟสถัดมาเรามีการปรับปรุง
- ดึงข้อมูลการใช้งาน BigQuery จาก Cloud logging แทนเพื่อให้ข้อมูล accurate มากขึ้น
- ทำ Budget Alert ซึ่งเป็นการทำงานร่วมกันทั้ง Data user, Project Owner, และ System owner ซึ่ง role ของเราคือไปช่วยเซ็ต flow ของ alert นี้
บทความ FinOps แบบเล่าละเอียดตั้งแต่ concept ยัน technical issue และ solution
2. Platform monitoring
อย่างที่กล่าวไปว่าเรามี services หลายส่วนที่ต้อง maintain เองบน Kubernetes ดังนั้นเราจึงมี Dashboard ที่คอยช่วย monitor โดยเราเลือก Grafana เพื่อทำ resource usage ต่างๆ CPU, Memory, Disk, Pod usage เป็นต้น รวมถึงทำ threshold alert ในบาง metrics
นอกจากนี้เรามี Resource Efficiency Dashboard เพื่อช่วย monitor ในพาร์ทของ cost กับ resource ต่างๆในระดับที่ลึกกว่า Cloud Billing ของ GCP
3. Add Trino for Query Engine
ก่อนหน้านี้เราใช้ BigQuery เป็น Query Engine สำหรับปั้น data model เป็นหลัก แต่กลับ challenge คือในบางโปรเจคต้อง query ในข้อมูลที่ปริมาณมากถึงหลายร้อยล้าน records ซึ่งเป็นส่งผลให้ cost เยอะเช่นกัน
เราเลยหา alternative choice เพื่อ support use case แบบนี้โดยการใช้น้องกระต่าย Trino ที่เป็น open-source query engine
Analytics Engineer
การเติบโตในปี 2023 ส่วนหนึ่งนั้นคือเราเปิดรับตำแหน่ง Analytics Engineer ขอหยิบยกนิยาม Analytics Engineer สั้นๆ จากบทความ ‘Analytics Engineer คือใคร ทำหน้าที่อะไรบ้าง’
Analytics Engineer คือ คนในทีม Data ที่คอยจัดการข้อมูลในองค์กรให้พร้อม สำหรับ Business User (BU) นำไปใช้วิเคราะห์ข้อมูลต่อได้ทันที โดยที่ BU ไม่ต้องมีขั้นตอนการเตรียมข้อมูลอีกรอบ เป็นผู้ที่มีความรู้ความเข้าใจในธุรกิจเป็นอย่างดี (Businees Domain Expert) โดยตำแหน่งจะมีความเป็น กึ่ง Data Engineer กึ่ง Data Analyst อยู่ในคนๆเดียวกัน
Analytics Engineer ทำหน้าที่ สร้าง Data Model, ตรวจสอบคุณภาพของข้อมูล และจัดทำเอกสารที่เกี่ยวกับข้อมูล โดยจะเข้ามาคั้นกลางระหว่าง DE และ DA ในขณะที่ Data Engineer สามารถโฟกัสในเรื่องเวลาโฟกัสกับเรื่อง Infrastructure, Performance มากขึ้น และ ทำให้ DA มีเวลาโฟกัสกับเรื่อง Analysis, Insight มากขึ้น
สำหรับพวกเราแล้ว Analytics Engineer จึงมีส่วนช่วยเติมเต็มหมวกขา business และความเข้าใจเรื่องข้อมูลให้กับ Data Engineer จนในท้ายสุดจึงสามารถ design pipeline กันได้อย่างประสิทธิภาพและเหมาะสมมากขึ้น
สามารถไปอ่านบทความเต็มๆจาก Analytics Engineer ตัวจริงเสียงจริงจาก Tanakrit K
ยังไม่หมดเท่านี้
หัวข้อที่เรากล่าวอาจไม่ครอบคลุมทุกส่วนในปี 2023 ยังไม่รวมถึง Gatekeeper, Unit Test, และอื่นๆ ซึ่งหัวข้อเหล่านี้จะได้ปล่อยเป็นบทความใหญ่ภายหลัง
ส่งท้าย
หลายอย่างที่เราพัฒนามีจุดประสงค์เพื่อให้ชีวิตของ data engineer ง่ายขึ้น ไม่แค่เพียง data users ที่อยากมั่นใจเรื่อง data แม้แต่เราเองก็อยากมั่นใจด้วยเช่นกัน
ทุกคนอาจสังเกตได้ว่า Journey ปี 2023 เราไม่ได้มี stack ใหม่ที่ชวนว้าวเหมือนบทความที่แล้ว แต่เรากลับเน้น Practice ที่เป็นการทำงานร่วมกันของทีม, เรียนรู้ discipline และปรับใช้กับของที่ขึ้นไป แล้วก็หันกลับมาว่าจะ optimize cost usage อย่างไรได้บ้าง
เพราะเราไม่ได้มองหาแค่การสร้างฟีเจอร์ใหม่ แต่หันกลับมาเพื่อลองถอยหลัง เช็คว่าที่ผ่านมาเราสามารถพัฒนาสิ่งเดิมๆที่มีอยู่แล้วปรับปรุงมันได้อย่างไร เพื่อให้ในวันข้างหน้าเราวิ่งได้ดีและเร็วขึ้นกว่าเดิมอย่างมั่นใจ
