หมวดหมู่: Articles

หนึ่งใน Top Strategic Technology Trends ของ Gartnerในปี 2022 คือ Data Fabric หลายๆคนอาจจะเข้าใจว่าเป็นการสร้างสถาปัตยกรรม Big Data อย่าง Data Warehouse, Data Lake หรือ Data LakeHouse หรือเป็นการทำ Single source of Truth ที่จะให้นักวิเคราะห์ข้อมูลสามารถเข้าใช้ได้จากแหล่งเดียวกัน ซึ่งจริงๆแล้วอาจไม่ใช่คำตอบที่ถูกต้องนัก

ผมได้อ่านรายงานเรื่อง Data Fabric as Modern Data Architecture ของ Alice LaPlante ที่ได้อธิบายในเรื่องนี้ไว้ว่า หลักการของ Data Fabric เป็นการทำ Data Architecture แบบกระจายในรูปแบบใหม่ (Modern Distributed Data Architecture) ที่จะทำให้เราสามารถจะเข้าถึงข้อมูลที่แชร์ไว้และสามารถบริหารจัดการข้อมูลเหล่านั้นได้ โดย Data Fabric จะมีหลักการสำคัญสามเรื่องคือ

• การมีข้อมูลสำหรับผู้ใช้ทุกคนและทุกกรณี กล่าวคือจัดเตรียมข้อมูลที่น่าเชื่อถือและทันสมัยกับการวิเคราะห์ที่หลากหลาย การบริหารและจัดการธรรมาภิบาลวิเคราะห์ รวมถึงการให้ผู้ใช้ทางธุรกิจ (Business user) สามารถใช้งานได้ด้วยตนเอง
• การมีข้อมูลทั้งหมดจากหลายแหล่ง กล่าวคือจะต้องมีข้อมูลทั้งที่เก็บไว้ในแหล่งเก็บข้อมูล หรือข้อมูลที่เคลื่อนไหว จากหลายแหล่ง โดยข้อมูลอาจมีรูปแบบที่แตกต่างกัน แต่จุดสำคัญคือต้องมีข้อมูลให้ครบถ้วนทั้งหมด
• การมีข้อมูลที่อยู่ในระบบใดๆที่หลากหลาย กล่าวคืออาจมีทั้ง Data Warehouse, Data Lake หรือ Data LakeHouse ในหลายๆระบบ แต่ละระบบอาจอยู่ทั้งบน On-Premise หรือ Multi Cloud ก็ได้ ไม่จำเป็นต้องมีรวบรวมไว้ที่เดียว

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

• Data Catalog ที่ให้เราสามารถที่จะมีแคตตาล็อกของของข้อมูล จากแหล่งข้อมูลที่หลากหลาย เพื่อให้บริหารจัดการและทำธรรมาภิบาลข้อมูลได้ดีขึ้น
• Master data management กล่าวคือมี Master data ชุดหนึ่งสำหรับข้อมูลทั้งภายในและภายนอกองค์กร
• Metadata management กล่าวคือมีนโยบายในการจัดการข้อมูลเพื่อให้มั่นใจได้ว่า สามารถเข้าถึง แชร์ เชื่อมโยง วิเคราะห์ และดูแลรักษาได้
• Data preparation มีเครื่องมือหรือซอฟต์แวร์ที่จะทำ Data Cleansing เพื่อให้องค์กรมั่นใจได้ว่าจะข้อมูลที่ทีคุณภาพ และมีความถูกต้อง
• Data Integration มีกระบวนการที่จะทำให้ข้อมูลจากหลายแหล่วสามารถเชื่อมโยงกันได้ และทำให้ผู้ใช้สามารถเห็นได้อย่าง Single View
• Data Analytics มีกระบวนการที่สามารถนำข้อมูลจากหลายแหล่งมาวิเคราะห์ได้
• Data Visualisation มีเครื่องมือที่จะเห็นข้อมูลจากหลายแหล่งในรูปแบบของกราฟหรือการแสดงผลที่ดูได้อย่างเข้าใจง่าย
• Data Governance มีนโนบายเพื่อให้แน่ใจได้ว่าข้อมูลต่างๆมีคุณภาพ และสามารถเข้าถึงได้จากกลุ่มผู้ใช้ต่างๆ

การสร้างสถาปัตยกรรม Data Fabric จึงไม่ได้หมายถึงการจัดกหา Product ตัวใดตัวหนึ่ง หรือจะเกิดขึ้นได้ทันทีทันใด แต่ Data Fabric จะใช้ระยะเวลาในการเดินทาง (Journey) ขึ้นไปตามลำดับ จนบรรลุเป้าหมาย ในหนังสือของ Alice LaPlante ได้ระบุว่าการทำ สถาปัตยกรรม Data Fabric จะมี Data Pipeline อยู่ 5 ขั้นคือ

ขั้นตอนที่ 1 Collect:  คือการเก็บข้อมูล ซึ่งอาจเป็นแบบ Real time เช่นข้อมูลจาก Transactional Database ข้อมูลจาก IoT ข้อมูลจากการบริการลูกค้า

ขั้นตอนที่ 2 Extract & Load: คือการดึงข้อมูลที่เก็บจากขั้นตอนที่ 1 โหลดลงไปใน Database หรือ Storage ในการเก็บข้อมูล ขั้นตอนนี้อาจต้องมีการทำ ETL หรือ ELT และในขั้นตอนนี้จะมีการทำ Data Preperation เพื่อให้ได้ข้อมูลที่มีคุณภาพ

ขั้นตอนที่ 3 Store: คือการเก็บข้อมูลที่อาจอยู่ใน Data Warehouse, Data Lake หรือ Data Lakeshore ข้อมูลที่เก็บในขั้นตอนนี้จะรวมไปถึง Streaming Data

