คู่มือภาพรวมภูมิทัศน์เครื่องมือข้อมูลสำหรับนักพัฒนา

• จัดภาพรวมภูมิทัศน์ทั้งหมดเพื่อให้นักพัฒนาซอฟต์แวร์ที่เพิ่งเข้ามาทำงานด้านข้อมูล ไม่ได้แค่จำชื่อเครื่องมือ แต่เข้าใจบทบาทและความเชื่อมโยงของเครื่องมือแต่ละตัวในขั้นตอน การเก็บ/การจัดเก็บ/การประมวลผล/การนำไปใช้ ของข้อมูล
• สายงานข้อมูลแบ่งคร่าว ๆ ได้เป็นประเภท การวิเคราะห์/วิทยาศาสตร์/วิศวกรรม/แมชชีนเลิร์นนิง โดยตั้งแต่ SQL และ BI ไปจนถึงโมเดลสถิติและโน้ตบุ๊ก, โครงสร้างพื้นฐานของ pipeline, และการดีพลอยโมเดลเพื่อใช้งานจริง ต่างก็จัดการกับปัญหาและเครื่องมือคนละแบบ
• ที่เก็บข้อมูลแบ่งเป็น data warehouse ที่ให้การวิเคราะห์ที่รวดเร็วและใช้งานสะดวก, data lake ที่ราคาถูกและยืดหยุ่น, และ lakehouse ที่เพิ่ม ACID และการจัดการสคีมาด้วยรูปแบบตาราง
• การประมวลผลข้อมูลขยายไปตั้งแต่การแปลงด้วย SQL อย่าง dbt, การประมวลผลแบบ local ของ pandas และ DuckDB, การประมวลผลแบบ batch แบบกระจายของ Spark, ไปจนถึงการประมวลผลแบบสตรีมของ Kafka และ Flink โดยมี orchestrator อย่าง Airflow คอยจัดการลำดับการรันและการกู้คืนเมื่อเกิดความล้มเหลวของงานที่แยกจากกัน
• ข้อมูลที่ผ่านการประมวลผลแล้วไม่ได้ใช้แค่กับแดชบอร์ด แต่ยังนำไปใช้กับงานขาย/ซัพพอร์ต, การวิเคราะห์เฉพาะกิจ, แมชชีนเลิร์นนิง, ฟีเจอร์วิเคราะห์ภายในผลิตภัณฑ์, และการขายข้อมูล โดยเมื่อระบบมีขนาดใหญ่ขึ้น catalog/semantic layer/lineage/governance จะกลายเป็นรากฐานสำคัญในการรักษาความหมายและความรับผิดชอบของข้อมูล

---

ขอบเขตที่นักพัฒนาควรรู้

• เป็น คู่มือภาพรวมสำหรับนักพัฒนา ที่เรียบเรียงโดยซอฟต์แวร์เอนจิเนียร์ซึ่งเข้าร่วมบริษัทด้านข้อมูลทั้งที่ไม่มีพื้นฐานมาก่อน เพื่อทำความเข้าใจการใช้งานของเครื่องมือและปฏิสัมพันธ์กับโน้ตบุ๊ก
• ไม่ครอบคลุมวิธีสร้างแดชบอร์ด, พื้นฐานสถิติ, วิธีดูแล Spark cluster หรือการเปรียบเทียบเชิงลึกของผลิตภัณฑ์แต่ละตัวในหมวดเดียวกัน
• แยก ช่วงของวงจรชีวิต ที่เครื่องมือแต่ละตัวรับผิดชอบ โดยไล่ตามเส้นทางตั้งแต่ข้อมูลเกิดขึ้นที่ไหน ไปจนถึงถูกประมวลผล จัดเก็บ และแสดงผลอย่างไร

สี่ประเภทของสายงานข้อมูล

• แม้ขอบเขตของบทบาทจริงจะค่อนข้างพร่าเลือน โดยเฉพาะในบริษัทหรือทีมขนาดเล็ก แต่เพื่อทำความเข้าใจภาพรวมทั้งหมด สามารถแบ่งได้เป็นสี่ประเภท
• สายวิเคราะห์ ใช้ SQL และสเปรดชีตในการตีความข้อมูลและทำภาพแสดงอินไซต์
  • ตัวอย่างตำแหน่งคือ Data analyst และ BI analyst โดยใช้ Tableau, Excel เป็นต้น
  • ตัวอย่างงานคือดึงข้อมูลลูกค้ามาคำนวณอัตราการเลิกใช้แยกตามภูมิภาค แล้วทำแดชบอร์ด Tableau พร้อมข้อเสนอแคมเปญรักษาลูกค้า
• สายวิทยาศาสตร์ ใช้สถิติ โมเดล และการทดลอง เพื่อตอบคำถามที่ลึกกว่าการรายงานผิวเผินหรือทำการคาดการณ์
  • ตัวอย่างตำแหน่งคือ Data scientist โดยใช้ Python, pandas, scikit-learn และโน้ตบุ๊กเป็นหลัก
  • สามารถสำรวจปัจจัยที่ทำให้ลูกค้าเลิกใช้ สร้างโมเดลความเป็นไปได้ที่ลูกค้าแต่ละรายจะเลิกใช้ แล้วออกแบบและวิเคราะห์ A/B test ของแคมเปญรักษาลูกค้าได้
• สายวิศวกรรม รวบรวม ทำความสะอาด และทำข้อมูลต้นทางให้เป็นมาตรฐาน เพื่อนำเข้าไปเก็บใน warehouse หรือ lake รวมถึงดูแลเครื่องมือข้อมูลและฐานข้อมูล
  • ตัวอย่างตำแหน่งคือ Data engineer โดยใช้ Python, Apache Spark, ฐานข้อมูล, warehouse และคลาวด์
  • อาจขยายผลการวิเคราะห์ให้เป็น reverse ETL pipeline ที่รันซ้ำได้ หรือรวมข้อมูลธุรกรรมจากหลายแหล่งพร้อมจัดการสคีมา คิวรี และการตรวจสอบคุณภาพ
