Data Lakehouse for Small & Midsize Business: Lakehouse Lite - Part II

Image credit: Joy Dachapratumvan

บทความนี้เป็น Part II ของ ชุด Data Lakehouse for Small & Midsize Business (SMB) โดยใน Part I เราได้แนะนำแนวทางการเลือกใช้เทคโนโลยีด้านข้อมูลสมัยใหม่ โดยเลือกใช้เท่าที่จำเป็นที่เรียกว่า Lakehouse Lite โดยใน Part II เราจะมาดูในรายละเอียดและเหตุผลในทางเทคนิค โดยใช้ Microsoft Azure Synapse Analytics (ASA) เป็นต้นแบบ เนื่องจากแนวคิดของ Azure ที่ มัดรวมเครื่องมือต่างๆ แบ่งกลุ่มตามขั้นตอนการทำงานกับข้อมูล (Data Life Cycle) ทำให้ง่ายต่อการเลือกใช้ตามความเหมาะสม ตั้งแต่ data integration, data discovery, data transformation ไปจนถึงการออกรายงาน แต่อย่างไรก็ดี สามารถนำแนวทางไปประยุกต์ใช้ใน Cloud Service อื่นๆ ได้ อนึ่งกระทู้... บทความนี้เป็น CR - Consumer Review จ่ายเงินซื้อเอง ไม่ได้รับค่าจ้างและผลประโยชน์ใดๆ

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

เนื้อหาประกอบด้วย

1. Architecture
2. Components
3. Setting
4. Tips

1. Architecture

Cloud Service Provide บางรายมีนำเสนอทางเลือกสำหรับ SMB เช่นของ Microsoft ซึ่งลดทอนความซับซ้อนลงมาระดับนึง

Image credit: Modern data warehouse for small and medium business

แต่อย่างไรก็ดี เราจะลดทอนลงมาอีก โดยเริ่มจากเฉพาะที่จำเป็นเท่านั้น เหมือนเราหาชุดเริ่มต้น Starter Kit สำหรับงานด้านข้อมูลมาใช้งาน โดยใน solution นี้  ไม่จำเป็นต้องใช้ traditional database หรือ MPP database แต่อย่างไร 

Data Lakehouse Lite Solution

2. Components

ใน Azure Synapse Analytics นั้นเราสามารถเลือกใช้เครื่องมือใน Azure Synapse Studio สำหรับการจัดการ และวิเคราะห์ข้อมูลในลักษณะที่เป็น single unifying service โดยเลือกใช้หลักๆ ดังนี้

- Azure Data Lake Storage (ADLS) Gen 2 สำหรับการจัดเก็บข้อมูลทั้งแบบ มีโครงสร้าง (structured data) และกึ่งโครงสร้าง (semi structured data) แทนการใช้ Blob Storage นอกจากปัจจัยเรื่องราคา storage ที่ต่ำแล้ว จากคุณสมบัติที่สำคัญของ hierachical namespace (HNS) หรือมองง่ายๆ ก็คือเหมือนเราใช้ folder บน MS Windows ซึ่งความสะดวกในแง่การจัดการสิทธิ์การเข้าใช้ไฟล์ข้อมูลใน subfolder เราสามารถทำ file partition scans ใน data lake ซึ่งช่วยด้านความเร็วในการเข้าถึงไฟล์ใน folder และ subfolder การจัดการในระดับ metadata ทำการย้ายไฟล์ขนาดใหญ่ทำได้อย่างรวดเร็ว ซึ่งมีผลอย่างมากในแง่ค่าใช้จ่าย เนื่องจาก cloud service คิดค่าใช้จ่ายตามการใช้งาน ไม่ว่าจะในแง่ระยะเวลา หรือทรัพยากรที่ต้องใช้

