ทำความเข้าใจ Parquet, Iceberg และ Data Lakehouse

(davidgomes.com)

6 คะแนน โดย GN⁺ 2023-12-31 | 2 ความคิดเห็น | แชร์ทาง WhatsApp

เทคโนโลยีการจัดเก็บข้อมูลไม่ได้เป็นก้อนเดียว แต่แบ่งเป็นหลายชั้นที่แตกต่างกัน เช่น รูปแบบไฟล์, รูปแบบในหน่วยความจำ, ชั้นเมทาดาทาของตาราง และสถาปัตยกรรม Lakehouse
Avro·Parquet·ORC·Arrow เป็นรูปแบบที่กำหนด เลย์เอาต์ไบนารี ของข้อมูล โดย Parquet เด่นด้านการบีบอัดแบบคอลัมน์และการประมวลผลเชิงวิเคราะห์ ส่วน Avro เหมาะกับการประมวลผลแบบแถวมากกว่า
Iceberg และ Delta Lake ไม่ใช่รูปแบบไฟล์ แต่เป็นชั้นเมทาดาทาระดับบนที่ช่วยให้ จัดการตารางขนาดใหญ่ บนไฟล์อย่าง Parquet ได้
Data Lakehouse เป็นแนวทางที่นำ ความสามารถแบบ Warehouse เช่น SQL query, งานแบบ batch และ governance มาวางบนไฟล์ดิบในสตอเรจอย่าง S3
Warehouse อย่าง Snowflake และ BigQuery ก็เริ่มรองรับรูปแบบเปิดอย่าง Iceberg ทำให้เส้นแบ่งระหว่าง Data Warehouse กับ Lakehouse ค่อย ๆ เลือนลง

ความแตกต่างระหว่างรูปแบบไฟล์กับรูปแบบในหน่วยความจำ

รูปแบบโอเพนซอร์สที่ช่วยให้การจัดเก็บและเข้าถึงข้อมูลมีประสิทธิภาพ มี วิธีจัดเก็บ และตำแหน่งการใช้งานที่แตกต่างกัน
- Apache Avro: ไบนารี, จัดเก็บแบบแถว (rowstore), ไฟล์
- Apache Parquet: ไบนารี, จัดเก็บแบบคอลัมน์ (columnstore), ไฟล์
- Apache ORC: ไบนารี, จัดเก็บแบบคอลัมน์, ไฟล์
- Apache Arrow: ไบนารี, จัดเก็บแบบคอลัมน์, หน่วยความจำ
- Protocol Buffers: เป็นภาษากำหนดโครงสร้างข้อมูลที่เป็นกลางต่อภาษาโปรแกรม และอาจจัดเก็บแบบแถวหรือแบบคอลัมน์ได้ต่างกันตามการนำไปใช้งาน
- CSV: เป็นข้อความและมีโครงสร้างเรียบง่ายมาก
เมื่อต้องการบันทึก DataFrame ของ Apache Arrow ลงเป็นไฟล์บนดิสก์ มักใช้ Feather และยังแปลงเป็นรูปแบบอื่นอย่าง Parquet ได้ด้วย
ระบบอย่าง Snowflake, Redshift, Athena และ Hive รองรับการอ่าน·เขียนทั้งรูปแบบเปิดและรูปแบบจัดเก็บแบบปิด แต่ ขอบเขตการรองรับรูปแบบเปิด อาจแตกต่างกันไปตามแต่ละผลิตภัณฑ์

สิ่งที่รูปแบบกำหนดจริง ๆ

รูปแบบไฟล์คือสเปกที่กำหนดว่าข้อมูลถูกจัดเรียงอย่างไรใน เลย์เอาต์ไบนารี จริง
Parquet เด่นด้านการบีบอัด ส่วน Avro เป็นการจัดเก็บแบบแถว จึงเหมาะกับการอ่านบล็อกของแถวบางส่วนมากกว่า
ทั้ง Parquet และ Avro รองรับ schema evolution ทำให้แก้ schema ของข้อมูลใหม่ได้โดยไม่ต้องเขียนข้อมูลเดิมทั้งหมดใหม่
ทั้งสองรูปแบบรองรับการแบ่งไฟล์ ซึ่งสำคัญต่อการประมวลผลข้อมูลแบบขนาน
รีโพซิทอรี Apache Parquet มีทั้งสเปกรูปแบบไฟล์จริงและ reference implementation ภาษา Java
Parquet สามารถอ่านและเขียนได้จากหลายภาษาและหลายเครื่องมือ และใน Pandas ก็สามารถบันทึก DataFrame เป็นไฟล์ Parquet ในเครื่องด้วย to_parquet ได้
Presto/Trino, Spark, DuckDB, Hive, Dremio, Impala, AWS Athena และ Apache Drill เป็นตัวอย่างเอนจินที่จัดการไฟล์ Parquet ได้

