บทความด้าน Big Data Architecture

ผมได้เขียนบทความ 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 ตอนโดยมีหัวข้อต่างๆดังนี้

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

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

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 Platgorm สำหรับผู้ให้บริการ Cloud สามรายหลักคือ Microsoft Azure, Google Cloud Platform และ AWS จะได้ได้ Block diagram ดังรูปที่ 2 – 4

รูปที่ 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

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

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

Big Data Architecture #4: สถาปัตยกรรม Data platform บน Public cloud

การออกแบบสถาปัตยกรรม Big Data บน Public cloud อาจแตกต่างกับการออกแบบบนระบบ On-premise ที่ผมเคยเขียนไว้ในตอนที่ 1 ว่าไม่ควรเน้นที่จะเป็น Data warehouse (อ่านเพิ่มเติมได้จาก Big Data Architecture #1: Big Data Pipeline ทำไมไม่ใช่ Data Warehouse) ทั้งนี้เนื่องจากเทคโนโลยี Data Warehouse ไม่ได้เหมาะสมกับคุณลักษณะของ Big Dataในเรื่องของ 4V ทำให้การเก็บข้อมูลขนาดใหญ่จะมีราคาแพง และจะเน้นได้เฉพาะข้อมูลแบบ Structure หรือ Semi-structure

แต่ในกรณีของผู้ให้บริการ Public cloud จะมีบริการ Data Warehouse ทีสามารถรองรับข้อมูลขนาดใหญ่ได้ในราคาที่ถูกกว่า ทำให้ในบางกรณีเราสามารถที่จะออกแบบสถาปัตยกรรม Big Data โดยใช้ Data Warehouse as a Service อย่าง Google BigQuery หรือ Azure Synapse ได้ ดังตัวอย่างในรูปที่ 1

รูปที่ 1 Big data architecture แบบ Data Warehouse only บนระบบ Microsoft Azure

กรณีนี้เราจะเห็นการใช้บริการบน Public Cloud สองอย่างหลักๆคือ

  1. Fully managed ETL service อย่าง Azure Data Factory หรือ Google Cloud DataFusion ที่จะทำหน้าที่ดึงข้อมูลจากแหล่งต่างๆเข่น RDBMS อย่าง MySQL ซึ่งอาจจะอยู่บนระบบ On-Premise หรือ Public Cloud แล้วทำการแปลงข้อมูลให้อยู่ใน Format ที่ต้องการก่อนโหลดเข้า Data Warehouse
  2. Fully managed data warehouse service อย่าง Azure Synapse หรือ Google BigQuery ซึ่งเป็นบริการแบบ PaaS ที่สามารถรองรับการเก็บข้อมูลขนาดใหญ่ โดยผู้ใช้บริการไม่ต้องไปกังวลเรื่องการดูแลระบบ

การใช้สถาปัตยกรรม Big Data ที่เน้นเฉพาะ Data Warehouse จะเหมาะกับกรณีของ Big data ที่มีเฉพาะที่มาจากแหล่งข้อมูลแบบ Relational มีรูปแบบข้อมูล (Schema) ที่แน่นอน ไม่ได้มาจากหลายแหล่งข้อมูลนัก และเน้นเฉพาะการทำ Business Intelligence (BI) หรือต้องการสืบค้นข้อมูลในรูปแบบของ SQL แต่หากมีแหล่งข้อมูลจำนวนมากและมีหลากหลายชนิด รวมถึงต้องการทำการวิเคราะห์เชิง Predictive โดยใช้ Machine Learning เราควรที่จะเน้นสถาปัตยกรรมแบบ Data Platform ที่ใช้ทั้ง Data Lake และ Data Warehouse เหมือนกรณีที่ผมเขียนอธิบายไว้ในตอนที่ 2 (อ่านเพิ่มเติมได้จาก Big Data Architecture #2: สถาปัตยกรรมบน Data Lake) ที่มี Block diagram ดังแสดงในรูปที่ 2

รูปที่ 2 Big data architecture ที่ใช้ทั้ง Data Lake และ Data Warehouse

ในกรณีการออกแบบสถาปัตยกรรมแบบ Data Platform เราจะเห็นการใช้บริการต่างๆบน Public cloud ดังนี้

  1. Fully managed ETL service อย่าง Azure Data Factory, Google Cloud Data Fusion หรือ AWS Glue
  2. Cloud storage อย่าง Azure Data Lake Storage, Google Cloud Storage หรือ AWS S3 เพื่อทำหน้าที่เป็น Storage หลักในการเก็บ Big data
  3. Fully managed data warehouse service อย่าง Azure Synapse, Google BigQuery หรือ AWS Redshift
  4. Fully managed Hadoop/Spark service อย่าง Azure HDInsight, Google DataProc หรือ AWS EMR เพื่อที่จะทำหน้าที่ในการทำ Data preparation หรือการทำ Data Analytics อย่าง Machine Learning โดยใช้เทคโนโลยี Hive หรือ Spark
  5. Ingestion service อย่าง Azure Event Hub, Google Cloud Pub/Sub หรือ AWS Kinesis ที่ทำหน้าที่ในการนำข้อมูลแบบ Streaming เข้าสู่ Cloud Storage

เพื่อให้เห็นสถาปัตยกรรม Big data แบบ Data Platform บน Public cloud services สามรายหลักคือ Microsoft Azure, Google Cloud Platform และ AWS ผมได้วาด Block diagram มาแสดงเปรียบเทียบกับระบบ On-premise ดังรูปที่ 3 – 6

รูปที่ 3 Big data architecture โดยใช้ Hadoop on-premise
รูปที่ 4 Big data architecture แบบ Data Platform บน Azure
รูปที่ 5 Big data architecture แบบ Data Platform บน AWS
รูปที่ 6 Big data architecture แบบ Data Platform บน Google Cloud Platform

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

IMC Institute

Big Data Architecture #3: จาก Hadoop แบบ On-Premise สู่การใช้บริการบน Public cloud

ในตอนที่แล้วผมได้ระบุว่าการทำ Big Data ควรที่จะต้องออกแบบสถาปัตยกรรมโดยใช้ Data Lake เป็น Storage หลัก และเทคโนโลยีที่เหมาะกับการทำ Data Lake มากที่สุดก็คือ Hadoop แต่อย่างไรการจะติดตั้งระบบ Hadoop แบบ On-premise ยังมีข้อที่ควรจะพิจารณาอีกในหลายด้านดังนี้

  • ระบบมีค่าใช้จ่ายด้าน Hadware และ Software เริ่มต้นที่ค่อนข้างสูง ซึ่งหากต้องการเก็บข้อมูลเป็นหลักสิบ Terabyte ค่าใช้จ่ายก็อาจเริ่มจากเป็นหลักสิบล้านบาท
  • ระบบ Hadoop มีความซับซ้อนในการติดตั้ง และบำรุงรักษา
  • ระบบ Hadoop จะไม่ได้แยกส่วนที่เป็น Storage และ Processing ออกจากกัน กล่าวคือระบบ Hardware เดียวกันจะถูกนำมาใช้งานในทั้งสองด้าน ทำให้ขาดความยืดหยุ่นและการลงทุนอาจไม่ได้ประสิทธิภาพนัก
  • การจะขยายระบบ Hadoop จะไม่สามารถทำได้ทันทีทันใดเพราะจะมีขั้นตอนในการจัดหา Hardware เพิ่มเติม
  • ระบบ Hadoop มีเทคโนโลยีในการประมวลผลที่ซับซ้อน และมีความหลากหลายทำให้นักพัฒนาต้องเรียนรู้หลากหลายระบบ และแม้แต่เพียงแค่การจะเข้าดูข้อมูลที่เก็บไว้ในระบบก็ไม่ง่ายนัก

จากข้อจำกัดข้างต้นทำให้หลายๆองค์กรหันมาสนใจสถาปัตยกรรม Big data แบบที่ใช้บริการต่างๆของ Public cloud ค่ายดังๆอาทิเช่น Amazon Web Services (AWS), Microsoft Azure หรือ Google Cloud Platform (GCP) เป็นต้น เนื่องจาก Public cloud เหล่านี้มีบริการที่เกี่ยวข้องกับ Big Data มากมาย อาทิเช่น

  • Cloud storage service อย่าง AWS S3, Azure data lake Storage หรือ Google cloud storage
  • Database service อย่าง RDS ของ AWS, Azure SQL หรือ Cloud SQL ของ GCP
  • Data warehouse service อย่าง Redshift ของ AWS, Azure Synapse หรือ Google BigQuery
  • Hadoop/Spark service อย่าง EMR ของ AWS, HDInsight หรือ Databrick ของ Azure, DataProc ของ GCP

ผมได้เขียนสรุปตัวอย่างบริการต่างๆที่ Public cloud ทั้งสามรายนี้มีเมื่อเทียบกับระบบ Big data แบบ On-premise ดังตารางข้างล่างนี้

รูปที่ 1 ตารางเปรียบเทียบบริการบน Public cloud ต่างๆ

จุดเด่นของการออกแบบสถาปัตยกรรม Big Data บน Public cloud เมื่อเทียบกับระบบ On-premise มีดังนี้

  • มีทรัพยากรที่ยืดหยุ่นกว่า (Elastic resources) กล่าวคือบริการต่างๆบน Cloud สามารถจะลดหรือขยายได้อย่างรวดเร็ว เช่นการเพิ่มขนาดการเก็บข้อมูล หรือเพิ่มจำนวน Server
  • Modularity กล่าวคือบริการแต่ละตัวเป็นอิสระต่อกัน ดังนั้นจึงมีการแยกระบบ Storage และ Processing โดยไม่ได้ผูกไว้กับระบบ Hardware ชุดเดียวกันเหมือน Hadoop แบบ On-premise
  • ค่าใช้จ่ายขึ้นอยู่กับการใช้งาน และไม่ต้องเสียค่าลงทุนเริ่มต้นสูงนัก
  • สามารถเริ่มทำโครงการได้อย่างรวดเร็ว เพราะบริการต่างๆบน Public cloud มีอยู่แล้ว สามารถเริ่มต้นโครงการได้ทันที
  • การใช้บริการ Cloud เริ่มเป็น New normal สำหรับการทำระบบไอที และมีบริการใหม่ๆทางด้าน Big data และ AI ที่สามารถทำให้เราสร้างนวัตกรรมในเรื่องต่างๆได้ง่ายขึ้น

แต่การจะใช้บริการบน Public cloud จำเป็นจะต้องออกแบบสถาปัตยกรรมให้ถูกต้องและเลือกบริการให้เหมาะสม ซึ่งผมจะเขียนอธิบายในตอนต่อไป

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

IMC Institute

Big Data Architecture #2: สถาปัตยกรรมบน Data Lake

ในตอนที่แล้ว ผมได้ระบุให้เห็นว่าการออกแบบสถาปัตยกรรม Big Data โดยใช้ Data Warehouse เพียงอย่างเดียวมีความไม่เหมาะสมอย่างไร เลยทำให้ในช่วงปี 2006 ได้มีการนำเทคโนโลยี Apache Hadoop มาใช้ในการทำหน้าเก็บและประมวลผลข้อมูลขนาดใหญ่ ที่เป็นหลักการของ Data Lake แทนที่ระบบของ Data Warehouse โดยมีสถาปัตยกรรมของระบบดังแสดงในรูปที่ 1

รูปที่ 1 Big data architecture โดยใช้ Data Lake

ทั้งนี้ Hadoop ที่เป็น Data Lake จะสามารถตอบโจทย์เรื่อง Big Data ตามคุณสมบัติต่างๆได้ดังนี้

  • Volume เทคโนโลยี Hadoop มีสถาปัตยกรรมแบบกระจายที่ใช้ Commodity Hardware ซึ่งอาจจะเริ่มจากจำนวนเครื่องไม่มากนักและขยายไปเรื่อยๆได้ ทำให้สามารถเก็บข้อมูลได้เป็น Petabyte ในราคาที่ถูกกว่าเทคโนโลยี Data Warehouse มาก
  • Variety เทคโนโลยี Hadoop สามารถเก็บข้อมูลได้หลากหลายชนิดทั้งที่เป็น structured data, semi-structured data และ unstructured data
  • Velocity เทคโนโลยี Hadoop มีการประมวลผลได้หลายภาษา และสามารถที่จะใช้ประมวลผลข้อมูล streaming แบบ real-time หรือ Near real time ได้

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

  • Data Ingestion: Sqoop, KafKa, NiFi, Flume, etc.
  • Data Storage: Hadoop Distributed File System (HDFS)
  • Data Processing / Data Analytic: Hive, Spark, Impala, Spark MLlib, etc.
  • Data Visualisation: Tableau, Power BI, Qlik, etc.
รูปที่ 2 Big data architecture ที่ใช้ทั้ง Data Lake และ Data Warehouse

เทคโนโลยีการประมวลผลของ Hadoop อย่าง Hive หรือ Spark หากจะนำไปแสดงผลโดยตรงยัง Data visualisation tool (ดังแสดงในรูปที่ 1) บางครั้งจะพบว่ามีความเร็วไม่พอ ดังนั้นเราจึงมักเห็นสถาปัตยกรรม Big data ที่นำเอา Data Warehouse (หรืออาจเป็น Database) มาเก็บข้อมูลไว้ก่อน (ดังแสดงในรูปที่ 2) เพื่อจะทำให้การทำ Query จาก Data visualisation tool มีความรวดเร็วขึ้น และจะแบ่งวิธีการวิเคราะห์ข้อมูล โดยการทำ BI จะใช้ข้อมูลที่อยู่ใน Data Warehouse ผ่านภาษา SQL ส่วนการทำ Data science ก็จะใช้ข้อมูลใน Data Lake ผ่านเครื่องมือต่างๆเช่น Spark MLlib เป็นต้น

แต่อย่างไรก็ตามการติดตั้ง Hadoop บนระบบ On-premise ก็ยังเป็นการลงทุนที่ค่อนข้างสูง จึงทำให้หลายๆโครงการในปัจจุบันเริ่มพิจารณาสถาปัตยกรรม Big data บนระบบ Cloud ซึ่งผมจะเขียนอธิบายในตอนต่อไป

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

IMC Institute

Big Data Architecture #1: Big Data Pipeline ทำไมไม่ใช่ Data Warehouse

ขั้นตอนการประมวลผลข้อมูลขนาดใหญ่ (Big data pipeline) จะประกอบด้วยขั้นตอนหลักและต้องใช้เทคโนโลยีต่างๆอยู่ 5 ด้านคือ

  1. Data Ingestion คือขั้นตอนการนำข้อมูลดิบ (Raw data) จากแหล่งต่างๆเข้ามา ซึ่งอาจต้องใช้เทคโนโลยีที่แตกต่างกันสำหรับแหล่งข้อมูลหลากหลายชนิด
  2. Data Storage คือขั้นตอนการเก็บข้อมูลมาไว้ที่เดียวกัน ซึ่งเทคโนโลยีในการเก็บข้อมูลจากหลายแหล่งอาจเป็น Data Warehouse หรือ Data Lake
  3. Data Processing คือขั้นตอนในการประมวลผลข้อมูลที่เป็นการแปลงข้อมูลดิบมาอยู่ในรูปแบบของข้อมูลที่นำไปวิเคราะห์ต่อได้ โดยขั้นตอนนี้อาจทำก่อนจะนำเข้า Data storage (เป็นการทำตามหลักการของ ETL) หรืออาจทำหลังจากที่มีข้อมูลอยู่ใน Data Storage แล้วก็ได้ (ทำตามหลักการ ELT) ซึ่งก็จะมีเทคโนโลยีที่หลากหลายในการประมวลผลข้อมูล ขึ้นอยู่กับประเภทของข้อมูลและเทคโนโลยีของ Data storage
  4. Data Analytics คือขั้นตอนการวิเคราะห์ข้อมูล ซึ่งอาจแบ่งได้เป็นการทำ Business Intelligence เพื่อค้นหาตำตอบต่างๆจากข้อมูลทีมีอยู่ หรือการทำ Data science ที่จะนำข้อมูลมาพัฒนาโมเดลในการพยากรณ์ต่างๆ ซึ่งการวิเคราะห์ทั้งสองแบบนี้อาจใช้เทคโนโลยีที่แตกต่างกัน
  5. Data Visualisation คือขั้นตอนในการแสดงผลข้อมูล ซึ่งอาจเป็นการนำข้อมูลที่ได้จากการวิเคราะห์มาแสดงผลให้ผู้ใช้เข้าใจได้ง่ายขึ้นผ่านรายงานหรือรูปกราฟฟิกต่างๆ
รูปที่ 1 Big data pipeline

เมื่อพูดถึงสถาบัตยกรรมทางด้าน Big data หลายคนก็จะมีคำถามในเรื่องของ Data storage ว่าควรจะเป็น Data warehouse หรือ Data Lake ดี เพื่อให้เห็นภาพเปรียบเเทียบระหว่างเทคโนโลยีทั้งสองแบบ ผมของเริ่มจากสถาปัตยกรรมของ Data Warehouse ในรูปที่ 2 ซึ่งเทคโนโลยี Data Warehouse ที่ส่วนใหญ่จะมีพื้นฐานมาจากระบบสถาปัตยกรรมฐานข้อมูลแบบ RDBMS ซึ่งจะทำหน้าที่สองอย่างคืดทั้งในการเป็น Storage และ Analytics โดยใช้ภาษาอย่าง SQL

รูปที่ 2 Data architecture ที่ใช้ Data Warehouse

ซึ่งถ้าเรายกตัวอย่างเทคโนโลยีต่างๆสำหรับการทำ Data Warehouse อาจเห็นดังนี้

  • Data Ingestion: Informatica, Talend, Oracle Data Integration Suite, Pentaho Data integration, Apache NiFi, etc.
  • Data Warehouse (Data storage & Data analytic): HP Vertica, Oracle Exadata, Teradata, etc.
  • Data Analytic (Data science): RapidMiner, Alteryx, Dataiku, etc.
  • Data Visualisation: Tableau, Power BI, Qlik, etc.

แต่เมื่อพิจารณาจากหลักการของ Big data จะพบว่า Data Warehouse มีข้อจำกัดหลายอย่างที่ไม่สามารถตอบโจทย์ได้ดังนี้

  • Volume เทคโนโลยี Data Warehouse จะเก็บข้อมูลปริมาณเพียงเป็นหลัก GB จนถึงเพียงหลายสิบ TB แต่เมื่อพูดถึง Big Data ปริมาณข้อมูลจะมีเป็น TB จนถึง PB ซึ่งถ้าต้องการ Data Warehouse ที่สามารถเก็บข้อมูลขนาดนี้ได้ ราคาจะแพงมากและอาจไม่สามารถรองรับได้
  • Variety เทคโนโลยี Data Warehouse จะออกแบบมาเพื่อรองรับข้อมูลที่มีโครงสร้าง (Structure data) ไม่ได้เน้นข้อมูลหลากหลายชนิด
  • Velocity ข้อมูลขนาดใหญ่บางครั้งจะมีข้อมูลที่เข้ามาต่อเนื่องและอาจต้องการวิเคราะห์ข้อมูลที่เพิ่งถูกนำเข้ามา (Streaming data) แบบทันทีทันใดในลักษณะ Near real time ซึ่งเทคโนโลยี Data warehouse ส่วนใหญ่ไม่ได้ออกแบบมาในลักษณะเพื่องานแบบนี้ และเครื่องมือในการวิเคราะห์ส่วนใหญ่ก็จะเป็นภาษา SQL

นอกจากนี้เราก็อาจจะพบว่า เทคโนโลยี Data Warehouse อาจมีจุดอ่อนอีกบางประการถ้าจะนำมาใช้งานกับ Big Data อาทิเช่น

  • มีราคาค่อนข้างสูง ถ้าต้องการเก็บข้อมูลจำนวนมาก
  • เทคโนโลยีที่ใช้ประมวลผลไม่มีความหลากหลายโดยมากจะใช้ภาษา SQL และหากมาทำงานด้าน Data Science จะค่อยข้างยากสำหรับข้อมูลขนาดใหญ่
  • Data Warehouseจะมีทั้ง Storage และ Analytics/Processing อยู่ในระบบเดียวกัน ทำให้การขยายตัวด้านใดด้านหนึ่งลำบาก เพราะต้องทำควบคู่กันไป

ด้วยเหตุผลเหล่านี้ การทำ Big data จึงจำเป็นต้องใช้ Data Lake เข้ามาทำหน้าที่ Data Storage ซึ่งผมจะอธิบายให้เข้าใจในตอนต่อไป

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

IMC Institute

Data Digital Transformation #13: ระดับการวัดความสามารถในการนำ Big Data ไปใช้ในองค์กร (BDBMMI)

เมื่อวันก่อนผมได้อ่านหนังสือเล่มหนึ่งชื่อ The Economics of Data, Analytics, and Digital Transformation ที่เขียนโดย Kirk Borne และ Bill Schmarzo ซึ่งเพิ่งตีพิมพ์เมื่อปลายปีที่แล้ว ผมว่าเป็นหนังสือที่อธิบายเรื่องเกี่ยวกับการวิเคราะห์คุณค่าของข้อมูลและการทำ Data analytics ในมุมมองทางเศรษฐศาสตร์ได้ดีมาก แต่สิ่งที่ผมอย่างกล่าวถึงในที่นี้คือเรื่องของระดับการวัดความสามารถในการนำ Big Data ไปใช้ในองค์กรหรือ Big Data Business Model Maturity Index (BDBMMI) ที่เขียนไว้ในบทแรกของหนังสือเล่มนี้

BDBMMI ที่กล่าวมานี้อาจไม่ใช่เรื่องใหม่ ผมเองก็เคยนำเรื่องนี้มาเขียนในบทความเรื่อง ระดับการวัดความสามารถในการนำ Big Data ไปใช้ในองค์กร ซึ่งระดับความสามารถของการนำ Big Data ไปใช้ในองค์กร (Big Data Matuarity Model) มีอยู่ 5 ระดับ คือ 1) Business Monitoring 2) Business Insights 3) Business Optimization 4) Data Monetization และ 5) Business Metamorphosis แต่หนังสือเล่มนี้อาจเปลี่ยนชื่อระดับที่ 4 และ 5 เป็น Insights Monetization และ Digital Transformation ตามระดับ โดยได้ให้คำอธิบายแต่ละขั้นตอนที่ชัดเจนขึ้นดังนี้

  1. Business Monitoring ในระดับนี้องค์กรได้ทำ Business Intelligence และ Data Warehouse ซึ่งเป็นขั้นตอนที่เราจะแสดงข้อมูลหรือทำรายงานต่างๆขององค์กรในลักษณะของ Descriptive Analytic ที่เราจะดูข้อมูลในอดีตเพื่อให้ทราบว่า What’s happened? แต่การทำขั้นทำขั้นตอนยังเป็นเพียงการนำข้อมูลมาวัดความสำเร็จที่ผ่านมา และยังขาดการวิเคราะห์สิ่งที่จะเกิดขึ้นหรือการทำ predictive analytics และ prescriptive analytics ที่องค์กรควรจะก้าวไปถึงระดับนี้ให้ได้ เพื่อจะทำให้กลายเป็นองค์กรที่ขับเคลื่อนด้วยข้อมูล ซึ่งจะต้องคิดในการนำข้อมูลมาวิเคราะห์ในเชิงธุรกิจมากขึ้น มีการทำด้าน Data science มากขึ้น และมีการสร้างวัฒนธรรมในการใช้ข้อมูลมากขึ้น
  2. Business Insights ในระดับนี้องค์กรมีการเริ่มต้นตั้งคำถามเพื่อให้ทราบว่า What is likely to happen next? กล่าวคือคาดการณ์ว่าน่าจะเกิดอะไรขึ้นกับ ตลาด กลุ่มลูกค้า สินค้า และบริการต่างๆ เป็นค้นหาข้อมูลเชิงลึก (Insights) ของลูกค้า สินค้า และบริการต่างๆ ขั้นตอนนี้องค์กรจะมีการรวบรวมข้อมูลจากหลายๆแหล่งทั้งภายนอกและภายในองค์กร มีการทำ Data Lake และเห็นการทำงานร่วมกันระหว่างฝั่งธุรกิจแผนกต่างๆ กับทีมงานนักวิทยาศาสตร์ข้อมูลมากขึ้น
  3. Business Optimizationในระดับนี้องค์กรจะมีการทำ predictive analytics และ prescriptive analytics โดยใช้ Machine Learning มากขึ้น จะมีข้อแนะนำในขั้นสิ่งต่างๆทีทำในขั้นตอนปฎิบัติงาน กล่าวคืออาจมี Recommendation system สำหรับลูกค้าแต่ละคน หรือสินค้าในแต่ละอย่าง ซึ่งเป็นผลลัพธ์ที่ได้มาจากการทำ Data science เพื่อคาดการณ์สิ่งที่ดีที่สุดสำหรับองค์กร
  4. Insights Monetization ในระดับนี้ไม่ได้หมายความว่าองค์กรจะนำข้อมูลที่มีอยู่ไปขายเพื่อหารายได้ แต่เป็นการนำข้อมูลไปสร้างคุณค่าเพิ่ม ที่อาจทำให้ได้ช่องทางการตลาดใหม่ๆ กลุ่มลูกค้าใหม่ๆ สินค้าและบริการใหม่ๆ ตลอดจนการหาพันธมิตรทางธุรกิจใหม่ๆ
  5. Digital Transformation ในระดับนี้องค์กรจะมีวัฒนธรรม (Culture) ในการใช้ข้อมูล การวืเคราะห์ข้อมูล เพื่อจะนำมาใช้ให้เกิดประโยชน์ทางธุรกิจอยู่ตลอดเวลา

