Across the lake to the Data Lakehouse

Next Kid in Town the "Data Lakehouse"

credit: ภาพประกอบจาก unsplash.com

สำหรับพวกเราที่อยู่ในสายงานข้อมูล ระบบงานที่เกี่ยวกับฐานข้อมูลขนาดใหญ่นั้นมีทั้ง Data Warehouse และ Data Lake ที่มาพร้อม Big Data บางองค์กรก็อาจมีอย่างใดอย่างหนึ่ง หรือมีทั้ง 2 แบบเลย เร็วๆ นี้ก็มีคำใหม่อย่าง Data Lakehouse ที่พยายามรวมข้อดีจากทั้ง Data Warehouse และ Data Lake เข้าด้วยกัน ว่าแต่มันคืออะไรกันนะ และถ้าองค์กรเรามี Data Warehouse หรือ Data Lake อยู่แล้ว จะต้องมีเพิ่มอีกมั้ย แต่พอหาข้อมูลดูแล้ว ต่างคนต่างก็ให้นิยามที่ต่างกัน ชวนให้สับสนเข้าไปอีก แล้วแต่ว่าข้อมูลมาจากค่ายไหน หรือกำลังขายอะไร บ้างกว่าเป็นสถาปัตยกรรมด้านการจัดการข้อมูลใหม่ระดับ paradigm shift ไปนั่นเลย เลยมาชวนกันคิดว่าเจ้าตัว Data Lakehouse ที่มีพูดกันถึงในระยะนี้มันคืออะไรกันแน่นะ หรือถ้าจะมีจริงๆ มันควรมีคุณสมบัติอะไรบ้าง เราควรเตรียมจะขนข้าวของย้ายจาก Data Warehouse หรือ Data Lake ไปอยู่บ้านใหม่ริมทะเลสาบกันดีมั้ย

หัวข้อชวนคุย

1. Data Warehouse, Data Lake คืออะไรและแตกต่างกันอย่างไร

1.1 Data Lake

1.2 Data Warehouse

2. Data Lakehouse คืออะไร

2.1 Data Lakehouse

2.2 Features of a Data Lakehouse

3. บทสรุป อนาคตของ Data Lakehouse


1. Data Warehouse, Data Lake คืออะไรและแตกต่างกันอย่างไร

ก่อนจะเก็บของเตรียมย้ายบ้าน เรามาดูกันก่อนว่าคุณลักษณะของ Data Warehouse และ Data Lake กัน จะได้เห็นภาพว่า Data Lakehouse นั้น เข้ามาเติมเต็มตรงไหน 


Data Lake: high level ภาพประกอบโดยผู้เขียน

1.1 Data Lake จะว่าไปก็เหมือนตลาดสด มักอยู่ต้นน้ำของกระบวนการด้านข้อมูล รองรับข้อมูลดิบ หรือกึ่งสุกกึ่งดิบที่ยังไม่ผ่านการปรุงแต่ง เนื่องจากเน้นการเก็บข้อมูลปริมาณมากๆ จึงเน้นพื้นที่เก็บข้อมูลที่มีต้นทุนต่ำ รองรับข้อมูลได้หลากหลาย ข้อมูลแบบมีโครงสร้างชัดเจน (structured data) กึ่งโครงสร้าง (semi structured data) แต่มักจะเน้นการเก็บข้อมูลแบบไม่มีโครงสร้าง (unstructured data) ด้วยที่มันไม่จำกัดโครงสร้างของข้อมูล จึงมีความคล่องตัวสูง แต่จากความดิบของข้อมูล ผู้ใช้ข้อมูลต้องใช้ความพยายามมากซักหน่อย และในจุดเด่นเรื่องความคล่องตัวของ Data Lake ถ้าไม่มีการจัดการที่ดีพอ ก็มีปัญหาตามมาเหมือนคลองใน กทม. คือใครจะโยนอะไรลงไปก็ได้ ไฟล์จะเปลี่ยนฟอร์แมทเมื่อไหร่ก็ได้ และเนื่องจากต้องรองรับข้อมูลหลายรูปแบบ การทำงานกับข้อมูลแบบมีโครงสร้างทำได้จำกัดมาก ไม่ว่าจะเป็นการกันสิทธิในการเข้าถึงข้อมูลบางส่วนของไฟล์หรือชุดข้อมูล ไม่สามารถ update ข้อมูลเป็นส่วนๆได้ จึงเหมาะกับการใช้งานในบางรูปแบบเท่านั้น และเป็นกลุ่มผู้ใช้งานที่มีทักษะสูง อย่าง data scientist ทำให้มักถูกใช้เป็นม้างานของงานปัญญาประดิษฐ์ (Artificial Intelligence)