ขั้นตอนที่ 4 Transform & Optimize: ขั้นตอนนี้สำคัญเป็นขั้นตอนที่สำคัญสุดของ Data Fabric จะเป็นการบริหารจัดการข้อมูล การทำ Master Data management (MDM) และการบริหารจัดการ Metadata ของข้อมูล

ขั้นตอนที่ 5 Delivery: ขั้นตอนนี้คือการส่งต่อให้ผู้ใช้ สามารถที่จะนำข้อมูลไปค้นหา วิเคราะห์ หรือแสดงผลได้ โดยผู้ใช้อาจต้องสามารถเข้าถึงข้อมูลได้ตามสิทธิ์และมี Data Catalog ให้ผู้ใช้

ซึ่งขั้นตอนเหล่านี้สามารถแสดงได้ตามรูปที่ 1

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

ธนชาติ นุ่มนนท์

IMC Institute

บทความอื่นๆที่เกี่ยวข้อง

• ตอนที่ 1 : Big Data Pipeline ทำไมไม่ใช่ Data Warehouse
• ตอนที่ 2 : สถาปัตยกรรมบน Data Lake
• ตอนที่ 3 : จาก Hadoop แบบ On-Premise สู่การใช้บริการบน Public cloud
• ตอนที่ 4 : สถาปัตยกรรม Data platform บน Public cloud
• ตอนที่ 5 : สถาปัตยกรรม Data platform สำหรับประมวลผลข้อมูลแบบ Streaming
• ตอนที่ 6 : สถาปัตยกรรม Cloud Data platform สำหรับประมวลผลข้อมูลทั้งแบบ Batch และ Streaming
• ตอนที่ 7: แนวโน้มสถาปัตยกรรม Big Data 2022
• ตอนที่ 8: การจัดการข้อมูลบน Data Lake
• ตอนที่ 9: สถาปัตยกรรม Data Lake + Data Warehouse
• ตอนที่ 10: สถาปัตยกรรม Data Lakehouse

ในตอนที่สองซึ่งผมเขียนเรื่องของ สถาปัตยกรรมบน Data Lake ได้ระบุไว้ช่วงหนึ่งว่า เทคโนโลยีการประมวลผลของสถาปัตยกรรม Data Lake เช่ย Hadoop อย่าง Hive หรือ Spark หากจะนำไปแสดงผลโดยตรงยัง Data visualisation tool โดยใช้คำสั่ง SQL จะพบว่ามีความเร็วไม่พอ ดังนั้นเราจึงมักเห็นสถาปัตยกรรม Big data ที่นำเอา Data Warehouse มาเชื่อมโยงกับ Data Lake และจะมีการนำข้อมูลจาก Data Lake บางส่วนไปเก็บไว้ใน Data Warehouse เพื่อจะทำให้การทำ Queryโดยใช้คำสั่ง SQL จาก Data visualisation tool มีความรวดเร็วขึ้น

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

จากรูปที่ 1 เราจะเห็นได้ว่าไดอะแกรมของ สถาปัตยกรรม Data Lake + Data Warehouse จะประกอบด้วยส่วนสำคัญสองส่วนคือ

1. Big Data Platform ซึ่งในกรณีของระบบ On-Premise ก็อาจเป็น Hadoop Ecosystem ซึ่งจะมี Storage ที่ทำหน้าที่เป็น Data Lake อย่าง HDFS ซึ่งเราสามารถจะใช้เทคโนโลยีในการประมวลข้อมูลแบบขนาน (Parallel processing) ใน HDFS ที่หลากหลายได้เช่น Spark, MapReduceม Hive หรือ Impala หรืออาจเน้นเฉพาะการค้นหาข้อมูลผ่าน Query Engine อย่าง Hive, Spark SQL หรือ Impala
2. Enterprise Data Warehouse (RDBMS) ส่วนนี้จะเป็นการส่งออก (Export) ข้อมูลจาก Data Lake บางส่วนที่ต้องการนำมาแสดงผลผ่าน BI Apps มาเก็บไว้ โดยการใช้เทคโนโลยีที่เป็น SQL ทั้งนี้เพราะการทำ SQL ผ่าน Data Warehouse จะทำได้รวดเร็วกว่า ซึ่งแม้ว่ารูปจะแสดงให้เห็นว่า เราสามารถที่จะใช้ Query Engine ของ Big Data Platform โดยใช้ภาษา SQL ดึงข้อมูลจาก Data Lake ไปแสดงผลยัง BI Apps โดยตรงก็ได้ แต่โดยมากจะพบว่ามีความล่าช้ากว่ามากจึงไม่นิยมทำกัน

ทั้งนี้การประมวลผลข้อมูลบนสถาปัตยกรรม Data Lake + Data Warehouse จะแบ่งกันชัดเจนดังนี้

• การทำ Data Preparation หรือ Data Processing สำหรับข้อมูลแต่โซนเช่นจาก Raw Zone ไปสู่ Trusted Zone หรือ Refined Zone จะทำบน Data Lake และใช้เทคโนโลยีอย่าง Apache Spark เป็นหลัก
• การนำข้อมูลไปแสดงผลผ่าน BI Apps จะใช้ข้อมูลที่อยู่ใน Data Warehouse และใช้ภาษา SQL โดย Data Engineer จะต้องทำการ Export ข้อมูลจาก Refined Zone หรือ Trusted Zone ไปเก็บไว้ใน Data Warehouse ก่อน
• การทำ Data Science จะใช้ข้อมูลที่อยู่ใน Data Lake ซึ่งโดยมากจะเป็นข้อมูลที่อยู่ใน Trusted Zone และใช้เทคโนโลยีที่เป็นการประมวลแบบ Machine Learning อย่าง Spark MLlib

( สำหรับรายละเอียดการบริหารจัดการข้อมูลแต่ละโซนของ Data Lake สามารถดูได้จาก บทความเรื่อง การจัดการข้อมูลบน Data Lake )