• สายแมชชีนเลิร์นนิง สร้างและดูแลโมเดล AI ตั้งแต่โมเดลจัดหมวดหมู่ไปจนถึง LLM
  • เป็นหมวดที่รวม ML scientist และ ML engineer ไว้ด้วยกัน และไม่ได้ลงรายละเอียดมากในเนื้อหาเพราะ ecosystem ของเครื่องมือแยกออกไปใหญ่พอสมควร
  • เช่น การประกอบข้อมูลฝึกสำหรับโมเดลแนะนำสินค้า ฝึกและปรับจูนโมเดล แล้วดีพลอยเป็น API ก่อนเฝ้าติดตามการทำนายและฝึกใหม่ตามการเปลี่ยนแปลงของพฤติกรรม

ETL และ ELT

• ETL(Extract-Transform-Load) คือโฟลว์ทั่วไปที่ดึงข้อมูลต้นทางออกมา ทำความสะอาดหรือรวมกับข้อมูลอื่น แล้วจึงนำผลลัพธ์ไปโหลดเข้าสู่ปลายทาง
• ลำดับของขั้นตอนไม่ได้ตายตัว และอาจทำซ้ำหรือทับซ้อนกันได้
• ELT คือการโหลดข้อมูลต้นทางเข้า warehouse ก่อน แล้วค่อยแปลงภายในนั้นและบันทึกผลลัพธ์เป็นตารางแยก
  • อาจทำให้ต้นทุนเพิ่มขึ้นจากพื้นที่จัดเก็บและการประมวลผลเพิ่มเติม
  • แต่ยังคงเก็บข้อมูลต้นฉบับไว้ จึงสามารถนำกลับมาประมวลผลใหม่ในรูปแบบอื่นภายหลังได้

รูปแบบไฟล์และหน่วยความจำ

• CSV เหมาะกับผู้ใช้ที่ไม่ใช่สายเทคนิค เพราะส่งต่อข้อมูลขนาดเล็กได้ง่ายและเปิดได้ในซอฟต์แวร์สำนักงานส่วนใหญ่
• Apache Parquet เป็นรูปแบบไฟล์แบบคอลัมน์ที่บีบอัดได้ดี และสามารถจัดเก็บ/ส่งต่อข้อมูลขนาดใหญ่ได้อย่างมีประสิทธิภาพ
  • เครื่องมือข้อมูลส่วนใหญ่รองรับ จึงทำหน้าที่เป็นรูปแบบกลางร่วมระหว่างเครื่องมือ
  • Apache ORC ก็แก้ปัญหาลักษณะคล้ายกัน
• Apache Avro เป็นรูปแบบไบนารีแบบแถว ใช้สำหรับส่งต่อเรคอร์ด โดยเฉพาะในการประมวลผลแบบสตรีม
• Apache Arrow เป็นรูปแบบ in-memory มาตรฐานโดยพฤตินัยที่ปรับให้เหมาะกับการประมวลผลและการส่งต่อแบบ zero-copy
  • Parquet เน้นไฟล์ขนาดเล็กและการสแกนเฉพาะรายการที่ต้องการ ส่วน Arrow เน้นการคำนวณจริงที่ใช้ประโยชน์จากคำสั่ง CPU·GPU และแคช
  • Arrow ใช้หน่วยความจำมากกว่า แต่ส่งข้อมูลระหว่างเครื่องมืออย่าง pandas และ DataFusion ของ Rust ได้อย่างมีประสิทธิภาพ
  • ใช้เป็น backend แบบเลือกได้ของ pandas ได้ และ Polars กับ DataFusion ก็ถูกสร้างขึ้นบน Arrow มาตั้งแต่ต้น

Data warehouse

• Data warehouse คล้ายฐานข้อมูลอย่าง PostgreSQL หรือ MySQL แต่ถูกปรับให้เหมาะกับโหลดงานด้านการวิเคราะห์
• ฐานข้อมูล OLTP อย่าง MySQL เหมาะกับงานค้นหาแถวผู้ใช้หนึ่งแถวด้วย ID ส่วน warehouse แบบ OLAP เหมาะกับการรวมยอดระดับคอลัมน์ เช่น ยอดขายรวมรายปีแยกตามภูมิภาค
• เดิมทีเป็นที่เก็บปลายทางของข้อมูลที่ผ่านการจัดระเบียบและมีโครงสร้างแล้ว แต่ใน ELT ก็ใช้เป็นจุดแรกสำหรับโหลดข้อมูลดิบได้เช่นกัน
• เนื่องจากรูปแบบการจัดเก็บและ query engine ผูกกันแน่น จึงให้คิวรี BI และรายงานที่รวดเร็ว แต่ก็เป็น ตัวเลือกที่มีต้นทุนสูงที่สุด ในบรรดาที่เก็บข้อมูลทั้งสามประเภท
• ผลิตภัณฑ์ในกลุ่มนี้ได้แก่ Snowflake, BigQuery, Redshift
• ตัวเลือกแบบโอเพนซอร์สและโฮสต์เองได้ ได้แก่ ClickHouse, Apache Doris, StarRocks
• สำหรับโปรเจ็กต์ขนาดเล็ก ฐานข้อมูลแบบดั้งเดิมก็อาจเพียงพอ

Data lake

• Data lake มีลักษณะใกล้เคียงกับโฟลเดอร์บนคลาวด์ขนาดใหญ่ที่เก็บข้อมูลแบบมีโครงสร้าง กึ่งมีโครงสร้าง และไม่มีโครงสร้าง เช่น CSV, Parquet, JSON, อีเมล, รูปภาพ โดยผ่านการประมวลผลให้น้อยที่สุด
• สามารถสร้างได้ด้วยการตั้งกฎการตั้งชื่อ กฎการแบ่งพาร์ทิชัน และนโยบายการเข้าถึงบน Amazon S3, Google Cloud Storage, Azure Blob Storage แล้วเก็บไฟล์ลงไป
• หากจัดการไม่ดี อาจกลายเป็น data swamp ที่ค้นหาหรือนำไปใช้ประโยชน์ได้ยาก
• ตัวเลือกแบบ managed ได้แก่ Azure Data Lake และฟีเจอร์ data lake ของ Snowflake
• หากต้องการคิวรีโดยไม่ต้องค้นหา ดาวน์โหลด และ parse ข้อมูลด้วยตัวเองโดยตรง จะต้องมี metadata catalog และ query engine
  • catalog จะบันทึกชื่อตาราง สคีมา และการแมปไฟล์
  • query engine จะใช้ metadata เหล่านั้นเพื่ออ่านไฟล์ที่เกี่ยวข้องและรันคิวรีอย่าง SQL
