Big Data Architecture #11: สถาปัตยกรรม Data Fabric

หนึ่งใน 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

รูปที่ 1 สถาปัตยกรรม Data Fabric [จาก Data Fabric as Modern Data Architecture}

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

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

IMC Institute

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

Big Data Architecture #10: สถาปัตยกรรม Data Lakehouse

สถาปัตยกรรม Big Data ที่องค์กรต่างๆใช้ในช่วงสิบปีที่ผ่านที่นิยมคือสถาปัตยกรรม Data Lake โดยในระยะแรกจะเป็นระบบ On-Premise ที่ใช้เทคโนโลยี Hadoop โดยใช้ HDFS (Hadoop Distributed File System) เป็น Data Storage แต่ในระยะหลังก็มีการทำสถาปัตยกรรม Data Lake โดยใช้ Public Cloud มากขึ้น อาทิเช่นการใช้ Google Cloud Storage, AWS S3 หรือ Azore Data Lake Storage เนื่องจากมีค่าใช้จ่ายที่ถูกกว่า และสามารถต่อยอดไปกับบริการอื่นๆบน Cloud ได้มากกว่า อาทิเช่น AI as a Service หรือบริการ Data Warehouse บน Cloud

แม้ Data Lake จะสามารถที่จะเก็บข้อมูลได้หลากหลายประเภททั้ง Structure, Semi-Structure และ Unstructure สามารถเก็บข้อมูลจำนวนมหาศาลและมีราคาที่ถูกกว่าการใช้ Data Warehouse แต่การบริหารจัดการข้อมูลบนสถาปัตยกรรม Data Lake ก็มีความท้าทายอยู่ในหลายเรื่อง อาทิเช่น

Governance : เนื่องจากข้อมูลใน Data Lake มีขนาดใหญ่ มีการนำเข้ามาอย่างต่อเนื่อง การบริหารจัดการข้อมูลใน Data Lake จึงทำได้ค้อนข้องยาก ต้องมีระบบการจัดการ Data Catalog ที่ดี ต้องมีการจัดการวงจรชีวิตของข้อมูล(Data Life Cycle) ที่ดี ต้องจัดการเรื่องของความปลอดภัยและความเป็นส่วนตัวของข้อมูลที่ดี

ข้อมูลใน Data Lake ค่อนข้างจะยุ่งเหยิงและขาดความน่าเชื่อถือ เนื่องจากข้อมูลที่ถูกนำเข้าใน Data Lake จะเป็นข้อมูลดิบ และอาจถูกนำเข้าอย่างต่อเนื่องบ่อยครั้ง ทำให้การจัดวางข้อมูลต่างๆค่อนข้างจะยุ่งเหยิง และหากไม่มีการจัดระบบที่ดีพอก็จะกระจัดกระจายไปหมด เหมือนการเก็บข้อมูลใน Harddisk แบบไม่มีระบบ นอกจากนี้ข้อมูลดิบบางครั้งยังขาดความน่าเชื่อถือ ดังนั้นการนำข้อมูลมาใช้ได้ต้องทำ Data Preperation และจัดแบ่งเป็นโซนให้ดีพอ ดังที่ได้เคยอธิบายไว้ในหัวข้อ Big Data Architecture #8: การจัดการข้อมูลบน Data Lake

Data Lake ไม่ได้สนับสนุนข้อมูลที่เป็น Transaction เนื่องจาก Data Lake จะเก็บข้อมูลดิบ จึงไม่ได้สนับสนุนข้อมูลที่เป็น Transaction แบบ Data Warehouse แต่จะมองข้อมูลเป็นออปเจ็คหรือไฟล์ที่จะเป็นก้อนหรือไฟล์เดียวกัน เราจะไม่สามารถเพิ่ม ค้นหาหรือลบข้อมูลระหว่างกลางช่วงใดช่วงหนึ่งได้ และไม่สนับสนุนคุณสมบัติ ACID (atomicity, consistency, isolation, durability) เหมือนที่ Data Warehouse สามารถทำได้กับข้อมูลที่เป็น Transaction