ในครั้งหน้าผมจะลองมาสรุปให้เห็นว่าการที่จะทำให้องค์กรสามารถเข้าไปสู่ในแต่ละขั้นตอนของ

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

IMC Institute

เราจะทราบได้อย่างไรว่า ข้อมูลของเราเป็น Fake data

เมื่อวันก่อนตอนผมบรรยายในงาน Webinar ครั้งที่ 45 ของสถาบันไอเอ็มซี ในหัวข้อ Data Engineering Technologies & Trends 2021 มีผู้ฟังท่านหนึ่งถามมาว่า “เราจะทราบได้อย่างไรว่า ข้อมูลของเราเป็น Fake data”

หลายคนอาจคิดว่าคำตอบนี้ส่วนหนึ่งเป็นเรื่องของทักษะด้านข้อมูล (Data literacy) ที่เราจะต้องใช้ตรรกะและองค์ความรู้แยกให้ได้ว่าข้อมูลใดเป็นข้อมูลจริงหรือเท็จ ข้อมูลมาจากแหล่งที่น่าเชื่อถือหรือไม่ แต่บังเอิญคำถามนี้กลายเป็นว่า ข้อมูลดังกส่าวมาจากแหล่งต้นทางที่เราคิดว่าน่าจะถูกต้อง มีความน่าเชื่อถือ แต่กลับเป็นว่ามีข้อมูลดิบบางส่วนที่ผิด แล้วเราจะทราบได้อย่างไร