• catalog ได้แก่ Hive Metastore, AWS Glue Data Catalog, Unity Catalog
• query engine ได้แก่ Apache Spark, Trino, Amazon Athena

เลคเฮาส์ข้อมูล

• เลคเฮาส์ข้อมูล เพิ่มความสามารถที่ใกล้เคียงกับแวร์เฮาส์บนเลคที่มีต้นทุนต่ำและยืดหยุ่น
• ฟอร์แมตตาราง ซึ่งเป็นองค์ประกอบหลัก จะจัดการรูปแบบการจัดเก็บระหว่างเอนจินคิวรีกับข้อมูลดิบ
  • ใช้ ACID เพื่อรองรับการเขียนพร้อมกัน ข้อผิดพลาดระหว่างการเขียน และความเสียหายของข้อมูล
  • แม้แต่ข้อมูลกึ่งโครงสร้างก็ต้องกำหนดสคีมา และข้อมูลไร้โครงสร้างอย่างสมบูรณ์จะไม่ได้ประโยชน์จากฟอร์แมตตาราง
  • รองรับการเปลี่ยนแปลงสคีมาและการจัดการเวอร์ชัน
  • ทำให้คิวรีเร็วขึ้นได้ด้วยการทำดัชนีและการปรับพาร์ทิชันให้เหมาะสม
  • บางอิมพลีเมนเทชันรองรับ time travel สำหรับการดูสแนปช็อต ณ ช่วงเวลาที่กำหนด
• เพราะสร้างบนเลค จึงอาจมีต้นทุนต่ำกว่าแวร์เฮาส์และไม่ผูกกับเอนจินคิวรีใดคิวรีหนึ่ง แต่ต้องนับรวมค่าใช้จ่ายด้านคอมพิวต์แยกต่างหากด้วย จึงเปรียบเทียบราคาแบบหนึ่งต่อหนึ่งได้ยาก
• ฟอร์แมตตารางหลักได้แก่ Apache Iceberg, Delta Lake, Apache Hudi
• บริการแบบจัดการมีทั้ง Lakehouse for Apache Iceberg ของ Google, Databricks, IBM watsonx.data

แหล่งข้อมูลและการเก็บรวบรวม

• ข้อมูลอาจมาจากฐานข้อมูลแอปพลิเคชันอย่าง PostgreSQL และ Mongo, API ภายนอกอย่าง Stripe, อีเวนต์วิเคราะห์จากเบราว์เซอร์, อุปกรณ์ IoT เป็นต้น
• อาจประมวลผลได้ทันทีหลังดึงข้อมูลออกมา หรือใน ELT อาจเก็บข้อมูลต้นฉบับไว้ในเลค เลคเฮาส์ หรือแวร์เฮาส์ก่อน ตามรูปแบบ ขนาด และโครงสร้างพื้นฐาน
• สคริปต์เฉพาะทางมีความยืดหยุ่น แต่ต้องเขียนโค้ดเชื่อมต่อที่ซ้ำๆ ใหม่เอง เช่น การยืนยันตัวตน การแบ่งหน้า และการจัดการข้อผิดพลาด
• เครื่องมือเก็บรวบรวมข้อมูล จัดการงานซ้ำเหล่านี้ด้วยการตั้งค่าคอนเน็กเตอร์ของแหล่งข้อมูลและปลายทาง
  • เพราะต้องโหลดข้อมูลที่ดึงออกมาไปเก็บไว้ที่ใดที่หนึ่งก่อน จึงมักเอนเอียงไปทางโฟลว์แบบ ELT
  • ผลิตภัณฑ์เด่นได้แก่ Fivetran, Airbyte, dlt
• Change Data Capture (CDC) จะจับการแทรก แก้ไข และลบจากล็อกการจำลองฐานข้อมูล โดยไม่ต้องคิวรีตารางซ้ำๆ
  • เครื่องมือเก็บรวบรวมมักใช้วิธีนี้ภายในเมื่อเชื่อมกับแหล่งข้อมูลฐานข้อมูล
  • Debezium ถูกใช้อย่างแพร่หลายในฐานะคอมโพเนนต์โอเพนซอร์สแบบสแตนด์อโลน

ภาษาในการประมวลผลข้อมูล

• Python เป็นภาษามาตรฐานโดยพฤตินัยสำหรับงานข้อมูล ด้วยชุมชนขนาดใหญ่และระบบนิเวศของไลบรารีเนทีฟ
  • เครื่องมือที่สร้างด้วยภาษาอื่นก็มักมี Python binding ให้ด้วย โดย Apache DataFusion ที่พัฒนาด้วย Rust เป็นตัวอย่างหนึ่ง
• numpy ให้ความสามารถด้านอาร์เรย์หลายมิติประสิทธิภาพสูง และเป็นพื้นฐานของหลายไลบรารี
• pandas เป็นมาตรฐานโดยพฤตินัยที่มีทั้ง Series แบบ 1 มิติ และ DataFrame แบบ 2 มิติ
  • สามารถทำวิชวลไลเซชันด้วย seaborn และ Plotly และสร้างแอปแบบอินเทอร์แอกทีฟด้วย streamlit
  • สามารถคิวรี SQL ด้วย DuckDB หรือใช้เทคนิคแมชชีนเลิร์นนิงของ scikit-learn ได้