Data Warehouse
Data Warehouse: high level ภาพประกอบโดยผู้เขียน

1.2 ส่วน Data Warehouse เหมือนร้านอาหารมีได้ตั้งแต่ร้านริมทางไปจนถึงร้านหรูๆ รับข้อมูลดิบๆ สุกๆ เข้ามาผ่านกระบวนการ จัดเตรียม ปรุงแต่ง เพื่อให้ใช้งานง่าย ข้อมูล รูปแบบการใช้งานส่วนมากเป็นลักษณะรายงานที่ใช้ประจำ เน้นข้อมูลที่มีโครงสร้างชัดเจน (structured data) สามารถจัดทำแบบจำลองข้อมูลที่มีความสัมพันธ์ซับซ้อนได้ดี รวมถึงความสามารถในการจัดการข้อมูลตามลำดับเวลา ในแง่การใช้งาน สามารถรองรับผู้ใช้งานได้หลากหลาย ตั้งแต่นักวิเคราะห์ที่ถนัดการเขียนโปรแกรม ไปจนถึงผู้บริหาร ฐานข้อมูลและเครื่องไม้เครื่องมือมีมากมายในท้องตลาด เนื่องจากการจัดการข้อมูลแบบโครงสร้างที่ดีของมัน ผลที่ตามมาคือการปรับเปลี่ยนโครงสร้างข้อมูลที่จัดเก็บ มีความซับซ้อน ใช้เวลานานและต้นทุนสูง โดยรวมทั้งระบบมีราคาค่อนข้างสูง และเนื่องจากแนวคิดของ Data Warehouse มีมานานเกือบ 40 ปี ทำให้มันมีพัฒนาการถึงขีดสุด ติดตรงที่การรองรับข้อมูลรูปแบบใหม่ๆ พวก unstructured data ทำได้ไม่ดี และถ้าต้องใช้กับข้อมูลขนาดใหญ่ จะเป็นระบบที่มีราคาสูงจนน่าตกใจ และจากความจริงในองค์กรที่ว่า อำนาจอยู่ในมือของผู้มีข้อมูล ทำให้หลายองค์กรจำใจยอมลงทุนมหาศาล 

ที่น่าสนใจคือ ในช่วงแรกๆ ของ Data Lake เรามักเห็นแนวคิดที่ว่า Data Lake จะมาทดแทน Data Warehouse แต่ไปๆ มาๆในที่สุดก็กลายเป็นองค์กรต้องมีทั้ง 2 แบบ ด้วยลักษณะเด่นของการเก็บและใช้งานข้อมูลที่แตกต่างกันของ Data Lake และ Data Warehouse ที่ทดแทนกันไม่ได้ จึงมักจะเห็นสถาปัตยกรรมที่มี Data Lake เป็นแหล่งเก็บข้อมูลดิบ โดยเฉพาะข้อมูลที่เป็น unstructured data และป้อนข้อมูล structured data หรือ semi-structured ที่แปลงเป็น structured data  แล้ว ให้กับ Data Warehouse เพื่อการจัดเตรียมข้อมูลและทำรายงาน หรือที่เรียกกันว่า 2-tier data architecture 

