Hiểu về Parquet, Iceberg và data lakehouse

Tìm hiểu: Parquet, Iceberg và data lakehouse của BroadIn

• Cách lưu trữ dữ liệu (trong tệp và trong bộ nhớ)

  • Có nhiều định dạng tệp khác nhau phục vụ việc truy cập và lưu trữ dữ liệu
  • Một số hệ thống chủ yếu dùng định dạng dữ liệu đóng, nhưng đa số hệ thống hỗ trợ các định dạng dữ liệu mở
  • Các định dạng tệp mã nguồn mở tiêu biểu gồm Apache Avro, Parquet, ORC, Arrow, Feather, Protobuf, v.v.
  • Các định dạng này cung cấp đặc tả về cách sắp xếp dữ liệu trong bố cục nhị phân thực tế
  • Parquet hỗ trợ nén rất tốt, còn Avro phù hợp để đọc các khối hàng cụ thể
  • Hỗ trợ tiến hóa schema và chia nhỏ tệp, là yếu tố thiết yếu cho xử lý song song
  • Có thể làm việc với các định dạng này trên nhiều ngôn ngữ lập trình và công cụ khác nhau

• Quản lý dữ liệu quy mô lớn - Iceberg và Delta Lake

  • Cần có cách để lưu trữ nhiều bảng khác nhau, tiến hóa schema riêng cho từng bảng, phân vùng dữ liệu hiệu quả và giúp các công cụ bên ngoài có thể dễ dàng đọc schema
  • Hive, Iceberg và Delta Lake đều hỗ trợ schema registry hoặc metastore
  • Iceberg và Delta Lake sử dụng Parquet làm định dạng tệp riêng lẻ
  • Iceberg và Delta Lake không phải là query engine hay storage engine, mà là các đặc tả mở giúp query engine có thể thực hiện công việc
  • Cho phép các tính năng như tiến hóa phân vùng, tiến hóa schema, nén dữ liệu, giao dịch ACID, tối ưu hóa truy vấn hiệu quả, time travel, v.v.

• Data lake và data lakehouse là gì?

  • Data lake là nơi các công ty lưu trữ lượng lớn dữ liệu ở dạng thô như OCR, tệp Parquet hoặc CSV
  • Data lakehouse là sự kết hợp các khả năng ở phía trên data lake, cho phép thực thi truy vấn SQL, thiết lập batch job, cấu hình data governance, v.v.
  • Có thể xem data lakehouse là một phiên bản của kho dữ liệu mở
  • Khi các data warehouse như Snowflake và BigQuery hỗ trợ các định dạng dữ liệu mở như Iceberg, ranh giới giữa data warehouse và data lakehouse đang trở nên mờ nhạt

Ý kiến của GN⁺

• Iceberg và Delta Lake đóng vai trò quan trọng như một lớp metadata để quản lý các tập dữ liệu quy mô lớn. Chúng cho phép quản lý dữ liệu hiệu quả và tối ưu hóa truy vấn, rất hữu ích cho các nhà khoa học dữ liệu và kỹ sư.
• Data lakehouse kết hợp ưu điểm của data lake và data warehouse, mở ra một mô hình mới cho quản lý và phân tích dữ liệu. Điều này mang lại cơ hội củng cố hơn nữa việc ra quyết định dựa trên dữ liệu.
• Khi mức độ hỗ trợ dành cho Iceberg tăng lên, các hệ thống quản lý và phân tích dữ liệu được kỳ vọng sẽ dần tiêu chuẩn hóa và tăng khả năng tương tác. Điều này sẽ mang lại nhiều linh hoạt và hiệu quả hơn trong việc lựa chọn và vận hành nền tảng dữ liệu.

[happing94]

Tôi đang so sánh Iceberg và Delta Lake, hóa ra ở đây đã được tổng hợp gọn gàng như vậy rồi.
Quan điểm và ý kiến mà tôi đang xem gần như tương tự.
Benchmark được chạy online là dùng Spark, và Head DevRel của Tabular đã viết rằng benchmark này đáng để tham khảo, nhưng không có nhiều ý nghĩa lớn.
Nếu phải chọn với tư cách là mã nguồn mở thì có vẻ Iceberg là lựa chọn duy nhất.
Phần tóm tắt thì tốt, nhưng sẽ hay hơn nếu có cả các liên kết tham khảo.

[GN⁺]

Ý kiến trên Hacker News

• Apache Iceberg và Delta Lake thường được nhắc đến như các định dạng bảng mở, nhưng trên thực tế có sự khác biệt.

  • Đặc tả định dạng bảng Apache Iceberg đủ rõ ràng để những ai quen với hệ quản trị cơ sở dữ liệu có thể xây dựng và truy vấn bảng Iceberg mà không gặp nhiều khó khăn.
  • Ngược lại, với đặc tả của Delta Lake, rất khó để hình dung mức độ công sức cần thiết nhằm hiện thực đầy đủ đặc tả hiện tại hoặc liên tục cập nhật nó.
  • Đặc tả Delta Lake trông giống như sản phẩm của việc đảo ngược kỹ thuật cách Databricks đã quyết định triển khai nội bộ để xây dựng lakehouse cho các doanh nghiệp Fortune 1000 thất vọng với Hadoop.
  • Tôi không thực sự chắc Delta Lake có giá trị như một hệ sinh thái thật sự mở hay không.

