Big Data กำลังจะกลายเป็น Big Data Silos: เหตุผลและแนวทางแก้ไข

ปรากฎการณ์ Big Data ทำให้เกิดความเปลี่ยนแปลงหลายอย่าง จากเดิมที่เราใช้ข้อมูลมาทำ Business Optimization แต่วันนี้เรามองว่าข้อมูลเป็น Strategic Asset สามารถสร้างคุณค่า (Value Creation) จากมุมมองการใช้ข้อมูลในแบบใหม่ๆ ซึ่งจะช่วยให้อยู่รอดจาก Disruption ที่เราไม่เคยเผชิญมาก่อนเลยได้. ในช่วง 1 ปีที่ผ่านมาหลายธุรกิจได้มีเริ่มมีการใช้งาน Big Data Technology อย่างจริงจังมากขึ้น มีการทำ Big Data Adoption ทั้งในแบบ on-Premises หรือ on-Cloud. มีการ Train พนักงานในองค์กรหรือรับพนักงานใหม่ที่มีความรู้ความเชี่ยวชาญเฉพาะด้าน Big Data เข้ามาทำงานกับระบบ. ทั้งหมดนี้ดูเหมือนว่า เราจะได้ทำทุกสิ่งอย่างเพื่อเตรียมพร้อมจะ Leveraging Big Data แล้ว อย่างไรก็ตามถ้าเราขาด Data Management ที่เหมาะสมแล้ว ก็เท่ากับว่า เราอาจกำลังจะสร้าง Data Silo ราคาแพงขึ้นอีกชุดหนึ่ง (Big Data Silos) และเป็นตัวอย่างให้หลายๆ Business Unitในองค์กร สร้างมันขึ้นมาอีกหลายๆ ชุดเลยทีเดียว.

จากประสบการณ์ทำงานกับ Big Data และ Data Management มายาวนานทั้งในองค์กรภาครัฐและเอกชนที่หลากหลาย ผู้เขียนพบว่า เกือบทุกองค์กรต่างพยายามทำความสะอาดข้อมูล (Data Cleansing) และทำการปรับโครงสร้างและรูปแบบข้อมูล (Data Transformation) ก่อนนำเข้าสู่สื่อบันทึกข้อมูล (Storage) ขององค์กร … จริงๆ ความพยายามเหล่านี้ก็ไม่ใช่สิ่งที่ผิดหลักการอะไร ในทางตรงข้ามเป็นการดำเนินการที่ถูกต้องและสอดคล้องกับหลักการ ETL (Extraction-Transformation-Loading) ซึ่งผมเองก็ยังใช้หลักการนี้กับงานข้อมูลที่ต้องการโครงสร้างแบบ Relational Model หรือต้องการทำ Data Warehousing. อย่างไรก็ตาม เมื่อนำหลักการด้าน ETL มาใช้ Managing Data ในสถานการณ์ที่หลายสิ่งหลายอย่างเปลี่ยนแปลงบ่อยและเร็วอย่างในโลกยุคนี้แล้ว อาจเกิดประเด็นทั้งในเรื่องความทันต่อเวลา (Timeliness) ได้

รูปที่ 1 แสดงกระบวนการจัดการข้อมูลก่อนยุค Big Data ซึ่งรูปด้านซ้ายคือการจัดการข้อมูลในช่วงเวลาที่องค์กรเพิ่งจะเริ่มต้นมีระบบจัดการข้อมูล และรูปด้านขวาแสดงการบริหารจัดการข้อมูลในปัจจุบันที่องค์กรมีระบบจัดการข้อมูลแยกกันในแต่ละ Business Unit (Silos)

สาเหตุการเกิด Data Silos

