Data Engineer ที่ TILDI ทำอะไรบ้าง เราจะเล่าให้ฟัง
หลายคนเมื่อได้ยินคำว่า Data Engineer หรือ Data Engineering ก็จะมักถึงคำว่า ETL (Extract, Transform, Load), คนทำ pipeline, คน clean ข้อมูล
ถูกต้องแล้วค่ะ นั่นคือหน้าที่หลักที่คนทั่วไปนิยามให้กับคำว่า Data Engineer แต่ความจริงแล้ว role นี้ในแต่ละบริษัทก็มีความแตกต่างกัน
ใน TILDI ของเรา ทีม Data Engineer ของเราไม่ได้มีหน้าที่แค่เป็นคนขนข้อมูลให้, transform ข้อมูลให้ หรือวาง pipelineให้ data user เพียงอย่างเดียว นั่นเป็นแค่เพียงส่วนหนึ่งของงานเราเท่านั้น
บทความนี้เราจะเล่าว่า Data Engineer ที่นี่ทำอะไรบ้าง โดยจะขอแบ่งเป็น 3 ส่วนดังนี้
- ETL pipeline
- Data Governance
- Security
ETL pipeline
ข้อมูลที่เรานำมา ingest เข้าระบบนั้นมี 2 ประเภทคือเป็นข้อมูล batch และ streaming
หากเป็น batch เราจะใช้ภาษา Python เป็นหลัก ไม่ว่าการดึงข้อมูลผ่าน REST API, เชื่อมต่อไป database หรือ write ข้อมูล และหากเป็น streaming เราก็ใช้เป็น Kafka
หากในบางเคสที่สามารถต้องดึงข้อมูลจาก data source ตัวดังที่คนนิยมใช้ ก็จะเลือกใช้ Airbyte ซึ่งเป็นตัวช่วยไม่ให้เราต้องเหนื่อยเขียน API ดึงข้อมูลจากที่หนึ่งไปสู่อีกที่หนึ่งเอง ซึ่งทุ่นแรงและเวลาได้โดยแค่ระบุต้นทางปลายทางที่เราต้องการ เช่น อยากดึงข้อมูลจาก MongoDB ไปยัง Google Cloud Storage เราก็แค่ระบุ connection, database, และ collection ที่เราต้องการ ผ่าน UI ซึ่งสะดวกสบายมากๆ
Data Lake zone
ในพาร์ทของการเก็บข้อมูล เมื่อ ingest เสร็จแล้วเราจะใช้ blob storage เป็นคนเก็บข้อมูลให้ เพราะราคาถูกและ flexible ที่สามารถเก็บได้ทุกรูปแบบของข้อมูล โดยเราใช้บริการของ GCP ดังนั้นเราจึงใช้ Google Cloud Storage (GCS)
โดยเราจะแบ่งออกเป็น 3–4 zonesใหญ่
- Pre-landing: โซนนี้จะเป็นโซนที่เก็บข้อมูลแบบดิบ (raw) คือข้อมูลหน้าตาที่ export จาก data sources เป็นไงก็จะหน้าตาแบบนั้น ซึ่งไม่ได้มีทุก pipeline เช่น เราจะใช้ในกรณีที่ไฟล์ที่เข้ามามีมากกว่า 1 tableใน 1 ไฟล์ เป็นต้น
- Landing: โซนนี้ทำหน้าที่คล้าย pre-landing แต่จะแบ่ง tables แยกกันเรียบร้อย เพื่อให้พร้อม process ใน step ถัดไป หลายครั้งเรามักจะเก็บข้อมูลด้วย CSV
- Transforming: โซน transforming นั้นจะเป็นโซนข้อมูลที่ process แล้วโดยใช้ dp-pyspark ซึ่งเป็น platform ที่เรา build ขึ้นมาเพื่อให้ Data Engineer เราทำงานง่ายขึ้น โดยเนื้อในของ dp-pyspark คือ Spark ที่เขียนด้วยภาษา Python นั่นเอง โดยแทนที่เราจะต้องเขียนโค้ด pyspark ที่ต้องมาเขียนใหม่ทุกรอบของการทำ pipeline เราจึงมี dp-pyspark ช่วยเอื้อแรง
เช่น สร้าง SparkContext ให้แล้ว และหากเราอยากจะ rename, เปลี่ยน data type สิ่งที่เราต้องทำก็แค่สร้าง config file แบบที่มี template ให้พร้อมใช้ แล้วระบุว่าเรา
- อยากดึงข้อมูลจากที่ไหน (source)
- ไปวางข้อมูลหลัง process แล้วไว้ที่ไหน (destination)
- ข้อมูลต้นทางเป็นไฟล์อะไร (csv, json, xlsx) และปลายทางอยากให้เป็นอะไร
- อยาก process อะไรบ้าง เช่น rename, ปรับ data type, เลือกบาง column ก็เพียงเลือกคำสั่งเท่านั้น
ทั้งหมดใน dp-pyspark ช่วยสร้างมาตรฐานภายในทีม ทำให้ทีมสามารถเข้าใจแต่ละ pipeline ได้โดยที่ไม่ต้องอ่าน code ยาวเฟื้อย แต่สามารถเข้าใจการ transform ข้อมูลจาก config file ได้เลย
ส่วนไฟล์ที่เก็บ เป็นไฟล์ parquet เพื่อประหยัดพื้นที่ในการเก็บ (หากอยากรู้ว่าไฟล์ parquet คืออะไร สามารถอ่านได้เพิ่มเติมได้ Big Data file formats: ทำความรู้จัก Avro, Parquet และ ORC )
ในบางกรณีเราจะสร้างเป็น Hudi table ซึ่งเป็น table ที่สามารถทำการ upsert ข้อมูลได้โดยง่าย และง่ายต่อการใช้ร่วมกับข้อมูลประเภท streaming ที่มีการ update บ่อยๆ
ซึ่งเราก็มีบทความเกี่ยวกับว่า Hudi คืออะไร และ เริ่มต้นใช้งานอย่างไร เช่นกัน
- Serving: โซนนี้จะเป็นโซนที่เก็บข้อมูลที่ปั้นเป็น data model สำหรับ analytics โดยเฉพาะ โดยเราจะทำงานร่วมกับ Data Analyst ว่าเราอยากใช้ dashboard ที่ต้องใช้ข้อมูลแบบไหน ก็จะปรับให้มาเป็นรูปแบบที่ Data Analyst นำไปใช้ต่อได้
ทั้ง Transforming และ Serving จะถูกสร้างเป็น External table ไปยัง BigQuery เพื่อสะดวกแก่ data user ของเราในการ query ดูข้อมูลและทำ dashboard
ในบางเคสที่ Transforming หรือ Serving เป็น Hudi เรามักจะใช้ท่า Hudi Sync เพื่อ sync hudi table ไปยัง BigQuery
Orchestrator: Airflow
ทั้ง pipeline นั้น เรามี Orchestrator เป็น Airflow ในการควบคุมการทำงาน move data ไปยังแต่ละโซน หรือบอกให้ Spark เริ่มทำงานเมื่อไร และ Airflow เราติดตั้งผ่าน Kubernetes
Airflow ของเรามี 2 ตัวสำหรับงาน 2 แบบคือ External และ Internal
External Airflow
เป็น Airflow ที่เอาไว้รับใช้การทำ ETL pipeline โดยเฉพาะ โดยจะรับใช้ให้แต่ละ Data Domain เช่น หากขนข้อมูล Promotion ก็จะเป็น pipeline ของ promotion ที่จะนำข้อมูลไปเก็บใน project promotion โดยเฉพาะ และไม่เก็บใน Data Platform เพื่อรองรับรูปแบบ Distributed data และเพื่อสอดคล้องกับ Data Mesh ในที่สุด
Internal Airflow
ตัว External Airflow ต้องยุ่งเกี่ยวกับ ETL และเชื่อมต่อกับ Domain Project มากมาย แต่ Internal จะเป็นคนคอยทำงานเบื้องหลังต่างๆในด้าน engineer เช่น การ backup metadata ของ pipeline, backup airflow connections, variables
ทั้ง 2 Airflow นั้นจะอ่านไฟล์ dags จาก GitLab ผ่านฟีเจอร์ที่เรียกว่า GitSync และเมื่อมีใครสักคนปรับเพิ่มโค้ดชุดใหม่ใน branch ที่เราเซ็ตไว้ Airflow บน Kubernetes ของเราก็จะอัพเดทไม่เกินรอ
ส่วนความพิเศษของ Airflow ที่ไม่พูดก็คงจะไม่ได้ คือ Airflow เป็น orchestrator ที่นิยมถูก integrate กับ open-source อื่นๆ เช่น DataHub ที่เราใช้อยู่ในการทำ Data Lineage และ Data Discovery/Data Catalog ซึ่งเราจะเล่าแบบละเอียดให้พาร์ทถัดไป
Data Governance
Welcome to Data Platform where we don’t create only ETL pipeline
ในจักรวาลของ Data Platform เราขอแบ่งออกเป็น 5 เรื่อง
- Data Observability
- Data Validation/ Data Quality
- Data Monitoring
- Data Lineage
- Data Discovery/ Catalog
1. Data Observability
เมื่อกี้ที่เราเล่าเกี่ยวกับ airflow ความจริงแล้ว External airflow ก็คุยกับ Internal airflow ได้นะ คุยกันเพื่อทำ Data Observability
External airflow จะไป trigger Internal airflow ในทุกครั้งที่ pipeline ปกติรันเสร็จ เพื่อบอกกับ internal ว่า รันเสร็จแล้วจ้า สิ่งที่ internal จะทำคือไปเคว้นหาข้อมูลที่แกใช้ใน pipeline แต่ละ steps นี่ใช้ไปเท่าไรนะแล้ว ไปถามทั้งจาก Spark และ GCS แล้วนำมาเก็บไว้ที่ MySQL database และเก็บว่า task มี metadata อะไรบ้าง
ซึ่งที่เราเล่าไปคือ Data Observability ซึ่งเป็นชื่อเดียวที่เราสร้างเป็น application หนึ่ง เพื่อมั่นใจว่าดาต้าเราควบคุมใน pipeline ยังปกติ เก็บเป็นสถิติไว้ และนำไปโชว์ใน Grafana dashboard หากวันใดวันหนึ่งไซส์ข้อมูลร่วงฮวบ เราก็สามารถรู้ได้
หากสนใจเพิ่มเติม น้องเกน Sojirath Thunprateep เล่ารายละเอียดเกี่ยวกับ Data Observability แบบเต็มๆในลิ้งนี้
2. Data Validation and Data Quality
ความสำคัญของการเก็บ metadata ของ pipeline เมื่อกี้ยังไม่จบแค่นั้น เรานำข้อมูลตรงนี้มาควบรวมกับ Great Expectations
Great Expectations เป็น tools สำหรับการทำ validation ว่า เฮ้ย ฉัน expect ว่าข้อมูลฉันต้องหน้าตาแบบนี้ column นี้ต้องไม่เป็น null, column นี้ต้องมีแค่ female กับ male เท่านั้น, หรือ table นี้ต้องมี 15 columns เท่านั้น ห้ามน้อยหรือเกินกว่านี้
พวกเราชาว Data Engineer เคยคุยกันว่าสิ่งที่สำคัญที่สุดในพาร์ท Data Governance คืออะไร จนได้คำตอบว่า Data Quality สำคัญที่สุด
เพราะถ้าหาก data user ไม่มีความมั่นใจในคุณภาพข้อมูลที่เรานำมาให้ เขาจะกล้านำมาใช้ได้อย่างไร
แล้วเขาจะรู้ได้ไงว่า table ชุดที่เขาต้องการมันเชื่อถือได้ยังไง
เรามี Data Trust Score ค่ะ
ใน DataHub จะมีรายละเอียดของ table และรายละเอียดของ Data Trust Score ว่า table นี้มี update ล่าสุดจาก pipeline เมื่อไร เผื่อ pipeline ตายแล้ว คนใช้ table ก็จะรู้ว่าอ๋อ ข้อมูลไม่ได้อัพเดทนี่นา หรือรู้ถึง วันเวลาล่าสุดที่รัน Validation ไปคือเมื่อไรน้า และทุกอย่างก็ถูกคำนวนออกมาเป็นค่า Trust Score ว่า table ชุดนี้น่าเชื่อถือแก่การใช้มากแค่ไหน (เต็ม 100%)
หาก % ไม่ดี Data Eng ก็แอบหน้าแตกได้ ต้องรีบไปแก้ pipelineให้ไวเลยจ้า 😂
3. Data Monitoring
พูดถึงการแก้ pipeline ให้ไว แล้วเราจะรู้ได้ยังไงว่า pipeline เราพังก่อนที่ data user จะรู้นะ?
Pain point ที่ user มักจะเจอคือ เจอข้อมูลแปลกๆหรือข้อมูลที่ไม่อัพเดท ซึ่งรู้ก็ต่อเมื่อ Dashboard ตัวเองมีตัวเลขเพี้ยนๆแล้วนี่นา ! (Data Analyst และ Business Analyst เชิญกรี๊ดได้ตามอัธยาศัย)
เราคงไม่อยากให้เกิดเหตุการณ์แบบนั้นแน่นอน เราจึงต้องมี monitoring คอยช่วยดูว่าหาก pipeline พัง เราจะต้องวิ่งเข้าไปดูและ take action เบื้องต้นทันที อย่างน้อยก็ถ้าไม่แก้ทันที ก็จะได้นำมาแก้ใน sprint ถัดไป
เราใช้ Opsgenie ในการ notify issue ให้เรา โดยเซ็ตที่ Airflow ว่าหากรันผิดพลาดก็จะไปยิง function ที่ให้ trigger Opsgenie นะ โดยสิ่งที่ Opsgenie จะทำคือสร้างเป็น alert ticket ขึ้นมา ส่งเข้า MS Teams
แล้วหากมีใครในทีม Data Engineer เห็น ticket นี้อยู่ละก็ ก็จะไปกด ack แล้วรีบตรวจสอบทันใด คนในทีมก็จะรู้เช่นกันว่าใครกำลัง handle issue นี้อยู่ ทำให้สื่อสารการทำงานในทีมง่ายขึ้นมาก
4. Data Discovery and Data Catalog
มันคงจะดีไม่น้อย หากเรารู้ว่ามีข้อมูลอะไรให้ใช้ในองค์กร เพื่อนำข้อมูลนี้ไปต่อยอด
ในการทำ Data Discovery และ Catalog พวกเรายกให้ DataHub เป็นคนจัดการให้
DataHub เป็น open-source tools เพื่อเป็น platform ที่เก็บ table metadata เพื่อให้คนที่ต้องการใช้ข้อมูลรู้ว่า table นี้เกี่ยวกับอะไร มี column อะไรให้ใช้ได้บ้าง ใครเป็น owner หรือ contact point ที่รู้ดีเกี่ยวกับ table นี้ที่สุดนะ ทำให้ชีวิต data user สะดวกขึ้น
ดูเพิ่มเติมได้ใน การ implement DataHub
5. Data Lineage
DataHub ยัง integrate เข้ากับ Airflow ในการทำเรื่อง Data Lineage ได้ คือการรู้ถึงการไหลของข้อมูลนี้วิ่งมาจากทางไหน มาจาก data source อะไร ถูกปั่นมาจาก table ไหนนะ
หากเราเซ็ตให้ 2 ตัวนี้รู้จักกันแล้ว ทุกครั้งของการรัน airflow pipeline ก็จะยิงไปหาเจ้า DataHub เพื่อสร้าง Lineage ว่ามี datasets อะไรที่ airflow ไปเก็บให้นะ จนทำให้เราเห็นแบบในภาพ โดยที่ไม่ต้องวาดภาพ Diagram การไหลข้อมูล แต่ถูกสร้างโดย auto จาก coding ใน Airflow
ดูเพิ่มเติมได้ใน การ implement Data Lineage แบบละเอียด
Security
หนึ่งในเรื่องน่าปวดหัวสำหรับองค์กรคงหนีไม่พ้นการควบคุมสิทธิ access ของ user หรืออย่างการดูว่าคนในองค์กรเขามีสิทธิในโปรเจคไหนบ้าง เป็นสิ่งที่ไม่มีใครตอบได้นอกจากต้องไปใช้เวลาค้นหาทีละโปรเจค
และบ่อยครั้งที่ Data Engineer ได้รับหน้าที่ assign สิทธิต่างๆให้กับ data user ซึ่งแน่นอนว่าคงเป็นเรื่องดีหากเรามีระบบที่คอยเป็นตัวกลางที่คอยจัดการเรื่องพวกนี้
เราจึงได้สร้าง applications อีกตัวที่ชื่อว่า Gatekeeper เพื่อเป็นตัวกลางระหว่างระบบเปิด ticket ในบริษัท โดยหาก ticket นั้นมีคน request สิทธิและ ticket ถูก approve แล้ว Gatekeeper จะเป็นคอย sync สิทธิและ assign role แก่ user นั้น ซึ่งนั่นรวมถึงการเข้าถึง BigQuery และ Cloud Storage ที่เป็นแหล่งรวบรวมข้อมูลที่ critical ในองค์กรด้วย
สุดท้ายแล้ว เราก็อยากมีที่ๆหนึ่งที่สามารถบอกได้ว่า “ใคร” สามารถเข้าถึง project ไหนได้บ้าง จนเกิดเป็น reports ที่ Data Studio
นอกจากเรื่องการ access ข้อมูลแล้ว เราก็อยากควบคุมค่าใช้จ่ายการ Query ในองค์กรเช่นกัน เพราะปริมาณข้อมูลเราก็ไม่ใช่น้อยๆ จึงมีอีก Dashboard ที่ sync จาก BigQuery table ที่รวบรวมการใช้งาน query ของ project นั้นๆด้วย
ในพาร์ทของ Security ด้านการ encrypt และ decrypt ข้อมูลที่เป็น PII ก็เคยเขียนเป็นบทความแล้วเช่นกัน การทำ Data Encryptionด้วย Cloud KMS + Tink (และการใช้งานร่วมกับ BigQuery Encryption Functions)
สรุป
นอกจากงานหลักอย่างการขนข้อมูลให้แก่ประชาชนชาวดาต้าทั้งหลายในองค์กรแล้ว เรา Data Engineer ผู้เสมือนเป็นต้นน้ำของคนใช้ข้อมูล เราหวังว่าข้อมูลที่เราขนให้จะมีคุณภาพ ไม่ว่าคุณภาพข้อมูลตัวมันเองหรือคุณภาพ infrastructure ที่เราวางไว้
ทั้ง 3 ส่วน ETL pipeline, Data Governance และ Security เป็นเพียงส่วนหนึ่งในสิ่งที่เราทำ (ยังไม่หมดอีกเหรอ!) เพราะเราหวังว่าวันหนึ่งเราจะทำให้องค์กรทำงานได้โดยไม่ต้องพึ่งพวกเรา ไม่ต้องมารอคอยข้อมูล ไม่มีพวกเราเป็น blocker ในการทำงานแต่สามารถพึ่งพาด้วยตัวเองได้
จะเห็นได้ว่าเราได้เล่าแต่ overview คร่าวๆ ในส่วนที่เป็นรายละเอียดมากๆ ทางเราก็เคยเขียนบล็อกบางส่วนไว้แล้วเช่นกัน หากไม่อยากพลาดบทความใหม่ๆละก็ สามารถติดตามได้ที่ medium ของ TILDI และ Mils’ Blog รวมถึง Facebook page ด้วยนะค้า https://www.facebook.com/mesodiar
และหากทั้ง 3 ส่วนที่เราเล่ามาไม่ชัดเจน หรืออยากรู้รายละเอียดเพิ่มเติมกว่านี้ ก็ต้องเข้ามาเป็นส่วนหนึ่งของทีมเราแล้วล่ะ
สมัครมาได้ที่ pongthep.vij@cjexpress.co.th เลยนะค้า
ขอบคุณที่อ่านมาถึงตรงนี้ค่ะ