- Open File Format (e.g. csv, JSON, parquet, delta ) แทนที่การเก็บไฟล์โดยใช้ traditional databases หรือ MPP database ซึ่งเป็น proprietary data format เราสามารถจัดเก็บข้อมูลโดยใช้ไฟล์ที่เป็น open format อย่าง parquet หรือ delta ซึ่งมีขนาดไฟล์เพียง 25% ของไฟล์ CSV ต้นฉบับเท่านั้น ช่วยประหยัดทั้งค่าใช้จ่ายของพื้นที่ในการเก็บและประมวลผล อีกทั้งยังสามารถใช้งานกับ SQL ได้ง่ายอีกด้วย

-  Serverless SQL Pool ซึ่งเป็น on demand ecosystem บน Azure ลดภาระในการจัดการโครงสร้างพื้นฐานหรือจัดสรร cluster สำหรับใช้งาน ซึ่งเหมาะสำหรับงานที่มีลักษณะเป็น on-demand หรือการวิเคราะห์ข้อมูลสำหรับ data analyst, data scientist เราสามารถสร้าง database, external table หรือ view โดยชี้ไปที่ไฟล์ข้อมูลใน ADLS Gen 2 เพื่อให้สะดวกในการใช้งาน อย่างไรก็ดี เนื่องจากเทคโนโลยีเหล่านี้เป็นลักษณะการใช้ทรัพยากรร่วมกันกับผู้ใช้งานอื่นๆ (shared resource) กรณีที่เรามีข้อมูลจำนวนมาก (Microsoft แนะนำที่มากกว่า 1TB หรือบาง consultant แนะนำ ที่ 4TB) และต้องการประสิทธิภาพสูงอย่างสม่ำเสมอ การจัดเก็บข้อมูลใน traditional database หรือกลุ่มที่เป็น dedicated resource อย่าง Dedicated SQL pool หรือ spark pool จะมีความเหมาะสมกว่า

- Serverless Apache Spark Pool ช่วยให้เราทำงานกับข้อมูลใน data lake หรือ lakehouse โดยใช้ Spark เทคโนโลยี ผ่านภาษา Spark SQL, PySpark บน notebook เราสามารถสร้าง database, tables บน spark pool ทำให้เราสามารถใช้คำสั่งในกลุ่ม DML (Data Manipulation Language) กับ delta table ซึ่งสามารถ update, delete ข้อมูลในไฟล์ ทำให้ spark pool เหมาะสมสำหรับการจัดเก็บข้อมูลในรูปแบบของ data warehouse มากกว่า serverless pool

- Power BI ส่วนของการวิเคราะห์ ทำรายงานและแสดงผลข้อมูล ผ่าน dashboard หรือการ visualize ข้อมูล รวมถึงสามารถแบ่งปันให้แก่ผู้ใช้คนอื่นๆ เป็นเครื่องมือที่มีให้บน Synapse Analytics โดยเราสามารถใช้ Power BI กับข้อมูลใน ADLS Gen 2 ผ่าน Serverless SQL Pool หรือ Spark Pool ได้โดยตรง 

- Synape pipelines สำหรับส่วนของ data ingestion และผูกกระบวนการทำงานตามลำดับขั้นตอน เป็น batch หรือ near real time สามารถตั้งเวลาหรือ trigger สำหรับเริ่มการทำงาน เรียกได้ว่า pipelines เป็นลูกพี่ลูกน้องกับ Azure Data Factory นั่นเอง

- Optional เราอาจใช้ SQL database เช่น Dedicated SQL pool หรือ SQL server, mySQL ในกรณีที่จำเป็น โดยสามารถใช้ในลักษณะที่เป็น serving layer โดยดึงเฉพาะข้อมูลส่วนที่จำเป็นเข้าใน database เหล่านั้น หรือสร้างเป็น external table โดยที่ข้อมูลส่วนใหญ่หรือทั้งหมดยังคงถูกจัดเก็บอยู่บน ADLS Gen 2

