วัดผลการใช้งานข้อมูลในองค์กรด้วย Data Domain Usage Monitoring — Part 2

บทความนี้เป็นภาคต่อพาร์ทที่แล้ว

Data Domain Usage Monitoring — วัดผลการใช้งานข้อมูลในองค์กร

ซึ่งพาร์ทที่แล้วเราเล่าว่า Data Product คืออะไร และ Data Mesh มีหน้าตายังไง สามารถช่วยองค์กรในด้านใดบ้าง

ในพาร์ทนี้เราจะเล่าด้าน technical โดยพูดถึงวิธี implement เจ้า Data Usage Monitoring ตั้งแต่ data source ที่นำมาใช้วิเคราะห์ข้อมูล, หน้าตา pipeline จากต้นน้ำยันปลายน้ำ และหน้าตาข้อมูลสุดท้าย (Data Model) ที่นำไปปั้นใส่ Dashboard หรือ Looker Studio

Table of Contents
- เข้าใจลักษณะขององค์กร
- แล้วเราอยากรู้อะไร?
- Data Sources
- Pipeline
- Data Model
- Looker Studio
- สรุป

เข้าใจลักษณะขององค์กร

ก่อนที่เราจะเริ่มตามหาว่าเราจะใช้ข้อมูลที่ไหนเพื่อนำมาวิเคราะห์ได้บ้าง เราต้องเข้าใจก่อนว่าโดยทั่วไปแล้วองค์กรใช้ข้อมูลกันยังไง

สำหรับที่ CJ Express แล้ว เราสามารถพูดได้ว่าเราเป็น Google BigQuery (Lover) เลยก็ว่าได้ เพราะเป็นเครื่องมือที่ค่อนข้างสะดวกในการหา insights ของข้อมูล และ performance การ query ค่อนข้างดี

เพียงแค่รู้ SQL เราก็สามารถเสกทุกอย่างได้ในพริบตา

ดังนั้นหลังจากที่ดึงข้อมูลมา transform อะไรเสร็จสิ้นแล้ว Data Engineer จะพยายามนำข้อมูลนี้ไป serve ให้บน BigQuery เพื่อให้ user นั้นใช้งานง่ายที่สุด

ในขณะเดียวกัน Analytics Engineer ก็ช่วยปั้น Data Model และนำไป serve บน BigQuery เช่นกัน

และ Data Analyst เองก็นำก้อนดาต้านี้ไปหมุน dashboard และทำ report เพื่อตอบโจทย์ business

โดยทุก Data Product ที่ Data Engineer, Analytics Engineer, Data Analyst เป็นคนสร้างขึ้นมา เราจะนำขึ้น DataHub ที่ทำตัวเป็น Data Discovery กลาง เพื่อให้บุคคลอื่นๆในองค์กรสามารถเข้ามา shopping ดูได้ว่าองค์กรเรามีข้อมูลอะไรให้บริการบ้าง (จากรูปคือเส้นสีส้มและไปถึงฝั่งขวา)

DataHub ทำหน้าที่เหมือนตัวแสดงผล, ค้นหา, ทำความเข้าใจลักษณะข้อมูลที่พร้อมให้ใช้ ซึ่งเรา install ataHub และ host และ manage เองบน Kubernetes ไม่ได้ใช้ DataHub Managed service แบบเสียตัง

แล้วเราอยากรู้อะไร?

คำถามที่สำคัญมากๆ (เส้นสีม่วง)

• เราจะรู้ได้ไงว่าหลังจากที่ทั้ง 3 role ขนและปั้นข้อมูลให้เสร็จสรรพขึ้น BigQuery พร้อมให้บริการแล้ว (Domain A, B, C) มันมีคนใช้ data จริงๆไหม ?
• เราจะรู้ได้ไงว่า Domain C ใช้ข้อมูลจาก Domain อะไรบ้าง ?
• เราจะรู้ได้ไงว่า user ที่ใช้หรือ query ข้อมูล เขาเป็นใคร? อยู่ตำแหน่งอะไรในองค์กร?