รูปแบบไฟล์อย่างเดียวไม่พอสำหรับการจัดการข้อมูลขนาดใหญ่

รูปแบบไฟล์แต่ละแบบกำหนดเพียง เลย์เอาต์ของไฟล์หนึ่งไฟล์ จึงไม่เพียงพอสำหรับจัดการชุดข้อมูลขนาดใหญ่ที่เปลี่ยนแปลงต่อเนื่อง
การจัดเก็บตารางจำนวนมาก, schema evolution ของแต่ละตาราง, การ query ตามช่วงเวลา, การ partition อย่างมีประสิทธิภาพ, การให้เครื่องมือภายนอกอ่าน schema และการเก็บสถิติเพื่อทำ cost-based query optimization จำเป็นต้องมีชั้นที่สูงกว่า
ชั้นนี้ประกอบด้วย table format และ schema registry หรือ metastore
Confluent Schema Registry รองรับ Avro และ Protobuf และเหมาะกับข้อมูลสตรีมมิงที่มีแนวโน้มเป็นการจัดเก็บแบบแถวมากกว่า

ตำแหน่งของ Hive, Iceberg และ Delta Lake

Facebook เปิดตัว Hive ในปี 2009 พร้อมกับรูปแบบเมทาดาทาของตารางของตนเอง และต่อมา Hive ก็รองรับรูปแบบต่าง ๆ หลายแบบ
Netflix พัฒนา Iceberg เพื่อก้าวข้ามข้อจำกัดด้านประสิทธิภาพและการขยายขนาดของ Hive
Databricks พัฒนา Delta Lake ซึ่งเป็นทางเลือกแทน Iceberg และภายหลังเปิดเป็นโอเพนซอร์ส
ทั้ง Iceberg และ Delta Lake ใช้ Parquet เป็นรูปแบบไฟล์รายไฟล์
Hive, Delta Lake และ Iceberg ล้วนรองรับแนวคิดที่เทียบได้กับ schema registry หรือ metastore
- HMS (Hive MetaStore) ของ Hive สามารถใช้ RDBMS ได้แทบทุกชนิด
- Iceberg มี Iceberg Catalogs
- Databricks มี Unity Catalog
Catalog และ metastore เหล่านี้ยังใช้กับ data governance เพื่อจัดการว่าทีมหรือผู้ใช้ใดเข้าถึงตารางใดได้ด้วย

หน้าที่ของ Iceberg และ Delta Lake

Delta Lake และ Iceberg ไม่ใช่ query engine หรือ storage engine เอง แต่เป็น สเปกเปิด ที่ช่วยให้ query engine ทำงานได้
ทั้งสองแก้ปัญหาเดียวกันด้วยวิธีต่างกัน และมีข้อถกเถียงเรื่องความเปิด เนื่องจาก Delta Lake มีความหลากหลายของผู้มีส่วนร่วมต่ำกว่า Iceberg
การรองรับ Iceberg กำลังเพิ่มขึ้นอย่างรวดเร็วใน Data Warehouse และ Lakehouse หลายแห่ง เช่น Redshift, BigQuery, Snowflake, Athena และ Dremio
Iceberg และ Delta Lake มีฟีเจอร์ที่จำเป็นสำหรับการดำเนินงานตารางขนาดใหญ่
- การ partition
- schema evolution
- การบีบอัดข้อมูล
- ธุรกรรม ACID สำหรับการเปลี่ยนแปลง schema
- query optimization อย่างมีประสิทธิภาพผ่าน column pruning, predicate pushdown และการเก็บสถิติ
- time travel สำหรับการ query ตามช่วงเวลา
Iceberg รองรับ partition evolution ทำให้เปลี่ยนวิธี partition หรือ shard key ของตารางได้โดยไม่ต้องเขียนข้อมูลเดิมทั้งหมดใหม่
ที่ Netflix การเปลี่ยน partition เป็นปัญหาใหญ่ และเป็นหนึ่งในเหตุผลที่สร้าง Iceberg ขึ้นมา

รูปแบบปิดและแรงกดดันในการรองรับ Iceberg