รูปที่ 1 แสดงกระบวนการจัดการข้อมูลโดยทั่วไปก่อนยุคสมัย Big Data. การเลือกใช้เทคโนโลยีหรือ Tools ต่างๆ เรามักคำนึงถึงผลลัพธ์จากการวิเคราะห์เป็นหลัก (Data Analytics-oriented). การคำนึงถึง Capabilities Limitation ของ Tools ที่เกี่ยวข้องกับขนาดข้อมูล (Volumes) ความเร็ว/ความต่อเนื่องของข้อมูลที่ไหลเข้ามา (Velocity) และโดยเฉพาะอย่างยิ่งความหลากหลาย (Varieties) เป็นอะไรที่เราไม่ค่อยคำนึงถึงกันหรือมีบ้างแต่อยู่ในลำดับท้ายๆ ไม่ได้สำคัญอะไร ต่อมาเมื่อตลาดมีการแข่งขันของธุรกิจที่ผันผวนและรุนแรงขึ้น ความต้องการใช้ข้อมูลของแต่ละ Business Unit ที่เปลี่ยนแปลงไปส่งผลให้ Characteristics ของข้อมูลในองค์กรเปลี่ยนไป คือ มันใหญ่ขึ้น เร็วขึ้น/ต่อเนื่องขึ้น และหลากหลายขึ้น เป็นผลทำให้ IT อาจไม่สามารถใช้เทคโนโลยีแบบเดิมๆ มาจัดการกับข้อมูลได้อย่างมีประสิทธิภาพอีกต่อไป ซึ่งแน่นอนว่า คุณภาพข้อมูลอย่างน้อยก็ในแง่ความทันต่อเวลาหรือการมีข้อมูลทันต่อการใช้งานนั้นย่อมลดน้อยถอยลงไปอย่างแน่นอน. นี้คือสาเหตุหนึ่งที่แต่ละ Business Unit ไปตั้งทีมและระบบขึ้นมาจัดการข้อมูลเสียเอง โดยเลือกจัดการข้อมูลในขนาดที่เล็กลง ความเร็วและความหลากหลายที่เทคโนโลยีของตนเองสามารถจัดการได้และสอดคล้องกับมุมมองการใช้ข้อมูล จึงกลายเป็น Silos แยกกันในแต่ละ Business Unit อย่างเช่นในทุกวันนี้ (รูปที่ 1 ทางด้านขวา)

รูปที่ 2 การจัดการข้อมูลขนาดใหญ่ (Big Data) ด้วยวิธีการดั้งเดิม ETL

Big Data Silos

มาถึงวันนี้ หลายองค์กรได้เข้าสู่ยุค Big Data ที่มีการนำ Big Data Technology มาใช้จัดการข้อมูลแล้ว แต่ก็ยังใช้การจัดการข้อมูลในแบบ ETL เหมือนที่เคยทำมาอย่างเคยชินตั้งแต่อดีต. แม้ว่า Big Data Tech. โดยส่วนใหญ่จะมีสถาปัตยกรรมระบบเป็นแบบ Multi-Nodes Cluster ที่มีประสิทธิภาพดีกว่าทั้งการเก็บข้อมูลและการประมวลผลข้อมูล ซึ่งเป็นผลมาจากความสามารถประมวลผลแบบ Distributed Computing และมีการจัดเก็บข้อมูลแบบ Distributed Storage ก็ตาม แต่ก็ไม่ได้หมายความว่า ผู้ใช้ข้อมูลจะได้รับข้อมูลในแบบที่ตนเองต้องการเสมอไป. ตัวอย่างเช่น ตามรูปที่ 2 IT ทำการ Extract ข้อมูลมาจาก Data Sources แล้วนำข้อมูลไปปรับปรุงและปรับโครงสร้าง (Transformation)ในแบบ Star Schema ในลักษณะการทำ Data Warehousing จากนั้นก็โหลดข้อมูลที่ผ่านการปรับปรุงแล้ว (Loading) เข้าสู่ Data Warehouse เพื่อให้ผู้ใช้ในแต่ละ Business Unit นำไปทำ Descriptive Analytics หรือออก Report ในเชิง Summarized Data ต่อไป. แต่โจทย์ Big Data ปัจจุบัน มีอีกหลายอย่าง เช่น Predictive Analytics, Prescriptive Analytics, Stream Data Analytics ที่การทำ Data Warehousing แบบดั้งเดิมตามรูปที่ 2 ไม่ตอบโจทย์เหล่านี้โดยตรง หรือแม้ว่าจะเป็นองค์กรที่มีการตัดสินใจทางธุรกิจยึดติดอยู่กับ Summaried Data ก็อาจได้รับข้อมูลที่ยังไม่เพียงพอต่อการตัดสินใจ ดังนั้น IT จึงจำเป็นต้อง Extraction และ Transform ข้อมูลในมุมมองใหม่ และ Load ข้อมูลในมุมมองนั้นเข้าสู่ระบบเพื่อสนับสนุนการทำ Analytics ต่อไปเกิดเป็นการทำซ้ำตามวงจรรูปที่ 2 บ่อยครั้ง

หาก IT ทำ ETL แล้วยังคง Timeliness อยู่ก็คงไม่เป็นไร แต่ถ้าช้ามาเมื่อไหร่ เกิดขึ้นบ่อยครั้ง นานๆ เข้า Business Unit ก็อาจจำเป็นต้องไปตั้งทีมและระบบขึ้นมาอีก เพื่อรองรับการพัฒนาข้อมูลที่ตนเองอยากใช้และควบคุมเรื่อง Timeliness ได้ เกิดเป็น Data Silos ในยุค Big Data (Big Data Silos)… เป็นประวัติศาสตร์ซ้ำรอยเดิมที่แก้ไม่หายสักทีก็เป็นได้.

ELT เป็นการจัดการข้อมูลที่เหมาะสมกับ Big Data