Data Lake และ Data Warehouse แบบ 2-Tier Architecture ภาพประกอบโดยผู้เขียน

ซึ่งจะว่าไปก็เป็นแนวทางการแก้ปัญหาที่ดีเลยทีเดียว แต่ด้วยข้อจำกัดทางเทคโนโลยี ทำให้เกิดภาระต่างๆ ตามมา เนื่องจากการเก็บข้อมูลแต่ละประเภทซึ่งใช้เทคโนโลยีที่ต่างกัน และมักจะเก็บข้อมูลซ้ำซ้อนกัน ตามมาด้วยการบริหารจัดการที่แตกต่างกัน ทำให้ต้องใช้เครื่องมือที่หลากหลาย ทั้งการใช้งานและการดูแลความปลอดภัยข้อมูล ตั้งแต่การควบคุมสิทธิเข้าถึงข้อมูล การเข้ารหัส ไปจนถึงเครื่องมือและกระบวนการพัฒนา ทดสอบและติดตามผล ซึ่งตามมาด้วย การที่ผู้ดูแลต้องมีทักษะและเครื่องมือที่แตกต่างกันในงานแบบเดียวกัน องค์กรเองก็ต้องมีค่าใช้จ่ายเพิ่มเติมด้วยเช่นกัน โดยเฉพาะอย่างยิ่งในปัจจุบันที่มีกฏหมายเพื่อปกป้องข้อมูลส่วนบุคคลทั้ง  GDPR(1), CCPA(2) และ PDPA(3) ของบ้านเรา ทำให้การดูแลข้อมูลเหล่านี้เป็นเรื่องที่มีความจำเป็นอย่างยิ่งยวด

จริงๆ แล้วแนวคิดที่พัฒนาเทคโนโลยีที่รองรับรูปแบบการใช้งานข้อมูลที่หลากหลายมีมานานตั้งแต่ก่อนที่ big data เป็นที่พูดถึงแล้ว คือแทนที่เราจะมีหลายๆ เทคโนโลยีสำหรับข้อมูลแต่ละแบบ ทำไมถึงไม่มีเทคโนโลยีชุดเดียว กับข้อมูลหลายๆ แบบ ตอบสนองการใช้งานทั้งแบบผู้บริหารดูรายงาน และนักวิเคราะห์ที่อยากเขียนโปรแกรมลงไปคาดคั้นความจริงเอากับข้อมูลเองละ ในช่วง 10 ปีที่ผ่านมา เราจะเห็นความพยายามของกลุ่ม Data Lake เทคโนโลยี ที่พัฒนาให้ครอบคลุม Data Warehouse หรือกลุ่ม Data Warehouse ที่พัฒนาให้ครอบคลุม Data Lake แต่แน่นอนว่ายังมีกลุ่มคนที่มีแนวคิดว่า ถ้ารวมนกกับปลา ก็จะได้เป็ดที่ว่ายน้ำไม่เก่งเท่าปลา และบินไม่เก่งเท่านก แล้วทำไมไม่มีทั้งนกและปลาไปละ แค่แยกการการจัดเก็บและใช้งานแต่ละประเภทให้ถูกต้องก็พอ  แต่ก็นั่นแหละ ในโลกความเป็นจริงมันไม่ได้สมบูรณ์แบบขนาดนั้น ก็ในเมื่อเราก็สามารถเก็บข้อมูลแบบมีโครงสร้างใน Data Lake แล้ว ทำไมเราต้องดิ้นรนย้ายไปเก็บไว้ที่อื่่นอีกด้วยละ 


2. Data Lakehouse คืออะไร 