สเปก Iceberg กำลังได้รับความนิยมอย่างรวดเร็วในฐานะรูปแบบที่หลายระบบรองรับ
ผลิตภัณฑ์ที่ใช้รูปแบบปิดต้องเผชิญแรงกดดันให้ยังคงทำประสิทธิภาพสูงสุดจากรูปแบบของตนเองได้ พร้อมกับต้องรองรับ Iceberg หรือ Delta Lake ในทางใดทางหนึ่ง
Iceberg อาจกลายเป็น ฟีเจอร์เช็กลิสต์ ที่ระบบฐานข้อมูลทุกระบบต้องรองรับในสักวัน
ด้วยเหตุผลด้านประสิทธิภาพ Iceberg อาจทดแทนรูปแบบข้อมูลแบบปิดได้ไม่ทั้งหมด
หากพัฒนารูปแบบข้อมูลเพื่อ query engine เพียงตัวเดียว นักพัฒนาฐานข้อมูลจะสามารถดึงประสิทธิภาพสูงสุดและสร้างนวัตกรรมได้เร็วกว่า

Data Lake และ Data Lakehouse

Data Lake คือที่ที่บริษัทเก็บข้อมูลปริมาณมากในรูปของ ไฟล์ดิบ เช่น Parquet หรือ CSV
Data Warehouse จัดเก็บข้อมูลในรูปแบบที่มีโครงสร้างมากกว่า เช่น ตาราง SQL ที่มี schema และ schema ของฐานข้อมูล
Data Lakehouse คือรูปแบบที่ผสานความสามารถอย่างการรัน SQL query, งานแบบ batch และการตั้งค่า data governance เข้ากับ Data Lake
หากใช้ Iceberg ร่วมกับ query engine และองค์ประกอบเพิ่มเติมอื่น ๆ ก็สามารถสร้าง Data Lakehouse บน Data Lake ได้
ในอดีต หากต้องการความสามารถเหล่านี้ มักต้องนำ Data Warehouse หรือ DBMS แบบดั้งเดิมมาใช้
Data Lakehouse ใช้ HDFS หรือ Cloud Blob Store อย่าง S3 เป็นที่เก็บข้อมูลทั้งหมด และปรับแต่ง query engine ให้ทำงานได้รวดเร็วบนสตอเรจนั้น
Databricks และ Dremio เป็นตัวอย่างผลิตภัณฑ์ Data Lakehouse
เมื่อ Warehouse อย่าง Snowflake และ BigQuery เพิ่มการรองรับ รูปแบบข้อมูลเปิด อย่าง Iceberg ความแตกต่างระหว่าง Data Warehouse กับ Data Lakehouse ก็ยิ่งพร่าเลือนมากขึ้น

2 ความคิดเห็น

happing94 2024-01-03

ผมกำลังเปรียบเทียบ Iceberg กับ Delta Lake อยู่พอดี สรุปออกมาได้เรียบร้อยดีแบบนี้เลยนะครับ
มุมมองและความเห็นก็แทบจะเหมือนกับที่ผมกำลังดูอยู่เลย
Benchmark ที่รันออนไลน์นั้นใช้ Spark และแม้จะพอใช้อ้างอิงได้ แต่ Head of DevRel ของ Tabular เขียนไว้ว่ามันไม่ได้มีความหมายมากนัก
ถ้าจะเลือกในฐานะโอเพนซอร์ส ก็ดูเหมือนว่า Iceberg จะเป็นตัวเลือกเดียว
สรุปดีครับ แต่ถ้ามีลิงก์อ้างอิงที่ใช้ด้วยก็น่าจะดี

GN⁺ 2023-12-31

ความคิดเห็นจาก Hacker News