โชคดีที่ Big Data มาพร้อมกับ Data Lake ที่เป็นหลักการกว้างๆ พูดถึง Repository ที่รองรับการจัดเก็บข้อมูลในแบบ Raw Format ซึ่งหมายถึง ได้รับข้อมูลมาอย่างไร ก็เก็บไว้อย่างนั้น จากนั้นเมื่อมีความต้องการใช้ข้อมูล จึงจะมาปรับปรุงข้อมูล/ปรับโครงสร้างข้อมูล (Data Transformation) กันในภายหลัง หรือกล่าวอีกอย่างหนึ่งว่า Data Lake สามารถรองรับข้อมูลซึ่งมีโครงสร้างแบบใดก็ได้ (Any Formats) ที่ใช้การจัดการข้อมูลแบบ ELT (Extraction-Loading-Transformation) นั่นเอง ผู้เขียนจะยกตัวอย่างการ Implement หลักการแนวคิดในเรื่องนี้ผ่านทาง Dataproc ซึ่งเป็น Service ที่ Provide Hadoop & Spark Cluster ของ Google Cloud Platform. สำหรับประโยชน์ที่จะได้รับจากการ Implement ในระดับองค์กร ประกอบด้วย

• Maintaining original formats ของ Raw Data ให้พร้อมที่จะนำไป Transformation ตามมุมมองความต้องการใช้ข้อมูลใหม่ๆ ตลอดเวลา
• High Performance: Spark เป็นซอฟต์แวร์ที่ประมวลผลแบบ in-Memory Computing ที่มีการประมวลผลแบบ Distributed Computing บน Multi-Nodes ซึ่งผู้เขียนได้เคยเปรียบเทียบกับเทคโนโลยีที่ประมวลผลบน Single Node ไว้ในงานเขียนก่อนหน้านี้
• Data Warehousing: Hive เป็น Data Warehouse ซอฟต์แวร์ของ Hadoop ที่เราสามารถใช้คำสั่งแบบ ANSI-SQL ทำการ Query ข้อมูลเพื่อทำ Summary Report ในมุมมองต่างๆ ได้
• Hadoop, Spark และ Hive เป็น Software ในแบบ Production Grade ที่ไม่เสียค่า Software License ในการใช้งาน
• รองรับการใช้ Apache Airflow เพื่อให้การทำงานทุกขั้นตอนตั้งแต่ต้นจนจบเกิดขึ้นโดยอัตโนมัติ

ขั้นตอนตัวอย่างการทำ ELT ต่อไปนี้ อยู่บนสมมติฐานที่ท่านผู้อ่านมี Google Account มีการลงทะเบียนการใช้งาน Google Cloud Platform และ Dataproc Cluster with Jupyter Notebook ซึ่งทำงานได้เรียบร้อยแล้ว

ตัวอย่างการ Implement หลักการแนวคิด ELT สำหรับการจัดการ Big Data

ขั้นตอนที่ 1: Extraction ข้อมูลจาก Data Source

การ Extraction ข้อมูลจาก Data Source ในตัวอย่างนี้เป็นการใช้คำสั่งง่ายๆ ของ Linux คือ wget ไปดึงข้อมูลจาก Link ใน Internet. ข้อมูลที่ได้คือ Raw Data ชื่อ LoanStats_web.csv อยู่ใน Linux File System ตามรูปที่ 3

รูปที่ 3 Raw Data

จากรูปที่ 3 คือ Raw Data ที่มีโครงสร้างแบบ Semi-Structure Data ซึ่งเป็น Text File โดยมีบรรทัดแรกเป็น Attribute Names จำนวน 144 Attributes และบรรทัดที่เหลืออีก 1,432,492 บรรทัด เป็น Attribute Values ซึ่งแต่ละ Value มี Delimitor เป็นเครื่องหมาย Comma (,) คั่นกลางอย่างคงเส้นคงวา (Consistent)

ขั้นตอนที่ 2: Loading Raw Data เข้าสู่ Hadoop HDFS

รูปที่ 4 แสดง Raw Data ใน HDFS (Hadoop Distributed File System)

ในขั้นตอนที่ 2 เป็นการใช้ HDFS Client (Code หมายเลข 6 จากรูปที่ 4) ทำการ Copy Raw Data จาก Linux File System ไปวางไว้ที่ HDFS ใน Path: /user/root/ โดยไม่มีการปรับปรุงหรือปรับแต่งข้อมูลใดๆ ก่อนหน้านี้เลย

ขั้นตอนที่ 3: การใช้ Spark ทำ Data Transformation

ในขั้นตอนนี้ประกอบด้วย 3 ขั้นตอนย่อย ดังนี้

