thanachart Articles

Data Lake / Data Warehouse / Data Lakehouse เอ้าท์แล้วจริงหรือ !? อะไรคือแนวทางถัดไป ?

วันก่อน ผมร่วมบรรยายงาน Webinar ของสถาบันไอเอ็มซีในหัวข้อเรื่อง “Data Lake / Data Warehouse / Data Lakehouse เอ้าท์แล้วจริงหรือ !? อะไรคือแนวทางถัดไป ?”  ร่วมกับคุณฐิติธร เสมาเงิน ตำแหน่ง Solution Engineering Director ของบริษัท Oracle Corporation (Thailand) โดยมีอาจารย์พันธุ์ทิตต์ สิรภพธาดา เป็นผู้ดำเนินการ

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

เรามักจะเอาความสามารถของบริษัทเทคโนโลยีขนาดใหญ่อย่าง Google Facebook หรือ Amazon มา แล้วคิดว่าเราจะต้องทำ Big data ให้เป็นแบบเขา ทั้งๆที่บริษัทเหล่านั้นข้อมูลมหาศาล มีงบประมาณมากมาย และมีบุคลากรมากพอที่จะทำข้อมูลให้เห็นเป็นแบบทันทีทันใด สามารถจะทำการวิเคราะห์ข้อมูล และคาดการณ์ต่างๆได้มากมาย ซึ่งคงแตกต่างกับสิ่งที่องค์กรในบ้านเราจะทำได้

และเมื่อพูดถึงเทคโนโลยี ถ้าเรามองย้อนไปเมื่อ10 กว่าปีก่อน เทคโนโลยี storage มีราคาแพง ประสิทธิภาพของฮาร์ดแวร์ก็ไม่ดีเทียบเท่าปัจจุบัน ดังนั้นในตอนนั้น Data Warehouse จึงทำ Big data ไม่ได้ ไม่สามารถเก็บข้อมูลขนาดใหญ่ในราคาถูกได้ ไม่สามารถเก็บข้อมูลที่เป็น unsturucture ได้ และ Data warehouse ส่วนใหญ่ เหมาะกับการทำ SQL ไม่เหมาะกับงาน Data science

ตอนนั้นเทคโนโลยี Big data จึงเป็นเรื่องของ Data Lake ที่จะมาแทนที่ Data Warehouse และก็มีการนำเทคโนโลยี Hadoop เข้ามาใช้ มีการใช้เครื่องมืออย่าง Apache Spark ในการทำ Data preparation หรือ Data Science แต่การลงทุน Data Lake มีค่าใช้จ่ายค่อนข้างสูง และ เมื่อคำนึงถึง ROI (Return of Investment) กว่าจะคุ้มค่าก็ต้องมีข้อมูลหลายสิบเทราไบต์ (Terabyte) ซึ่งทำให้องค์กรส่วนใหญ่พบว่าไม่คุ้มค่ากับการลงทุนในการทำ Data lake

นอกจากนี้การใช้ Data lake ตามลำพังก็ไม่เหมาะกับองค์กรที่ต้องทำ Business Intelligence จึงต้องนำ Data Warehouse มาช่วยในการทำ Dashboard หลังๆ Buzz word ก็เลยกลายเป็น Data Lakehouse โดยการเพิ่มประสิทธิภาพทำให้ Data Lake กลายเป็น Data Warehouse ได้ แต่ก็ทำได้ค่อนข้างยาก

แต่ด้วยความสามารถของเทคโนโลยีในปัจจุบัน Storage มีราคาถูกลง CPU มีความเร็วขึ้น จึงทำให้ Data Warehouse สามารถเก็บข้อมูลขนาดใหญ่หลายสิบเทราไบต์ได้ในราคาถูกลง แถมเก็บ unstructure data ได้ ทำ Data science ได้ แถมสมัยนี้ SQL ยังทำ Data science ได้ การเขียน code จึงง่ายขึ้น ดังนั้นความจำเป็นในการใช้ Hadoop หรือ Spark ก็เริ่มน้อยลง และการลงทุนกับ Data Warehouse ในการทำ Big data อาจจะคุ้มค่ากว่าถ้าข้อมูลไม่ได้ใหญ่มากมายมหาศาล