เหตุผลหลักที่ทำให้แนวคิด Data Lakeshouse เริ่มมาเป็นที่พูดถึงคือช่วงนี้ ส่วนหนึ่งเป็นผลจาก การเติบโตที่รวดเร็วมากของแนวคิด มาตราฐานหรือสถาปัตยกรรมแบบเปิด (open standard or open architecture) ทำให้ จากเดิมที่เทคโนโลยีของ Data Warehouse มักอยู่ในมือผู้ให้บริการรายใหญ่ไม่กี่ราย ยิ่งมีข้อมูลมาก ต้องการระบบที่ทำงานรวดเร็ว ยิ่งมีผู้ให้บริการน้อยลง และราคาแพงขึ้นมาก แต่ Data Lake ที่มาพร้อมกับมาตราฐานแบบเปิด ทำให้เกิดแนวคิดว่า ทำไมไม่ทำ Data Warehouse ให้ไม่ต้องผูกติดกับผู้ให้บริการบ้าง เก็บข้อมูลจำนวนมากๆ และประมวลผลให้เร็วๆ โดยใช้เทคโนโลยีราคาต่ำ หรือในมุมกลับกัน ทำไมไม่ทำให้ Data Lake ใช้งานง่ายๆ มีการบริหารจัดการข้อมูลที่เป็นระบบ ใช้งานกับข้อมูล Structured Data ได้เก่งๆ แบบ Data Warehouse บ้าง

Data Lakehouse: high level ภาพประกอบโดยผู้เขียน

2.1 ข้ามจาก Data Lake ไปสู่ Lakehouse

เอาละในเมื่อการมีเทคโนโลยีชุดเดียวที่มีเก่งแบบ 2 in 1 ที่ทั้งสวยและเก่งเหมือนน้องญ่าญ่านั้นมีไม่มาก ระบบที่มีคุณสมบัติเด่นของทั้ง Data Lake และ Data Warehouse ยังเกิดเต็มรูปแบบได้ยาก เราจึงเห็นแนวคิดที่มักมาเป็น solution หรือ data platform ที่รวม 2 เทคโนโลยีเข้าด้วยกัน บางเจ้าก็มัดรวมมันดื้อๆ เลย คือเอา Data Lake และ Data Warehouse มาขายรวมกันแล้วเรียกว่า (Data) Lake (Ware)House ซะงั้น กับกลุ่มที่ขยายขอบเขตของ Data Lake เดิม หรือ Data Warehouse เดิมออกมานิดหน่อย แล้วเรียกว่า Lake House ไปเลย เหมือนรีแบรนด์มันซะ อันที่จริงนั้นเมื่อดูจากลักษณะการใช้งานแล้ว Data Lakehouse ก็เหมือนกับ 2-tier data architecture ที่มีการพัฒนาขึ้นไปขั้นอีกนั่นเอง ขึ้นกับว่าเทคโนโลยีไหนและผู้ให้บริการรายไหนจะมีจุดเด่นและปิดจุดด้อยด้านไหนนั่นเอง ถึงตอนนี้เราน่าจะได้คำตอบแล้วว่า ทำไม Data Lakehouse ถึงมีแนวทางที่หลากหลาย และถึงขั้นเปลี่ยนแปลงแนวคิดระดับ paradigm shift หรือเปล่า

2.2 Features of a Data Lakehouse

ถึงแม้เราอาจจะไม่จำเป็นต้องรีบย้ายบ้านกันตอนนี้ แต่ถ้าองค์กรของเรากำลังมองหาหรือคิดจะปรับปรุงโครงสร้างการจัดการข้อมูลแล้วละก็ การมองไปถึงอนาคตก็เป็นเรื่องที่ดี เรามาดูกันว่าบ้านริมทะเลสาปของเราควรคุณสมบัติอะไรบ้าง โดยมองย้อนกลับไปที่ข้อเด่น และข้อด้อยของทั้ง Data Lake และ Data Warehouse 