ดังนั้นเราจะให้ได้ว่าการจะทำโครงการ Big Data ได้ดี สถาปัตยกรรมที่ใช้จะต้องประกอบไปด้วยทั้ง Data Lake และ Data Warehouse รวมทั้งมีการใช้เทคโนโลยีที่หลากหลายดังอธิบายในตอนนี้

ธนชาติ นุ่มนนท์

IMC Institute

——-

บทความอื่นๆที่เกี่ยวข้อง

• ตอนที่ 1 : Big Data Pipeline ทำไมไม่ใช่ Data Warehouse
• ตอนที่ 2 : สถาปัตยกรรมบน Data Lake
• ตอนที่ 3 : จาก Hadoop แบบ On-Premise สู่การใช้บริการบน Public cloud
• ตอนที่ 4 : สถาปัตยกรรม Data platform บน Public cloud
• ตอนที่ 5 : สถาปัตยกรรม Data platform สำหรับประมวลผลข้อมูลแบบ Streaming
• ตอนที่ 6 : สถาปัตยกรรม Cloud Data platform สำหรับประมวลผลข้อมูลทั้งแบบ Batch และ Streaming
• ตอนที่ 7: แนวโน้มสถาปัตยกรรม Big Data 2022
• ตอนที่ 8: การจัดการข้อมูลบน Data Lake

เมื่อกล่าวถึงสถาปัตยกรรมข้อมูลโดยใช้ Data Lake เราจะเข้าใจได้ว่าหลักการคือจะให้ความสำคัญกับข้อมูลทุกอย่าง เราจะเน้นที่จะนำข้อมูลดิบ (Raw Data) เข้าไปเก็บใน Data Lake แล้วจึงค่อยแปลงข้อมูลก่อนทำการประมวลผล กล่าวคือ เราจะเน้นหลักการการทำ ELT (Extract, Load แล้วค่อย Transform) ข้อมูล ที่จะเป็นวิธีการ Schema on Read ซึ่งแตกต่างจากกรณีของ Data Warehouse ที่จะเป็นการทำ ETL (Extract, Transform and Load) ข้อมูล ซึ่งเป็นการทำ Schema on Write

Data Lake แม้จะเป็นการเก็บข้อมูลดิบ แต่ไม่ใช่ว่าจะมีแต่ข้อมูลดิบที่เก็บใน Data Lake ปกติแล้วข้อมูลที่อยู่ใน Data Lake จะถูกแบ่งออกเป็นโซน โดยแต่ละโซนจะมีการเก็บข้อมูลที่ต่างกัน และมีผู้ใช้ข้อมูลในแต่ละโซนที่แตกต่างกัน ซึ่งโดยทั่วไปข้อมูลใน Data Lake จะแบ่งออกเป็นสามโซนดังนี้

1. Bronze Zone หรือบางทีก็เรียกว่า Raw Zone หรือ Landing Zone เป็นโซนของ Data Lake ที่ใช้เก็บข้อมูลดิบจากแหล่งต่างๆที่นำเข้ามาสู่ระบบ ข้อมูลในโซนนี้ยังเป็นข้อมูลดิบ อาจยังขาดความถูกต้อง ยังไม่สมบูรณ์ ต้องการ Clean ข้อมูลก่อน ถึงจะนำไปใช้งานได้ โดยมากคนที่จะใช้ข้อมูลในโซนนี้จะเป็น Data Engineer ที่จะทำกระบวนการ Data Preperation หรือแปลงข้อมูลให้สมบูรณ์ขึ้นก่อนนำไปใช้ในขั้นต่อไป
2. Silver Zone หรือบางทีก็เรียกว่า Trusted Zone หรือ Process Zone เป็นโซนของ Data Lake ที่ใช้เก็บข้อมูลที่ทาง Data Engineer ได้ทำแปลงข้อมูลจาก Raw Zoneให้สมบูรณ์ขึ้นแล้ว และสามารถนำมาใช้ในการวิเคราะห์ข้อมูลทั้งแบบ Descriptive หรือ Predictive analytics ได้ ผู้ที่จะใช้ข้อมูลในโซนนี้อาจเป็น Business Analyst หรือ Data Scientist
3. Gold Zone หรือบางทีเรียกว่า Refined Zone หรือ Access Zone ซึ่งเป็นโซนของ Data Lake ที่ใช้เก็บข้อมูลที่อาจจะผ่านการเชื่อมโยงข้อมูลจากหลายชุด หรือทีอาจเป็น เพื่อนำมาข้อมูลที่ผ่านจาก Silver Zone มาเพื่อให้ผู้ใช้ทั่วไปใช้งานเช่น Business User มาดูและวิเคาะห์ข้อมูลผ่าน Dashboard

จากการที่ Data Lake แบ่งข้อมูลเป็นหลายโซน เราคงจะเห็นได้ว่า ข้อมูลที่เก็บใน Data Lake อาจมีปริมาณมากกว่าข้อมูลจริง และจำเป็นจะต้องเก็บข้อมูลซ้ำในแต่ละโซน และบางครั้ง เพื่อให้ข้อมูลมีขนาดเล็กลงก็อาจจำเป็นต้องเก็บข้อมูลใน Format ที่มีการบีบอัดข้อมูลเช่น Parquet หรือ ORC

Data Governance ก็เป็นอีกประเด็นหนึ่งที่สำคัญในการบริหารจัดการ Data Lake เพราะมีข้อมูลที่หลากหลาย จึงจำเป็นต้องมี Data Catalog ที่ดี มีการจัดเก็บ Metadata และ การดูแลเรื่องความปลอดภัยของข้อมูล (Data security) นอกจากนี้ผู้ใช้ Data Lake อาจจะต้องทำ Data Preparation เป็นประจำเมื่อมีข้อมูลใหม่เข้ามาหรือข้อมูลใน Raw Zone มีการเปลี่ยนแปลง