จากที่ Microsoft รวมทั้งหมดนี้เข้าเป็น one development studio จึงเป็นเหตุผลหลักที่เลือกใช้ Azure Synapse Analytics เพื่อแสดงแนวคิดของ lakehouse lite ลดความซับซ้อนของการใช้งาน services และ tools จำนวนมาก ทำให้การ monitor และตรวจสอบในขั้นตอนต่างๆ ทำได้ง่าย ลดภาระด้านการจัดการและดูแลความปลอดภัยของข้อมูลและระบบ

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

3. Setting

ในที่นี้เราขอไม่ลงรายละเอียดในการสร้าง components ต่างๆ บน Azure เช่น การสร้าง Azure Account, subscription ต่างๆ ซึ่งสามารถศึกษาจาก Microsoft ได้โดยตรง

3.1 Synapse Analytics Workspace ในการสร้าง workspace จะมีให้กำหนด primary ADLS Gen 2 Storage Account และ container โดย Serverless SQL Pool จะถูกสร้างขึ้นมาในขั้นตอนการสร้าง workspace ซึ่งจะให้เรากำหนด username และ password สำหรับ SQL Pool ด้วย สำหรับการสร้าง Synapse Workspace ศึกษาได้จาก Creating a Synapse Workspace ในตัวอย่างนี้เรายึดแนวทาง multiple-workspaces-single-lake ที่นำเสนอโดย Jovan Popovic 

Multiple-workspaces-single-lake topology (image credit Jovan Popovic)

โดยสร้าง workspace (lh-synapse-ws), storage account (lhdatalakestorage), container (lhdatalakecontainer) อย่างละหนึ่ง เพื่อความสะดวกในการใช้งานและบริหารจัดการ

Storage Account, Container และ Lakehouse folder ใน Container

3.2 Apache Spark Pool เราใช้เพื่อการสร้าง database, table เช่น delta lake, delta table ส่วนการสร้าง Apache Spark Pool ศึกษาได้จาก Quickstart: Create a serverless Apache Spark pool using Synapse Studio

Apache Spark pools

3.3 Lakehouse folders ภายใต้ container ของ lakehouse ตาม data life cycle เป็น zone ตาม industry practice คือ 

1. Bronze หรือ raw สำหรับเก็บข้อมูลที่มาจากระบบงานต่างๆ โดยเป็นไฟล์ ในรูปแบบ CSV, parquet, JSON ในส่วนนี้ควรมีการจัด folder และ subfolder เพื่อให้ง่ายต่อการใช้งาน
2. Silver หรือ enriched สำหรับเก็บไฟล์ที่ถูกปรับปรุงข้อมูลให้เหมาะสมเบื้องต้นสำหรับการใช้งาน เช่นการแปลงรูปแบบจาก semistructure เป็น structure, data cleansing, จัดทำ partition หรือ join ข้อมูลจากไฟล์ต่างๆเข้าด้วยกัน มักเก็บไฟล์ในรูปแบบ parquet หรือ delta แต่ก็ยังสามารถเก็บในรูปแบบ CSV ได้เช่นกัน 
3. Gold หรือ curated สำหรับเก็บไฟล์ที่ถูกจัดเตรียมเพื่อการใช้งาน หรือวิเคราะห์ข้อมูล และเรายังสามารถการจัดเก็บข้อมูลแบบ Fact, Dimension, Slowly Changing Dimensions (SCDs) ตามแนวทางของ data warehouse ได้เช่นกัน ซึ่งสามารถทำได้ทั้งด้วยไฟล์ parquet กรณีขนาดไฟล์ไม่ใหญ่มาก หรือ delta กรณีที่การ update ไฟล์เดิมมีความเหมาะสมกว่า 

ทั้งนี้การจัดแบ่งและตั้งชื่อตาม industry practice เช่น data life cycle ยังอาจปรับเปลี่ยนเพื่อให้เข้าใจง่ายสำหรับการใช้งานของเรา สะดวกต่อการจัดการและใช้งานไฟล์ต่างๆ โดยส่วนตัวไม่ค่อยนิยมกับการเรียกแบบ bronze, silver และ gold เนื่องจากไม่ได้สื่อถึง data life cycle เลยซักกะนิด