ส่วนที่ควรต้องมี 

  1. รองรับการจัดเก็บข้อมูลทั้้ง Structured, Semi-structured และ Unstructured Data
  2. รองรับทั้งข้อมูลดิบ และข้อมูลที่ผ่านการปรุงแต่ง ข้อมูลมีการสร้างความสัมพันธ์ระหว่างชุดข้อมูล 
  3. สำหรับข้อมูลแบบมีโครงสร้าง ต้องควบคุมรูปแบบข้อมูลที่เข้าได้ (schema enforcement) เพื่อควบคุมคุณภาพข้อมูล และง่ายต่อการนำไปใช้ แต่ยังคงความยืดหยุ่นกับรูปแบบที่แตกต่างกัน
  4. มีความยืดหยุ่นในการจัดสรรพื้นที่ในการจัดเก็บ และพลังในการประมวลผล เพิ่มลดได้ตามความความจำเป็น
  5. ทรัพยากรหรือพื้นที่ในการจัดเก็บสามารถเลือกใช้ได้หลากหลาย ทั้งในแง่ความเร็วในการเข้าถึงข้อมูลและราคาตามความจำเป็น และสะดวกในการควบคุมค่าใช้จ่าย
  6. รองรับความถี่การนำเข้าข้อมูลทั้งแบบ batch และ streaming
  7. มีการศูนย์กลางในกำกับดูแล ไม่ว่าจะเป็นควบคุมการเข้าถึงข้อมูล การเผยแพร่ การปกปิดข้อมูล (anonymization) การควบคุมคุณภาพ การจัดทำ data catalog ตลอดจนการใช้ทรัพยากรของระบบงาน การจัดการ audit log
  8. รองรับการใช้งานหลากหลายรูปแบบ ทั้งการจัดทำรายงาน การวิเคราะห์ และการใช้งานสำหรับกระบวนการ machine learning และปัญญาประดิษฐ์ (AI)

นอกจากนี้ยังมีคุณสมบัติอื่นๆ ที่สำคัญสำหรับบางองค์กร เช่น

  1. การเข้ารหัสข้อมูลทั้งส่วนจัดเก็บและระหว่างเคลื่อนย้ายข้อมูล
  2. เทคโนโลยีหลักที่ใช้เป็นแบบมาตราฐานเปิด open standard ไม่ยึดติดกับผู้ให้บริการ
  3. เครื่องมือที่ใช้สามารถปรับเปลี่ยน ถอดเข้าออกได้ตามความจำเป็น เพื่อรองรับการใช้งาน และเทคโนโลยีใหม่ในอนาคต
  4. ควบคุมการนำเข้าข้อมูลให้มีมาตราฐาน และการตรวจสอบ โดยผ่านกระบวนการ ควบคุมและกำกับดูแลข้อมูล (data governance) โดยทำเป็นกระบวนการอัตโนมัติ
  5. รองรับแนวคิดแบบ self service เพื่อให้ผู้ใช้งานในรูปแบบต่างๆ สามารถดูแลจัดการกับงานของตัวเองได้ ภายใต้การกำกับดูแลในระดับองค์กร


เช่นเดียวกันกับ Data Warehouse และ Data Lake คุณสมบัติที่กล่าวมา ไม่ได้หมายถึงว่า จะต้องเป็นระบบ เดี่ยวๆ ที่สามารถทำได้ทั้งหมด มันควรเป็นกลุ่มของระบบ เครื่องมือ กระบวนการต่างๆ ที่ประกอบกันขึ้นมาเป็น Data Lakehouse ส่วนองค์กรไหนจะเลือกเทคโนโลยีแบบไหน หรือเครื่องมืออะไรมาประกอบบ้าง ก็ดูตามความจำเป็น ความต้องการเฉพาะด้าน และตังค์ในกระเป๋า CFO


3. บทสรุป อนาคตของ Data Lakehouse

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

Note:

(1) GDPR: General Data Protection Regulation 

(2) CCPA: California Consumer Privacy Act

(3) PDPA: พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล

Credit:

รูป icon ประกอบจาก  www.flaticon.com


Across the lake to the Data Lakehouse Across the lake to the Data Lakehouse Reviewed by aphidet on 10:15 AM Rating: 5

No comments:

Powered by Blogger.