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

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

  • วิธีการจัดเก็บข้อมูล (ในไฟล์และในหน่วยความจำ)

    • มีรูปแบบไฟล์หลากหลายสำหรับการเข้าถึงและจัดเก็บข้อมูล
    • บางระบบใช้รูปแบบข้อมูลแบบปิดเป็นหลัก แต่ระบบส่วนใหญ่รองรับรูปแบบข้อมูลแบบเปิด
    • รูปแบบไฟล์โอเพนซอร์สหลัก ได้แก่ Apache Avro, Parquet, ORC, Arrow, Feather, Protobuf เป็นต้น
    • รูปแบบเหล่านี้กำหนดสเปกว่า จะจัดเรียงข้อมูลในโครงสร้างไบนารีจริงอย่างไร
    • Parquet รองรับการบีบอัดได้ดี และ Avro เหมาะกับการอ่านบล็อกแถวบางส่วน
    • รองรับ schema evolution และการแบ่งไฟล์ ซึ่งเป็นสิ่งจำเป็นต่อการประมวลผลแบบขนาน
    • สามารถทำงานกับรูปแบบเหล่านี้ได้จากหลากหลายภาษาโปรแกรมและเครื่องมือ
  • การจัดการข้อมูลขนาดใหญ่ - Iceberg และ Delta Lake

    • จำเป็นต้องมีวิธีสำหรับจัดเก็บตารางหลายแบบ พัฒนาแต่ละสคีมาได้ แบ่งพาร์ทิชันข้อมูลอย่างมีประสิทธิภาพ และทำให้เครื่องมือภายนอกอ่านสคีมาได้ง่าย
    • Hive, Iceberg และ Delta Lake ต่างก็รองรับ schema registry หรือ metastore
    • Iceberg และ Delta Lake ใช้ Parquet เป็นรูปแบบไฟล์รายตัว
    • Iceberg และ Delta Lake ไม่ใช่ query engine หรือ storage engine แต่เป็นสเปกแบบเปิดที่ช่วยให้ query engine สามารถทำงานได้
    • ทำให้สามารถใช้งานความสามารถต่าง ๆ เช่น partition evolution, schema evolution, การบีบอัดข้อมูล, ธุรกรรม ACID, การเพิ่มประสิทธิภาพคิวรีอย่างมีประสิทธิผล และ time travel
  • Data Lake และ Data Lakehouse คืออะไร?

    • Data Lake คือที่ที่บริษัทต่าง ๆ จัดเก็บข้อมูลปริมาณมากในรูปแบบดิบ เช่น OCR, Parquet หรือไฟล์ CSV
    • Data Lakehouse คือการรวมความสามารถบน Data Lake ที่ทำให้สามารถรัน SQL query ตั้งค่างานแบบแบตช์ และกำหนด data governance ได้
    • Data Lakehouse อาจมองได้ว่าเป็นเวอร์ชันหนึ่งของ open data warehouse
    • เมื่อ data warehouse อย่าง Snowflake และ BigQuery รองรับรูปแบบข้อมูลแบบเปิดอย่าง Iceberg มากขึ้น เส้นแบ่งระหว่าง data warehouse กับ data lakehouse ก็เริ่มเลือนรางลง