Data Sources

ต้นทางของข้อมูลจะมี 3 ตัวคือ

1. Table ที่ให้บริการบน DataHub
2. ข้อมูลการใช้งาน data
3. ข้อมูลคนในองค์กร

1. Table ที่ให้บริการบน DataHub

จริงๆมีหลายวิธีในการดึงข้อมูลจาก DataHub เลย

ในเคสนี้เราจะดึงจาก DataHub OpenAPI ที่เขามีเตรียมไว้ให้แล้ว ซึ่งมันทำให้เราสามารถดึงพวก BigQuery Dataset จากใน DataHub ได้ผ่าน REST-API ซึ่งเข้าไปแล้วจะเป็น SWAGGER ว่ามี API อะไรให้ใช้บ้าง

ซึ่ง structure ใน DataHub จะมี 2 ตัว

• Domain เช่น Member master, Sale, Order หรือ Domain team ที่เราเคยเล่าในบทความที่แล้ว
• Dataset เช่น BigQuery Dataset หรือ Data product นั่นเอง

โดยที่ Dataset นั้นจะถูกผูกอยู่ใน Domain อีกที เหมือนที่ Data Product เป็นของ Domain team นั้นๆ

ดึงข้อมูล DataHub dataset

โดยเราจะใช้ API openapi/v2/entity/dataset โดยเพิ่ม params aspects=domains ไปด้วย เพื่อให้มันคืน dataset แบบแนบ domain

curl -X 'GET' \\\\
  '<https://<your_datahub_link>/openapi/v2/entity/dataset?systemMetadata=false&aspects=domains&count=10&query=%2A>' \\\\
  -H 'accept: application/json'

โดยผลลัพท์จะได้เป็น json มา

example response:

"entities": [
    {
      "urn": "urn:li:dataset:(urn:li:dataPlatform:bigquery,<gcp_project_id>.member_master_serving.member_consent,PROD)",
      "datasetKey": {
        "value": {
          "__type": "DatasetKey",
          "platform": "urn:li:dataPlatform:bigquery",
          "name": "<gcp_project_id>.member_master_serving.member_consent",
          "origin": "PROD"
        }
      },
      "domains": {
        "value": {
          "__type": "Domains",
          "domains": [
            "urn:li:domain:AAAA-BBBBBB-CCCCCCCCCC"
          ]
        }
      }
    },

ผลลัพท์จะให้ entities โดยคืน URN (Uniform Resource Name) ซึ่งเป็นการใช้เรียก resource ต่างๆใน DataHub

ซึ่ง URN ก็จะบอกว่ามี Dataset และ domain อะไรบ้าง

ในตัวอย่างนี้เราแสดงผลแค่เพียง 1 ค่า ความจริงแล้วมี URN หลายตัวเลย

แล้วเรา convert ตัวนี้ให้เป็นตาราง

ซึ่งค่า Domain ที่เราได้จะเป็น urn ที่ unique แบบอ่านไม่รู้เรื่อง เราเลยต้องเรียก API ตัว domain อีกตัว

ดึงข้อมูล DataHub domain

openapi/v2/entity/domain

curl -X 'GET' \\
  'https://<your_datahub_link>/openapi/v2/entity/domain?systemMetadata=false&aspects=domainProperties&count=10&query=%2A' \\
  -H 'accept: application/json'

response:

{
  "scrollId": "eyJzb3J0IjpbInVybjpsaTpkb21haW46NWVjMTQwZTMtMTMxOS00NTQ1LTlhMGMtOWJiMmJiNjAxMDI0Il0sInBpdElkIjpudWxsLCJleHBpcmF0aW9uVGltZSI6MH0=",
  "entities": [
    {
      "urn": "urn:li:domain:AAAA-BBBBBB-CCCCCCCCCC",
      "domainKey": {
        "value": {
          "__type": "DomainKey",
          "id": "AAAA-BBBBBB-CCCCCCCCCC"
        }
      },
      "domainProperties": {
        "value": {
          "__type": "DomainProperties",
          "name": "Member Master",
          "created": {
            "time": 1714122172343,
            "actor": "urn:li:corpuser:datahub"
          }
        }
      }
    },
    {
      "urn": "urn:li:domain:DDDD-EEEEE-FFFFFFFFFFF",
      "domainKey": {
        "value": {
          "__type": "DomainKey",
          "id": "DDDD-EEEEE-FFFFFFFFFFF"
        }
      },
      "domainProperties": {
        "value": {
          "__type": "DomainProperties",
          "name": "Product Master",
          "created": {
            "time": 1708681656734,
            "actor": "urn:li:corpuser:datahub"
          }
        }
      }
    }
  ]
}

จะเห็นได้ว่าใน domainProperties มันจะให้ค่า name ที่อ่านรู้เรื่องมาให้

คราวนี้เรา convert มาเป็นตาราง

ขั้นตอนถัดไปก็เพียง merge 2 table นี้เข้าด้วยกัน ก็จะแมปได้ว่า dataset นี้เป็นของ domain อะไร

2. ข้อมูล log การใช้งาน data

— ดึงข้อมูล query จาก INFORMATION_SCHEMA.JOBS_BY_PROJECT

เมื่อเรา query 1 ครั้งใน BigQuery จะเกิดเป็น 1 Job ในโปรเจคนั้น

โชคดีที่ BigQuery มีสิ่งนี้มาให้ นั่นคือ view ที่เราสามารถดูข้อมูล Job ที่เกิดขึ้นใน GCP โปรเจคนั้นๆได้

โดยการ query จาก

[PROJECT_ID.]`region-REGION`.INFORMATION_SCHEMA.JOBS[_BY_PROJECT]

ความเทพของมันคือ มันมี field ที่ชื่อว่า referenced_tables ที่จะคืนค่าว่า query นั้นใช้จาก project, dataset, table ไหน

พูดไปอาจจะไม่เห็นภาพ งั้นเราลอง query และโชว์ผลลัพท์ให้ดูดีกว่า

query:

result:

นั่นคือ เรา query ที่โปรเจค domain_c_project (โปรเจคเรารันใน BigQuery) ด้วย query ด้านล่าง

select * from `domain_a_project.member_master_serving.member_consent` limit 10

โดยการใช้ table ที่อ้างอิงใน query คือโปรเจค domain_a_project

• ref_tables เป็นคนบอกว่าต้นทางคืออะไรบ้าง นั่นคือ
• ref_tables.project_id = domain_a_project
• ref_tables.dataset_id = member_master_serving
• ref_tables.table_id = member_consent

หรืออีกตัวอย่าง ที่ advance ขึ้นมาหน่อย

สมมติเรามี query ที่ค่อนข้างซับซ้อนมากๆ มีการ join table ถึง 5 ตัวเลย

• table ทั้ง 5 นั้นมาจาก sales-project, branch-project, และ ecommerce-project
• เรา query ที่โปรเจค ecommerce-project
• นั่นหมายความว่า producer project จะเป็น sales-project, branch-project นั่นเอง แต่ในเคสนี้ table ใน branch-project ไม่ได้อยู่บน DataHub ก็จะไม่ถูกนับว่าเป็น producer project จึงเหลือเพียง sales-projectนั่นเอง
• consumer project จะมีเพียง ecommerce-project เนื่องจากเราคิวรี่ที่โปรเจคนี้

3. ข้อมูลคนในองค์กร

สำหรับข้อมูลตรงนี้ก็ไม่ซับซ้อนอะไร ก็เป็นข้อมูลคนในองค์กรว่าใครทำหน้าที่อะไร, อยู่ทีมอะไร ซึ่งจะมาเสริมมิติให้กับ data model ของเราว่าคนที่ใช้งานข้อมูลเขาเป็นใคร เขาเป็น data analyst รึเปล่า หรือเป็น superuser ที่สามารถใช้ข้อมูลได้คล่องแคล่วอิสระ และเราจะช่วยเหลือเขายังไงได้บ้าง

Pipeline

สำหรับ pipeline เราดึงข้อมูลจาก 3 sources แบบ automate โดยใช้ Airflow เข้ามาช่วยจัดการ task ต่างๆและรันแบบ daily

โดยที่ทั้ง 3 ต้นทางนี้จะ join รวมกันที่ serving zone และได้ผลลัพท์คือ master_serving

ซึ่ง master_serving ของเรานั้น แท้จริงแล้วคือไฟล์ parquet ที่มีการทำ partitioning ไว้ master_serving/year=xxxx/month=xx/day=xx เก็บไว้ใน Google Cloud Storage

โดยที่เราสร้างเทเบิล BigQuery ขึ้นมา เป็นประเภท BigLake table เนื่องจากมันให้ข้อดีมากกว่า BigQuery External table ทั่วไปในด้านใน grant access และความสามารถด้าน Row-level security, column-security และ Data Mask

cr. รูปจาก https://www.youtube.com/watch?v=D4BhIraXP-I

ผู้อ่านสามารถศึกษา BigLake table ได้จากบทความนี้เช่นกัน เขียนโดย Nawaphon Thiandusit

BigLake แบบจับมือทำ

Data Model

Data ที่ join กันแล้ว หน้าตาแบบไหน ?

ยกตัวอย่างเช่น คุณ dante หัวหน้าแผนก C เข้าไปคิวรี่ที่โปรเจค cdp-pj โดยใน query มีการอ้างอิงที่ table ในโปรเจค assortment-pj ที่ table ชื่อ pog_article มาจาก domain ชื่อ Planogram (POG) ในวันที่ 18 มิถุนายน 2024

มันจะทำให้เรารู้ว่า table ต้นทางนี้ถูกใช้โดยโปรเจคไหน

Looker Studio

สุดท้ายแล้ว เราก็ create report โดยเลือกต้นทางเป็น BigQuery

และเลือก project, dataset, table เป็นเจ้า master_serving ที่เราปั้นเอาไว้

และหลังจากนั้นก็ customize report ได้ดั่งใจนึก

คำอธิบายของ report นี้จะอยู่ในพาร์ทแรกค่ะ

ซึ่ง report ในหน้านี้นั้น เราใช้ฟีเจอร์ที่ชื่อว่า Data Masking เพื่อ sensor sentitive ทั้งหลาย

สรุป

เราเชื่อมั่นว่า report นี้จะเข้ามาตอบคำถามที่เราสงสัยมาตลอดว่าการสร้าง Data Platform และการนำคอนเซ็ปต์ Data Mesh มาใช้ในองค์กรนั้นจะถูกวัดผลได้อย่างไร มีบุคคลเข้ามาใช้จริงๆหรือไม่

และเราก็หวังว่า metric ต่างๆในหน้านี้จะเป็นการช่วยติดตามผลลัพท์ได้ ไม่ว่าจะฝั่งคนผลิต data product เอง (producer) หรือผู้ใช้งาน data product (consumer)

และหวังว่าในอนาคต ตัวเลข นี้จะเพิ่มมากขึ้นและทำให้เราเข้าใจในตัว user ผู้ใช้มากขึ้น

เพิ่มเติม

dashboard นี้จะเน้นที่ usage เป็นหัวใจ หากมองเป็นเรื่อง cost เป็นหลักก็จะมีอีก dashboard ที่ในมิติด้าน cost โดยเฉพาะ และอัพเดทแบบ hourly ที่เร็วกว่าความต้องการใน Data Usage ตัวนี้

สามารถศึกษาได้ในบทความ FinOps ที่เราและ Nitit Taepant เขียนไว้ค่ะ

FinOps: Our Team's Journey to Saving on BigQuery Usage (Over $300!)

Finops: Journey to improve and manage the cost of BigQuery