• R ใช้ในแวดวงวิชาการ ส่วน Java และ Scala ใช้ในเฟรมเวิร์กบิ๊กดาต้าอย่าง Spark ขณะที่ Julia และ Rust ก็ใช้กับงานข้อมูลเช่นกัน แต่การใช้งานยังแพร่หลายน้อยกว่า Python
• SQL ถูกใช้อย่างกว้างขวางสำหรับการคิวรีและการแปลงข้อมูลในแวร์เฮาส์ แต่ไวยากรณ์จะแตกต่างกันเล็กน้อยตามสภาพแวดล้อมการรัน

การประมวลผลแบบแบตช์และเรียลไทม์

• การประมวลผลแบบแบตช์ จะประมวลผลข้อมูลก้อนใหญ่เป็นรอบๆ เช่น การสรุปยอดขายของเดือนก่อน เหมาะกับงานที่รอผลได้เป็นชั่วโมงหรือเป็นวัน
• การประมวลผลแบบเรียลไทม์ ใช้ทั้งรูปแบบสตรีมที่ประมวลผลทันทีเมื่อข้อมูลมาถึง หรือไมโครบัตช์เป็นช่วงๆ เช่น ทุก 20 วินาที
• ไปป์ไลน์ที่ความเร็วของผลลัพธ์สำคัญ เช่น การตรวจจับบอต จะใช้การประมวลผลแบบเรียลไทม์เพื่อระบุและบล็อกผู้ใช้ให้เร็วที่สุด

การแปลงข้อมูลด้วย SQL

• dbt และ SQLMesh นิยามการแปลงข้อมูลด้วยคำสั่ง SQL select และคอมไพล์ให้รันบนเอนจินคิวรีจริง
• เครื่องมือทั้งสองไม่ได้ประมวลผลข้อมูลโดยตรง แต่ทำหน้าที่ ออร์เคสเทรตการแปลงข้อมูล
• เมื่อเทียบกับสคริปต์ Python ที่ผู้ใช้เขียนเอง จะช่วยทำให้รูปแบบการแปลงข้อมูลเป็นมาตรฐานและแยกงานซับซ้อนออกเป็นโมเดลย่อยที่มีการพึ่งพากัน
• ref ของ dbt ใช้อ้างอิงโมเดลแทนการฮาร์ดโค้ดชื่อตาราง และรันตามลำดับที่ถูกต้องจากกราฟการพึ่งพา
• โดยทั่วไปผลลัพธ์จะถูกเก็บไว้ในแวร์เฮาส์ เลคเฮาส์ หรือเลคเดียวกับต้นทาง แต่ก็สามารถส่งไปยังปลายทางอื่นได้ตามการตั้งค่าเอนจินคิวรี

DataFrame แบบโลคัลและ DuckDB

• DataFrame คือ abstraction ของอาร์เรย์ 2 มิติสำหรับจัดการข้อมูลแบบตาราง และใน Python นั้น pandas ถูกใช้มากที่สุด
• อิมพลีเมนเทชันอื่นมีทั้ง Polars ของ Python และ Rust, DataFusion ของ Rust, DataFrames.jl ของ Julia, data.frame ของ R และ tablesaw ของ Java
• pandas, data.frame และ tablesaw เป็นแบบ eager execution ที่คำนวณทันทีเมื่อเรียกใช้
• LazyFrame ของ DataFusion และ Polars จะสะสมการทำงานเป็น logical plan แล้วจึงรันตอน .collect()
  • เพราะสามารถปรับแต่งแผนให้เหมาะสมก่อนรัน จึงมีโอกาสทำงานได้เร็วกว่า
• ไลบรารีแบบโลคัลมีข้อจำกัดด้านหน่วยความจำและ CPU
  • pandas ประมวลผลข้อมูลทั้งหมดในหน่วยความจำ จึงถูกจำกัดตามขนาด RAM
  • สตรีมมิงของ Polars จัดการข้อมูลที่ใหญ่กว่า RAM ได้ แต่การทำงานบางอย่างยังต้องโหลด working set เข้าไปในหน่วยความจำ
• DuckDB เป็นฐานข้อมูล OLAP แบบ in-process ที่มักถูกเรียกว่า “SQLite สำหรับงานวิเคราะห์”
  • สามารถคิวรี CSV, Parquet และ pandas DataFrame บนเครื่องโลคัลด้วย SQL ได้โดยไม่ต้องมีโครงสร้างพื้นฐานแยกต่างหาก

การประมวลผลแบบกระจายขนาดใหญ่

• เมื่อเกินขีดจำกัดของเครื่องเดี่ยว ก็จะแบ่งข้อมูลออกเป็นหลายส่วนเพื่อประมวลผลแบบขนานบนคลัสเตอร์ และสเกลแนวนอนตามปริมาณงาน
• Apache Hadoop เป็นเครื่องมือเด่นในยุคแรก แต่ปัจจุบันถือเป็นระบบเลกาซี และยังพบได้ในสภาพแวดล้อมรุ่นเก่า
• Apache Spark เป็นมาตรฐานโดยพฤตินัยในปัจจุบันสำหรับการโหลดข้อมูล การแปลงข้อมูล การประมวลผลแบบขนาน และการปรับแต่งประสิทธิภาพ
  • PySpark มีทั้ง DataFrame API และชั้นความเข้ากันได้กับ pandas
  • SparkR เพิ่งถูกยกเลิก และยังมี binding สำหรับ Java และ Scala ด้วย
  • เพราะอ่านและเขียนกับสตอเรจได้หลากหลาย จึงถูกใช้ทั้งเป็นเอนจินคิวรีสำหรับ data lake และงานแปลงข้อมูลขนาดใหญ่
• Dask ขยายโค้ด Python ไปสู่คลัสเตอร์โดยยังคงใกล้เคียงกับ API ที่คุ้นเคยของ pandas และ numpy
• Ray เป็นเฟรมเวิร์กการประมวลผลแบบกระจายอเนกประสงค์ที่ถูกใช้มากเป็นพิเศษกับการฝึก ML
• Apache Flink รองรับการประมวลผลแบบแบตช์ด้วย แต่จุดเด่นหลักคือการประมวลผลสตรีม