ความเห็นของ GN⁺

  • Iceberg และ Delta Lake มีบทบาทสำคัญในฐานะชั้นเมทาดาทาสำหรับจัดการชุดข้อมูลขนาดใหญ่ โดยช่วยให้การจัดการข้อมูลและการเพิ่มประสิทธิภาพคิวรีมีประสิทธิผลมากขึ้น จึงเป็นประโยชน์ต่อทั้งนักวิทยาศาสตร์ข้อมูลและวิศวกร
  • Data Lakehouse ผสานข้อดีของ Data Lake และ Data Warehouse เข้าด้วยกัน และนำเสนอแนวทางใหม่สำหรับการจัดการและวิเคราะห์ข้อมูล ซึ่งเปิดโอกาสให้การตัดสินใจบนฐานข้อมูลมีความแข็งแกร่งยิ่งขึ้น
  • เมื่อการรองรับ Iceberg เพิ่มขึ้น คาดว่าระบบจัดการและวิเคราะห์ข้อมูลจะค่อย ๆ มีมาตรฐานมากขึ้นและทำงานร่วมกันได้มากขึ้น ซึ่งจะนำมาซึ่งความยืดหยุ่นและประสิทธิภาพที่สูงขึ้นในการเลือกใช้และใช้งานแพลตฟอร์มข้อมูล

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 แต่ในความเป็นจริงมีความแตกต่างกัน

    • สเปก table format ของ Apache Iceberg ชัดเจนมากพอที่คนที่คุ้นเคยกับระบบฐานข้อมูลจะสามารถสร้างและคิวรีตาราง Iceberg ได้โดยไม่ยากนัก
    • ในทางกลับกัน สเปกของ Delta Lake ทำให้ยากที่จะประเมินความพยายามที่จำเป็นในการทำ implementation ให้ครบถ้วนตามสเปกปัจจุบันหรืออัปเดตตามอย่างต่อเนื่อง
    • สเปกของ Delta Lake ดูเหมือนเป็นการ reverse engineer วิธี implementation ที่ Databricks ตัดสินใจใช้ภายในเพื่อสร้าง lakehouse สำหรับบริษัท Fortune 1000 ที่ผิดหวังกับ Hadoop
    • จึงยังไม่แน่ใจว่า Delta Lake มีคุณค่าในฐานะระบบนิเวศแบบเปิดอย่างแท้จริงหรือไม่
  • ในโลกของฐานข้อมูล การที่ Delta, Iceberg และ Hudi เก็บข้อมูลเป็นฟอร์แมตโอเพนซอร์สบนสตอเรจอย่าง S3 ถือเป็นการเปลี่ยนแปลงครั้งใหญ่

    • นั่นหมายความว่าสตอเรจและส่วนการประมวลผลจำนวนมากถูกทำให้เป็นมาตรฐาน จึงย้ายข้ามฐานข้อมูลได้ง่ายขึ้น และเครื่องมือส่วนใหญ่สามารถทำงานกับชุดไฟล์เดียวกันได้ในแบบที่มีความเสถียรระดับทรานแซกชัน
    • ตัวอย่างเช่น ระหว่างที่ Snowflake กำลังเขียนไฟล์ นักวิทยาศาสตร์ข้อมูลสามารถคิวรีข้อมูลแบบเรียลไทม์จาก Jupyter notebook ได้ และ ClickHouse ก็สามารถให้การวิเคราะห์ที่เน้นผู้ใช้กับข้อมูลชุดเดียวกันได้
    • ต่อให้ธุรกิจตัดสินใจย้ายจาก Snowflake ไป Databricks ก็ไม่ใช่ปัญหาใหญ่
    • ตอนนี้ความเร็วในการคิวรีฟอร์แมตเหล่านี้บน S3 ยังไม่เร็วเท่าการ ingest แบบเนทีฟ แต่แรงกดดันจากตลาดจะทำให้ผู้ขายฐานข้อมูลทุกรายต้องปรับแต่งประสิทธิภาพ
    • นี่คือชัยชนะครั้งใหญ่ของโอเพนซอร์สและความเปิดกว้าง และทำให้ธุรกิจสามารถถือครองข้อมูลในฟอร์แมตที่เปิดและย้ายได้
    • lakehouse ก็ส่งผลคล้ายกัน หลายบริษัทมีทั้ง data lake และ data warehouse และต้องคัดลอกข้อมูลระหว่างสองระบบ การคิวรีข้อมูลชุดเดียวกันและดูแลเพียงระบบเดียวจึงสำคัญไม่แพ้กัน
  • ทำงานกับไฟล์ Parquet บน S3 มาหลายปี แต่ไม่เคยเข้าใจชัดเจนว่า Iceberg คืออะไร อย่างไรก็ตาม บทความนั้นอธิบาย Iceberg ได้ดี

    • Iceberg คือฟอร์แมตเมทาดาทาฐานข้อมูลสำหรับชุดข้อมูลพื้นฐาน โดยอธิบาย schema, partitioning และอื่น ๆ
    • ใน DBMS แบบดั้งเดิม schema, query engine และ storage format จะมาเป็นแพ็กเกจเดียวกัน
    • แต่ในโลกบิ๊กดาต้า คุณสามารถสร้างองค์ประกอบของฐานข้อมูลขึ้นใหม่ตั้งแต่ต้น และผสมจับคู่กันได้ ใช้ Iceberg เป็น metadata format, DuckDB เป็น query engine, Parquet เป็น storage format และ S3 เป็นสื่อจัดเก็บข้อมูลได้
  • วิธีที่ดีที่สุดในการเก็บ Apache Arrow dataframe เป็นไฟล์บนดิสก์คือใช้ Feather แต่ก็สามารถแปลงเป็นฟอร์แมต Apache Parquet ได้เช่นกัน

    • หากต้องการสร้าง lakehouse แบบ non-JVM ของตัวเอง สามารถใช้ Iceberg เป็น metadata, Parquet เป็นข้อมูล, ใช้ Arrow table เพื่อคิวรีด้วย DuckDB และประมวลผลข้อมูลผ่าน Arrow->Pandas หรือ Polars ได้
    • หากนำ Feather มาผสม สแต็ก Python lakehouse ในปัจจุบันจะไม่ทำงาน
  • เคยได้ยินเรื่อง data lake แต่ "data lakehouse" ฟังดูเหมือนสถานที่ที่เหล่าข้อมูลชนชั้นสูงออกไปตกปลาข้อมูลด้วยเรือข้อมูลในฤดูร้อน

  • กำลังจัดการข้อมูลราว 100TB บน GCP ใช้ BigQuery เป็น query engine และใช้ Hive partitioning แบบง่าย ๆ พอใจกับการที่รันคิวรีทั้งหมดได้และมีต้นทุนถูกมาก แต่ latency ค่อนข้างสูงขึ้นมาไม่น้อย (ซึ่งไม่ใช่ปัญหาใหญ่สำหรับบริษัท)

    • สงสัยว่าการทำ Iceberg จะช่วยปรับปรุงเรื่องนี้ได้หรือไม่ และถามว่ามีใครเคยใช้ Iceberg บ้างไหม
  • ตื่นเต้นกับ Iceberg มาก แต่ครั้งล่าสุดที่ตรวจดูมีเพียงไลบรารี Spark เท่านั้นที่เป็น implementation และ Iceberg connector ของ Trino ก็พึ่งพา Hive อย่างหนัก

    • ทั้งอุตสาหกรรมกำลังมีปัญหาในการหย่าขาดจากเทคโนโลยี legacy อย่าง MapReduce, Hive และ Spark
    • วางแผนจะกลับไปศึกษา Iceberg อีกครั้ง และหวังว่าพื้นที่นี้จะพัฒนาไปได้ดี ทุกวันนี้เรามีทั้งเครื่องมือและพลังการประมวลผลที่ทำให้จัดการข้อมูลได้โดยไม่ต้องพึ่งเทคโนโลยี legacy และข้อมูลทุกอย่างก็ไม่ได้เป็น big data เสมอไป
    • ผลลัพธ์คือ "data engineering" กำลังยิ่งคล้ายกับการพัฒนา backend ทั่วไปมากขึ้น และแนวปฏิบัติการพัฒนาทั่วไปก็กำลังถูกนำมาใช้
    • หวังว่าจะมีไลบรารี Iceberg แบบ pure Python ออกมาในเร็ว ๆ นี้
  • ตั้งคำถามว่าทำไมถึงไม่มีใครอธิบายทั้งหมดนี้ด้วยแนวคิดที่เป็นรูปธรรมมากกว่านี้ ควรอธิบายวิธีเก็บข้อมูล วิธีเชื่อมต่อและคิวรีข้อมูล รวมถึงความเร็วของการคิวรี (เทียบกับความเร็วระดับทรานแซกชันและระดับ "analytics")

  • จาก benchmark ทั้งหมดที่เห็นออนไลน์ ฟอร์แมต Delta Lake ให้ประสิทธิภาพดีกว่า Iceberg มาก

    • จึงถามว่านี่เป็นสิ่งที่ฝังอยู่ในสเปกโดยพื้นฐาน หรือ Iceberg ยังมีโอกาสไล่ช่องว่างนี้ให้แคบลงได้หรือไม่
  • ยอมรับว่าโพสต์บล็อกอาจไม่ได้ครอบคลุม 100% หรือเป็นจุดเริ่มต้นที่ดีที่สุดสำหรับคนส่วนใหญ่

    • แต่ชอบทัศนคติที่ว่า วิธีเรียนรู้สิ่งใหม่ที่ดีที่สุดคือการอธิบายมันกลับให้คนอื่นฟัง และตนเองก็เริ่มนำแนวคิดนี้ไปใช้กับโน้ตบนเว็บไซต์แล้ว