thanachart Articles

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

thanachart Articles

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), Oracle cloud, Huawei Cloud และ Alibaba Cloud เป็นต้น เนื่องจาก Public cloud เหล่านี้มีบริการที่เกี่ยวข้องกับ Big Data มากมาย อาทิเช่น

  • Cloud storage service อย่าง AWS S3, Azure data lake Storage, Google cloud storage หรือ Object storage service ของ Huawei Cloud
  • Database service อย่าง RDS ของ AWS, Azure SQL, Cloud SQL ของ GCP, ApsaraDB RDS ของ Alibaba Cloud หรือ Autonomous database ของ Oracle cloud
  • Data warehouse service อย่าง Redshift ของ AWS, Azure Synapse, Google BigQuery, Huawei DWS, Alibaba AnalyticDB หรือ Autonomous data warehouse ของ Oracle cloud
  • Hadoop/Spark service อย่าง EMR ของ AWS, HDInsight หรือ Databrick ของ Azure, DataProc ของ GCP, MapReduce service หรือ Data Lake Service ของ Huawei Cloud

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

จุดเด่นของการออกแบบสถาปัตยกรรม 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

thanachart Articles

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

thanachart Articles

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