• Trong thế giới cơ sở dữ liệu, việc Delta, Iceberg và Hudi lưu trữ dữ liệu trên các hệ lưu trữ như S3 dưới dạng định dạng mã nguồn mở là một thay đổi rất lớn.

  • Điều đó có nghĩa là phần lớn lớp lưu trữ và xử lý được chuẩn hóa, giúp việc di chuyển giữa các cơ sở dữ liệu trở nên dễ dàng hơn, và hầu hết các công cụ đều có thể làm việc với cùng một tập tin theo cách ổn định về giao dịch.
  • Ví dụ, trong lúc Snowflake đang ghi vào các tệp, một nhà khoa học dữ liệu có thể truy vấn dữ liệu theo thời gian thực trong notebook Jupyter, còn ClickHouse có thể cung cấp phân tích hướng người dùng trên chính dữ liệu đó.
  • Ngay cả khi doanh nghiệp quyết định chuyển từ Snowflake sang Databricks thì đó cũng không phải vấn đề lớn.
  • Hiện tại, tốc độ truy vấn các định dạng này trên S3 chưa nhanh bằng nhập liệu gốc, nhưng áp lực thị trường sẽ buộc mọi nhà cung cấp cơ sở dữ liệu tối ưu hiệu năng.
  • Đây là một chiến thắng lớn cho mã nguồn mở và tính mở, vì doanh nghiệp có thể nắm giữ dữ liệu của mình ở định dạng mở và có thể di chuyển được.
  • Lakehouse cũng tạo ra tác động tương tự. Nhiều công ty có cả data lake lẫn data warehouse, và phải sao chép dữ liệu giữa hai hệ thống. Có thể truy vấn cùng một tập dữ liệu và chỉ phải quản lý một hệ thống cũng quan trọng không kém.

• Tôi đã làm việc với các tệp Parquet trên S3 nhiều năm nhưng chưa từng hiểu chính xác Iceberg là gì. Tuy nhiên, bài viết đó giải thích Iceberg rất tốt.

  • Iceberg là một định dạng siêu dữ liệu cơ sở dữ liệu cho tập dữ liệu nền, mô tả schema, partitioning, v.v.
  • Trong DBMS truyền thống, schema, công cụ truy vấn và định dạng lưu trữ được cung cấp như một gói duy nhất.
  • Nhưng trong thế giới big data, bạn có thể tự xây dựng các thành phần cơ sở dữ liệu từ đầu rồi trộn và ghép chúng lại. Bạn có thể dùng Iceberg làm định dạng siêu dữ liệu, DuckDB làm công cụ truy vấn, Parquet làm định dạng lưu trữ, và S3 làm phương tiện lưu trữ.

• Cách tốt nhất để lưu Apache Arrow dataframe xuống đĩa dưới dạng tệp là dùng Feather, nhưng cũng có thể chuyển nó sang định dạng Apache Parquet.

  • Nếu muốn tự xây dựng một lakehouse không phụ thuộc JVM, bạn có thể dùng Iceberg làm siêu dữ liệu, Parquet làm dữ liệu, dùng bảng Arrow để truy vấn bằng DuckDB, rồi xử lý dữ liệu qua Arrow->Pandas hoặc Polars.
  • Nếu trộn thêm Feather vào thì stack lakehouse Python hiện tại sẽ không hoạt động.

• Tôi đã nghe về data lake, nhưng "data lakehouse" nghe như nơi giới thượng lưu dữ liệu đi câu cá dữ liệu bằng thuyền dữ liệu vào mùa hè.

• Tôi đang xử lý khoảng 100TB dữ liệu trên GCP, dùng BigQuery làm công cụ truy vấn và áp dụng partitioning Hive đơn giản. Tôi hài lòng vì có thể chạy mọi truy vấn và chi phí rất rẻ, nhưng độ trễ khá cao lên nhiều (dù không phải vấn đề lớn với công ty).

  • Tôi tự hỏi liệu triển khai Iceberg có thể cải thiện điều này không. Có ai có kinh nghiệm dùng Iceberg không?

• Tôi rất hào hứng với Iceberg, nhưng lần cuối tôi tìm hiểu thì chỉ có thư viện Spark là hiện thực duy nhất, còn connector Iceberg của Trino lại phụ thuộc rất mạnh vào Hive.

  • Cả ngành dường như đang gặp khó khăn trong việc ly hôn với các công nghệ di sản như MapReduce, Hive và Spark.
  • Tôi định tìm hiểu lại Iceberg và hy vọng lĩnh vực này sẽ phát triển. Ngày nay chúng ta có công cụ và sức mạnh tính toán để xử lý dữ liệu mà không cần công nghệ di sản, và không phải mọi dữ liệu đều là big data.
  • Kết quả là, "kỹ thuật dữ liệu" ngày càng trở nên giống phát triển backend thông thường hơn, và các thực hành phát triển phổ biến đang được áp dụng.
  • Tôi rất mong một thư viện Iceberg thuần Python sẽ sớm ra mắt.

• Tôi tự hỏi vì sao không ai có thể giải thích tất cả điều này bằng những ý tưởng cụ thể hơn. Cần phải giải thích cách lưu trữ dữ liệu, cách kết nối và truy vấn nó, cũng như tốc độ truy vấn ra sao (so với tốc độ giao dịch và tốc độ "phân tích").

• Trong mọi benchmark tôi thấy trên mạng, định dạng Delta Lake đều cho hiệu năng tốt hơn Iceberg rất nhiều.

  • Câu hỏi là điều đó có phải xuất phát từ điều gì đó mang tính nền tảng trong đặc tả hay không, hay Iceberg vẫn có khả năng thu hẹp khoảng cách.

• Tôi thừa nhận bài blog có lẽ không thể bao quát 100% hoặc trở thành điểm khởi đầu tốt nhất cho đa số mọi người.

  • Tôi thích tinh thần cho rằng cách tốt nhất để học điều gì mới là giải thích lại nó cho người khác, và bản thân tôi cũng bắt đầu áp dụng điều đó vào phần ghi chú trên website của mình.