การสตรีมเหตุการณ์และ Kafka

• การประมวลผลสตรีมเหมาะกับงานที่ต้องการผลลัพธ์ทันที เช่น การตรวจจับการฉ้อโกงบัตรเครดิต หรือการตรวจสอบความถูกต้องของอีเวนต์เว็บแอนะลิติกส์เมื่อมาถึง แล้วเสริมข้อมูลภูมิศาสตร์ของ IP ก่อนส่งเข้า ClickHouse
• หากประมวลผลทันทีเมื่อข้อมูลมาถึง ก็อาจไม่จำเป็นต้องเก็บ raw payload แยกไว้จนกว่าจะถึงรอบรัน batch ถัดไป
• Apache Kafka เป็นแพลตฟอร์ม event streaming แบบกระจายศูนย์และทนทานต่อความขัดข้อง ที่รับอีเวนต์จาก producer มาเก็บไว้และให้ consumer อ่าน
  • ต่างจาก message queue ตรงที่แม้ consumer จะยืนยันการรับข้อความแล้ว อีเวนต์ก็จะไม่ถูกลบ และ consumer หลายตัวสามารถอ่านซ้ำได้จนกว่านโยบายการเก็บรักษาจะหมดอายุ
  • ตัว Kafka เองไม่ได้ประมวลผลข้อมูล แต่ให้ worker แยกต่างหากทำหน้าที่เป็น consumer เพื่อประมวลผล
• Kafka Connect ใช้เชื่อม Kafka เข้ากับระบบภายนอก เช่น ฐานข้อมูล
• Kafka Streams เป็นไลบรารี Java·Scala สำหรับทำ stateful transformation, window aggregation และ join บน Kafka
  • ทำงานแบบฝังอยู่ในแอปพลิเคชัน และทำงานได้เฉพาะบน Kafka
• แพลตฟอร์ม event streaming อื่น ๆ ได้แก่ Apache Pulsar, Redpanda, AWS Kinesis Data Streams

เอนจินประมวลผลสตรีม

• Apache Flink รับคำจำกัดความของแหล่งที่มาของอีเวนต์และขั้นตอนการประมวลผล แล้วดูแลงานด้านการ deploy บนคลัสเตอร์, การขยายระบบ และการกู้คืนเมื่อเกิดความขัดข้อง
• ไปป์ไลน์อาจมีการกรอง, การแมปฟิลด์, window aggregation, การลบข้อมูลซ้ำ และการส่งออกไปยัง Kafka topic อื่นหรือฐานข้อมูล
• งานที่ deploy แล้วจะประมวลผลอีเวนต์ใหม่ต่อเนื่อง ไม่ใช่ batch ที่จบการทำงาน
• ตัวเลือกอื่นมี Spark Structured Streaming, Google Cloud Dataflow, Azure Stream Analytics

การออร์เคสเตรตงาน

• เมื่อมี dbt transformation, งาน Spark และสคริปต์แบบกำหนดเองเพิ่มขึ้น orchestrator จะนำแต่ละขั้นตอนมาประกอบเป็นไปป์ไลน์เดียว
• หากกำหนดแต่ละงานและ dependency เป็นโค้ด ซึ่งมักใช้ Python ก็จะได้ DAG หรือกราฟไม่มีวงวนแบบมีทิศทาง
• orchestrator ไม่ได้ประมวลผลข้อมูลเอง แต่ทำหน้าที่ประสานการรันสคริปต์ Spark, เรียก dbt transformation, ส่ง HTTP request เป็นต้น
• สามารถใช้ schedule, อีเวนต์จาก Kafka, การสั่งรันด้วยตนเองจาก UI, HTTP request หรือ trigger ที่สร้างด้วยปลั๊กอินได้
• สามารถรันงานอิสระแบบขนานกัน และเมื่อมีขั้นตอนล้มเหลวก็ retry เฉพาะจุดนั้นก่อนทำต่อจากจุดเดิมได้
• เนื่องจากเป็น งานประมวลผลแบบ batch ที่รันตั้งแต่ต้นจนจบ จึงไม่เหมาะกับไปป์ไลน์สตรีมที่ทำงานต่อเนื่อง ซึ่งในกรณีนั้นจะพึ่งเอนจินประมวลผลอย่าง Flink เอง
• ผลิตภัณฑ์ที่เป็นตัวแทน ได้แก่ Apache Airflow, Dagster, Prefect, Luigi
  • Luigi เก่ากว่าและปัจจุบันได้รับความนิยมน้อยกว่า

การสังเกตการณ์และการติดตามคุณภาพ

• data observability แบ่งได้เป็น สถานะของไปป์ไลน์ และคุณภาพของข้อมูลเอง
  • การมอนิเตอร์ไปป์ไลน์ใช้ตรวจว่ามีการรันหรือไม่, ล้มเหลวหรือไม่, และใช้เวลานานเท่าไร
  • การมอนิเตอร์ข้อมูลใช้ตรวจความใหม่ของข้อมูล, ความผิดปกติของปริมาณข้อมูล, การเปลี่ยน schema โดยไม่แจ้งล่วงหน้า เป็นต้น
• สำหรับไปป์ไลน์ สามารถใช้ทั้งเครื่องมือ observability ทั่วไปของแอปพลิเคชัน เช่น Prometheus, Grafana, ELK และความสามารถที่มีอยู่ใน orchestrator เอง
• การตรวจสอบคุณภาพข้อมูล สามารถทำได้ด้วย Great Expectations ที่ให้กำหนดรูปแบบที่คาดหวังได้โดยตรง และ dbt tests
• ผลิตภัณฑ์แบบอัตโนมัติจะเรียนรู้แพตเทิร์นของข้อมูลปกติก่อน แล้วตรวจจับความผิดปกติ โดยมีตัวอย่างเช่น Monte Carlo, Bigeye, Metaplane

การโหลดซ้ำหลายครั้งในไปป์ไลน์