แม้ว่า Apache Iceberg กับ Delta Lake มักถูกจัดรวมกันว่าเป็น Open Table Format ทั้งคู่ แต่ในความเป็นจริงดูแตกต่างกันมาก
สเปกของ Iceberg อยู่ที่ https://iceberg.apache.org/spec/ และถ้าเป็นคนที่เข้าใจระบบฐานข้อมูล ก็ดูเหมือนว่าสามารถอ่านแล้วทำ implementation สำหรับสร้างและ query ตาราง Iceberg ได้โดยไม่ยากนัก
ส่วนของ Delta Lake คือ https://github.com/delta-io/delta/blob/master/PROTOCOL.md ซึ่งแม้แต่ปริมาณงานที่ต้องใช้เพื่อ implement สเปกปัจจุบันให้ครบก็ยังประเมินได้ยาก และยิ่งไม่ต้องพูดถึงการตามสเปกขนาดมหึมาที่เปลี่ยนตลอดนี้ให้ทัน
พูดตรง ๆ คือ สเปกของ Delta Lake อ่านแล้วเหมือนเอกสารที่ reverse engineer มาจากการประนีประนอมด้าน implementation ที่ Databricks ใช้สร้าง lakehouse อย่างรวดเร็วให้บริษัท Fortune 1000 ที่เคยเจ็บตัวกับ Hadoop
ยังไม่ค่อยเชื่อว่าการเลือกใช้ Delta Lake คือการเข้าสู่ ecosystem แบบเปิด จริง ๆ และอยากเห็นหลักฐานที่ทำให้สบายใจในประเด็นนี้มากกว่านี้
เพิ่มเติมคือประวัติบน GitHub ก็ไม่ได้ช่วยให้สบายใจ: https://github.com/delta-io/delta/commits/master/PROTOCOL.md
มันดูเหมือนเป็นกระบวนการที่ฟีเจอร์หรือการแก้ไขตามอำเภอใจถูกส่งมาเป็น PR โดยวิศวกรของ Databricks แล้วก็ได้รับการอนุมัติทันทีโดยวิศวกรอาวุโสของ Databricks
- เห็นด้วยทั้งหมด Databricks จะตั้งใจไม่ใส่ฟีเจอร์อย่าง Bloom filter ไว้ใน Delta เวอร์ชันโอเพนซอร์สก็เป็นสิทธิของเขา
  แต่แบบนั้นก็ไม่อาจอ้างได้ว่าเป็นฟอร์แมตแบบเปิดที่ขับเคลื่อนโดยชุมชน เว้นแต่ว่าจะเป็นเวอร์ชันแบบ Animal Farm ที่ “บางฝ่ายเท่าเทียมกว่าฝ่ายอื่น”
- ผมเคยลอง implement การรองรับ Delta ตั้งแต่ต้นในคอมโพเนนต์หนึ่งของ Microsoft Fabric แล้วรู้สึกว่าแค่ “สเปก” อย่างเดียวยังไม่พอมาก ถ้าไม่ลองเทียบกับ implementation ของ Spark เพิ่มเติม
  ถ้าจะใช้ฟีเจอร์อย่าง computed columns หรือ check constraints ก็ต้องรองรับ Spark SQL expressions ด้วย ซึ่งเอกสารฝั่งนั้นยิ่งแย่กว่าเดิม
- ผมก็รู้สึกเหมือนกัน ระวังตัวอย่างมากกับทุกอย่างที่ Databricks ทำ
  มันใกล้เคียงโอเพนซอร์สแค่ในนาม และคิดว่าไม่ควรไว้ใจ
  ผมก็เคยใช้ Delta Lake และเจอข้อจำกัดที่น่าหงุดหงิดกับมุมคม ๆ ในการใช้งานจริงเยอะมาก สุดท้ายโปรเจกต์นั้นก็ถูกพับไปทั้งหมด และตอนนั้นก็ได้ศึกษาทั้ง Iceberg ด้วย
  Iceberg กับ Hudi ดูเหมือนถูกออกแบบชุดความสามารถได้สม่ำเสมอกว่า แต่ได้รับการสนับสนุนน้อยกว่า และหวังว่าส่วนนี้จะดีขึ้นในอนาคต
- ผมติดตามวงการนี้มา 1-2 ปีและสงสัยมาตลอดว่าทำไมในโลกโอเพนซอร์ส Iceberg ถึงได้รับความนิยมมากกว่า คำอธิบายนี้ช่วยได้มาก
  แต่ในช่วง 6 เดือนที่ผ่านมา ผมรู้สึกว่า Iceberg ยังมีปัญหาในการทำเครื่องมือสำหรับผู้ใช้นอก ecosystem ของ JVM ขณะที่ Delta ดูนำหน้าอยู่ ในแง่นั้น Delta เข้าถึงได้ง่ายกว่ามาก
- การใช้ JSON กับการเปลี่ยนแปลงของ Delta นี่ช่างโง่จริง ๆ
  ถ้าเทียบกันแล้ว SQL Server ทำเรื่องนี้ได้ดีกว่ามาก ตารางเก็บข้อมูลแบบคอลัมน์ (columnstore indexes ซึ่งเทียบได้กับ Parquet/ORC ภายในเอนจิน) เป็นแบบ immutable และ delta จะถูกเก็บไว้ใน B-Tree เพื่อการบีบอัด การเข้าถึง และความเร็ว
  เมื่อถึงจุดหนึ่ง column store จะถูกจัดระเบียบดิสก์ใหม่ ผสาน หรือสร้างใหม่บางส่วนหรือทั้งหมด และ B-Tree ก็จะถูกลบ จากนั้นเริ่มใหม่เมื่อมีการเปลี่ยนแปลงชุดใหม่สะสมขึ้นมา
  การทำสิ่งนี้ด้วย JSON ต่อให้พูดให้นุ่มนวลก็ยังเป็นสัญญาณของยุคสมัยที่ย่ำแย่
  อะไรก็น่าจะดีกว่า Delta Lake โดยเฉพาะ Iceberg ที่ดูดีกว่า
