Data Domain Usage Monitoring — วัดผลการใช้งานข้อมูลในองค์กร
สำหรับองค์กรที่มีการ adapt ใช้คอนเซ็ปต์เรื่อง Data Mesh แล้ว เราจะวัดผลการใช้งานจริงของ user ได้อย่างไร?
บทความ Data Domain Usage Monitoring จะขอแบ่งออกเป็น 2 พาร์ท
- พาร์ทนี้เราจะเน้นเรื่องของการวาง data architecture ภายในองค์กร และผลลัพท์สุดท้ายได้ Dashboard หน้าตายังไง แบบคน non-tech อ่านแล้วเข้าใจได้
- อีกพาร์ทจะเป็น technical ว่า implement Data Usage Monitoring นี้ได้ยังไง เช่นการทำ pipeline และดึง data source จากที่ไหนได้บ้าง
แต่สำหรับใครที่งงคำว่า Data Domain หรือ Data Mesh คืออะไร เดี๋ยวเราค่อยๆทำความเข้าใจพร้อมกัน
Data Mesh คืออะไร ? แบบสั้นๆ
ในบางองค์กรจะมีทีม data กลางที่คอยดูแลเรื่องการทำวิเคราะห์ข้อมูลโดยเฉพาะ บ้างก็ทำตั้งแต่ data engineering หรือดูแล data infrastruture ด้วย หรือทำยัน report ส่งผู้บริหาร ตั้งแต่ต้นน้ำยันปลายน้ำ
ซึ่งกลายเป็นว่าทีม data กลางรับบทหนักในการรับจบทุกงาน โดยทีม data กลางต้องไปทำความเข้าใจว่า data แต่ละ domain คืออะไร, หน้าตายังไง, พฤติกรรมยังไง, technical ก็ต้องรู้, infra ก็ต้องรู้ ( — ปวดหัวครั้งที่ 1)
ผลกระทบคือ พอเวลามีคนมาขอเข้าถึงข้อมูลหรือมาขอคำปรึกษากับทีมกลาง ก็ได้ response ที่ช้ามากกกก(ก.ไก่ ล้านตัว)
เพราะทีมกลางอาจจะติดพันงานอื่นอยู่ เพราะตัวเองรับงานจากทั้งองค์กร( — ปวดหัวครั้งที่ 2 ละ)
เลยมีคอนเซ็ปต์ที่ชื่อว่า Data Mesh ที่เข้ามาแบ่งเป็นบทบาทชัดเจน
- ทีม data กลางสลายไป จาก centralize สู่ decentralize
- กระจาย Ownership สู่ domain — แต่ละทีม domain ดูแลรับผิดชอบ data ของตัวเอง
- มองว่า Data as product — ใช้คอนเซปต์ Product thinking กับ analytical data
- กระจายคนที่ดูแล infra เป็นทีม data platform แทนและทำ data platform เป็น self-serve
หมายความว่า platform นี้จะเป็นเครื่องมือที่ทำให้ domain ทีมสามารถไป consume data และสร้าง data product ด้วยตนเองอย่างสะดวกสบาย - รวมถึงมี federated governance ที่คอยคุมให้ product ออกมาเป็น standard และตาม regulations
A data mesh architecture is a decentralized approach that enables domain teams to perform cross-domain data analysis on their own. At its core is the domain with its responsible team and its operational and analytical data.
Domain team คือใคร
เล่าเพิ่มอีกนิด
ตัวอย่างเช่น สมมติมีคนในทีม business มาบอกทีม data กลางว่า เธอๆทำ report ให้ทีมฉันหน่อย
ในทีมdataกลางก็จะมี data engineer ที่คอยกวาดdataมาให้ แล้วนำมาวางไว้ Data warehouse กลาง และมี Data Analyst ปั้น report ให้ (ถ้าในเคสที่ data analyst ไม่มี data eng ก็รับจบไป แล้วแต่องค์กรนะ ฮ่าๆ)
แต่พอมี Data Mesh
ทีม data กลางจะสลายไป แต่เป็นภาพของ Domain team คือคนมีความรู้ความเข้าใจใน domain นั้นๆ และทำงานร่วมกับ Engineer
ประโยชน์ที่ได้คือ report มีประสิทธิภาพมากขึ้น ! การ optimize process ต่างๆก็จะดีมากขึ้น เพราะทำงานกับคนรู้จริงโดยตรง
เอ๊ะ? แต่เห็นมีเจ้าก้อนสี่เหลี่ยม Data Product ด้วย มันคืออะไรกันนะ
Data Product คืออะไร ?
Data Product คือ ก้อน data ที่จะถูกนำไปใช้ทำการวิเคราะห์ข้อมูลหรือ use case ต่างๆ
ตัวอย่างเช่น
- BigQuery dataset
- ไฟล์ parquet ที่อยู่ใน Cloud Storage หรือ S3
- Message ใน Kafka topic ก็นับนะ
ซึ่งเจ้า Data Product ก็เกิดจาก Domain team ที่มี product owner และ engineer ทำงานร่วมกันก็ได้เช่นกัน สำหรับที่นี่ก็มี Analytics Engineer หรือ Data Analyst ร่วมด้วยในบาง domain
ซึ่งสุดท้ายแล้ว จะมี Data Discovery เป็นที่ๆรวบรวมว่า Data Product ตอนนี้ในองค์กรมีอะไรบ้าง คนในองค์กรหรือ domain อื่นๆก็สามารถเข้ามา explore แล้วนำมาใช้ประโยชน์ด้วย
ข้อดีอีกอย่างของ Data Discovery คือ ลดการทำ data product ที่ซ้ำซ้อนกันได้ด้วย
ในบทความนี้จึงขอใช้คำว่า Data Domain = Data Product ซึ่งหมายความว่ามันคือ output (ที่เป็น data) จาก domain team เนอะ
เล่า Data Domain อีกสักนิดนึง
เราคิดว่าทุกคนเข้าใจ Data Mesh ระดับหนึ่งแล้ว คราวนี้เราขอมาเจาะลึกที่ Data Domain กัน
คือเจ้า Data Domain เนี้ย มันมีหลาย level มาก
ถ้าตาม concept จะเป็นแบบรูปบนเลย เขาจะแบ่งออกเป็น 3 ประเภท ขอไล่จากล่างขึ้นบน
- Source-aligned
ตามชื่อเลย คือ data ที่มาจาก source เช่นพวกข้อมูล customer, order, shipment, invoice, product
2. Aggregate
เป็นอีกเลเวลที่เอาข้อมูลจาก source-aligned มายำเพื่อทำเป็น use-case ตอบโจทย์อะไรบางอย่าง
เช่น ทำ CRM หรือ Customer Relation Management คือเป็นข้อมูลกลางที่เราจะดูแล customer ได้ ซึ่งจะเกิดข้อมูลกลางนี้ได้มันก็ต้องดูด data มาจาก customer, shipment, invoice ที่อยู่ในชั้น source-aligned
3. Consumer-aligned
เลเวลนี้จะเป็น business ทีมที่นำ data มาเพื่อขับเคลื่อนอะไรสักอย่างเพื่อมาตอบโจทย์กับ Business unit ตัวเอง เช่นนำมาทำ reports, KPIs
ทีมที่อยู่ในเลเวลนี้ก็เช่น ทีม marketing, ทีมบริหาร
หากใครสนใจเรื่อง Data Mesh ใน TILDI ของเราก็มีพี่บีท Punsiri Boonyakiat สรุปเรื่อง Data Mesh ให้แล้ว
เราปูพื้นฐานมาได้พอสมควรละ คราวนี้โจทย์ต่อไปของเราคือ
“เราจะวัดผลการใช้งาน Data Domain เราอย่างไรดีนะ ?”
เพราะสำหรับบางองค์กรที่พยายามผลักดัน ‘การสร้างทีม Domain’ และ ‘การสร้าง Data Product’
ตัวองค์กรเองก็อยากรู้ว่า
- Domain team มีการ interact กันอย่างไร ?
- Data Product ที่ถูกสร้างขึ้นมา มีใครใช้มาก-น้อยแค่ไหน ?
หรือเป็นในมุมของแต่ละ Role ใน Domain
- Product Owner สงสัยว่า มีคนใช้ Data Product ของเรามากแค่ไหน ?
- Data Engineer สงสัยว่าคนที่ได้ผลกระทบเวลา pipeline พัง จริงๆมีใครบ้าง ?
- Analytics Engineer หรือ Data analyst สงสัยว่า มีคนใช้ Data Model (ในที่นี้มองเป็นส่วนหนึ่งของ Data Product) ที่ตัวเองสร้างนั้น มีใครบ้าง ? หาก Logic มีการปรับเปลี่ยนต้องแจ้งใคร ?
Data Domain Usage Monitoring
ด้วยเหตุนี้จึงเกิดเป็น Data Domain Usage Monitoring เพื่อจับตาดูว่าการใช้งานจริงของ Data Product นั้นมีมากน้อยแค่ไหน
ในที่นี้เราจะวัดแบ่งออกเป็น 2 กลุ่ม คือ
- กลุ่ม Producer — ผู้ให้บริการข้อมูล
เช่น พวก Customer, Product, Order
หรือถ้าตามที่เราเล่าไปข้างบนคือ Source-aligned นั่นเอง ซึ่งกลุ่มนี้จะเป็น source-aligned, Aggregate ก็ได้ ขึ้นอยู่กับว่าเขาเป็นคนให้คนอื่นใช้ Data product ของตัวเองไหม - กลุ่ม Consumer — ผู้ใช้ข้อมูล
เช่น Marketing, Management, E-commerce
หรือโปรเจคอื่นๆใน CJ เช่น Nine Beauty เป็นกลุ่มที่นำข้อมูลจาก Producer ไปใช้ทำ Dashboard, Report หรือ ML Model
Dashboard
จนสุดท้ายเราได้ทำ Dashboard มาโดยนำข้อมูล usage จริงจากการที่ user query จาก BigQuery ในแต่ละ Google Cloud Platform project
ในรูปดังกล่างนำข้อมูลบางส่วนมาแสดงผลเป็นตัวอย่าง ซึ่งเราขอแสดงผล 2 หน้าหลักๆให้ทุกคนได้ชมกัน
1. หน้า Overview
สิ่งที่เราสามารถ monitor ได้แค่
- จำนวน Domain
- จำนวน Producer Project
- จำนวน Consumer Project
- จำนวน Active User ในยอดเดือนนั้นๆ
- Domain ที่นิยมใช้เป็น provider มากที่สุด 5 อันดับแรก
- Domain ที่ consume ใช้ข้อมูล 5 อันดับแรก
ซึ่งเราสามารถเห็น top rank users ในเดือนนั้นได้เหมือนกันว่าเขาเป็นใครอยู่ทีมอะไร
เข้าใจว่า Domain ไหนเป็นต้นทางของใคร
ในภาพรวมเราจะเห็นความนิยมของ Data Domain ว่า project/product ไหนถูกใช้มากที่สุดและทราบ user ที่แวะเวียนมาใช้งานเรื่อยๆได้มาอยู่ domain ใด และแผนกไหนในองค์กร
เข้าใจพฤติกรรม user
และเราสามารถเข้าใจพฤติกรรมของเขาได้ เช่น เขา query บ่อยแค่ไหน (ดูจาก query count) เมื่อเทียบกับ Date Count (จำนวนวันที่ query ในเดือนนั้น)
หาก query เยอะและ Date Count แตะ 30 หรือ 31 ทุกวัน ก็เป็นไปได้ว่า user นี้อาจจะผูกไว้กับ Dashboard จึงมีจำนวน query ที่เยอะ
หรือการใช้งานปกติ จำนวน query เยอะแต่ date countแค่ 7 วันต่อเดือน ก็เป็นการใช้งานทั่วไปที่พบได้
2. หน้า Producer
หน้านี้จะเจาะลึกลงมาอีกชั้น
ดูว่า Domain นั้นให้บริการ Table ไหนบ้าง
และดู usage ที่ใช้ table นั้นได้เลยว่าใครใช้อยู่
หาก pipeline มีข้อผิดพลาด ไม่สามารถ deliver ข้อมูลได้ตามปกติ, Data Engineer สามารถเข้ามาดู dashboard นี้เพื่อดูว่าเขาคนนั้นเป็นใคร และแจ้งไปที่คนที่ใช้งานได้ถูกต้อง
ดูว่า table นั้น มี domain ใดที่ใช้อยู่บ้าง
เราจะเห็นออกมาเป็น donut เพื่อทราบจำนวน % คร่าวๆ และดูดีเทลได้ที่ตาราง Usage count ด้านข้าง
เพิ่มเติม
- ในบทความนี้ใช้ Data Masking ของ GCP เป็นตัวช่วยในการ mask sensitive data ที่แสดงผลในรูปด้วย
หากสนใจ สามารถอ่านเพิ่มเติมได้ที่นี่ค่ะ
- สำหรับการ implement pipeline และ data source เพื่อดึงข้อมูลมาแสดงผลบน Dashboard นั้นจะขอแบ่งออกเป็นอีกพาร์ท
พาร์ท 2
และเราจะพูดเรื่องนี้แบบเต็มๆในงาน Google I/O Cloud Extended 2024 ในงานวันที่ 14 July 2024 (สปอยนิดนึง555)
สามารถสมัครเพื่อรับตั๋วเข้างานได้ฟรีเลยนะคะ
Date: Sunday 14 July 2024
Time: 12:30 - 18.00 PM
Venue: K+ Building, 72 Soi Chula 20, Bangkok, 10330
Register Link: bit.ly/io-cloud-extended-2024
FB Event: https://www.facebook.com/share/L2b3cNuSTh3FCC8r/
Ref
- https://www.datamesh-architecture.com/ ->เขียนดีมาก แนะนำเลย