3.1 ใช้ Apache Spark อ่าน Raw Data (LoanStats_web.csv) จาก HDFS แล้ว Convert เป็น DataFrame ซึ่งเป็น Structure Data ในแบบที่ Spark สามารถประมวลผลได้

รูปที่ 5 แสดงขั้นตอนการอ่าน Raw Data จาก HDFS แล้ว Convert เป็น Spark’s DataFrame

3.2 ใช้ Apache Spark ทำการ Cleansing Data เช่น การเอาเครื่องหมาย % ออกจากตัวเลขอัตราดอกเบี้ย (int_rate) ซึ่งมีอยู่ใน Raw Data ตามที่กรอบสีแดงในรูปที่ 3 เป็นต้น

รูปที่ 6 แสดงขั้นตอนการ Cleansing Data

3.3 ใช้ Spark เขียนข้อมูลที่ผ่านการปรับปรุงแล้วจากขั้นตอน 3.2 ลงสู่ HDFS ในแบบ Parquet Format ซึ่งเป็น Column-oriented Structure ที่เหมาะกับการทำ Descriptive Analytics ต่อไป

รูปที่ 7 แสดงขั้นตอนการเขียนข้อมูลที่ผ่านการปรับปรุงแล้ว ลงสู่ HDFS ในแบบ Parquet Format

ขั้นตอนที่ 4: Data Analytics บนข้อมูลแบบ Parquet Format

การทำ Data Analytics ตามตัวอย่างนี้เป็นการทำ Descriptive Analytics ด้วย Hive ซึ่งมีการสร้าง Hive Table หลายๆ Tables บนข้อมูลเดียวกัน (ข้อมูลแบบ Parquet Format). แม้ว่า ขั้นตอนการเขียน Parquet Files ตาม Code หมายเลข 23 รูปที่ 7 นั้น จะเป็นการเขียนทุก Attributes จำนวน 144 Attributes ลงไปทั้งหมดก็ตาม แต่เราสามารถสร้าง Hive Table ที่มี Fields (Attributes) ที่แตกต่างกันได้หลายๆ Tables

4.1 การสร้างและการทำ Analytics บน Hive Table “analytics_loan” ซึ่งมีเพียง 3 Fields เพื่อวิเคราะห์อัตราดอกเบี้ยและค่าเฉลี่ยวงเงินกู้ยืมที่แตกต่างกันไปตาม Credit Scores

รูปที่ 8 แสดงการทำ Analytics บน Table “analytics_loan”

4.2 การสร้างและการทำ Analytics บน Hive Table “analytics_borrow” ซึ่งมี 4 Fields เพื่อทราบค่าเฉลี่ยวงเงินกู้ยืม ที่แตกต่างกันไปตามระยะเวลาการจ้างงานของผู้กู้ยืม

รูปที่ 9 แสดงการทำ Analytics บน Table “analytics_borrower”

ผู้เขียนขอสรุปการ Implement หลักการแนวคิด ELT สำหรับการจัดการ Big Data ข้างต้นไว้ตามรูปที่ 9

รูปที่ 10 แสดงการจัดการข้อมูลขนาดใหญ่ (Big Data) ด้วยการทำ ELT

จากรูปที่ 9 แสดงให้เห็นว่าเมื่อ Implement ELT แล้ว จะช่วยลดการทำ Extraction และ Loading แต่ยังคงมีการ Transformation ให้สอดคล้องกับโจทย์ Analytics ที่หลากหลายได้บ่อยครั้งตามต้องการ และยังช่วยลดการสูญเสีย Information ที่จำเป็นต่อการทำ Analytics มุมมองใหม่ๆ เช่น Fraud Detection อีกด้วย. สำหรับ Code ทั้งหมดของงานเขียนนี้ ท่านสามารถโหลดมาลองใช้ได้จาก https://github.com/aekanun2020

สรุปส่งท้าย

Data Silos เป็นสิ่งที่ไม่มีใครอยากให้เกิดขึ้นในองค์กร แต่ก็อาจเป็นเรื่องที่หลีกเลี่ยงไม่ได้และทำขึ้นมาตามความจำเป็น. Big Data Technology เกิดขึ้นมาด้วยเหตุผลหนึ่งคือ เพื่อให้จัดการข้อมูลที่มีหลากหลาย Format ได้ ฉะนั้นแล้วต้องใช้มันให้ถูกต้องตามจุดประสงค์การเกิดมาของมัน. หากเราไปทำลายความหลากหลายของข้อมูลตั้งแต่แรกเก็บแล้ว ทั้งการสูญเสีย Information สำหรับงานใหม่ๆ และความล่าช้าที่เกิดขึ้นจากการต้องไป Extraction and Loading ซ้ำๆ เพื่อตอบโจทย์ที่เปลี่ยนแปลงบ่อยแล้ว Big Data Silos จะเกิดขึ้นอย่างแน่นอนครับ.