ดังนั้นเราจะเห็นได้ว่า การบริหารจัดการ Data Lake จะมีความซับซ้อน และต้องมี Data Engineer ในการที่จะดูแลข้อมูลในโซนต่างๆ กับต้องมีระบบ Data Governance ทีดี

ธนชาติ นุ่มนนท์

IMC Institute

——-

บทความอื่นๆที่เกี่ยวข้อง

• ตอนที่ 1 : Big Data Pipeline ทำไมไม่ใช่ Data Warehouse
• ตอนที่ 2 : สถาปัตยกรรมบน Data Lake
• ตอนที่ 3 : จาก Hadoop แบบ On-Premise สู่การใช้บริการบน Public cloud
• ตอนที่ 4 : สถาปัตยกรรม Data platform บน Public cloud
• ตอนที่ 5 : สถาปัตยกรรม Data platform สำหรับประมวลผลข้อมูลแบบ Streaming
• ตอนที่ 6 : สถาปัตยกรรม Cloud Data platform สำหรับประมวลผลข้อมูลทั้งแบบ Batch และ Streaming
• ตอนที่ 7: แนวโน้มสถาปัตยกรรม Big Data 2022

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

1. Data Lake house จะทำให้การบริหารจัดการ Big Data ทำได้ดีขึ้น จากที่กล่าวไว้ว่าการเก็บข้อมูลของ Big Data จะมีอยู่สองแนวทางคือ Data Warehouse และ Data Lake ซึ่งข้อมูลที่เก็บใน Data Warehouse ส่วนใหญ่จะเป็นข้อมูลในรูปแบบเดิมที่เป็น Structure data และมีข้อจำกัดในเรื่องขนาดของข้อมูล องค์กรต่างๆจึงหันมาใช้ Data Lake ในการเก็บข้อมูลมากขึ้น เพราะสามารถเก็บข้อมูลได้หลากหลาย และเก็บข้อมูลปริมาณมหาศาลได้ดีกว่า

แต่ข้อมูลที่เก็บใน Data Lake ที่มักเป็นข้อมูลดิบ จะขาดการ cleansing ที่ดีทำให้ข้อมูลไม่มีคุณภาพ และขาดการจัดระเบียบที่ดีพอ ทำให้การค้นหาหรือการทำธรรมาภิบาลของใน Data Lake ค่อนข้างจะยากกว่าการใช้ Data Warehouse ดังนั้นจึงมีการพูดถึงการจัดเก็บข้อมูลใน Data Lake ที่มีระเบียบและมีมาตรฐานโดกยเฉพาะข้อมูลประเภท Structure data และ Semi structure data อย่าง Data Lakehouse ของ Databrick ที่น่าจะมาแทนที่ Data Lake แบบเดิมๆ

2. การวิเคราะห์ข้อมูลจะใช้ Citizened Data scientist มากขึ้น แต่ก่อนการวิเคราะห์ข้อมูลแบบ Predictive analytics จะต้องพึ่งนักวิทยาการข้อมูล (Data scientist) ที่ต้องมีความเก่งด้านอัลกอริทึมและการเขียนโปรแกรมเป็นอย่างดี แต่ก็มักจะเจอปัญหาที่นักวิทยาการข้อมูลอาจขาดมุมมองทางด้านธุรกิจและอุตสาหกรรมที่ต้องการวิเคราะห์ ทำให้วืเคราะห์ออกมาได้ไมาดีเท่ากับคนที่มี domain expert

แต่ในปัจจุบันมีเทคโนโลยีที่เป็น AutoML ซึ่งเป็นการทำ Data Science โดยไม่ต้องเขียนโปรแกรม (No-code) เช่น Google AutoML หรือ Amazon Sagemaker Canvas ซึ่งทำให้คนทั่วไปสามารถจะทำเองได้ และเป็นเครื่องมือที่ใช้งานง่าย ดังนั้นแนวโน้มในการวิเคราะห์ข้อมูลในอนาคตจะมุ่งสู่การใช้ Citizened Data scientist ที่เป็นคนทำงานในองค์กรหรืออุตสาหกรรมนั้นๆ โดยไม่จำเป็นต้องมีความรู้ด้านไอทีหรือ Data Science มากนัก

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

4. การวิเคราะห์ข้อมูลจะเน้นข้อมูลที่ถูกต้อง (Right data) มากกว่าปริมาณ หลักการเดิมของการวิเคราะห์ข้อมูล Big Data คือการที่เราจะเน้นเรื่องของปริมาณ และข้อมูลที่มีขนาดใหญ่ โดยเรามักจะบอกว่า ยิ่งมีข้อมูลมากก็จะวิเคราะห์ข้อมูลได้ดียิ่งขึ้น แต่ในปัจจุบันมีข้อมูลมหาศาล บางอย่างมีความซ้ำซ้อน บ้างก็ไม่ถูกต้อง ทำให้การวิเคราะห์ข้อมูลล่าช้า บางครั้งก็คาดเคลื่อน ดังนั้นแนวโน้มของการวิเคราะห์ข้อมูลจึงต้องเน้นเฉพาะข้อมูลที่ถูกต้องกล่าวคือทำ Right data analytic แทนคำว่า Big data analytic

5. สถาปัตยกรรม Big Data มุ่งไปสู่ Multi cloud มากขึ้น การทำโครงการ Big data ที่เป็นระบบ On-premise เพืยงอย่างเดียวเป็นไปได้ยากขึ้น เพราะข้อมูลเริ่มมีขนาดใหญ่ขึ้น ต้องการทรัพยากรคอมพิวเตอร์มากขึ้น การลงทุนจะมีมูลค่าสูงเกินไป ดังนั้นจึงจำเป็นที่ต้องพึ่งบริการ Big data บน Public cloud มากขึ้น และขณะเดียวกัน Public cloud แต่ละรายก็จะมีบริการการวิเคราะห์ข้อมูลที่แตกต่างกันออกไป องค์กรต่างก็อาจจะต้องใช้บริการของผู้ให้บริการหลายราย ดังนั้นแนวโน้มของ สถาปัตยกรรม Big Data ก็คงจะเห็นการใช้ทั้งระบบ On-premise และ Public cloud ที่จะกลายเป็น Multicloud

