20 คะแนน โดย xguru 2020-11-23 | 2 ความคิดเห็น | แชร์ทาง WhatsApp

สรุปว่าทำไมถึงต้องมี Nemo, Amundsen, DataHub และพวกมันมีฟังก์ชันอะไรบ้าง

"ทำไมเราถึงต้องมี DDP? มันทำอะไรได้บ้าง?"

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

[ คำถามที่มักถามกันเวลาค้นหาข้อมูล ]

→ ข้อมูล "_____" หาได้จากที่ไหน? : บางครั้งอาจไม่รู้ด้วยซ้ำว่าควรค้นด้วยคำไหน จึงค้นหาชื่อตาราง/คอลัมน์ด้วยคำอย่าง click, page view เป็นต้น

→ ข้อมูลนี้คืออะไร? : ตารางนี้มีคอลัมน์อะไรบ้าง เป็นชนิดข้อมูลแบบไหน และค่าเหล่านี้มีความหมายว่าอะไร?

→ ต้องขอสิทธิ์เข้าถึงจากใคร? : ข้อมูลเรื่องความเป็นเจ้าของข้อมูลและสิทธิ์ก็ควรเป็นส่วนหนึ่งของเมทาดาทาด้วย

→ ข้อมูลนี้ถูกสร้างขึ้นมาอย่างไร? เชื่อถือได้ไหม? : ใครเป็นคนสร้าง และสร้างผ่านกระบวนการใด? นักวิเคราะห์ทำด้วยมือทุกเดือนหรือไม่? มีการใช้งานในบริษัทมากแค่ไหน? lineage ของข้อมูลนี้คืออะไร?

→ ควรใช้ข้อมูลนี้อย่างไร? : คอลัมน์ไหนเกี่ยวข้องกันบ้าง? ควร join กับตารางไหน? ถ้าจะจัดระเบียบข้อมูลควรใช้ฟิลเตอร์อะไร? คนที่ใช้ตารางนี้เป็นหลักคือใคร? (เพราะจะได้ไปถามคนนั้น) และมักใช้คอลัมน์ไหนบ้าง?

→ ข้อมูลนี้รีเฟรชบ่อยแค่ไหน? : ถ้าบางครั้งมีความล่าช้า เกิดขึ้นบ่อยแค่ไหน? ข้อมูลครอบคลุมช่วงเวลายาวเท่าไร? ถ้ามีแค่ไม่กี่สัปดาห์ก็คงไม่เหมาะกับงานแมชชีนเลิร์นนิง

[ ฟังก์ชันสำหรับการค้นหา ทำความเข้าใจ และใช้งานข้อมูล ]

  • ค้นหาข้อมูล หรือค้นด้วยวิธีที่ฉลาดกว่าเดิม

→ วิธีพื้นฐานในการหาข้อมูลที่ต้องการคือค้นหาเมทาดาทา เช่น ชื่อคอลัมน์ คำอธิบายของตารางและคอลัมน์ รวมถึงคำอธิบายหรือคอมเมนต์ที่ผู้ใช้ป้อน ไว้ใน ElasticSearch

→ หากผลการค้นหามีจำนวนมาก ก็จำเป็นต้องจัดลำดับความสำคัญ สำหรับ Lyft และ Spotify จะจัดอันดับจากความถี่ในการใช้งานตาราง กล่าวคือ parse query log แล้วนำข้อมูลการใช้งานตารางไปใส่เป็นข้อมูลจัดอันดับใน ElasticSearch

→ Nemo ของ Facebook ขยายแนวคิดนี้ไปอีกขั้น โดย parse คำค้นแบบภาษาธรรมชาติด้วย spaCy และใช้ Unicorn ที่ใช้ค้นหา social graph เพื่อจัดอันดับผ่านการให้คะแนนแบบ kNN เป็นต้น

