Data Lake หรือ ถังขยะราคาแพงกันแน่?
Data Lake เป็น Storage/Repository ที่ใช้เก็บบันทึกข้อมูลขนาดใหญ่ โดยมี ELT (Extraction-Loading-Transformation) เป็นแนวทางการบริหารจัดการข้อมูลที่เหมาะสมกับ Data Lake ซึ่งทำให้เรายังคงรักษาสภาพเดิมของข้อมูลที่ได้รับมาจาก Data Source โดยไม่เปลี่ยนแปลงอะไรเลย หรือกล่าวอีกอย่างหนึ่งว่า Extract จาก Data Source มาแล้ว ก็ Loading เก็บลง Storage ของเราในแบบ Raw Format เลย. แต่ด้วยการใช้ Data Lake มักจะเกิดมีประเด็นบางอย่างที่ส่งผลต่อการบริหารจัดการข้อมูล จึงทำให้เราได้ “Data เละ” แทน Data Lake เป็นถังขยะใบใหม่ที่มีราคาแพง พร้อมของแถมคือปัญหาด้าน Data Quality มากมาย. บทความนี้จะขอกล่าวถึงความจำเป็นในการทำ ELT กับ Data Lake และประเด็นที่อาจเกิดขึ้นกับ Data Lake จากการทำ ELT ตลอดจนแนวทางแก้ไขบน Public Cloud.
ความจำเป็นในการทำ ELT กับ Data Lake
Data Lake รองรับการบริหารจัดการข้อมูล 2 แบบ แบบแรก คือ การทำ ETL ซึ่งเป็นวิธีการแบบดั้งเดิมในลักษณะเดียวกับที่ท่านเคยทำบนระบบบริหารจัดการฐานข้อมูลโดยทั่วไป เช่น การ Extract ข้อมูลมาจาก Data Source แล้วนำมาทำ Cleansing และ Transform ให้มีโครงสร้างแบบ Star Schema จากนั้นก็ Loading เข้าสู่ Data Lake แล้วใช้ Hive (Data Warehouse Software) สร้างเป็น Fact Table และ Dimension Table ต่อไป. ในแบบที่สอง คือ การทำ ELT เป็นวิธีการใหม่ที่เก็บข้อมูลในแบบ Raw Format ซึ่งจะไม่เกิดการสูญเสีย Information ที่มีความจำเป็นมากต่องานหลายๆ อย่าง. งาน Data Analytics ที่ผู้วิเคราะห์ข้อมูลมักจะต้องการข้อมูลในหลายๆ มุมมอง หลายครั้งเลยที่ผมพบว่า ข้อมูลจาก Database/Data Warehouse ไม่เพียงพอต่อการวิเคราะห์ในรายละเอียด เช่น ใน Database มีเพียงข้อมูลงบการเงินของกิจการ เฉพาะปีล่าสุดเท่านั้น ไม่มีข้อมูลงบการเงินของกิจการย้อนหลังไปในลักษณะ Historical Data เลย จึงเป็นเหตุให้ไม่สามารถทำ Time Series Analysis ได้. การทำ Fraud Analysis ที่ต้องใช้เทคนิคด้าน Machine Learning — Outlier Analysis นั้นจำเป็นอย่างยิ่งที่จะต้องได้ข้อมูลต้นฉบับมาทำการวิเคราะห์ หากข้อมูลถูก Cleansing ด้วยการกำจัดค่าว่างหรือ NULL ทิ้งไปแล้ว ก็จะทำให้การวิเคราะห์ที่เกี่ยวข้องกับการปกปิดข้อเท็จจริงที่ควรบอกให้แจ้งนั้น (ฉ้อโกง) ทำได้ยากยิ่งขึ้น.
การบริหารจัดการข้อมูลในแบบ ELT จึงดูเหมือนจะสร้างความสะดวกให้กับผู้เก็บรวบรวมข้อมูลและผู้บันทึกข้อมูลที่จะบันทึกอะไรก็ได้ลงไปใน Data Lakeโดยไม่ผ่านกฎเกณฑ์ที่เคร่งครัดเหมือนใน Database อีกต่อไป. ทั้งยังทำให้รองรับการทำ Analytics ที่หลากหลายมากขึ้น … ไม่ใช่แค่เพียงแค่นำข้อมูลไปทำ Summary Reports หรือ Dashboard ทั่วไปเท่านั้น.
ประเด็นที่อาจเกิดขึ้นกับ Data Lake
ความสะดวกและประโยชน์ที่ได้รับจากการใช้ Data Lake ด้วยการบริหารจัดการแบบ ELT อาจทำให้เราหลงลืมเรื่องสำคัญที่สุดของการบริหารจัดการข้อมูล คือ การเขียนคำอธิบายข้อมูล. แท้จริงแล้วคำอธิบายข้อมูลนั้นมีมานานแล้วตั้งแต่อดีต เช่น การทำ Data Dictionary ก็จัดว่าเป็นการอธิบายว่ามีข้อมูลอะไรบ้างในฐานข้อมูล เพื่อที่จะให้ผู้ใช้ได้เข้าใจว่าข้อมูลที่ตนเองอยากได้นั้นอยู่ในตารางข้อมูลไหน และมี Fields ชื่ออะไรบ้างที่ตัวเองอยากเห็น จะได้ระบุใน SQL Statement ได้อย่างถูกต้อง. ใน Data Lake ก็เช่นเดียวกัน ถ้าปราศจากคำอธิบายข้อมูลซึ่งสมัยนี้เรียกในชื่อใหม่ว่า Metadata แล้ว Data Analyst ก็คงทำงานลำบากมิใช่น้อย.
เมื่อไม่มี Metadata แล้วเกิดอะไรขึ้น? … ถ้าความจำดีหรือทำงานคนเดียวตลอดได้ตลอดไปก็คงไม่มีปัญหาอะไร. แต่ถ้าทำไม่ได้แล้ว เมื่อถึงคราวจะต้องใช้ข้อมูลที่เก็บไว้ ก็อาจจะจำไม่ได้ว่าเก็บไว้ที่ Path ไหน กว่าจะควานหาเจอก็ใช้เวลานาน (Non-Timeliness). ซ้ำร้ายถ้ายิ่งทำงานกันหลายๆ คน บนชุดข้อมูลเดียวกัน ก็อาจเจอข้อมูลเดียวกันที่มีมากกว่า 1 ชุดโดยที่แต่ละชุดมีข้อมูลที่ไม่เหมือนกันอยู่ด้วย (Inconsistent). อีกทั้งจำไม่ได้ด้วยแล้วว่า ข้อมูลนี้ได้มาจากไหน เราได้ลงมือทำอะไรกับข้อมูลไปบ้าง จะตรวจสอบย้อนกลับไปเพื่อดูความถูกต้องตรงกันกับแหล่งที่มาก็อาจเป็นเรื่องที่ทำได้ยาก จึงทำให้เราขาดความเชื่อมั่นในการใช้ข้อมูลเพราะกลัวว่าจะเป็นข้อมูลที่ไม่ถูกต้อง (Inaccurate). ทั้งหมดนี้เป็นประเด็นปัญหาด้านคุณภาพข้อมูลทั้งสิ้น.
แล้วทำไมผู้เกี่ยวข้องจึงไม่ทำ Metadata ไว้ล่ะ? … ทุกวันนี้ผมก็ใช้ Data Lake อยู่ขอตอบตรงๆ ว่า เมื่อ Data Lake ไม่มีกฎเกณฑ์ข้อจำกัด (Constraints) เหมือนใน Database แล้ว ด้วยความเร่งรีบและประมาทในเรื่องความจำ ในบางครั้งผมจึงเก็บข้อมูลลงใน Data Lake โดยไม่ได้ทำ Metadata ไว้ จากนั้นก็ไปทำงานอย่างอื่นต่อเลย.
Metadata ทำเพียงครั้งเดียวใช่หรือไม่? … องค์กรควรต้องจัดให้มีการปรับปรุง Metadata อย่างสม่ำเสมอ แต่การปรับปรุงฯ นี้ก็ไม่ง่ายเสมอไป ยกตัวอย่างเช่น หัวข้อ “The date the data set was modified” ซึ่งเป็น 1 ใน Metadata จำนวน 20 ตัว (ตาม ISO/IEC 11179 — Metadata Registry standard). ผมเจอประเด็นนี้ในงานโครงการด้าน Data Governance ของหน่วยงานภาครัฐไทยหน่วยงานหนึ่ง เพราะ ข้อมูลของหน่วยงานนี้เกิดขึ้นทุกวัน การ Tracing changes ที่เกิดขึ้นแบบนี้จึงอาจเป็นเรื่องที่ไม่สะดวกหากขาดเทคโนโลยีช่วย
แนวทางแก้ไข
จุดเริ่มต้นของการแก้ไข คือ การลงมือทำ Metadata โดยใช้ Tools เข้าช่วย ซึ่งเป็นไปได้ตั้งแต่ทำแบบ Manual โดยใช้ Microsoft Excel ตีตารางแล้วบรรจุหัวข้อ Metadata ตาม ISO/IEC 11179 ไปจนถึงใช้ซอฟต์แวร์เฉพาะทาง. อีกทางเลือกหนึ่ง วันนี้ Google Cloud มี Service ชื่อ Data Catalog ที่ใช้ทำ Metadata Management และมี Catalog ข้อมูล ซึ่งช่วยให้เข้าถึงข้อมูลได้สะดวกและทันต่อการใช้งานมากยิ่งขึ้น (Timeliness). แม้ว่าจะยัง Data Catalog จะยังไม่สามารถทำ Metadata tagging บนข้อมูลในทุก Services ของ Google Cloud ได้ แต่ก็เป็นสัญญาณที่ดีสำหรับการจัดทำ Metadata บน Public Cloud ซึ่งก่อนหน้านี้เป็นเรื่องที่ทำได้ยากมาก และไม่สะดวกยิ่ง.
เมื่อทำ Metadata เสร็จแล้ว การ Tracing changes ที่เกิดขึ้นกับข้อมูลสามารถใช้ Google Cloud Dataprep ซึ่งเป็น Cloud Service ตัวหนึ่งที่ใช้ทำ Data Preparation บนข้อมูลขนาดใหญ่ (Big Data). ผู้ใช้สามารถสร้าง Flow ในการปรับปรุงข้อมูลตั้งแต่ต้นจบจบแบบ End-to-End ซึ่งทำให้เห็นว่า Data มาจาก Source ไหนบ้าง แล้วผ่านกระบวนการปรับปรุงข้อมูลอะไรบ้าง จนกระทั่งนำผลลัพธ์จากการปรับปรุงไปเก็บไว้ที่ไหน. แม้ว่า Google Cloud Dataprep จะไม่ใช่ Tools สำหรับทำ Metadata โดยตรง แต่ผลพลอยได้จากใช้งาน เราจะได้ “Recipe as Wrangle” ที่สามารถดาวน์โหลดไป เพื่อ Trace ดู Changes ต่างๆ ที่เกิดขึ้นกับข้อมูลได้.
Changes ที่เกิดขึ้นกับข้อมูลมี 2 ประเภท คือ Metadata Change และ Change ในระดับ Content. “Recipe as Wrangle” จาก Google Cloud Dataprep ทำให้เราเห็น Metadata Change ตั้งแต่เก็บรวบรวมข้อมูลมาจนถึงปัจจุบันว่ามีการเปลี่ยนแปลงอะไรเกิดขึ้นกับโครงสร้างของข้อมูลบ้าง เช่น ข้อมูลเดิมมี 20 Attributes แต่ได้ผ่านการ Drop ทิ้งไปจำนวน 2 Attributes ประกอบด้วย Attributes ชื่อ “itemQuantity”, “itemRevenue” และมีการ Merge Attributes เกิดขึ้น จึงมีการเพิ่ม Attribute ใหม่ซึ่งเป็นผลลัพธ์จากการ Merge เข้ามาอีก 1 Attribute ชื่อ “unique_session_id” เป็นต้น. นอกจากนี้ “Recipe as Wrangle” จาก Google Cloud Dataprep ยังทำให้เราเห็นว่าเกิดการปรับปรุงเปลี่ยนแปลงอะไรไปบ้างในระดับ Content ด้วย เช่น มีการลบ Duplicated Records ทิ้งไป จำนวน 124 เรคคอร์ด เป็นต้น.
ด้วยเหตุนี้ “Recipe as Wrangle” จึงทำให้ผู้ใช้ข้อมูล เช่น Data Scientist, Data Analytics, Business Users ทราบที่มาที่ไปของข้อมูลและสามารถประเมินระดับความถูกต้อง (Accuracy), Consistency (ความถูกต้องตรงกันของข้อมูล) และเรื่องอื่นๆ ของ Data Quality ได้ไม่ยาก.
สรุปส่งท้าย
การมีข้อมูลอยู่ใน Data Lake แต่เราไม่กล้าที่จะใช้ข้อมูลนั้น ก็ไม่ต่างอะไรกับการมีขยะอยู่ในถัง … ข้อมูลนั้นคงไม่ใช่ Oil ที่แท้จริงในยุค 21 อีกต่อไป … Data Lake จึงอาจเป็นได้เพียงถังขยะราคาแพงที่เสียบปลั๊กมีไฟเลี้ยงไว้เท่านั้น (แถมยังเปลืองไฟอีก). การจัดทำ Metadata และ Tracing changes เป็นส่วนสำคัญของ Data Lineage และ Data Governance ที่จะช่วยให้เราได้รับข้อมูลที่มีคุณภาพ และเกิด Transparency of Data ซึ่งเป็นก้าวที่สำคัญยิ่งในการ Transform องค์กรของเราสู่ Data-Driven Enterprise ต่อไป.