การประมวลผลข้อมูลบน Data Lake ทำได้ยาก ระบบประมวลผลข้อมูลบน Data Lake ไม่ได้ใช้เครื่องมือพื้นฐานเช่นภาษา SQL อย่าง Data Warehouse และบางครั้งแม้แต่การจะประมวลข้อมูลง่ายๆอาจต้องเขียนโปรแกรมที่ซับซ้อนอย่าง Apache Spark หรือ Hive นักวิเคราะห์ข้อมูลบน Data Lake อาจต้องเรียนรู้เทคโนโลยีในการประมวลที่หลากหลาย

ซึ่งผมเองก็เคยได้เขียนบทความในตอนที่แล้วว่า การวิเคราะห์ข้อมูลส่วนใหญ่ด้วยภาษา SQL อาจต้องนำข้อมูลจาก Data Lake เข้าสู่ Data WareHouse เพื่อความรวดเร็วในการแสดงข้อมูล โดยใช้สถาปัตยกรรม Data Lake ร่วมกับ Data Warehouse

รูปที่ 1 สถาปัตยกรรม Big Data รูปแบบต่างๆ [จาก The Modern Cloud Data Platform, Alice LaPlante]

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

  • จะสนับสนุนการทำ Transaction เหมือนกับ Data Warehouse และมีคุณสมบัติด้าน ACID
  • ข้อมูลจะถูกบังคับให้มี Schema เลยจะทำให้การทำ Governance เป็นไปได้ง่ายขึ้น
  • สามารถเก็บข้อมูลได้หลากหลายประเภท ทั้ง Structure, Semi-structure และ Unstructure
  • สามารถทำ BI จาก Data Lakehouse ได้โดยตรงผ่าน connector อย่าง JDBC/ODBC
  • สนับสนุนเครื่องมือการประมวลผลได้หลากหลายเหมือน Data Lake เช่น SQL หรือ Apache Spark และสามารถที่จะใช้เครื่องมือที่หลากหลายในการที่จะเข้าถึงข้อมูลเช่นการใช้ API หรือภาษาอย่าง Python หรือ R
  • มีมาตรฐานเปิดในการเก็บข้อมูล เช่นอาจเป็น Apache Parquet, ORC
  • จะต้องแยกระหว่าง Storage กับการประมวลผล (Compute) เพื่อให้แต่ละส่วนสามารถ Scale ได้อย่างอิสระ

ทั้งนี้ในปัจจุบันมีบริการบน Public Cloud หลายๆอย่างที่มีคุณสมบัติใกล้เคียงกับ Data Lakehouse เช่น Amazon Athena, SnowFlake หรือ Google BigQuery แต่ก็อาจขาดคุณสมบัติที่สำคัญในบางเรื่องเช่นด้านการบริหารจัดการ Data Governance หรือไม่สามรถเก็บข้อมูลที่เป็น Unstructure ได้ หรืออย่างกรณีของ Google BigQuery ก็มาตรฐานในการเก็บข้อมูลเฉพาะ

ดังนั้นเวลากล่าวถึง Data Lakehouse จึงทำให้หลายคนจันึกถึงเทคโนโลยีตัวหนึ่งคือการใช้ Delta Lake เสริมไปกับ Apache Spark ที่รันอยู่บน Data Lake แบบเดิม โดย Delta Lake จะเพิ่มคุณสมบัติด้าน ACID กับการสนับสนุนการทำ Transaction ต่างๆตามที่ Data LakeHouse ต้องการ โดยจะมีวิธีการใช้ Delta Lake ได้หลายแบบคือ

  • การใช้ Delta Lake ผ่าน local Spark shells
  • การใช้ผ่าน GitHub ทาง https://github.com/delta-io/delta
  • การใช้บริการ Cloud ของ Databricks ที่เป็น Community Edition
รูปที่ 2 สถาปัตยกรรม Data Lakehouse โดยใช้ Delta Lake [จาก Essential PySpark for Scalable Data Analytics queueม S.Nudurupati]