นอกจากนี้บริการบน Public Cloud หลายอย่าง ก็สามารถนำ Data Warehouse มาทำ Big data ได้ เช่น  Google cloud platform มีบริการอย่าง  BigQuery ที่เป็น Data Warehouse ขนาดใหญ่ ที่เก็บข้อมูลได้ทุกประเภท (Structure, semi-structure และ unstructure) แถมทำ Machine learning โดยใช้ SQL อย่างง่ายๆได้ กล่าวคือ Google Cloud กำลังทำ Data Warehouse  ให้กลายเป็น Data Lakehouse ได้ โดยไม่ต้องใช้  Hadoop หรือ  Spark ที่ต้องทำ Data Lake ให้เป็น  Data Lakehouse ซึ่งทำได้ยากกว่า

เรายังได้คุยกันว่า Buzz word ใหม่ๆอย่าง Data Fabric ที่บอกว่า Data อาจเก็บไว้ที่ไหนก็ได้ และประมวลผลที่ไหนก็ได้ ตามทฤษฎีอาจจะใช่ แต่สุดท้ายในทางปฎิบัติคงจะทำได้ยากเพราะเราต้องคำนึงถึง Data gravity หรือแรงดึงดูดของข้อมูล ถ้าข้อมูลเราอยู่ที่ใด เราควรจะต้องประมวลผลที่นั้นเป็นส่วนใหญ่ เพื่อลดค่าใช้จ่ายในการประมวลผลข้ามแพลตฟอร์ม หรือลดความล่าช้าในการถ่ายโอนข้อมูลข้ามแพลตฟอร์ม

สุดท้ายผมปิดท้ายเล่าให้ฟังว่า สิบกว่าปีก่อนพอ Data lake มาใหม่ๆ ผมก็ใช้เวลาในการเรียน การสอน การทำ Big data บน Hadoop และ Spark  พอ Big data บน Public Cloud มาก็เริ่มมาใช้ Cloud storage เป็น Data Lake แทน Hadoop และใช้ Spark as a Service แต่พอเทคโนโลยีปัจจุบันมีประสิทธิภาพมากยิ่งขึ้น ก็สามารถกลับมาใช้ Data Warehouse ใช้ SQL ทำโครงการ Big data ได้เหมือนสมัยที่ทำข้อมูลบน Database ธรรมดาเมื่อสิยกว่าปีก่อน

ดังนั้นก่อนจะก้าวไปทำเทคโนโลยีตาม  Buzz word เราควรจะเข้าใจวัตถุประสงค์และความต้องการของธุรกิจเราให้ชัดเจนก่อน และก็อาจไม่จำเป็นต้องตามเทคโนโลยีไปตลอด อย่างกรณีนี้สุดท้ายไปๆมาๆก็กลับกลายเป็นว่า Datawarehouse ก็กลายเป็น Data Lakehouse ที่ทำโครงการ Big data ได้อย่างง่าย

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

IMC Institute

(ผู้สนใจสามารถติดตาม Webinar ได้ตาม Link นี้)

thanachart Articles

Big Data Architecture #12: สถาปัตยกรรมแบบ Distributed Data Sources

หลังจากที่เขียนบทความด้าน Big Data Architecture ตอนที่ 11 ในเรื่องของ Data Fabric เมื่อต้นปีนี้ ผมก็ไม่ได้เขียนตอนต่อไปมานานมาก ซึ่งในช่วงปีที่ผ่านมา แนวโน้มของการทำสถาปัตยกรรม Big Data เริ่มเปลี่ยนไปจากที่เคยมีความพยายามในการแก้ปัญหา Data Silo ที่มีข้อมูลอยู่หลากหลายแห่งแลัวพยายามที่จะพัฒนา สถาปัตยกรรมที่รวมข้อมูลไว้ในระบบเดียวกันเพื่อให้ Single source of trust data เพื่อทำให้มี Data Source เพียงระบบเดียวในองค์กร ซึ่งจากรูปข้างล่างแสดงให้เห็นถึงพัฒนาการของสถาปัตยกรรมแบบนี้ที่เป็น Data Warehouse ในช่วงปี 2000 และพัฒนามาสู่ Data Lake ในช่วงปี 2010 ซึ่งก็อาจเป็นระบบ Hadoop HDFS ที่เป็น On-Premise หรือ Cloud Storage บน Public cloud

ที่มา Google Cloud : Big Lake