เป็นบทความที่ดี ผมทำงานกับไฟล์ Parquet บน S3 มาหลายปี แต่ไม่ค่อยรู้แน่ชัดว่า Iceberg คืออะไร บทความนี้อธิบายได้ดีมาก
Iceberg คือฟอร์แมต metadata ของฐานข้อมูลที่ใช้อธิบาย schema และ partitioning เป็นต้น ของชุดข้อมูลพื้นฐาน
โดยส่วนใหญ่จะใช้ธรรมเนียมการ partition แบบ Hive อย่าง /key3=000/key2=002/ แต่ Iceberg ดีกว่าตรงที่เปิดเผยโครงสร้างให้ query engine เห็นได้มากกว่า
ใน DBMS แบบดั้งเดิมอย่าง Postgres ทั้ง schema, query engine และ storage format จะมาเป็นแพ็กเกจเดียวกัน
แต่ในโลกบิ๊กดาต้า คุณสามารถประกอบชิ้นส่วนของฐานข้อมูลขึ้นมาใหม่ตั้งแต่ต้นและสลับใช้ข้ามกันได้ เช่น ใช้ Iceberg เป็นฟอร์แมต metadata, DuckDB เป็น query engine, Parquet เป็น storage format และ S3 เป็นสื่อจัดเก็บข้อมูล
ในโลกของฐานข้อมูล นี่ถือเป็นการเปลี่ยนแปลงครั้งใหญ่ เพราะด้วย Delta, Iceberg และ Hudi ทำให้ข้อมูลส่วนใหญ่มักถูกเก็บใน ฟอร์แมตโอเพนซอร์ส บน S3
เมื่อสตอเรจและการประมวลผลจำนวนมากถูกทำให้เป็นมาตรฐาน การย้ายข้อมูลระหว่างฐานข้อมูลก็จะง่ายขึ้น และท้ายที่สุดเครื่องมือแทบทั้งหมดก็จะสามารถจัดการกับชุดไฟล์เดียวกันได้อย่างปลอดภัยในเชิงทรานแซกชัน
ตัวอย่างเช่น ขณะที่ Snowflake กำลังเขียนลงไฟล์ นักวิทยาศาสตร์ข้อมูลก็สามารถคิวรีแบบเรียลไทม์จาก Jupyter notebook ได้ และ ClickHouse ก็สามารถให้บริการงานวิเคราะห์สำหรับผู้ใช้บนข้อมูลชุดเดียวกันพร้อมการรับประกันความสอดคล้องได้
หลังจากนั้น ต่อให้บริษัทตัดสินใจย้ายจาก Snowflake ไป Databricks ก็จะไม่ใช่เรื่องใหญ่มากอีกต่อไป
ตอนนี้ความเร็วในการคิวรีฟอร์แมตเหล่านี้บน S3 ยังไม่เร็วเท่าการโหลดแบบเนทีฟ แต่ด้วยแรงกดดันจากตลาด ผู้ขายฐานข้อมูลทุกรายจะถูกบังคับให้ปรับแต่งประสิทธิภาพ และสุดท้ายก็น่าจะเข้าใกล้ประสิทธิภาพของข้อมูลที่โหลดแบบเนทีฟ
นี่เป็นชัยชนะครั้งใหญ่ในแง่ของความเปิดกว้าง โอเพนซอร์ส และการที่องค์กรถือครองข้อมูลของตนเองใน ฟอร์แมตที่เปิดและพกพาได้
เลคเฮาส์ก็มีนัยเดียวกัน หลายบริษัทมีทั้ง data lake และ data warehouse แล้วก็ต้องคัดลอกข้อมูลไปมาระหว่างกัน
การมีเพียงระบบเดียวสำหรับคิวรีและจัดการข้อมูลชุดเดียวกันก็ให้ผลกระทบที่ใหญ่มากเช่นกัน
นี่เป็นช่วงเวลาที่น่าตื่นเต้นมากสำหรับวงการ data engineering
- Apache Arrow และ Substrait ได้ทำงานเพื่อทำให้ความเป็นจริงแบบนี้เกิดขึ้น
  อนาคตดูเหมือนจะเป็นไปได้ที่จะส่ง execution plan ตอนรันคิวรีไปยังหลายเอนจินทั่วทั้งคลาวด์ รวมถึงเครื่อง local ด้วย