ซึ่งการใช้ Delta Lake เราจะสนใจที่จะใช้กับ Silver Zone ของ Data Lake เพื่อทำให้โซนนั้นทำหน้าที่เป็น Data LakeHouse

รูปที่ 3 การแบ่งโซนของ Data Lakehouse [จาก Data Engineering with Apache Spark, Delta Lake, and Lakehouse, Manoj Kukreja, Danil Zburivsky]

หากท่านใดสนใจที่จะทำ Data LakeHouse ผมแนะนำให้ลองเข้าไปศึกษาเว็บ Databricks เพิ่มเติม

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

IMC Institute

——-

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

Big Data Architecture #9: สถาปัตยกรรม Data Lake + Data Warehouse

ในตอนที่สองซึ่งผมเขียนเรื่องของ สถาปัตยกรรมบน 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 โดยตรงก็ได้ แต่โดยมากจะพบว่ามีความล่าช้ากว่ามากจึงไม่นิยมทำกัน
รูปที่ 1 สถาปัตยกรรม Data Lake + Data Warehouse (cr: Fundamentals Big Data and AI Architecture, Guido Schmutz)

ทั้งนี้การประมวลผลข้อมูลบนสถาปัตยกรรม 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

——-

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

Big Data Architecture #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

source: https://www.dragon1.com/demo/data-lake-template

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

——-

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


Big Data Architecture #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

——————————

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

รวบรวมบทความคอลัมน์ Think Beyond ในหนังสือพิมพ์กรุงเทพธุรกิจ ปี 2563

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

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

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

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

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

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

IMC institute

รวบรวมบทความคอลัมน์ Think Beyond ในหนังสือพิมพ์กรุงเทพธุรกิจ ปี 2564

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

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

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

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

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

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

IMC institute


บทความด้าน Big Data Architecture และแนวโน้ม Big Data 2022

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

ผมได้เคยเขียนบทความ Big Data Architecture มาหลายตอนเพื่อให้ได้อ่านกัน จะได้เข้าใจได้ว่า การออกแบบสถาปัตยกรรม 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 เป็นอย่างไร
  • สถาปัตยกรรม Data Lakeshore ที่กำลังพูดถึงในปัจจุบันว่าจะมาแทนที่ Data Lake คือออะไร
  • ความหมายของ Data Fabric

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

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

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

IMC Institute

Big Data Architecture #6: สถาปัตยกรรม Cloud Data platform สำหรับประมวลผลข้อมูลทั้งแบบ Batch และ Streaming [ปรับปรุง]

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

รูปที่ 1 Big Data Pipeline บน Cloud Platform

และเมื่อพิจารณาถึงการทำสถาปัตยกรรมบน 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

รูปที่ 2 Big data architecture แบบ Data Platform สำหรับข้อมูลแบบ Batch & Streaming บน Azure
รูปที่ 3 Big data architecture แบบ Data Platform สำหรับข้อมูลแบบ Batch & Streaming บน AWS (Icon version ใหม่)
รูปที่ 4 Big data architecture แบบ Data Platform สำหรับข้อมูลแบบ Batch & Streaming บน GCP
รูปที่ 5 Big data architecture แบบ Data Platform สำหรับข้อมูลแบบ Batch & Streaming บน Huawei Cloud
รูปที่ 6 Big data architecture แบบ Data Platform สำหรับข้อมูลแบบ Batch & Streaming บน Alibaba Cloud
รูปที่ 7 Big data architecture แบบ Data Platform สำหรับข้อมูลแบบ Batch & Streaming บน Oracle Cloud

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

IMC Institute

Big Data Architecture #5: สถาปัตยกรรม Data platform สำหรับประมวลผลข้อมูลแบบ Streaming

สถาปัตยกรรม Data platform ที่ผมได้อธิบายในตอนที่ผ่านๆมาออกมาเน้นที่การประมวลผลแบบ Batch แม้ข้อมูลที่นำเข้ามาจะสองประเภทคือทั้งแบบ Batch และ Streaming แต่ข้อมูลทั้งสองประเภทจะถูกนำมาเก็บใน Storage ชุดเดียวกันที่ทำหน้าที่เป็น Data Lake แล้วนำไปประมวลผลและวิเคราะห์ข้อมูลในลักษณะที่เป็นแบบ Batch เท่านั้น