ผมเองทำงานกับข้อมูลดิบมาเยอะ และบ่อยครั้งก็จะพบว่าข้อมูลจากแหล่งต้นทางผิดจริง แต่ก็ใช่ว่าจะผิดมากมาย ส่วนใหญ่อาจผิดพลาดเพราะการใส่ตัวเลขผิดพลาด หรือมีการเก็บข้อมูลคาดเคลื่อน เรื่องพวกนี้เป็นเรื่องปกติมากของการทำ Data analytics ยิ่งข้อมูลมีขนาดใหญ่ (Big data) ก็อาจทำให้มีโอกาสผิดได้มากขึ้นและจำนวนข้อมูลอาจผิดพลาดมากขึ้น ความผิดพลาดบางครั้งอาจไม่มีนัยสำคัญอะไรเลย แต่บางครั้งข้อมูลที่ผิดพลาดเพียง record เดียวก็อาจทำให้เกิดการวิเคราะห์ผิดพลาดได้ ถ้าความผิดพลาดในข้อมูลนั้นมหาศาล

กระบวนการที่จะช่วยทำให้ลดความผิดพลาดของข้อมูลส่วนหนึ่งคือ การทำ Data preperation ซึ่งเป็นหน้าที่ของ Data engineerในการจะต้องนำข้อมูลดิบ (Raw data) มาแปลง มาตรวจสอบความถูกต้องเสียก่อน เช่นหา Missing data หรือ Outlier กล่าวคือหาข้อมูลที่ดูแล้วผิดปกติแล้วทำการแก้ไข เช่นบางครั้งข้อมูลลบการเงินของบริษัทอาจมีจำนวนสูงผิดปกติ จำนวนพน้กงานมากผิดปกติ ข้อมูลส่วนตัว อายุ น้ำหนัก ดูสูงผิดปกติ หรือข้อมูนำเข้าส่งออกอาจใช้สกุลเงินต่างกัน ข้อมูลเหล่านี้ Data engineer จะช่วยทำการ Data Cleansing ให้ได้ เช่นอาจปรับหาค่าที่เหมาะสมมาใส่ หรือตัดออก และแปลงข้อมูลดิบให้กลายเป็นข้อมูลที่น่าเชื่อถือ (Trusted data) เพื่อให้ Data analyst หรือ Data scientist นำไปทำการวิเคราะห์ข้อมูลและแสดงผลต่อไป