3.4 Database บน Serverless SQL pool และแบ่ง database schema โดยแบ่งตามการจัดเก็บข้อมูลใน container เช่น bronze หรือ raw, silver หรือ , gold หรือ เพื่อให้จัดการรูปแบบการใช้งานได้เหมาะสม โดยในตัวอย่างเราสร้าง database ชื่อ lakehouse_lite

Database, Schema และ External Tables ใน Serverless SQL pool

3.5 External table หรือ view สำหรับไฟล์ใน bronze/raw เพื่อให้สามารถได้ง่ายโดย SQL มี 2 วิธีในการสร้าง external table คือ Create External Table ซึ่งเป็นการสร้าง table ขึ้นมาบนไฟล์ และ Create External Table As Select (CETAS) ซึ่งทำ 2 ขั้นตอน คือ สร้างไฟล์ใหม่ขึ้นมา และสร้าง external table ใน Serverless SQL pool โดยในขั้นตอนนี้ต้องมีการกำหนด external data source และ external file format ด้วย ซึ่ง external table เหล่านี้สามารถใช้งานเหมือน table จาก traditional relational database เช่น ใช้งานกับ PowerBI, tableau ได้โดยตรง แต่มีข้อจำกัดที่ external table ไม่รองรับไฟล์ประเภท JSON

3.6 Data transformation ใช้เพื่อทำขั้นตอนต่างๆ เช่น การแปลงประเภทไฟล์ feature engineering จัดเตรียมข้อมูล ไปจนถึงการจัดเก็บข้อมูลในรูปแบบของ data warehouse ซึ่งเป็นกระบวนการที่ทำให้ข้อมูลไหลจาก zone หนึ่งไปยังอีก zone หนี่ง เช่นจาก raw/bronze ไป enriched/silver ใน ASA ทำได้หลายวิธี 

เช่น

- CETAS เป็น SQL script อาจเรียกใช้โดยตรง หรือแปลงเป็น stored procedure เพื่อประโยชน์ด้าน code reuse แทนที่จะเขียน SQL script สำหรับแต่ละ table สามารถศึกษาได้จาก CETAS with Synapse SQL  อย่างไรก็ดี เนื่องจาก external table ไม่รองรับ partition เราสามารถแก้ปัญหาทางอ้อมโดยใช้ pipeline เรียก stored procedure วน loop เพื่อสร้าง partition แล้วจึงสร้าง view ขึ้นมาครอบอีกชั้นหนึ่ง การใช้ Spark pool จึงเหมาะสมและง่ายกว่ากรณีที่เราต้องการใช้ partition

- SparkSQL หรือ pySpark โดยใช้ notebook บน Spark pool

- Data Flow ซึ่งเป็น low code GUI

Data transformation โดยใช้ stored procedure

3.7 Synapse Pipelines ใช้ในการผูกการทำงานตามลำดับขั้นตอน การเรียกใช้ dataflow, stored procedure, notebook และ script รวมถึง การจัดการค่า parameters,  file operation, looping ต่างๆ ตลอดจนการทำ scheduling และ trigger

Pipeline ผูกขั้นตอนต่างๆ เข้าด้วยกันเป็น process และสั่งการทำงาน

4. Tips

สำหรับการทำงานกับข้อมูล หรือโครงการที่มีขนาดค่อนข้างใหญ่ ทีมงานหลายคน การออกแบบ และกำหนดค่าต่างๆ จะช่วยให้การทำงานเป็นระเบียบและจัดการได้ง่ายขึ้น ประมวลผลได้เร็ว ควบคุมค่าใช้จ่ายได้ดี จึงได้รวบรวมคำแนะนำจากผู้มีประสบการณ์จากแหล่งต่างๆ รวมถึงของ Microsoft เองไว้ให้เลือกนำไปใช้ โดยแบ่งเป็นส่วนดังนี้