• เป้าหมายปลายทางของการโหลดใน ETL คือ warehouse·lake·lakehouse แต่ข้อมูลไม่ได้ถูกเก็บเพียงครั้งเดียวที่ปลายทางของไปป์ไลน์ หากถูกเก็บหลายครั้งในรูปแบบที่แตกต่างกัน
• สถาปัตยกรรมเมดัลเลียน แบ่งระดับการจัดระเบียบข้อมูลในสตอเรจเดียวกันออกเป็น 3 ชั้น
  • Bronze คือข้อมูลดิบที่เข้ามาจากต้นทางโดยตรง
  • Silver คือข้อมูลที่ผ่านการจัดระเบียบและทำให้เป็นมาตรฐาน เช่น แก้ชนิดข้อมูล, ลบข้อมูลซ้ำ, รวมข้อมูลจากหลายต้นทาง
  • Gold คือข้อมูลที่สรุปผลหรือทำโมเดลให้เหมาะกับวัตถุประสงค์เฉพาะ เช่น แดชบอร์ดหรือรายงาน
• โดยทั่วไปนักวิเคราะห์จะ query ตาราง Gold เป็นหลัก ส่วนวิศวกรอาจไล่ลงไปถึง Bronze เพื่อดีบักไปป์ไลน์

การทำโมเดลเชิงมิติ

• หากโครงสร้างเมดัลเลียนแสดงระดับการจัดระเบียบของข้อมูล การทำโมเดลเชิงมิติ จะเป็นตัวกำหนดรูปแบบของตารางใน warehouse
• เป็นแนวทางที่ได้รับความนิยมจากหนังสือ 《The Data Warehouse Toolkit》 ของ Ralph Kimball ซึ่งแยกตารางข้อเท็จจริงและตารางมิติออกจากกัน
• ตารางข้อเท็จจริง เก็บหนึ่งเหตุการณ์หรือหนึ่งค่าที่วัดได้ต่อหนึ่งแถว เช่น คำสั่งซื้อ, การชำระเงิน, การดูหน้าเพจ
  • มักยาวและแคบ มีตัวเลขและ foreign key ไปยังตารางมิติจำนวนมาก และขยายต่อเนื่อง
• ตารางมิติ เก็บบริบทที่เหตุการณ์เกิดขึ้น เช่น ลูกค้า, สินค้า, วันที่
  • มักกว้างกว่าและเปลี่ยนแปลงค่อนข้างช้า
• เมื่อมีตารางข้อเท็จจริงอยู่ตรงกลางและตารางมิติล้อมรอบ จะเรียกว่า star schema
  • ยังมี snowflake schema ที่ทำ normalization มากกว่า และไม่เกี่ยวข้องกับผลิตภัณฑ์ Snowflake
• grain คือการกำหนดว่าหนึ่งแถวแทนอะไร เช่น หนึ่งคำสั่งซื้อ, หนึ่งรายการสินค้าในคำสั่งซื้อ, หรือหนึ่งยอดสั่งซื้อรายวันต่อหนึ่งลูกค้า
• data mart คือส่วนย่อยของ warehouse ที่จัดไว้สำหรับทีมหรือหัวข้อเฉพาะ เช่น การตลาดหรือการเงิน และมักอยู่ในชั้น Gold
• ไม่ใช่ทุกทีมจะยึดตามแนวทางนี้อย่างเคร่งครัด บางแห่งใช้ warehouse สมัยใหม่ที่เร็วและต้นทุนสตอเรจต่ำเพื่อสร้าง ตารางใหญ่ตารางเดียว แบบ de-normalized กว้าง ๆ ตามวัตถุประสงค์

OLAP แบบเรียลไทม์สำหรับแอปพลิเคชัน

• สำหรับแดชบอร์ดภายใน ตาราง Gold ใน warehouse ก็เพียงพอ แต่หากต้องให้บริการผู้ใช้จำนวนมากในระดับมิลลิวินาที ทั้ง latency ของ query และต้นทุนต่อคำขออาจไม่เหมาะสม
• ข้อมูลที่ต้องการ concurrency สูงและการตอบสนองรวดเร็ว เช่น analytics สำหรับผู้ใช้, การมอนิเตอร์ภายในแบบเรียลไทม์, ลีดเดอร์บอร์ด, รายการยอดนิยม, การวัดการใช้งาน จะถูกย้ายไปยัง ฐานข้อมูล OLAP แบบเรียลไทม์
• กลุ่มนี้ได้แก่ Apache Druid, Apache Pinot, ClickHouse, Apache Doris โดย ClickHouse ถูกใช้อย่างแพร่หลาย

Reverse ETL

• Reverse ETL คือการส่งข้อมูลที่ประมวลผลแล้วจาก warehouse กลับไปยังเครื่องมือปฏิบัติการ เช่น CRM
• หากคำนวณมูลค่าตลอดอายุลูกค้าจากข้อมูล Stripe แล้วใส่กลับเข้า HubSpot ทีมขายก็จะเห็นลูกค้ามูลค่าสูงได้ทันที
• เครื่องมือเฉพาะทางจะช่วยเชื่อมตาราง·คอลัมน์กับฟิลด์ปลายทาง และจัดการเรื่องความล้มเหลว, การ retry, การจำกัดอัตรา, การแจ้งเตือน, การซิงก์แบบ incremental
• ตัวเลือกได้แก่ Airbyte Data Activation, Fivetran Activations, Hightouch, RudderStack
  • Fivetran Activations ใช้ชื่อ Census ก่อนการเข้าซื้อกิจการ

แค็ตตาล็อกข้อมูลและชั้นความหมาย

• แค็ตตาล็อกข้อมูล สำหรับคน ช่วยเก็บต้นทางของข้อมูล เจ้าของ นโยบายการเข้าถึง และข้อมูลสำหรับการค้นหา เพื่อเพิ่มบริบทธุรกิจให้กับตารางและคอลัมน์
  • มีจุดประสงค์ต่างจาก metastore สำหรับ query engine
  • ตัวอย่างที่เด่นได้แก่ Unity Catalog, DataHub, OpenMetadata