- การสมมติว่าผู้ขายฐานข้อมูลทุกรายจะยอมทิ้งฟอร์แมตจัดเก็บภายในของตน แล้วแข่งขันกันแค่ที่ชั้นการคำนวณนั้น เป็นการมองข้ามทั้งโครงสร้างพื้นฐานทางวิศวกรรมและโมเดลธุรกิจที่พวกเขาสะสมมาหลายทศวรรษ
  ถ้าเป็น Snowflake อาจจะคุ้มกว่าถ้าปิดกิจการแล้วคืนเงินหลายพันล้านดอลลาร์ให้นักลงทุน เพราะการผูกข้อมูลไว้ใน ecosystem ของตัวเองคือโมเดลธุรกิจทั้งหมดของพวกเขา
  เลยสงสัยว่ามีตัวอย่างดี ๆ ไหมที่ มาตรฐานเปิด ทำให้บริษัทต่าง ๆ ยอมทิ้งเทคโนโลยีแบบปิดของตน
ไม่ค่อยเห็นด้วยอย่างมากกับคำพูดที่ว่า “วิธีที่ดีที่สุดในการเก็บ Apache Arrow dataframe เป็นไฟล์บนดิสก์คือ Feather และยังแปลงเป็น Apache Parquet เป็นต้นได้”
ถ้าจะสร้างเลคเฮาส์เองโดยไม่ใช้ JVM การจัดวางที่ดีที่สุดคือใช้ Iceberg เป็นเมทาดาทา, Parquet เป็นข้อมูล, DuckDB เป็น query engine และคิวรีด้วย Arrow table
ต้นทุนในการอ่าน Parquet เป็น Arrow โดยตรงนั้นต่ำมาก แล้วค่อยส่งต่อ Arrow → Pandas หรือ Polars ก็ได้ จะส่งตรงหรือผ่านบริการที่อิง Arrow Flight ก็ได้
ถ้าเอา Feather มาใส่ ตอนนี้ทั้ง Python เลคเฮาส์สแตกจะทำงานได้ไม่ค่อยดี
- เคยคิดอยู่ช่วงหนึ่งว่า Feather ไม่มีการรับประกันฟอร์แมตระยะยาว
  ตอนนี้อาจเปลี่ยนไปแล้ว แต่ก็ยังรู้สึกว่า Parquet เป็นตัวเลือกที่พร้อมรับอนาคตที่สุด
เคยได้ยิน data lake แต่ “data lakehouse” ฟังดูเหมือนสถานที่ที่ข้อมูลชนชั้นสูงไปนั่ง data boat ตก data fish กันหน้าร้อน
- ชื่อนั้นล้อได้ง่ายก็จริง แต่ปัญหาที่มันพยายามแก้ถือว่าใช่
  หลายบริษัทเก็บข้อมูลไว้ใน data lake แล้วใช้ warehouse เพื่อให้ BI กับเครื่องมืออย่าง Tableau หรือ PowerBI สุดท้ายก็ต้องคัดลอกข้อมูลไปมาระหว่างสองฝั่ง
  data lakehouse ที่คิวรี lake โดยตรงพร้อมใช้ทรานแซกชันและ governance กับข้อมูลชุดเดียว สามารถทำให้สแตกเรียบง่ายขึ้นมากและลดต้นทุนได้ด้วย
- ที่จริงแล้วไม่เคยเข้าใจเลยว่า “data lake” หมายถึงอะไรนอกจาก “กองรวมไฟล์ข้อมูลขนาดใหญ่ที่หลากหลาย”
- การตั้งชื่อเป็นเรื่องยาก และหวังว่าวงการนี้จะมีชื่อที่ดีกว่านี้ในสักวัน
  ทุกครั้งที่ได้ยินหรืออ่าน คำนี้ยังฟังแปลก ๆ ในหัวอยู่มาก
คาดหวังกับ Iceberg เป็นพิเศษ เพราะมันเป็นโอเพนซอร์ส
แต่ครั้งล่าสุดที่ดู เหมือน implementation จะมีแค่ Spark library และ Iceberg connector ของ Trino (อดีต Presto, SQL engine) ก็ยังพึ่งพา Hive อย่างมาก
ทั้งอุตสาหกรรมดูเหมือนยังหย่าขาดจากมรดกของ MapReduce, Hive และถ้าจะพูดตรง ๆ คือ Spark ได้ยาก
หลังจากนั้นก็ยังไม่ได้กลับไปดู Iceberg อีก แต่ตั้งใจว่าจะดูเร็ว ๆ นี้ และหวังมากว่าพื้นที่นี้จะพัฒนาไปอีก
ตอนนี้เรามีทั้งเครื่องมือและพลังประมวลผลในการจัดการข้อมูลโดยไม่ต้องพึ่งเทคโนโลยีเลกาซีแล้ว และข้อมูลทุกอย่างก็ไม่ได้เป็นบิ๊กดาต้าเสมอไป
เพราะงั้นโชคดีที่ data engineering กำลังค่อย ๆ คล้ายงาน backend development ทั่วไปมากขึ้น และแนวปฏิบัติการพัฒนาปกติก็กำลังหยั่งราก
หวังว่าในอนาคตอันใกล้มากจะมี Python Iceberg library แบบแท้ ๆ ออกมา
- ตอนนี้ Trino ไม่ได้พึ่ง Hadoop/Hive กับ data lake connector ไหนแล้ว
  ต้องใช้ความพยายามอย่างมากในการถอด dependency นั้นออก
