Hiểu về Parquet, Iceberg và data lakehouse
(davidgomes.com)- Công nghệ lưu trữ dữ liệu không phải là một khối thống nhất mà được chia thành các lớp khác nhau như định dạng tệp, định dạng bộ nhớ, tầng metadata của bảng và kiến trúc lakehouse
- Avro·Parquet·ORC·Arrow là các định dạng quy định bố cục nhị phân của dữ liệu; Parquet mạnh về nén theo cột và xử lý phân tích, còn Avro phù hợp hơn với xử lý theo hàng
- Iceberg và Delta Lake không phải là định dạng tệp, mà là tầng metadata cấp cao hơn cho phép quản lý bảng quy mô lớn trên các tệp như Parquet
- Data lakehouse là cách bổ sung các chức năng của data warehouse như truy vấn SQL, batch job và governance lên trên các tệp thô trong kho lưu trữ như S3
- Ngay cả các warehouse như Snowflake và BigQuery cũng đang hỗ trợ các định dạng mở như Iceberg, khiến ranh giới giữa data warehouse và lakehouse ngày càng mờ đi
Sự khác biệt giữa định dạng tệp và định dạng bộ nhớ
- Các định dạng mã nguồn mở giúp tối ưu hóa việc lưu trữ và truy cập dữ liệu có cách lưu trữ và vị trí sử dụng khác nhau
- Apache Avro: nhị phân, lưu trữ theo hàng (rowstore), tệp
- Apache Parquet: nhị phân, lưu trữ theo cột (columnstore), tệp
- Apache ORC: nhị phân, lưu trữ theo cột, tệp
- Apache Arrow: nhị phân, lưu trữ theo cột, bộ nhớ
- Protocol Buffers: là ngôn ngữ định nghĩa cấu trúc dữ liệu trung lập với ngôn ngữ lập trình, và tùy cách triển khai mà có thể là lưu trữ theo hàng hoặc theo cột
- CSV: dựa trên văn bản và có cấu trúc rất đơn giản
- Khi lưu một dataframe Apache Arrow thành tệp trên đĩa, người ta thường dùng Feather, và cũng có thể chuyển đổi sang các định dạng khác như Parquet
- Các hệ thống như Snowflake, Redshift, Athena và Hive hỗ trợ đọc/ghi cả định dạng mở lẫn định dạng lưu trữ đóng, nhưng mức độ hỗ trợ định dạng mở có thể khác nhau tùy sản phẩm
Định dạng thực sự quy định điều gì
- Định dạng tệp là đặc tả quy định dữ liệu được sắp xếp như thế nào trong bố cục nhị phân thực tế
- Parquet mạnh về nén, còn Avro dùng cách lưu trữ theo hàng nên phù hợp hơn để đọc các khối hàng cụ thể
- Cả Parquet và Avro đều hỗ trợ tiến hóa schema, cho phép thay đổi schema của dữ liệu mới mà không cần ghi lại toàn bộ dữ liệu cũ
- Cả hai định dạng đều hỗ trợ chia nhỏ tệp, điều rất quan trọng cho xử lý dữ liệu song song
- Kho lưu trữ Apache Parquet chứa đặc tả định dạng tệp thực tế và implementation tham chiếu bằng Java
- Parquet có thể được đọc và ghi bởi nhiều ngôn ngữ và công cụ; trong Pandas, bạn cũng có thể lưu DataFrame thành tệp Parquet cục bộ bằng
to_parquet - Presto/Trino, Spark, DuckDB, Hive, Dremio, Impala, AWS Athena và Apache Drill là các ví dụ về engine có thể xử lý tệp Parquet
Quản lý dữ liệu quy mô lớn: chỉ định dạng tệp là chưa đủ
- Các định dạng tệp riêng lẻ chỉ định nghĩa bố cục của một tệp, nên chưa đủ để quản lý các tập dữ liệu lớn luôn thay đổi
- Để lưu nhiều bảng, hỗ trợ tiến hóa schema cho từng bảng, truy vấn theo thời điểm, phân vùng hiệu quả, cho công cụ bên ngoài đọc schema và lưu thống kê cho tối ưu hóa truy vấn dựa trên chi phí, cần có một tầng cao hơn
- Tầng này bao gồm table format và schema registry hoặc metastore
- Confluent Schema Registry hỗ trợ Avro và Protobuf, phù hợp hơn với dữ liệu streaming vốn có xu hướng lưu trữ theo hàng
Vị trí của Hive, Iceberg và Delta Lake
- Facebook đã công bố Hive vào năm 2009 cùng với định dạng metadata bảng riêng của mình, và sau đó Hive hỗ trợ nhiều định dạng hơn
- Netflix phát triển Iceberg để vượt qua các giới hạn về hiệu năng và khả năng mở rộng của Hive
- Databricks phát triển Delta Lake như một lựa chọn thay thế cho Iceberg và sau đó công bố mã nguồn mở
- Cả Iceberg và Delta Lake đều dùng Parquet làm định dạng tệp riêng lẻ
- Hive, Delta Lake và Iceberg đều hỗ trợ khái niệm tương ứng với schema registry hoặc metastore
- HMS (Hive MetaStore) của Hive thực tế có thể dùng gần như bất kỳ RDBMS nào
- Iceberg có Iceberg Catalogs
- Databricks có Unity Catalog
- Các catalog và metastore này cũng có thể được dùng cho data governance, chẳng hạn quản lý đội nhóm hay người dùng nào có thể truy cập bảng nào
Iceberg và Delta Lake đảm nhiệm những gì
- Delta Lake và Iceberg không phải là query engine hay storage engine, mà là đặc tả mở giúp query engine có thể hoạt động
- Cả hai giải quyết cùng một vấn đề theo những cách khác nhau, và Delta Lake có tranh cãi về tính mở vì mức độ đa dạng contributor thấp hơn Iceberg
- Hỗ trợ Iceberg đang tăng rất nhanh trong nhiều data warehouse và lakehouse như Redshift, BigQuery, Snowflake, Athena và Dremio
- Iceberg và Delta Lake cung cấp các tính năng cần thiết để vận hành bảng quy mô lớn
- phân vùng
- tiến hóa schema
- nén dữ liệu
- giao dịch ACID cho thay đổi schema
- tối ưu hóa truy vấn hiệu quả thông qua cắt tỉa cột, pushdown điều kiện và thu thập thống kê
- time travel để truy vấn theo thời điểm
- Iceberg hỗ trợ tiến hóa phân vùng, cho phép thay đổi cách phân vùng của bảng hoặc shard key mà không cần ghi lại toàn bộ dữ liệu hiện có
- Với Netflix, việc thay đổi phân vùng từng là một nỗi đau lớn và là một trong các lý do tạo ra Iceberg
Định dạng đóng và áp lực phải hỗ trợ Iceberg
- Đặc tả Iceberg đang nhanh chóng trở nên phổ biến như một định dạng được nhiều hệ thống hỗ trợ
- Các sản phẩm dùng định dạng đóng đang chịu áp lực phải vừa đạt hiệu năng cao nhất có thể với định dạng riêng, vừa hỗ trợ Iceberg hoặc Delta Lake theo một cách nào đó
- Iceberg có thể trở thành một tính năng checklist mà mọi hệ quản trị cơ sở dữ liệu rồi sẽ phải hỗ trợ
- Vì lý do hiệu năng, Iceberg có thể khó thay thế hoàn toàn các định dạng dữ liệu đóng
- Nếu phát triển định dạng dữ liệu chỉ cho một query engine duy nhất, các nhà phát triển cơ sở dữ liệu có thể khai thác hiệu quả tối đa và đổi mới nhanh hơn
Data lake và data lakehouse
- Data lake là nơi công ty lưu trữ lượng lớn dữ liệu dưới dạng tệp thô như Parquet hoặc CSV
- Data warehouse lưu dữ liệu theo cách có cấu trúc hơn, như bảng SQL có schema và schema cơ sở dữ liệu
- Data lakehouse là mô hình kết hợp data lake với các khả năng như thực thi truy vấn SQL, batch job và cấu hình data governance
- Có thể xây dựng data lakehouse trên data lake bằng cách dùng Iceberg cùng query engine và các thành phần bổ sung khác
- Trước đây, để có các khả năng này, người ta phải triển khai data warehouse hoặc DBMS truyền thống hơn
- Data lakehouse dùng các cloud blob store như HDFS hoặc S3 làm nơi lưu trữ cho toàn bộ dữ liệu, rồi tối ưu query engine để chạy nhanh trên lớp lưu trữ đó
- Databricks và Dremio là các ví dụ về sản phẩm data lakehouse
- Khi các warehouse như Snowflake và BigQuery bổ sung định dạng dữ liệu mở như Iceberg, sự phân biệt giữa data warehouse và data lakehouse càng trở nên mơ hồ hơn
2 bình luận
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.
Ý kiến trên Hacker News
Apache Iceberg và Delta Lake thường được xếp chung như các định dạng bảng mở (Open Table Format), nhưng thực tế trông khá khác nhau
Đặc tả Iceberg nằm tại https://iceberg.apache.org/spec/, và với người hiểu về hệ thống cơ sở dữ liệu thì có vẻ có thể dựa vào đó để triển khai việc tạo và truy vấn bảng Iceberg mà không gặp quá nhiều khó khăn
Trong khi đó phía Delta Lake là https://github.com/delta-io/delta/blob/master/PROTOCOL.md, nhưng rất khó ngay cả để ước lượng khối lượng công việc cần thiết nhằm triển khai đầy đủ đặc tả hiện tại, và việc theo kịp một đặc tả khổng lồ liên tục thay đổi này còn mịt mờ hơn
Thành thật mà nói, đặc tả Delta Lake đọc giống như một tài liệu reverse-engineer các thỏa hiệp triển khai phát sinh khi Databricks xây lakehouse thật nhanh cho các công ty Fortune 1000 từng bị Hadoop làm cho khốn đốn
Tôi vẫn chưa bị thuyết phục rằng việc chọn Delta Lake thực sự là bước vào một hệ sinh thái mở, và sẽ tốt nếu có cơ sở nào đó đủ làm yên tâm về điểm này
Nói thêm, lịch sử GitHub cũng không khiến người ta yên tâm: https://github.com/delta-io/delta/commits/master/PROTOCOL.md
Trông như các tính năng và sửa đổi tùy ý được đưa lên bằng PR của kỹ sư Databricks, rồi được một kỹ sư cấp cao của Databricks phê duyệt ngay lập tức
Nhưng khi làm vậy thì không thể đồng thời tuyên bố đây là một định dạng mở do cộng đồng dẫn dắt. Trừ khi đó là phiên bản kiểu Animal Farm rằng “một số bên bình đẳng hơn những bên khác”
Muốn dùng các tính năng như cột tính toán hoặc ràng buộc kiểm tra thì cũng phải hỗ trợ biểu thức Spark SQL, mà tài liệu phía đó còn sơ sài hơn
Chúng chỉ gần giống mã nguồn mở trên danh nghĩa, và tôi nghĩ không nên tin tưởng
Tôi cũng đã dùng Delta Lake, và trong thực tế có rất nhiều giới hạn gây bực bội cùng các góc cạnh sắc nhọn. Cuối cùng dự án đó bị hủy hoàn toàn, và khi đó tôi cũng đã khảo sát Iceberg
Iceberg và Hudi có bộ tính năng được thiết kế nhất quán hơn, nhưng khi ấy được hỗ trợ ít hơn; hy vọng phần này sẽ cải thiện trong tương lai
Trong 6 tháng qua, tôi có ấn tượng rằng Iceberg gặp khó khi cung cấp công cụ cho người dùng ngoài hệ sinh thái JVM, trong khi Delta đi trước. Xét ở khía cạnh đó thì Delta dễ tiếp cận hơn nhiều
Để so sánh, SQL Server triển khai tốt hơn nhiều. Các bảng lưu trữ hướng cột (columnstore indexes, tương đương Parquet/ORC bên trong engine) là bất biến, còn delta được lưu trong B-Tree để có khả năng nén, khả năng truy cập và tốc độ
Đến một thời điểm nào đó, kho cột sẽ được chống phân mảnh, hợp nhất hoặc xây dựng lại một phần hay toàn bộ, rồi B-Tree bị xóa và bắt đầu lại khi các thay đổi mới tích tụ
Làm việc này bằng JSON, nói giảm nói tránh thì cũng là dấu hiệu của một thời kỳ tệ hại
Có lẽ bất cứ thứ gì cũng tốt hơn Delta Lake, và đặc biệt Iceberg có vẻ tốt hơn
Bài viết hay. Tôi đã xử lý các file Parquet trên S3 nhiều năm, nhưng không thật sự biết Iceberg chính xác là gì; bài viết giải thích rất rõ
Iceberg là một định dạng metadata cơ sở dữ liệu mô tả schema và partitioning của tập dữ liệu nền tảng, v.v.
Phần lớn mọi người dùng quy ước partitioning của Hive như
/key3=000/key2=002/, nhưng Iceberg tốt hơn ở chỗ nó phơi bày nhiều cấu trúc hơn cho query engineTrong các DBMS truyền thống như Postgres, schema, query engine và định dạng lưu trữ được cung cấp như một gói duy nhất
Nhưng trong big data, bạn có thể lắp ráp các thành phần cơ sở dữ liệu từ đầu và trộn dùng lẫn nhau. Có thể dùng Iceberg làm định dạng metadata, DuckDB làm query engine, Parquet làm định dạng lưu trữ và S3 làm phương tiện lưu trữ
Đây là một thay đổi lớn trong thế giới cơ sở dữ liệu. Vì nhờ Delta, Iceberg, Hudi, dữ liệu thường được lưu dưới dạng định dạng mã nguồn mở trên S3
Khi phần lớn lưu trữ và xử lý được chuẩn hóa, việc di chuyển giữa các cơ sở dữ liệu sẽ dễ hơn, và gần như mọi công cụ cuối cùng đều có thể xử lý cùng một tập hợp tệp theo cách an toàn về mặt giao dịch
Ví dụ, trong khi Snowflake đang ghi vào tệp, nhà khoa học dữ liệu có thể truy vấn theo thời gian thực trong Jupyter notebook, còn ClickHouse có thể cung cấp phân tích cho người dùng trên cùng dữ liệu đó mà vẫn duy trì bảo đảm nhất quán
Sau này, nếu công ty quyết định chuyển từ Snowflake sang Databricks thì cũng không còn là chuyện quá 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 nạp dữ liệu native, nhưng do áp lực thị trường, mọi nhà cung cấp cơ sở dữ liệu sẽ buộc phải tối ưu hiệu năng và cuối cùng sẽ tiến gần đến hiệu năng của dữ liệu được nạp native
Đây là một thắng lợi lớn về tính mở, mã nguồn mở, và việc doanh nghiệp nắm giữ dữ liệu ở định dạng mở, có tính di động
Lakehouse cũng có cùng hàm ý. Nhiều công ty vừa có data lake vừa có data warehouse, rồi phải sao chép dữ liệu giữa hai bên
Việc chỉ có một hệ thống để truy vấn và quản lý cùng một tập dữ liệu cũng mang lại tác động lớn tương tự
Đây là thời điểm rất thú vị trong lĩnh vực data engineering
Trong tương lai, có thể thấy viễn cảnh khi thực thi truy vấn, ta có thể gửi kế hoạch thực thi không chỉ tới nhiều engine trên toàn đám mây mà cả tới máy cục bộ
Với Snowflake, có khi họ thà đóng cửa doanh nghiệp và trả lại hàng chục tỷ đô la cho nhà đầu tư còn hơn. Giữ dữ liệu bị khóa trong hệ sinh thái của họ chính là toàn bộ mô hình kinh doanh của họ
Tôi tò mò liệu có ví dụ tốt nào về việc tiêu chuẩn mở khiến doanh nghiệp từ bỏ công nghệ độc quyền hay không
Tôi hoàn toàn không đồng ý với câu “Cách tốt nhất để lưu Apache Arrow dataframe thành tệp trên đĩa là Feather, và cũng có thể chuyển đổi sang Apache Parquet, v.v.”
Nếu muốn tự xây một lakehouse không dựa trên JVM, cấu hình tốt nhất là dùng Iceberg làm metadata, Parquet làm dữ liệu, DuckDB làm engine truy vấn và truy vấn bằng bảng Arrow
Chi phí đọc trực tiếp Parquet thành Arrow rất thấp, sau đó có thể chuyển Arrow → Pandas hoặc Polars. Có thể chuyển trực tiếp hoặc thông qua dịch vụ dựa trên Arrow Flight
Nếu đưa Feather vào đây thì toàn bộ stack lakehouse Python hiện tại sẽ không vận hành tốt
Có thể giờ đã thay đổi, nhưng Parquet vẫn cho cảm giác là lựa chọn được chuẩn bị tốt nhất cho tương lai
Tôi từng nghe về data lake, nhưng “data lakehouse” nghe như nơi dữ liệu thượng lưu đi thuyền dữ liệu để câu cá dữ liệu vào mùa hè
Nhiều công ty lưu dữ liệu trong data lake, rồi dùng warehouse để cung cấp BI cho các công cụ như Tableau hay PowerBI. Thế là họ phải sao chép dữ liệu giữa hai bên
Data lakehouse, nơi có thể truy vấn trực tiếp lake và áp dụng giao dịch cùng governance lên một tập dữ liệu duy nhất, có thể đơn giản hóa stack rất nhiều và cũng giảm chi phí
Mỗi lần nghe hoặc đọc nó, trong đầu tôi đều thấy khá gượng gạo
Tôi đặc biệt kỳ vọng vào Iceberg. Vì nó là mã nguồn mở
Tuy nhiên, lần cuối tôi xem xét, phần triển khai chỉ là thư viện Spark, còn connector Iceberg của Trino (trước đây là Presto, một SQL engine) thì phụ thuộc rất mạnh vào Hive
Có cảm giác toàn ngành đang khó ly hôn với di sản của MapReduce, Hive, và nếu dám nói thì cả Spark nữa
Từ đó đến nay tôi chưa xem lại Iceberg, nhưng dự định sẽ sớm xem, và thật sự mong lĩnh vực này phát triển
Giờ đây chúng ta đã có công cụ và năng lực tính toán để xử lý dữ liệu mà không cần công nghệ legacy, và không phải dữ liệu nào cũng là big data
Vì vậy, may mắn là data engineering ngày càng giống phát triển backend thông thường hơn, và các thực hành phát triển bình thường cũng đang bén rễ
Hy vọng trong tương lai rất gần sẽ có một thư viện Python Iceberg thuần túy
Đã phải bỏ ra nỗ lực rất lớn để loại bỏ sự phụ thuộc đó
Databend thì tôi dựng được trong một giờ, và tôi nghĩ khi có triển khai Rust, tính di động so với Java/Hive sẽ tốt hơn, nên sau này sẽ dễ dùng nghiêm túc hơn
Tôi không hiểu vì sao không thể giải thích tất cả những điều này cụ thể hơn
Giá mà họ nói rõ dữ liệu được lưu thế nào, kết nối và truy vấn ra sao, truy vấn nhanh đến mức nào. Chẳng hạn như sự khác nhau giữa tốc độ giao dịch và tốc độ truy vấn phân tích
Hiện tại chúng tôi đang xử lý khoảng 100TB dữ liệu trên GCP, dùng BigQuery làm engine truy vấn và sử dụng kiểu phân vùng Hive đơn giản như
/key3=000/key2=002/Chúng tôi hài lòng vì có thể chạy mọi truy vấn mong muốn và chi phí cũng cực rẻ
Tuy nhiên độ trễ đang tăng khá cao, dù điều đó không quá quan trọng với chúng tôi. Dù vậy vẫn tò mò liệu việc áp dụng Iceberg có cải thiện phần này không
Muốn biết có ai có kinh nghiệm như vậy không, và nhìn chung kiến trúc kiểu này thật sự rất tuyệt
Mục đích chính của những công nghệ này là quản lý dữ liệu quy mô lớn, nhưng chúng cũng mở rộng các khả năng mà định dạng lưu trữ thô như Parquet cung cấp. Vì vậy có thể hữu ích, nhưng cần cân nhắc xem có thật sự cần không
Tôi chưa dùng BigQuery, nhưng có thể có các tính năng tương tự
Trước hết cần định nghĩa “độ trễ” đang nói ở đây là gì, và “khá cao” là ở mức nào
Kho dữ liệu phân tích được thiết kế cho xử lý theo lô hiệu quả, còn tìm một bản ghi đơn lẻ không phải mục tiêu chính của kiến trúc này. Muốn tìm kiếm nhanh thì cần caching hoặc indexing
Trong một số trường hợp, chỉ cần thêm
limit 1cho truy vấn tìm một bản ghi đơn lẻ là đã có thể giải quyếtCần kiểm tra xem có đang dùng định dạng lưu trữ dữ liệu hiệu quả như Parquet không, đồng thời kiểm tra kích thước file để xem có gặp "small file problem" không
Tiếp đó cũng cần kiểm tra xem có đang dùng các tính năng liên quan của BigQuery không. Trước và sau các bước kiểm tra này, hãy chạy
explaincho truy vấn; nếu không dùng khóa phân vùng hoặc cột chỉ mục thì trong bất kỳ hệ thống big data nào, kết quả tìm kiếm cũng sẽ không xuất hiện tức thìNếu không dùng bảng BigQuery làm đầu vào cho tính toán throughput cao, tôi sẽ tập trung vào tối ưu công cụ BI hoặc tạo bảng phân tích để tránh độ trễ cho người dùng cuối
Ví dụ gần đây chúng tôi đã materialize phép join bảng fact/dimension và phép toán
COALESCEđể tạo một bảng lớn chuyên cho phân tíchVề mặt khái niệm thì nó nằm “ngoài” cấu trúc data warehouse thông thường, nhưng vì vẫn tồn tại trong dbt nên vẫn giữ được chất lượng dữ liệu và lineage
Nhờ vậy chúng tôi loại bỏ được các phép tính cố định của Tableau và giảm khoảng 95% thời gian tải/nhóm của người dùng cuối
Nếu là truy vấn liên hợp tới GCS/S3 thì có thể nhanh hơn
Tôi thật sự thích thái độ “Bài này không bao quát 100%, và có lẽ cũng không phải điểm khởi đầu tốt nhất cho đa số mọi người. Vì đây là bài tôi viết cho chính mình. Tôi cảm thấy cách tốt nhất để học điều mới là buộc bản thân phải giải thích lại cho người khác”
Tôi cũng đã bắt đầu áp dụng cách này trên giấy và trong ghi chú trên website của mình
Tôi đã rất kỳ vọng đào sâu vào kỷ nguyên Iceberg của các kho Parquet được quản lý nhiều hơn
Nhưng hỗ trợ I/O GPU nhanh (GPUDirect/cuFile) vẫn còn tụt lại vài năm
Vì vậy mỗi lần cố đưa nó tới khách hàng cho workload AI, chúng tôi lại đụng phải bức tường đó
Cuối cùng có vẻ đây là chuyện sẽ xảy ra, và gần với câu hỏi “khi nào” hơn là “có thể không”. Sẽ thật tuyệt nếu có thể đạt được cả hai
Với lưu trữ văn bản thì Parquet ngày nay là đủ
PyTorch Data Loader và TF Data cung cấp client đa luồng đọc trước song song, lấp đầy buffer bộ nhớ rồi trao đổi với GPU
Tôi đồng ý rằng S3 có thể trở thành nút thắt ở đây. Vì vậy chúng tôi đặt HopsFS lên trên S3 như một cache NVMe nhất quán, phân tán toàn cầu
Anyscale cũng đã làm điều tương tự với cache NVMe cục bộ cho S3
Ngoài ra còn có một định dạng file thú vị là Lance, giống Parquet nhưng dành cho dữ liệu ảnh. Nó có thêm chỉ mục I/O ngẫu nhiên nhanh để tìm ảnh bên trong file