ในกรณีที่เราต้องการจะประมวลผลข้อมูล streaming แบบ real-time หรือ Near real time ได้นั้น รูปแบบสถาปัตยกรรมที่ผ่านมาอาจไม่สามารถตอบโจทย์ได้ ดังนั้นจึงจำเป็นจะต้องออกแบบสถาปัตยกรรมในรูปแบบอื่น ซึ่งโดยทั่วไปจะมีอยู่สองรูปแบบคือ Lambda architecture และ Kappa architecture

  • Lambda architecture จะเป็นสถาปัตยกรรมดังรูปที่ 1 ที่แบ่งออกเป็น 3 Layer คือ Batch layer ที่จะเป็นการประมวลผลข้อมูลแบบ Batch ที่อยู่ใน Data Lake โดยมี Speed layer ที่จะเป็นการประมวลผลข้อมูล Streaming แบบ Realtime และ สุดท้ายจะเอาผลลัพธ์ของการประมวลผลทั้งสองมารวบรวมไว้ที่ Serving layer เพื่อนำมาแสดงผลต่อไป
รูปที่ 1 Lambda architecture จาก https://luminousmen.com/post/modern-big-data-architectures-lambda-kappa/
  • Kappa architecture จะเป็นสถาปัตยกรรมดังรูปที่ 2 ที่มีเพียง 2 Layer Ffpจะมองข้อมูลทุกประเภทเป็นแบบ Streaming แม้แต่ข้อมูลในอดีตที่เป็นแบบ Batch ก็จะถูกป้อนเข้ามาแบบ Streaming แล้วประมวลผลไว้ที่ Speed layer จากนั้นจึงเก็บผลลัพธ์ไว้ที่ Serving layer จุดเด่นของการใช้สถาปัตยกรรมแบบนี้คือเราสามารถเขียนโปรแกรมทั้งหมดได้ใน Speed layer ไม่จำเป็นต้องแยกโปรแกรมออกมาสองชุดแบบสถาปัตยกรรม Lambda
รูปที่ 2 Kappa architecture จาก https://luminousmen.com/post/modern-big-data-architectures-lambda-kappa/

ทั้งนี้เทคโนโลยีที่จะนำมาใช้ในกy[สถาปัตยกรรมทั้งสองแบบนี้ในระบบ On-premise โดยทั่วไปมักจะเป็นเทคโนโลยี Hadoop และ Kafka ดังแสดงในรูปที่ 3

รูปที่ 3 Data Platform สำหรับสถาปัตยกรรมในการประมวลผลข้อมูลแบบ Streaming

โดยเราสามารถที่จะเลือกใช้เทคโนโลยีต่างๆในแต่ละ Layer ได้ดังนี้

  • Batch Layer: ข้อมูล Streaming ที่เข้ามาอาจดึงเข้ามาด้วย KafKa แล้วเก็บไว้ใน Data Lake อย่าง HDFS และประมวลผลด้วย Hive, Spark
  • Speed Layer: ข้อมูล Streaming ที่เข้ามาอาจดึงเข้ามาด้วย KafKa แล้วเก็บไว้ใน Fast Storage อย่าง KafKa storage และประมวลผลแบบ Realtime ด้วย Spark Streaming, KafKa Streaming, KSQL
  • Serving Layer: ผลลัพธ์ของการประมวลในแต่ละ Layer อาจนำมาเก็บใน Data Warehouse ที่อาจเป็น NoSQL หรือ RDBMS อย่าง Cassandra, HBase, Oracle, MySQl

ทั้งนี้ในกรณีของ Lambda architecture ก็จะเน้นใช้เทคโนโลยีทั้งหมดในรูป แต่กรณีของ Kappa architecture จะไม่บล็อกของการประมวลผลแบบ Batch แต่จะป้อนข้อมูลดิบจาก Data Lake ไปประมวลผลผ่าน Fast storage และ Realtime processong/analytics

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

IMC institute