ทั้งหมดนี้คือ Big Data Trends 2022 ที่ผมอยากสรุปไว้

ธนชาติ นุ่มนนท์

IMC Institute

——————————

บทความอื่นๆที่เกี่ยวข้อง

• ตอนที่ 1 : Big Data Pipeline ทำไมไม่ใช่ Data Warehouse
• ตอนที่ 2 : สถาปัตยกรรมบน Data Lake
• ตอนที่ 3 : จาก Hadoop แบบ On-Premise สู่การใช้บริการบน Public cloud
• ตอนที่ 4 : สถาปัตยกรรม Data platform บน Public cloud
• ตอนที่ 5 : สถาปัตยกรรม Data platform สำหรับประมวลผลข้อมูลแบบ Streaming
• ตอนที่ 6 : สถาปัตยกรรม Cloud Data platform สำหรับประมวลผลข้อมูลทั้งแบบ Batch และ Streaming

ผมได้เขียนบทความในคอลัมน์ Think Beyond ในหนังสือพิมพ์กรุงเทพธุรกิจตั้งแต่ปี 2562 เลยได้รวบรวมบทความที่เขียนไว้ในช่วงปี 2563 ดังนี้

ไตรมาสที่สี่ ปี 2563

• 25 ธันวาคม ผลกระทบ ‘เทคโนโลยี’ กับแนวโน้มธุรกิจปีหน้า
• 6 ธันวาคม ‘WEF’ ชี้ปรับทักษะคนเป็น ‘เรื่องจำเป็น’
• 27 พฤศจิกายน เมื่อ ‘เอไอ’ กลายเป็นเรื่องง่าย ถึงเวลาที่ต้อง ‘พัฒนาคน’
• 20 พฤศจิกายน ‘ดิจิทัลคอนเทนท์ต่างชาติ’ กลืนตลาดไทย ‘ปัญหา’ จึงเริ่มปรากฏ
• 13 พฤศจิกายน กลยุทธ์ด้าน ‘ดิจิทัล’ สำหรับองค์กรในปีหน้า
• 6 พฤศจิกายน ‘รอยเท้าดิจิทัล’ สิ่งที่เราสร้างเอง แต่จะมีผลระยะยาว
• 30 ตุลาคม แนวโน้มเทคโนโลยีดิจิทัล ปี 2021
• 23 ตุลาคม ยุค ‘ทุนนิยมสอดแนม’ นำไปสู่ความแตกแยกในสังคม
• 9 ตุลาคม ‘ดิจิทัล ดิสรัปชั่น’ ชี้ชะตา ธุรกิจ ‘รอด-ไม่รอด’
• 2 ตุลาคม ‘บิ๊กดาต้า’ กับ ‘เลือกตั้ง’ ประธานาธิบดีสหรัฐอเมริกา

ไตรมาสที่สาม ปี 2563

• 11 กันยายน ‘โฆษณาชวนเชื่อ’ ยุคใหม่ ผ่าน‘โซเชียลมีเดีย’ (ตอนจบ)
• 4 กันยายน การโฆษณาชวนเชื่อยุคใหม่ผ่าน ‘โซเชียลมีเดีย’ (1)
• 28 สิงหาคม มองมุมเปลี่ยน “ดิจิทัล-โซเชียลฯ” ตัวสร้างวิกฤติสังคม
• 21 สิงหาคม ‘ทักษะที่จำเป็น’ ต่อการทำงานในโลกหลังยุคโควิด
• 14 สิงหาคม โลกอินเทอร์เน็ตอาจมี 2 ขั้ว “อเมริกา และ จีน”
• 24 กรกฎาคม ส่องผลสำรวจ อี-กอฟเวอร์เมนท์ 2020
• 17 กรกฎาคม เอสเอ็มอี บิ๊กดาต้าของ สสว. ความร่วมมือเปิดข้อมูลภาครัฐ
• 10 กรกฎาคม ‘Data is the new oil’ การแข่งขันที่ทุกฝ่ายต้องตระหนัก
• 3 กรกฎาคม สี่ยุคของ ‘เสิ่นเจิ้น’ ที่ก้าวสู่การเป็น ‘ซิลิคอน วัลเลย์’

ไตรมาสที่สอง ปี 2563

• 26 มิถุนายน ปรากฎการณ์ Winner Take All ต้องลงทุน-สร้างทักษะที่ถูกต้อง
• 19 มิถุนายน Digital Transformation ความสำเร็จจากปัญหาอุปสรรคผู้บริโภค
• 12 มิถุนายน ‘เรียน-สอนออนไลน์’ จะทดแทน การเรียนปัจจุบันได้จริงหรือ
• 5 มิถุนายน ‘เน็ตฟลิกซ์’ ที่เป็นมากกว่า แพลตฟอร์มด้านภาพยนตร์
• 29 พฤษภาคม ความต่างระหว่างเงินดิจิทัลและระบบการชำระเงินดิจิทัล
• 22 พฤษภาคม ‘โควิด-19’ ตัวเร่งมหาวิทยาลัย ปรับตัวสู่ ‘โลกออนไลน์’
• 15 พฤษภาคม ‘มารยาท 10 ข้อ’ การประชุมออนไลน์
• 8 พฤษภาคม ตลาด ‘ชุมชนออนไลน์’ ช่วยผู้คนในสังคมอยู่รอด
• 1 พฤษภาคม การประชุมออนไลน์ กำลังกลายเป็น ‘New Normal’
• 24 เมษายน เมื่อข้อมูลในระบบไม่ถูก ระบบคัดกรองก็ทำงานได้ไม่ดี
• 17 เมษายน โลกหลังยุคโควิด (Post-COVID era)จะเปลี่ยนอย่างไรในมุมดิจิทัล (ตอนที่สอง)
• 10 เมษายน โลกหลังยุคโควิด (Post-COVID Era) จะเปลี่ยนอย่างไรในมุมดิจิทัล
• 3 เมษายน ‘โควิด-19’ จุดเปลี่ยนสู่‘เรียนออนไลน์’ แต่ต้องไม่ทิ้งใครไว้ข้างหลัง