Store

- เราอาจจัดแบ่ง storage account, container และ lakehouse folder หลายแบบตามลักษณะการใช้งาน เช่น ตาม data life cycle: /raw, /enriched หรือแยกตามเฟสการพัฒนา develop, test and production: /dev, /sit ตามระบบงาน: /application01 หรือ ตามเรื่องธุรกิจ (business area): /sales, /accounting เป็นต้น และยังสามารถนำผสมกันได้อีกด้วย ทั้งนี้ก็จัดแบ่งรูปแบบการเก็บอย่างเหมาะสม ขึ้นกับหลายปัจจัย

- พยายามยึดแนวทาง multiple-workspaces-single-lake หากทำได้ ซึ่งมีเพียง 1 datalake storage account เพื่อประโยชน์ในการแชร์ข้อมูล การคุมการใช้ข้อมูลตาม containers และควรตั้งชื่อ workspace ให้สอดคล้องกับ container โดยเฉพาะกรณีใช้หลาย workspaces

- กรณีที่ไฟล์มีจำนวนมาก และขนาดใหญ่ ควรจัดแบ่ง partition (หรือสร้าง sub folder) ของไฟล์ใน ADLS Gen 2 เพื่อให้ใช้ความสามารถของ file metadata function ใน Serverless SQL pool ช่วยในการระบุ partition ได้ง่าย ทำให้เราใช้ข้อมูลเท่าที่จำเป็นในแต่ละ partition ซึ่งมีผลกับความเร็วในการทำงาน และค่าใช้จ่าย

- การแบ่ง partition หรือ subfolder ของข้อมูลใน container ควรพิจารณาจากการจัดเก็บและใช้ข้อมูลเป็นสำคัญ เช่น หากเราใช้เป็นรายเดือน รายปี  เราควรจัดเป็น /year/month เป็นต้น

- ปัจจุบัน external table ใน serverless SQL pool ไม่รองรับการทำ partition pruning จึงต้องสร้างเป็น view แล้วใช้ filepath function ใน view จึงสามารถใช้ประโยชน์จากการทำ partition ได้

- เลือกใช้ view แทนการใช้ external table กรณีที่ต้องการจำกัดให้เห็นข้อมูลแค่บาง column หรือกำหนดเงื่อนไขในการดูข้อมูล

Process

- ในการสร้าง external table, table ควรกำหนด data type และ data length ให้เหมาะสม แทนการใช้ค่า default จากระบบ เพื่อเป็นการบอกระบบให้จัดสรรทรัพยากรและดำเนินการกับข้อมูลนั้นอย่างเหมาะสม ตัวอย่างเช่น string data type ในไฟล์ เมื่อเราสร้าง external table หรือ table ระบบจะกำหนดค่าตั้งต้นเป็น varchar(8000) หรือ nvarchar(4000) ซึ่งใช้พื้นที่และทรัพยากรระบบมากเกินจำเป็น การกำหนดให้เหมาะสมจะช่วยด้านความเร็วในการประมวลผล ลดการใช้ทรัพยากรของระบบ และค่าใช้จ่าย

- กรณีที่เราเขียนโปรแกรมสำหรับ data transformation โดยใช้ notebook แนะนำให้เขียนเป็นชุดฟังค์ชั่นสั้นๆ ทำงานเฉพาะเรื่อง ในแต่ละ notebook เพื่อลดความซับซ้อนของการเขียนโปรแกรม การ debug วิเคราะห์ปัญหา และการดูแลในภายหลัง เนื่องจากเราสามารถเรียกใช้ notebook หลายๆ ชุด ให้ทำงานต่อเนื่องกันได้ โดยใช้ pipelines ทำให้ง่ายต่อการ monitor ในขั้นตอนต่างๆ ง่ายต่อดูแล มากกว่าการเขียนเป็นโปรแกรมยาวๆ เหมือนการเขียนโปรแกรมทั่วไป