• ชั้นความหมาย เก็บคำนิยามมาตรฐานของเอนทิตีทางธุรกิจ ความสัมพันธ์ และเมตริก
  • ทำให้สิ่งต่าง ๆ เป็นมาตรฐานเดียวกัน เช่น โมเดลลูกค้ามาจากตารางและคอลัมน์ใด ตลาดใดอยู่ใน EMEA และรายได้หักเงินคืนออกหรือไม่
  • เมื่อเลือกเอนทิตีและเมตริกที่ถูกต้องในเครื่องมือ BI หรือ AI agent ระบบจะเปลี่ยนเป็นคิวรีที่ต้องใช้ หรือให้ข้อมูลที่จำเป็นต่อการสร้างคิวรี
• ตัวอย่างได้แก่ LookML ของ Looker, Cube, dbt Semantic Layer และฟีเจอร์ด้าน semantic ของ Unity Catalog

สายสืบทอดข้อมูล

• สายสืบทอดข้อมูล (data lineage) ใช้ติดตามว่าข้อมูลถูกแปลงอย่างไรเมื่อผ่าน pipeline
• สามารถเก็บรวบรวมอัตโนมัติได้จาก DAG ของ orchestrator, การ parse SQL สำหรับการแปลง และ event/metadata ที่งานประมวลผลส่งออกมา
• ในระดับตาราง จะบันทึกความสัมพันธ์ว่า gold.orders ถูกสร้างจาก silver.orders และ silver.customers
• ในระดับคอลัมน์ จะติดตามได้ถึงความสัมพันธ์ว่า customers.life_time_value คำนวณมาจาก orders.total และ subscription_payments.amount
• ใช้ประเมินผลกระทบปลายน้ำเมื่อมีการลบคอลัมน์ วิเคราะห์สาเหตุรากของเมตริกที่ผิดพลาด และใช้เพื่อการปฏิบัติตามข้อกำหนดเกี่ยวกับการใช้ข้อมูลระบุตัวบุคคล
• Unity Catalog, DataHub และ OpenMetadata รองรับการแสดงภาพสายสืบทอด แต่ทั้ง pipeline ต้องส่งข้อมูลติดตามผ่าน connector หรือ event ที่ใส่เองด้วยตนเอง
• แทนที่จะใช้รูปแบบเฉพาะของผู้ให้บริการ ก็สามารถใช้มาตรฐาน OpenLineage ที่หลายแค็ตตาล็อกและเครื่องมือประมวลผลรองรับได้

แดชบอร์ด BI และรายงาน

• แดชบอร์ดและรายงานเป็นปลายทางการใช้งานที่พบบ่อยที่สุดของ data pipeline และในบริษัทขนาดเล็กอาจเป็นกรณีใช้งานแทบจะเพียงอย่างเดียว
• เครื่องมือ BI เชื่อมต่อกับ warehouse, lakehouse และฐานข้อมูลแอปพลิเคชัน เพื่อให้สร้างกราฟและแดชบอร์ดได้โดยไม่ต้องเขียนโค้ด
• หัวใจสำคัญคือ self-service ที่ให้ผู้ใช้ที่ไม่ใช่สายเทคนิคสร้างกราฟหรือสำรวจข้อมูลได้เองใน UI โดยไม่ต้องขอให้นักวิเคราะห์ช่วยทุกครั้ง
• สามารถส่งรายงานตามกำหนดผ่านอีเมลหรือ Slack หรือแจ้งเตือนเมื่อเมตริกเกินค่าที่ตั้งไว้
• Tableau และ Power BI ถูกใช้อย่างแพร่หลายในองค์กรขนาดใหญ่ และเน้นการทำ visualization ที่ทรงพลังและยืดหยุ่น
• Looker ปรับให้เหมาะกับองค์กรสายเทคนิค โดยมีชั้นความหมาย LookML เป็นแกนหลัก
• Metabase ตั้งค่าได้รวดเร็วรวมถึงแบบ self-hosted และเข้าถึงง่ายสำหรับผู้ใช้ที่ไม่ใช่สายเทคนิค
• Looker Studio เป็นผลิตภัณฑ์แยกต่างหากที่ไม่ใช้ LookML และมีความสามารถน้อยกว่า Looker โดยล่าสุดเปลี่ยนชื่อกลับเป็น Data Studio

การวิเคราะห์เชิงปฏิบัติการ

• การวิเคราะห์เชิงปฏิบัติการ คือการนำข้อมูลเข้าไปอยู่ในแอปพลิเคชันที่คนทำงานนอกสายวิเคราะห์ใช้ทุกวัน ไม่ใช่รายงานสำหรับผู้บริหาร
• ตัวอย่างการใช้งานมีดังนี้
  • ซิงก์ข้อมูลสรุปการใช้งานไปยัง HubSpot เพื่อให้ทีมขายทำ upsell กับลูกค้าที่เหมาะสม
  • ซิงก์คำสั่งซื้อล่าสุด ทิกเก็ตซัพพอร์ต และแพ็กเกจไปยัง Zendesk เพื่อให้ทีมซัพพอร์ตเห็นบริบทของลูกค้า
  • สร้างแอปภายในที่แสดงสถานะการนำผลิตภัณฑ์ไปใช้ของลูกค้าแต่ละรายสำหรับทีม customer success
• Reverse ETL เป็นวิธีส่งต่อที่พบได้บ่อย แต่แอป Customer 360 ภายในที่ query warehouse โดยตรงก็ถือเป็นการวิเคราะห์เชิงปฏิบัติการเช่นกัน

การวิเคราะห์เฉพาะกิจ การวิเคราะห์เชิงสำรวจ และโน้ตบุ๊ก