ไตรมาสที่หนึ่ง ปี 2563

• 27 มีนาคม สุดท้ายเราจะเห็นคำว่าโลก ‘ยุคก่อนโควิด’ และ’ยุคหลังโควิด’
• 20 มีนาคม เชื่อมั่นประเทศไทย วิกฤตินี้ประเทศต้องชนะ
• 13 มีนาคม นโยบายที่หน่วยงาน ‘ควรมี’ ต่อ ‘การทำงานทางไกล’
• 6 มีนาคม ผลกระทบของไวรัสโควิด ต่อบริษัทด้านเทคโนโลยี
• 28 กุมภาพันธ์ ‘ข้อมูลในโลกออนไลน์’ อย่าเชื่อเพราะเพื่อนแชร์มา
• 21 กุมภาพันธ์ คนไทยใช้เวลากับอินเทอร์เน็ต สูง ‘อันดับห้า’ ของโลก
• 7 กุมภาพันธ์ ‘บ้านอัจฉริยะ’ และ ‘เมืองอัจฉริยะ’ สู่สังคมที่ดีขึ้น
• 31 มกราคม สร้างภูมิคุ้มกัน สกัด ‘Fake News’
• 24 มกราคม เลี่ยงฝุ่น PM 2.5 ใช้เทคโนโลยีลดการเดินทาง
• 17 มกราคม ลดช่องว่าง ‘เชิงดิจิทัล’ ลดความเหลื่อมล้ำสังคม
• 10 มกราคม ผลิตนักวิทย์ฯแบบขาดพื้นฐาน หวั่นซ้ำรอยสร้างนักคอมพ์
• 3 มกราคม เมื่อเทคโนโลยีดิจิทัลทำให้การแข่งขันไร้พรมแดน

ธนชาติ นุ่มนนท์

IMC institute

ผมได้เขียนบทความในคอลัมน์ Think Beyond ในหนังสือพิมพ์กรุงเทพธุรกิจตั้งแต่ปี 2562 เลยได้รวบรวมบทความที่เขียนไว้ในช่วงปี 2564 ดังนี้

ไตรมาสที่สี่ ปี 2564

• 31 ธันวาคม ปี 2565 เมื่อโลกก้าวเข้าสู่ยุค Digital Transformation 2.0
• 26 ธันวาคม ปรากฏการณ์ศัพท์ใหม่ กระตุ้นกระแสแต่อาจไม่เกิดจริง
• 19 ธันวาคม ค่าใช้จ่ายสอนโมเดลเอไอ‘สูง’กว่าที่หลายคนคิดไว้มาก
• 10 ธันวาคม นโยบาย Cloud First จุดเริ่มต้น พัฒนาระบบไอทียุคปัจจุบัน
• 3 ธันวาคม “คนไทย” ติดอันดับโลก “ปรับตัว” การใช้และลงทุนสกุลเงิน “คริปโทฯ”
• 29 พฤศจิกายน แนวโน้ม ‘เทคโนโลยี-แนวคิด’ ที่ ‘ผู้บริหาร’ ต้องเปลี่ยน
• 21 พฤศจิกายน ลูกหลานควรเรียนอะไรจึงไม่ตกงานในยุคเอไอ
• 14 พฤศจิกายน ความต่างระหว่าง “เงินบาทดิจิทัล-ชำระเงินออนไลน์ และ พร้อมเพย์แบบเดิม”
• 8 พฤศจิกายน เทคโนโลยี Deepfake ปลอมได้ทุกสิ่ง “มีสติ-ศึกษา-แยกแยะ” ก่อนเชื่อ
• 31 ตุลาคม “ธนาคารออนไลน์” ระบบมีปัญหา หรือเราขาดความ “ตระหนัก”
• 22 ตุลาคม แม้อาจไม่จำเป็นต้องไปธนาคาร สุดท้ายเรายังต้องฝากเงินกับธนาคาร
• 15 ตุลาคม หลังจบโควิดพฤติกรรมผู้คน จะไม่กลับไปเหมือนเดิม
• 8 ตุลาคม “เงินหยวนดิจิทัล” ที่เป็นทั้ง “สกุลเงิน” และ “ระบบชำระเงิน”
• 1 ตุลาคม ‘จีน’สกัดเงินสกุลดิจิทัลอื่นโต ปลุกเชื่อมั่น‘เงินหยวนดิจิทัล’

ไตรมาสที่สาม ปี 2564