- ฉันก็คล้ายกัน เคยใช้เวลาว่างราวหนึ่งเดือนพยายามประกอบสแตกเก่าให้พอแค่ insert ข้อมูลได้ แต่จบลงแบบไม่น่าพอใจ
  แต่ Databend ขึ้นระบบได้ในหนึ่งชั่วโมง และมองว่าถ้ามี implementation ฝั่ง Rust ก็จะพกพาได้ดีกว่า Java/Hive ทำให้เอาไปใช้งานจริงต่อได้ง่ายขึ้นในอนาคต
ไม่รู้ว่าทำไมถึงอธิบายทั้งหมดนี้ให้เป็นรูปธรรมกว่านี้ไม่ได้
น่าจะบอกให้ชัดได้ว่าข้อมูลถูกเก็บอย่างไร เชื่อมต่อและคิวรีอย่างไร และคิวรีเร็วแค่ไหน เช่น ความต่างระหว่าง ความเร็วทรานแซกชัน กับ ความเร็วคิวรีเชิงวิเคราะห์
ปัจจุบันเราดูแลข้อมูลราว 100TB บน GCP ใช้ BigQuery เป็นเอนจินสำหรับคิวรี และใช้ Hive partitioning แบบง่ายอย่าง /key3=000/key2=002/
สามารถรันคิวรีที่ต้องการได้ทั้งหมด และต้นทุนก็ถูกมากจนน่าพอใจ
เพียงแต่ latency ค่อนข้างสูงขึ้น แต่ก็ไม่ใช่เรื่องสำคัญมากสำหรับเรา ถึงอย่างนั้นก็สงสัยว่าถ้านำ Iceberg มาใช้ ส่วนนี้จะดีขึ้นหรือไม่
อยากรู้ว่ามีใครมีประสบการณ์แบบนี้ไหม และโดยรวมแล้วสถาปัตยกรรมแบบนี้ยอดเยี่ยมมาก
- มีสรุปที่ใช้ได้สำหรับหัวข้อนี้อยู่ที่: https://aws.amazon.com/blogs/big-data/choosing-an-open-table... ในส่วน “Optimizing read performance”
  เป้าหมายหลักของเทคโนโลยีแบบนี้คือ การจัดการข้อมูลขนาดใหญ่ แต่ก็ยังขยายความสามารถที่ฟอร์แมตการจัดเก็บดิบอย่าง Parquet มีให้อยู่แล้วด้วย ดังนั้นอาจช่วยได้ แต่ต้องพิจารณาก่อนว่าจำเป็นจริงหรือไม่
  แม้จะไม่เคยใช้ BigQuery มาก่อน แต่ก็อาจมี similar features
  ก่อนอื่นต้องนิยามให้ชัดว่า “latency” ที่พูดถึงคืออะไร และ “ค่อนข้างสูง” หมายถึงระดับไหน
  ที่เก็บข้อมูลสำหรับงานวิเคราะห์ถูกออกแบบมาเพื่อการประมวลผลแบบกลุ่มที่มีประสิทธิภาพ และการค้นหาเรกคอร์ดเดี่ยวไม่ใช่เป้าหมายหลักของสถาปัตยกรรมนี้ การค้นหาให้เร็วต้องอาศัยแคชหรือดัชนี
  ในบางกรณี แค่เพิ่ม limit 1 ให้กับการค้นหาเรกคอร์ดเดี่ยวก็อาจแก้ปัญหาได้
  ควรตรวจสอบว่าใช้ฟอร์แมตจัดเก็บข้อมูลที่มีประสิทธิภาพอย่าง Parquet อยู่หรือไม่ และเช็กขนาดไฟล์ว่ามี "small file problem" หรือเปล่า
  จากนั้นควรดูด้วยว่าได้ใช้ฟีเจอร์ที่เกี่ยวข้องของ BigQuery หรือไม่ ก่อนและหลังการตรวจสอบเหล่านี้ ลองรัน explain กับคิวรีด้วย และถ้าไม่ได้ใช้ partition key หรือคอลัมน์ดัชนี ก็ไม่มีระบบบิ๊กดาต้าไหนที่จะคืนผลการค้นหาได้ทันที