• การวิเคราะห์เฉพาะกิจ (ad-hoc analysis) คือการใช้ข้อมูลที่มีอยู่สืบหาคำถามแบบครั้งเดียว เช่น สาเหตุของการลดลงของการสมัครใช้งาน หรือ cohort ที่ทำให้เกิดการขอคืนเงิน
• การวิเคราะห์เชิงสำรวจ คือการดูข้อมูลเพื่อหาอินไซต์โดยไม่มีคำถามที่กำหนดไว้ล่วงหน้า
• เนื่องจากการคำนวณถัดไปเปลี่ยนไปตามผลลัพธ์ และซับซ้อนกว่าการกรองหรือสรุปแบบง่าย ๆ เครื่องมือรายงานทั่วไปเพียงอย่างเดียวจึงอาจไม่พอ
• สามารถใช้ Python และ pandas/Polars, SQL UI ของ warehouse, Spyder, RStudio เป็นต้น
• โน้ตบุ๊ก รวมเซลล์อย่าง Markdown, โค้ด และ SQL ไว้ในไฟล์เดียว และวางภาพ กราฟแบบโต้ตอบ และผลลัพธ์ตารางไว้ข้างโค้ด
  • เหมาะกับการสำรวจแบบเป็นขั้นตอนพร้อมดูผลการรัน และการนำเสนอผลลัพธ์
  • ตัวอย่างที่เด่นได้แก่ Jupyter, Google Colab, Deepnote, marimo
  • แพลตฟอร์มอย่าง Databricks และ Snowflake ก็มีโน้ตบุ๊กของตัวเองเช่นกัน

การใช้ข้อมูลของแมชชีนเลิร์นนิง

• ML เป็นสาขาแยกต่างหากที่มี feature store, เครื่องมือฝึก ติดตาม และ deploy แต่ก็เป็นปลายทางการใช้ข้อมูลที่สำคัญ
• นอกจาก LLM แล้ว ยังมีโมเดลเฉพาะทางอย่างการคาดการณ์การยกเลิกบริการ ระบบแนะนำ การพยากรณ์อุปสงค์ และการแบ่งกลุ่มลูกค้า ซึ่งต้องมี ข้อมูลฝึกที่ผ่านการเตรียมแล้ว ก่อนนำเข้าสู่โปรดักชัน
• Data scientist หรือ ML engineer จะดึง feature จาก warehouse เช่น จำนวนคำสั่งซื้อในช่วง 30 วันที่ผ่านมา หรือจำนวนวันที่ผ่านไปหลังการล็อกอินครั้งล่าสุด เพื่อนำไปฝึกและ deploy โมเดล
• ผลลัพธ์การคาดการณ์จะถูกนำไปใช้ต่ออีกครั้ง เช่น คะแนน churn ใน CRM หรือคำแนะนำสินค้าสำหรับผู้ใช้

การวิเคราะห์แบบฝังในแอป

• การวิเคราะห์แบบฝังในแอป คือการให้ข้อมูลวิเคราะห์อย่างสินค้ายอดนิยม พื้นที่ของลูกค้า หรืออันดับการค้นหาแก่ผู้ขายใน marketplace ภายในแอปพลิเคชัน
• หากมีเพียงกราฟที่กำหนดไว้ล่วงหน้า 5 แบบและตัวกรองที่จำกัด ก็สามารถพัฒนา query, UI และไลบรารีกราฟได้เอง
• หากผู้ใช้ต้องทำคำถามที่ซับซ้อน อาจใช้เครื่องมือ BI อย่าง Metabase, Looker, Tableau หรือผลิตภัณฑ์ที่เน้นการ embed อย่าง Sisense และ Luzmo
• แอปพลิเคชันโฮสต์จะรับผิดชอบเรื่องการยืนยันตัวตนและการกำหนดสิทธิ์ ส่วนเครื่องมือแบบฝังจะจัดการ UI สำหรับ query และการเรนเดอร์กราฟ

การขายข้อมูลเป็นสินค้าโดยตรง

• ข้อมูลไม่ใช่แค่วัตถุดิบของฟีเจอร์ แต่สามารถเป็น ตัวผลิตภัณฑ์เอง ได้
• สามารถเก็บรวบรวม แปลง และทำดัชนีข้อมูลจากบล็อกเชนคริปโตหลายเครือข่ายแล้วขายสิทธิ์เข้าถึงให้นักวิเคราะห์ หรือเก็บผลการค้นหาของ Google แล้วขายให้ผู้เชี่ยวชาญ SEO ก็ได้
• หากต้องการขายข้อมูลและสิทธิ์ในการ query จำเป็นต้องมี pipeline ที่แข็งแรงสำหรับการเก็บข้อมูลได้ทันเวลา และมีความสามารถในการ query ประสิทธิภาพสูง

การกำกับดูแลข้อมูล

• การกำกับดูแลข้อมูล ดูแลว่าใครสามารถเข้าถึงข้อมูลอ่อนไหว เช่น ข้อมูลระบุตัวบุคคลหรือข้อมูลสุขภาพได้บ้าง และบันทึกการเข้าถึงไว้
• ยังครอบคลุมถึงความเป็นเจ้าของข้อมูล การจัดการข้อมูลส่วนบุคคลอย่างสิทธิที่จะถูกลืม ตำแหน่งที่จัดเก็บจริง และระยะเวลาการเก็บรักษา
• สามารถรองรับได้ด้วยเทคโนโลยีอย่าง role/access control ของ warehouse, ข้อมูลความเป็นเจ้าของในแค็ตตาล็อก และการติดตามการใช้ PII ผ่านสายสืบทอด
• นี่ไม่ใช่แค่ปัญหาด้านเทคนิค แต่เกี่ยวข้องกับคนและกระบวนการอย่างมาก และเชื่อมโยงใกล้ชิดกับฝ่ายกฎหมาย การกำกับดูแลการปฏิบัติตามข้อกำหนด และความปลอดภัย
• ภูมิทัศน์ข้อมูลทั้งหมดสามารถมองเป็นลำดับการไหลตั้งแต่การเก็บจากต้นทาง ไปจนถึงการจัดเก็บ ประมวลผล และนำไปใช้ และภายใต้แต่ละหมวดหมู่ก็ยังมีเครื่องมือและตัวเลือกย่อยใหม่ ๆ เกิดขึ้นอย่างต่อเนื่อง