- ตั้งค่า Cost Control ใน SQL pool เสมอ

Others

- เพื่อหลีกเลี่ยง data swamp หรือสภาวะข้อมูลยุ่งเหยิงกองๆทับซ้อนกันใน data lake จนไม่มีใครรู้ว่ามีอะไรอยู่ที่ไหน มีจึงควรมีขั้นตอนคัดเลือกข้อมูลเข้าไปเก็บใน lakehouse และทำ data catalog เพื่อเป็นการลงทะเบียนชุดข้อมูลที่มีการจัดเก็บ โดยระบุเพียงเนื้อหาที่จำเป็น และเพียงพอสำหรับการใช้งานของเรา ไม่ว่าจะเป็นชื่อไฟล์ ความหมายของข้อมูล ใครเป็นเจ้าของ ต้องเก็บไว้นานแค่ไหน ซึ่งสามารถทำแบบง่ายๆ เป็น excel หรือ csv แล้วแชร์ให้คนอื่นเข้ามาดู หรือ upload เข้า lakehouse เป็นเสมือนอีก 1 ชุดข้อมูลก็ได้

เราอาจคิดว่าสำหรับ SMB ซึ่งมีข้อมูลไม่มากนัก มีผู้ใช้จำกัด จึงไม่จำเป็นต้องใช้แนวทางเหล่านี้ก็ได้ เพราะเหมาะสำหรับกรณีมีข้อมูลจำนวนมาก แต่การที่เราเลือกใช้แนวทางที่เป็น industry practice อย่างเหมาะสม (ซึ่งไม่จำเป็นต้องนำไปใช้ทุกข้อ) จะช่วยให้ทำงานได้ง่าย สะดวกต่อการดูแล ขยายสเกลงาน รองรับการทำงานที่ใหญ่และซับซ้อนในอนาคตได้

ในเบื้องต้นเรายังไม่ได้เน้นถึงการจัดการข้อมูลรูปแบบต่างๆ ในงาน data warehouse เช่น การจัดการ data inconsistency, late arrival, missing key,  history maintenance ไปจนถึง การจัดเก็บข้อมูลในลักษณะต่างๆ ซึ่งเป็นพื้นฐานการจัดการข้อมูลใน data warehouse แต่สามารถเลือกนำไปพัฒนาเพิ่มเติมตามความจำเป็นในการใช้งาน

Conclusion

ท่ามกลางทางเลือกที่หลากหลายและซับซ้อนสำหรับพัฒนา Data Lakehouse, Data Lake บน cloud เรายังมีทางเลือกแบบง่ายๆ โดยลงทุนไม่สูงนักให้เราได้เลือกใช้ เพื่อเริ่มต้นพัฒนาและเรียนรู้ โดยเฉพาะสำหรับ SMB ที่มีทรัพยากรจำกัด แน่นอนว่าไม่มีทางเลือกที่เป็น one-size-fits-all ที่ตอบโจทย์ทุกๆเรื่องของทุกๆคน เรายังต้องศึกษาทำความเข้าใจข้อดี ข้อจำกัด รวมถึงความต้องการด้านอื่นๆ เพื่อการเลือกใช้อย่างเหมาะสม เช่น รูปแบบการใช้งาน การต่อยอดใช้ AI วัฒนธรรมองค์กร การดูแลความปลอดภัยข้อมูลที่เหมาะสมเพียงพอ เมื่อเราเข้าใจอย่างเพียงพอแล้ว การพัฒนาอย่างต่อเนื่องของเทคโนโลยีด้านข้อมูลและการแข่งขันกันอย่างเข้มข้นระหว่างผู้ให้บริการจึงเป็นเหมือนคลื่นที่ช่วยผลักดัน เปิดโอกาสใหม่ๆ ให้กับเราเลือกใช้สิ่งที่เหมาะสมกับการใช้ของเราได้อย่างที่ไม่เคยมีมาก่อน