→ อีกวิธีหนึ่งคือการแนะนำข้อมูล โดยแนะนำข้อมูลที่มีการเข้าถึงและใช้งานมากที่สุดในองค์กรและในทีม

  • ทำความเข้าใจข้อมูลด้วย schema, preview, สถิติ, lineage

→ ข้อมูลพื้นฐานสำหรับทำความเข้าใจตารางคือ schema ของข้อมูล : ชื่อคอลัมน์ ชนิดข้อมูล และคำอธิบาย (Description)

→ หากผู้ใช้มีสิทธิ์อ่าน ก็สามารถแสดง preview ของข้อมูลได้ (ประมาณ 100 แถว)

→ ยังสามารถให้สถิติที่คำนวณไว้ล่วงหน้าในระดับคอลัมน์ได้ด้วย : จำนวนแถวของแต่ละคอลัมน์ จำนวนแถวที่เป็น Null ค่าสูงสุด/ต่ำสุด/เฉลี่ย/มัธยฐาน/ส่วนเบี่ยงเบนมาตรฐาน จำนวนค่าที่ไม่ซ้ำกัน และถ้าเป็นคอลัมน์วันที่ก็แสดงช่วงเวลาทั้งหมดของข้อมูล

→ มีการแสดง lineage ของข้อมูลเพื่อให้เห็นความสัมพันธ์ของ dependency ทั้งก่อนหน้าและถัดไป : สำหรับงาน ETL (ที่ schedule ด้วย Airflow) สามารถตรวจสอบ schedule หรือความล่าช้าได้ด้วย

  • เรียนรู้วิธีใช้ข้อมูลจากรูปแบบการใช้งานของผู้ใช้อื่น

→ เมื่อเจอตารางแล้ว จะช่วยให้ผู้ใช้เรียนรู้วิธีใช้ตารางนั้นได้อย่างไร? วิธีง่ายที่สุดคือแสดงรายชื่อคนที่เกี่ยวข้องกับตารางนั้น

→ เจ้าของข้อมูลอาจเป็นผู้ให้สิทธิ์ได้ และผู้ใช้ประจำก็อาจช่วยอธิบายภาพรวมหรือข้อสังเกตของข้อมูลได้ : Amundsen และ DataHub สามารถเชื่อมคนเป็นเอนทิตีกับตารางได้

→ แต่ถ้าพึ่งพาเฉพาะผู้เชี่ยวชาญที่รู้ข้อมูลนั้นดี ก็อาจเกิดคอขวดได้ ดังนั้นการเชื่อมโยงเมทาดาทาเพิ่มเติมจึงเป็นวิธีที่ scalable กว่า

→ สามารถให้สถิติการใช้งานของแต่ละคอลัมน์ เพื่อช่วยให้ผู้ใช้หาคอลัมน์ที่เกี่ยวข้องมากที่สุดได้

→ และเพื่อให้รู้ว่าควร join ตารางนี้กับตารางใด การแสดงรายการตารางที่มักถูก join ร่วมกันและคอลัมน์ที่ใช้ join ก็มีประโยชน์ ข้อมูลลักษณะนี้จำเป็นต้อง parse query log

→ หากต้องการให้ข้อมูลเชิงลึกด้านการใช้งานมากขึ้น ก็สามารถแสดง query ล่าสุดของตารางนั้นได้ ซึ่งช่วยให้รู้ว่ามีการกรองข้อมูลจริงอย่างไร

→ lineage ของข้อมูลก็มีประโยชน์เช่นกัน สามารถรู้ได้ว่ามี downstream table ใดใช้ตารางปัจจุบันอยู่ และแสดง query ที่ใช้สร้างมันได้ด้วย จึงมองเห็นได้ว่าตารางนั้นถูกนำไปใช้กับ use case อื่นอย่างไร

→ ถ้า downstream table ที่ค้นพบตรงกับเป้าหมายของเรา ก็สามารถนำมาใช้แทนได้ ช่วยลดต้นทุนการคำนวณ/การจัดเก็บ