• 24 กันยายน “จีน” กับ “กฎแห่งอินเทอร์เน็ต” ฤาจะปฏิวัติวัฒนธรรมรอบใหม่
• 17 กันยายน ผลสำรวจ “อุตฯ ดิจิทัลไทย สะท้อนปรับตัวสู่สังคมดิจิทัล
• 10 กันยายน เราควรเชื่อมั่นในระบบ “เอไอ” ให้มาตัดสินแทนเราหรือไม่
• 3 กันยายน “ระบบจดจำใบหน้า” ความน่ากลัวกับการสูญเสียความเป็นส่วนตัว
• 27 สิงหาคม เมื่อคน ‘อัฟกานิสถาน’ต้องการ ปุ่มคลิกเดียวลบ‘รอยเท้าดิจิทัล’
• 20 สิงหาคม “ข้อมูลส่วนบุคคล”กับบริการออนไลน์ ใครได้ใครเสียประโยชน์?
• 13 สิงหาคม นักเรียน ‘รุ่นโควิด’ หยุดเรียน 1 ปี ให้เลื่อนชั้นอัตโนมัติ
• 6 สิงหาคม บูรณาการองค์ความรู้เพื่อ พัฒนาแอพ ‘Home isolation’
• 30 กรกฎาคม เมื่อรัฐบาลจีนเข้มเรื่องข้อมูล ‘เทคฯยักษ์ใหญ่’ ต่างมีผลกระทบ
• 23 กรกฎาคม การสืบราชการไซเบอร์ สิ่งที่เราไม่ควรมองข้าม
• 16 กรกฎาคม เมื่อ‘ข้อมูลเท็จ’แพร่กระจาย ใน‘สังคมออนไลน์’
• 9 กรกฎาคม ’10 ตำแหน่งงานไอที’ ในอนาคต
• 2 กรกฎาคม จบ ‘โควิด’ คุณคิดว่ารูปแบบ การทำงานจะเหมือนเดิมหรือไม่?

ไตรมาสที่สอง ปี 2564

• 25 มิถุนายน ‘การเรียนออนไลน์’ รอบใหม่ ‘เด็ก’ และ ‘ครู’ พร้อมยิ่งขึ้น
• 18 มิถุนายน ความเสี่ยงโลกออนไลน์เมื่อ ‘ข้อมูลบัตรประชาชน’ ไม่เป็นความลับ
• 11 มิถุนายน การนำ ‘เทคโนโลยี’ มาใช้กับ ‘การปรับเปลี่ยนวัฒนธรรม’
• 4 มิถุนายน ความต่างระหว่าง ‘เข้าประชุมออนไลน์’ กับ ‘แอบฟัง’ ประชุมออนไลน์
• 28 พฤษภาคม จัดอันดับ ‘รับมือ Fake News’ เยาวชนไทยติดรองสุดท้าย
• 21 พฤษภาคม NetFlix:อุตสาหกรรมทีวีเปลี่ยน เพราะ ‘เทคโนโลยี’
• 14 พฤษภาคม ‘หมอพร้อม’ กับศักยภาพ พัฒนาไอทีในประเทศไทย
• 7 พฤษภาคม ‘ไทย’ อันดับ 16 อีคอมเมิร์ซโลก แต่ ‘ค้าออนไลน์’ ข้ามประเทศ ‘
• 30 เมษายน ทำแบบฟอร์มออนไลน์ ต้องกังวลว่า องค์กรนั้นส่งมาจริงไหม
• 23 เมษายน Digital Transformation ต้องเริ่มจาก‘ข้อมูล’ ไม่ใช่เทคโนโลยี
• 9 เมษายน การสร้างวัฒนธรรม ‘ด้านข้อมูล’ ในองค์กร 5 ข้อ
• 2 เมษายน เชื่อหรือไม่? ทีมเบสบอล แข่งชนะจากการใช้ข้อมูลตัดสินใจ

ไตรมาสที่หนึ่ง ปี 2564

• 26 มีนาคม ‘อุปกรณ์อัจฉริยะ’ แต่กลับล้วง‘ข้อมูลส่วนตัว’ เรา
• 19 มีนาคม เมื่อ Starbucks ไม่ใช่ร้านขายกาแฟ แต่คือบริษัทด้านเทคโนโลยี
• 12 มีนาคม ทักษะด้านข้อมูล คือ อนาคตองค์กร ในยุคอุตสาหกรรม 4.0
• 5 มีนาคม จับตาอนาคต AI แดนมังกร จะแซงหน้าอเมริกา-ยุโรป หรือไม่?
• 24 กุมภาพันธ์ ‘Resume’ สมัครงานยุคใหม่
• 12 กุมภาพันธ์ หลักสูตรแบบเดิมในมหาวิทยาลัย ยัง ‘จำเป็น’ อยู่หรือไม่
• 5 กุมภาพันธ์ พนง.ร้านค้าต้อง ‘สร้างทักษะ’ มืออาชีพแข่งกับออนไลน์
• 29 มกราคม เส้นทางสู่ “นักวิทยาศาสตร์ข้อมูล”
• 22 มกราคม 10 ทักษะแห่งอนาคต ด้านเทคโนโลยีไอที
• 15 มกราคม เปิดโผ ขีดแข่งขันประเทศต่างๆ ทั่วโลกปี 2020 ของ WEF
• 8 มกราคม แนวทางปรับองค์กรเข้าสู่ ‘WFH 2.0’
• 1 มกราคม ‘ปี 2563’ สู่ ‘ปี 2564’ ปีเปลี่ยนแปลง สู่ ‘สังคมดิจิทัล’

ธนชาติ นุ่มนนท์

IMC institute

ในปี 2022 แนวโน้มของสถาบัตยกรรม Big Data กำลังเปลี่ยนไปจากเดิมที่กล่าวถึง Hadoop หรือ Data Lake ก็จะกลายเป็นเรื่องของ Big Data on Cloud และ Data Lakehouse มากขึ้น

ผมได้เคยเขียนบทความ Big Data Architecture มาทั้งหมด 6 ตอนเพื่อให้ได้อ่านกัน จะได้เข้าใจได้ว่า การออกแบบสถาปัตยกรรม Big Data ควรต้องใช้เทคโนโลยีอย่างไรบ้าง โดยผมมองระบบ Big Data เหมือนระบบไอทีทั้วไปที่จะต้องมี

• Input ซึ่งในที่นี้คือ Big Data ที่มีคุณลักษณะ 4V คือ Volume, Velocity, Variety และ Veracity
• Process/System ซึ่งในที่นี้คือ Big Data Pipeline หรือ Big Data Architecture
• Output ซึ่งในที่นี้ก็คือผลลัพธ์ที่ได้จากการวิเคราะห์ Big Data ซึ่งอาจเป็นแบบ Business Intelligence หรือ Data Science

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