แต่อย่างไรก็ตามแม้ Data engineer จะสร้าง Trusted data ให้แล้ว ก็ใช่ว่าข้อมูลนั้นจะถูกต้อง 100% แหล่งข้อมูลที่เข้ามาก็อาจจะเกิดการผิดพลาดแต่วิธีการด้าน Data engineering ก็ยังไม่สามารถแก้ไขได้ จากสารพัดสาเหตุ อาทิเช่น นำข้อมูลเข้ามาไม่ครบ ได้ข้อมูลผิดๆแต่ต้น หรือแม้แต่ข้อมูลถูกต้องแล้ว แต่ Data analyst ไม่เข้าใจข้อมูลดีพอ เลยทำการวิเคราะห์ที่ผิดแล้วแสดงผลผิดพลาดก็เป็นไปได้

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

ดังนั้นการที่จะทราบได้อย่างไรว่า ข้อมูลของเราเป็น Fake data คำตอบผมคือ กระบวนงานของ Data engineering และประสบการณ์ของ Domain expert เป็นเรื่องสำคัญสุด

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

IMC Institute

งาน Data Engineer มีความสำคัญมากพอๆกับงานของ Data Scientist (ตอนที่ 2)

เมื่อตอนที่แล้วผมเขียนถึงประเภทงานด้านต่างๆที่เกี่ยวข้องกับการวิเคราะห์และบริหารจัดการข้อมูล (งาน Data Engineer มีความสำคัญมากพอๆกับงานของ Data Scientist (ตอนที่ 1)) และชี้ให้เห็นว่างานของวิศวกรข้อมูล (Data emgineer) มีความสำคัญพอๆกับงานของนักวิทยาศาสตร์ข้อมูล (Data Scientist) และบางครั้งอาจมีความสำคัญมากกว่าเสียด้วยซ้ำไป