→ Data Access Layer ของ Twitter, Databook ของ Uber และ Metacat ของ Netflix ต่างก็รองรับ lineage

→ ก่อนจะใช้ข้อมูลจริง ผู้ใช้ยังอยากรู้ด้วยว่าข้อมูลอัปเดตบ่อยแค่ไหน การระบุว่าข้อมูลถูก partition ตามหน่วยเวลาใด (วัน/ชั่วโมง เป็นต้น) จึงมีประโยชน์

→ DDP สามารถเชื่อมกับแพลตฟอร์มอย่าง Airflow เพื่อตรวจสอบงาน ETL ที่ถูก schedule ไว้ และดูได้ว่าใช้เวลานานเท่าไร เป็นต้น

[ เปรียบเทียบ DDP แต่ละตัวในภาพรวม ]

→ ทุกตัวรองรับการค้นหาแบบ free-text บน ElasticSearch หรือ Solr ส่วน Amundsen และ Lexikon มีฟังก์ชันแนะนำบนหน้าแรก

→ ทุกตัวแสดงข้อมูลพื้นฐานของตาราง (schema, คำอธิบาย) ส่วน Amundsen และ Databook มี preview ข้อมูลและสถิติคอลัมน์

→ แพลตฟอร์มส่วนใหญ่มีฟังก์ชัน data lineage ในตัว ยกเว้น Amundsend ที่ตอนนี้ยังไม่รองรับ แต่มีอยู่ใน roadmap ปี 2020

→ มี 5 แพลตฟอร์มที่เปิดเป็นโอเพนซอร์ส

[ เปรียบเทียบ DDP แบบโอเพนซอร์ส ]

→ เปิดเผยในเดือนกุมภาพันธ์ 2020

→ รองรับการค้นหา, table schema, ownership, lineage

→ รองรับ 3 เอนทิตีคือ Dataset, User, Group และมีแผนจะเพิ่มเอนทิตีอย่าง Schemas/Jobs/Metrics/Dashboards

→ รองรับเมทาดาทาของ Hive, Kafka, RDB (ภายในองค์กรรองรับมากกว่านี้ และอาจเปิดเผยเพิ่มเติมในอนาคต)

→ Expedia, TypeForm นำไปใช้แล้ว และ MS, Morgan Stanley, Orange Telecom, ThoughtWorks ฯลฯ กำลังทำ POC

→ เปิดเผยในเดือนตุลาคม 2019

→ รองรับการค้นหา, คำแนะนำ, หน้าแสดงรายละเอียดตารางที่ถ่ายทอด preview/สถิติคอลัมน์/เจ้าของ/ผู้ใช้หลักได้ดี ยังไม่มี lineage แต่มีแผนเพิ่ม