แต่อย่างไรก็ตาม การทำสถาปัตยกรรมที่ต้องการให้เกิด Data Source เพียงระบบเดียวเดังกล่าวกลับไม่ประสบความสำเร็จอย่างที่ตั้งใจ ซึ่งจากรูปจะเห็นว่าในปัจจุบันสถาปัตยกรรม Big Data กลายเป็นระบบที่มี Data Warehouse และ Data Lake หลายๆระบบ และกลายเป็น Data Silo รูปแบบใหม่ ซึ่งทำให้เกิดผลกระทบที่ตามมาในหลายๆประการอาทิเช่น

  • มีข้อมูลใหม่ๆเพิ่มเข้ามาเรื่อยๆอย่างรวดเร็วตลอดเวลาทำให้ Data Lake ไม่สามารถรองรับได้ และอาจต้องขยายเพิ่มจำนวน Data Lake หรือต้องสร้างระบบเพิ่ม
  • ข้อมูลมีความซ้ำซ้อนในหลายที่ และความที่มีหลายระบบก็ทำให้การอัฟเดทและบริหารข้อมูลมีความยุ่งยาก รวมถึงต้องใช้เครื่องมือที่หลากหลาย
  • ข้อมูลกระจายอยู่ในหลายที่ทั้งใน Data Lake หรือ Data Warehouse หลายๆระบบ ในตำแหน่งที่ต่างกัน ทั้ง On-premise หรือ Cloud หลายๆระบบ
  • Use case ในการใช้ข้อมูลมีความหลากหลายกว่าเดิม ต้องการเทคโนโลยีที่ใช้ในการวิเคราะห์ข้อมูลและบริหารข้อมูลที่ต่างกัน และอาจต้องรองรับผู้ใช้ที่หลากหลายขึ้น เช่น Data Warehouse อาจเหมาะกับการทำ BI หรือ SQL ส่วน Data Lake อาจเหมาะกับการทำ Machine Learning หรือการแปลง Data

ดังนั้นแนวโน้มของสถาปัตยกรรม Big Data ที่เราจะเห็นในปัจจุบัน จะมุ่งสู่ Distributed Data Architecture มากขึ้น โดยจะมี Data Warehouse หรือ Data Lake หลายระบบกระจายอยู่ในตำแหน่งที่ต่างกัน แต่สิ่งที่เราต้องทำให้ได้ก็คือเรื่องของสถาปัตยกรรม Data Fabric ที่เราจะต้องสามารถบริหารจัดการข้อมูลที่อยู่ในระบบที่หลากหลายเหล่านี้ได้จากเครื่องมือเดียวกัน นอกจากนี้เราไม่จำเป็นต้องมีการเคลื่อนย้ายข้อมูลจากระบบหนึ่งมาอีกระบบเช่นจาก Data Lake มายัง Data Warehouse ให้เกิดความซ้ำซ้อน และจะต้องมีเครื่องมือในการที่วิเคราะห์ข้อมูลสำหรับ Use case ต่างๆจากแหล่งข้อมูลที่หลากหลายได้เช่นอาจเป็นเครื่องมือในการทำ Machine Learning หรือ Business Intelligence ดังสถาปัตยกรรมในรูปข้างล่างนี้

Distributed Big Data Architecture

ทำให้ในปัจจุบันผู้ให้บริการ Public cloud หลายรายเห็นแนวโน้มที่สถาปัตยกรรม Big Data จะเป็นแบบ Distributed Data Sources จึงได้ออกบริการที่ทำให้เราสามารถพัฒนาระบบ Big Data ที่มีสถาปัตยกรรมอย่างนี้ได้ อาทิเช่น Google Cloud Platform มีบริการที่ชื่อ DataPlex สำหรับการทำ Unified data management / data governance หรือบริการ Big Lake ที่ทำให้เราวิเคราะห์ข้อมูลจากแหล่งข้อมูลต่างๆได้ ซึ่งในตอนหน้าจะมาอธิบายให้เข้าใจการทำงานของบริการเหล่านี้

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

IMC Institute

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

thanachart Articles

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

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

thanachart Articles

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

——-

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

thanachart Articles

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

——-

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

thanachart Articles

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

——-

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

thanachart Articles

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

——————————

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

thanachart Articles

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

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

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

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

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

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

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

IMC institute

thanachart Articles

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

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

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

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

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

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

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

IMC institute


thanachart Articles

บทความด้าน 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