สำหรับเหตุผลต่างๆขออธิบายดังนี้

  1. การทำงานด้านข้อมูลจะเริ่มต้นจากกระบวนการทางวิศวกรรมข้อมูล ซึ่งเป็นหน้าที่ของ Data engineer ที่จะต้องนำเข้าข้อมูล จัดการแปลงข้อมูล ปรับข้อมูลให้มีความถูกต้อง รวมถึงการตัดข้อมูลที่ผิดพลาดออก ก่อนที่จะส่งงานนี้ไปให้ Data Scientist หรือ Data analyst ไปทำการพยากรณ์หรือวิเคราะห์ข้อมูลต่อ ดังนั้นถ้าวิศวกรข้อมูลส่งข้อมูลมาผิดพลาด ไม่สมบูรณ์ ก็จะมีผลทำให้การวิเคราะห์หรือการพยากรณ์ข้อมูลต่างๆผิดพลาดไปด้วย ดังที่กล่าวว่า garbage in garbage out
  2. เมื่อวิเคราะห์ถึง Data analytic life cycle ตามมาตรฐานของ CRISP-DM(Cross-industry standard process for data mining) จะเห็นได้ว่ามีอยู่ 6 ขั้นตอน เริ่มจาก การทำความเข้าใจธุรกิจ (Business Understanding) ไปจนถึงการนำไปใช้งาน (deployment) ซึ่งเราจะพบว่างานส่วนใหญ่เกือบ 70-80% จะใช้เวลาไปกับขั้นตอนของ Data preparation กล่าวคือการเตรียมข้อมูลที่เป็นงานของ Data engineer ขณะที่งานของ Data scientist อย่างขั้นตอนการสร้างแบบจำลอง (Modeling) และ การประเมินผล (Evaluation) จะใช้เวลาไม่นานนัก
  1. งานการวิเคราะห์ข้อมูลขนาดใหญ่ (Big data)ที่พบในทางปฎิบัติจริงโดยมากจะเป็นงานการวิเคราะห์ข้อมูลทั่วไปที่ใช้หลักการของ Business Intelligence (BI) โดยเป็นหน้าที่ของนักวิเคราะห์ด้านข้อมูล (Data analyst) แล้วอาจนำผลไปทำ Dashboard โดยใช้เครื่องมือด้าน Visualization ซึ่งงานเหล่านั้นพบมากกว่างานด้านการพยากรณ์ข้อมูล (Predictive analytic) ที่ต้องทำโดย Data scientist ด้วยซ้ำไป เพราะหน่วยงานต่างๆจะเริ่มต้นจากการทำ BI ก่อน
  2. งานด้านการพยากรณ์ข้อมูล (Predictive analytic) ที่ทำโดยมากมักจะเป็นงานในการพัฒนาโมเดลพื้นฐานที่มีอยู่ทั่วไป และอาจต้องการนักวิทยาศาสตร์ข้อมูลที่เน้นการพัฒนาโปรแกรม หรือ Citizen Data Scientist ในการทำมากกว่าต้องการ นักวิทยาศาสตร์ข้อมูลขั้นสูง ซึ่งเราจะพบว่าสามารถนำงานเหล่านั้นให้ Data engineer มาศึกษาการเขียนโปรแกรมการพยากรณ์ข้อมูลได้ และบางครั้งอาจจะง่ายกว่าการที่จะเอานักวิทยาศาสตร์ข้อมูลขั้นสูงมาฝึกเป็น Data engineer เสียด้วยซ้ำไป กล่าวคือเราอาจให้ Data engineer มาทำหน้าที่ Data scientist ได้ในงานที่ไม่ซับซ้อน
  3. ข้อมูลจาก The 2021 Data Science Interview Report ระบุว่าตำแหน่งงานทางด้าน Data scientist เริ่มมีการเติบโตน้อยลงจากที่เคยเพิ่มปีละ 80% เหลือเพียงโตขึ้น 10% จากปี 2020 เมื่อเทียบกับปี 2019 ขณะที่งานด้าน Data engineer กลับโตขึ้นถึง 40% นอกจากนี้ยังมีการศึกษาโดย Mihail Eric ที่ลงบทความใน https://www.kdnuggets.com/ พบว่างานทางด้าน Data engineer มีความต้องการสูงกว่างานด้าน Data science ถึง 70%
  1. สุดท้ายมีบทความเรื่อง Data Engineer VS Data Scientist ที่รายงานการสำรวจเงินเดือนเฉลี่ยระหว่าง Data engineer กับ Data Scientist ในปี 2018 พบว่าเงินเดือนของ Data engineer เฉลี่ยอยู่ที่  $151K ต่อปี ส่วน Data Scientist $139K ต่อปี
ที่มา https://towardsdatascience.com/data-engineer-vs-data-scientist-bc8dab5ac124
ที่มา ที่มา https://towardsdatascience.com/data-engineer-vs-data-scientist-bc8dab5ac124

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

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

IMC Institute