• อะไรคือความแตกต่างระหว่าง Data Warehouse และ Data Lake
• การออกแบบ Big Data Architecture จำเป็นต้องการ Hadoop หรือไม่
• การออกแบบสถาปัตยกรรมโดยใช้ Public Cloud Services ต้องใช้บริการอะไรบ้าง
• สถาปัตยกรรมในการวิเคราะห์ข้อมูลแบบ Streaming เป็นอย่างไร

ซึ่งบทความของผมมีทั้งหมด 6 ตอนโดยมีหัวข้อต่างๆดังนี้

• ตอนที่ 1 : Big Data Pipeline ทำไมไม่ใช่ Data Warehouse
• ตอนที่ 2 : สถาปัตยกรรมบน Data Lake
• ตอนที่ 3 : จาก Hadoop แบบ On-Premise สู่การใช้บริการบน Public cloud
• ตอนที่ 4 : สถาปัตยกรรม Data platform บน Public cloud
• ตอนที่ 5 : สถาปัตยกรรม Data platform สำหรับประมวลผลข้อมูลแบบ Streaming
• ตอนที่ 6 : สถาปัตยกรรม Cloud Data platform สำหรับประมวลผลข้อมูลทั้งแบบ Batch และ Streaming

แต่ในปีนี้จะมีเรื่องใหม่ๆที่น่าสนใจมากขึ้น ทำให้ผมจะต้องเขียนบทความในตอนต่อๆไป เพื่อที่จะนำเสนอเทคโนโลยีใหม่ๆ โดยเฉพาะเรื่องของ Data Lakehouse โดยตั้งใจจะเริ่มเขียนบทความไว้เพิ่มเติมตอนต่างๆดังนี้

• ตอนที่ 7 แนวโน้มสถาปัตยกรรม Big Data 2022
• ตอนที่ 8 การจัดการข้อมูลบน Data Lake
• ตอนที่ 9 สถาปัตยกรรม Data Lakehouse
• ตอนที่ 10 สถาปัตยกรรม Data Fabric

ซึ่งผมจะทำการเผยแพร่ต่อไป

ส่วนผู้ที่สนใจอยากศึกษาเพิ่มเติมทาง IMC Institute ก็มีบันทึกวิดีโอรายการย้อนหลังรายตอนที่เกี่ยวข้องกับ Big Data architecture โดยเผยแพร่ไว้ที่ YouTube channel ของ IMC Institiute และก็มีหลักสูตรด้าน Big Data Architecture Design ที่จะทำการสอนทุกสามเดือน

ธนชาติ นุ่มนนท์

IMC Institute

ในตอนที่แล้วผมได้เขียนบทความให้เห็นว่าหากเราต้องการทำการประมวลผลข้อมูลแบบ Streaming เราอาจต้องปรับสถาปัตยกรรม Big data ให้เป็นแบบ Lambda หรือ Kappa และถ้าจะทำบนระบบ On-premise เราอาจต้องใช้เทคโนโลยีอย่าง Apache Kafka ที่มีทั้งการทำ Ingestion, Fast storage และ Real-time processing

และเมื่อพิจารณาถึงการทำสถาปัตยกรรมบน Cloud เราอาจจะเห็นได้ว่าขั้นตอน Big Data Pipeline ที่เคยระบุว่ามี 5 อย่างคือ Ingestion, Storage, Processing, Analytics และ Visualisation เมื่อต้องการออกแบบให้ประมวลผลทั้งแบบ Bacth และ Streaming จะมีความซับซ้อนขึ้น โดยอาจต้องมี Storage, Processing และ Analytics ที่ใช้กับข้อมูลทั้งสองแบบคือ Batch และ Streaming รวมถึงอาจต้องมี Pipeline ที่ใช้ในการเก็บข้อมูลสำหรับ Serving layer โดยจะมีสถาปัตยกรรมดังรูปที่ 1 ที่มีองค์ประกอบต่างๆดังนี้

• Ingestion ที่จะนำข้อมูลเข้ามาทั้งแบบ Batch และ Streaming
• Storage ในการเก็บข้อมูลที่อาจแบ่งเป็น Fast storage สำหรับข้อมูลแบบ Streaming และ Data Lake สำหรับข้อมูลแบบ Batch
• Processing/Analytics ในการประมวลและวิเคราะห์ข้อมูลที่อาจแบ่งเป็น Batch Processing/Analytics และ Real-time Processing/Analytics
• Serving layer ที่อาจเป็น Data Warehouse หรือ No SQL ที่จะทำหน้าที่เก็บผลลัพธ์ของการประมวลผลข้อมูลทั้งสองแบบ
• Visualisation ส่วนที่เป็นการแสดงผลที่อาจจะดึงมาจาก Serving layer

จากสถาปัตยกรรมข้างต้นนี้ หากไปเปรียบเทียบกับสถาปัตยกรรม Data Platform เดิมที่อยู่บน Cloud ซึ่งผมเคยได้สรุปไว้ในบทความ Big Data Architecture #4: สถาปัตยกรรม Data platform บน Public cloud จะพบว่ามีบริการที่อาจต้องนำเพิ่มขึ้นมาดังนี้

• Fast storage อย่าง อย่าง Azure Event Hub, Google Cloud Pub/Sub หรือ AWS Kinesis เพื่อทำหน้าที่เป็น Storage หลักในการเก็บข้อมูล Streaming
• Real-time processing อย่าง Azure Stream Analytics, Google Cloud DataFlow หรือ AWS Kinesis Stream Analytics

โดย Cloud Data Platform สำหรับผู้ให้บริการ Cloud สามรายหลักคือ Microsoft Azure, Google Cloud Platform และ AWS, Huawei Cloud, Alibaba Cloud และ Oracle cloud จะได้ Block diagram ดังรูปที่ 2 – 7

ธนชาติ นุ่มนนท์

IMC Institute