- ขนาดของเราประมาณ 1/10 ของฝั่งนั้น แต่ในงาน data visualization ลูกค้าแทบไม่มีความอดทนอยู่แล้ว ความเร็วคิวรีจึงเป็นเรื่องที่เราให้ความสำคัญมาก
  ถ้าไม่ได้ใช้ตาราง BigQuery เป็นอินพุตของงานคำนวณ throughput สูง ผมจะโฟกัสกับการปรับแต่งเครื่องมือ BI หรือสร้าง ตารางสำหรับงานวิเคราะห์ เพื่อกัน latency ฝั่งผู้ใช้ปลายทางมากกว่า
  ตัวอย่างเช่น ไม่นานมานี้เรา materialize การ join ระหว่าง fact/dimension table และการคำนวณ COALESCE เพื่อสร้างตารางขนาดใหญ่สำหรับการวิเคราะห์โดยเฉพาะ
  ในเชิงแนวคิด มันอยู่นอกโครงสร้าง data warehouse ปกติ แต่เพราะยังอยู่ใน dbt เราจึงยังรักษาคุณภาพข้อมูลและ lineage ไว้ได้
  ผลคือเราตัด Tableau fixed calculations ออกไปได้ และลดเวลาโหลด/จัดกลุ่มของผู้ใช้ปลายทางลงได้ราว 95%
- ถ้าใช้ BigQuery native storage อยู่ Iceberg จะไม่ช่วยให้คิวรีเร็วขึ้น
  แต่ถ้าเป็น federated query ไปยัง GCS/S3 ก็อาจเร็วขึ้นได้
- ถ้าย้ายไป AWS ได้ อันนี้ก็ดูน่าสนใจมาก: https://www.boilingdata.com/
ชอบทัศนคติที่ว่า “บทความนี้ไม่ได้ครอบคลุม 100% และอาจไม่ใช่จุดเริ่มต้นที่ดีที่สุดสำหรับคนส่วนใหญ่ เพราะมันเป็นบทความที่ฉันเขียนให้ตัวเอง การบังคับให้ตัวเองอธิบายสิ่งที่เพิ่งเรียนให้คนอื่นฟังอีกครั้งคือวิธีเรียนรู้สิ่งใหม่ที่ดีที่สุด” มาก
ฉันเองก็เริ่มนำวิธีนี้มาใช้ทั้งบนกระดาษและในโน้ตบนเว็บไซต์ของตัวเองแล้ว
ตอนแรกคาดหวังมากกับการเจาะลึกยุคของ Iceberg สำหรับที่เก็บ Parquet แบบมีการจัดการมากขึ้น
แต่ตอนนี้การรองรับ I/O ความเร็วสูงสำหรับ GPU (GPUDirect/cuFile) ยังตามหลังอยู่หลายปี
เลยชนกำแพงนี้ทุกครั้งเวลาพยายามนำไปใช้กับลูกค้าสำหรับ AI workload
ดูแล้วสุดท้ายคงเกิดขึ้นได้ และใกล้เคียงกับคำถามว่า “เมื่อไร” มากกว่า “ทำได้ไหม” ถ้าทำได้ครบทั้งสองด้านก็คงเจ๋งมาก
- อยากรู้ว่าเป็น use case แบบไหน เป็นการเก็บข้อมูลภาพหรือเปล่า?
  ถ้าเป็นการเก็บข้อความ ทุกวันนี้ Parquet ก็เพียงพอแล้ว
  PyTorch Data Loader และ TF Data มีไคลเอนต์แบบมัลติเธรดที่อ่านล่วงหน้าแบบขนาน เติม memory buffer แล้วส่งข้อมูลไปกลับกับ GPU ให้
  เห็นด้วยว่า S3 อาจเป็นคอขวดตรงนี้ได้ ดังนั้นเราจึงวาง HopsFS ไว้บน S3 พร้อม แคช NVMe แบบ globally distributed consistent
  Anyscale ก็เคยทำสิ่งคล้ายกันด้วย local NVMe cache สำหรับ S3
  อีกฟอร์แมตไฟล์ที่น่าสนใจคือ Lance ซึ่งคล้าย Parquet แต่สำหรับข้อมูลภาพ โดยมีดัชนีสำหรับ random I/O แบบรวดเร็วเพื่อค้นหารูปภาพภายในไฟล์เพิ่มเข้ามา