→ มีแผนรองรับการเชื่อมกับ Data Quality System ด้วย (น่าจะเป็น Great Expectations - https://greatexpectations.io/)

→ มี community ที่ยอดเยี่ยม : มีการพัฒนาและ contribute การเชื่อมต่อกับ BigQuery/Redshift/Apache Atlas เป็นต้น

→ รองรับการเชื่อมต่อกับแหล่งข้อมูลมากกว่า 15 ประเภท (Redshift, Cassandra, Hive, Snowflake และ RDB ต่าง ๆ), dashboard อย่าง Tableau, Redash, Mode Analytics รวมถึง Airflow

→ เอกสารทำไว้ดี และสามารถทดสอบบนเครื่องโลคัลด้วย Docker ได้

→ มีองค์กรนำไปใช้มากกว่า 30 แห่ง รวมถึง Asana, Instacart, iRobot, Square

→ เข้าร่วมเป็นโครงการ incubation ใหม่ของ Linux AI Foundation ในเดือนกรกฎาคม 2020

→ เปิดเผยในเดือนมิถุนายน 2018

→ มีการค้นหา, ดู schema และมี metrics สำหรับวิเคราะห์ต้นทุนและพื้นที่จัดเก็บ

→ มีฟังก์ชันแจ้งเตือนการเปลี่ยนแปลงของตาราง/พาร์ทิชัน สามารถรับการแจ้งเตือนเมื่อถูกลบเพราะปัญหาเรื่องต้นทุน เป็นต้น

→ รองรับการเชื่อมต่อกับ Hive, Teradata, Redshift, S3, Cassandra, RDS

→ เคยระบุว่ากำลังพัฒนาฟังก์ชัน versioning/validation ของ schema/metadata

→ แม้จะเป็นโอเพนซอร์ส แต่ไม่มีเอกสารเลย จึงยังไม่มีบริษัทไหนนำไปใช้

→ เปิดเผยในเดือนตุลาคม 2018

→ เน้นเรื่อง data quality และ lineage

→ รองรับ data governance, data quality ผ่าน Great Expectations และ catalog สำหรับ dataset กับ job

→ มี WebUI รวมถึงคอมโพเนนต์ Airflow และไคลเอนต์ Java/Python ให้

→ สามารถทดสอบบนเครื่องโลคัลด้วย Docker ได้ แต่เอกสารยังมีไม่มาก

→ เริ่มต้นในเดือนกรกฎาคม 2015 ในฐานะส่วนหนึ่งของ Data Governance Initiative

→ เวอร์ชัน 1.0 เปิดเผยในเดือนมิถุนายน 2018 และปัจจุบันคือ 2.1

→ เป้าหมายหลักคือ data governance เพื่อช่วยให้องค์กรปฏิบัติตามข้อกำหนดด้านความปลอดภัย/คอมพลายแอนซ์

→ มีฟังก์ชันที่หลากหลาย เช่น การติดแท็กทรัพยากร การกระจายแท็กไปยัง downstream dataset และความปลอดภัยในการเข้าถึงเมทาดาทา

→ รองรับฟังก์ชันแจ้งเตือนการเปลี่ยนแปลงเมทาดาทาด้วย

→ รองรับการค้นหาแบบ free-text, การดูรายละเอียด schema และ data lineage

→ รองรับการค้นหาขั้นสูงด้วยไวยากรณ์คล้าย SQL

→ รองรับการเชื่อมต่อกับแหล่งเมทาดาทาอย่าง HBase, Hive, Kaflka เป็นต้น

→ สามารถสร้าง/แก้ไขเมทาดาทาผ่าน REST API ได้ด้วย

→ เอกสารทำไว้ดีเช่นกัน

  • กรณีที่ ING นำ Atlas และ Amundsen มาใช้ร่วมกันนั้นน่าสนใจ https://medium.com/wbaa/…

  • แม้จะไม่ใช่ DDP แบบสมบูรณ์ แต่โอเพนซอร์ส Whale เป็นเครื่องมือ DDP แบบเรียบง่ายมากที่ทำดัชนีเนื้อหาใน data warehouse เป็น Markdown และรองรับการค้นหา/แก้ไข/versioning

→ น่าลองดูในฐานะเครื่องมือ DDP สำหรับนักพัฒนา https://github.com/dataframehq/whale

  • แม้จะไม่เซ็กซี่เท่าแมชชีนเลิร์นนิง แต่ data discovery คือขั้นตอนแรกที่สำคัญในเวิร์กโฟลว์ของ data science

2 ความคิดเห็น

 
toughrogrammer 2020-11-23

โอ้ สรุปได้ดีมากเลยครับ/ค่ะ ไว้ต้องลองใช้ Amundsen ดูสักครั้งแล้ว

 
xguru 2020-11-23

Nemo - แพลตฟอร์มการค้นหาข้อมูลของ Facebook https://th.news.hada.io/topic?id=3024

กรณีศึกษาการสร้าง DDP ที่หาได้ไม่มากนักในประเทศ