Iceberg v3, chỉ còn một Lakehouse
Databricks đã ra thông cáo báo chí về phiên bản mới của Iceberg v3, kết hợp thêm một vài tính năng mới. Mình xin đưa một chút nhận định về tương lai của Lakehouse.
Note: mình vẫn đi tìm kiếm các bạn Lead-level Data Engineer với hơn 5 năm kinh nghiệm nhé. Có thể đọc qua ở đây và contact mình qua LinkedIn nhé.
Iceberg v3, đưa Lakehouse về cùng một mối
Viết về mấy thứ Technical của Data Engineering, thì mình cũng thấy có được một chút đón nhận. Nếu vậy thì mình cũng tranh thủ xin phép chia sẻ thêm một chút về những thứ mới có.
Trong tuần này, Databricks đã ra thông báo về phiên bản Iceberg v31. Với nhiều cải thiện về tính năng và chức năng, phiên bản mới này của Iceberg là một bước tiến mới của Databricks, và có vẻ hướng mà họ đang nhắm đến đó là dọn dẹp lại cái big data ecosystem mà họ đang quản lý. Đó là những bước tiến về cải thiện hỗ trợ các tính năng của SQL cũng như tệp dữ liêu. Đó là việc kết hợp những tính năng tốt đẹp của Delta và Iceberg để xây dựng ra tiêu chuẩn chung. Và những bước tiến tiếp theo để củng cố vững chắc hệ sinh thái mà họ đã và đang xây dựng.
Để kể một chút về lịch sử, thì gốc gác của những người sáng lập Databricks, đó là những người đã viết lên Apache Spark. Spark được ra đời làm thay đổi cả hệ thống xử lý big data, và với việc là những con người đóng góp chính vào việc phát triển các tính năng của Spark, team Databricks luôn luôn đóng vai trò là những người tiên phong trong xử lý Big Data.
Không chỉ muốn dừng lại là những người cầm trịch của Spark, họ còn có tham vọng nắm giữ cả hệ sinh thái Big Data, bằng việc phát triển thêm các tính năng về tầng Data Layer, về cách thức dữ liệu được lưu trữ, để thay đổi những gì đã được thiết lập ra từ hệ sinh thái của Hive/MapReduce. Delta Table format, đi cùng với khái niệm Lakehouse, được phát triển từ team Databricks, như một bước tiến mới về cách dữ liệu được lưu trữ và xử lý, với tham vọng đạt được những tính năng của Data Warehouse ở trong hệ thống Big Data, đó là ACID-compliant.
Cùng với thời đó, Iceberg cũng được sáng tạo ra, từ các Engineer từ Netflix; Iceberg nhanh chóng được donate cho Apache Software Foundation và từ đó được phát triển và sử dụng rộng rãi bởi các công ty với dữ liệu rất rất lớn, như Apple, Netflix, LinkedIn. Các nhà sáng lập Iceberg lập ra một công ty về quản lý dữ liệu, tên là Tabular.
Giữa sự cạnh tranh của Databricks Delta và Apache Iceberg, đã có hẳn hai nhánh về phát triển môi trường Lakehouse. Mặc dù ý tưởng về Table Format với Manifest files đều tương tự nhau, nhưng mà dần dần có sự khác biệt về mặt phát triển giữa hai phía. Databricks và platform của họ vẫn tiếp tục hỗ trợ Iceberg vì Iceberg rất được ủng hộ, nhưng về mặt quản trị thì tích hợp thì họ gần như phải làm việc gấp nhiều lần. Để rồi, đến năm 2024, thì Databricks đã mua lại cả công ty Tabular2, với lời hứa sẽ tiếp tục phát triển hệ thống Open Source, cũng như xây dựng một hệ thống lưu trữ dữ liệu mà có thể kết hợp được các tiêu chuẩn khác biệt với nhau (interoperability).
Và với Iceberg v3, đây có vẻ là bước tiến rõ ràng đầu tiên để Databricks đi theo hướng đi này, và để họ có khả năng là công ty đi đầu và dẫn dắt các quy chuẩn về Big Data.
Iceberg v3 có gì mới?
Trong thông cáo báo chí của Databricks, thì họ có liệt kê ra 4 điểm chính:
Deletion Vectors
Row Lineage
Semi-Structured Data and Geospatial Types
Interoperability across Delta Lake, Apache Parquet, and Apache Spark
Mình có thể đi qua nhanh về những thay đổi này.
Deletion Vectors, có thể hiểu là một cách sử dụng manifest file một cách thông minh để tăng hiệu năng xử lý. Ví dụ bạn có 1M records, nhưng mà bạn muốn xoá đi chỉ 10 records trong đó trong một lần thêm dữ liệu.
Thời đầu tiên, một file mới với (1M-10) records sẽ được viết và thay thế cho file cũ.
Deletion files: thay vì viết lại toàn bộ các records, một file mới sẽ được viết lên, lưu lại thông tin là 10 records này đã được soft-deleted và sẽ ko được compute engine xử lý.
Deletion Vectors: khi bạn có nhiều bước thêm sửa xoá, số lượng delete files sẽ ngày càng tăng lên, và compute engine sẽ phải đọc rất nhiều file manifest. Deletion vectors được lưu lại với định dạng mới chỉ bao gồm 1 file, và sẽ lưu toàn bộ thông tin về các records đã được soft-delete → tối ưu về việc xử lý metadata lên nhiều lần.
Row Lineage, là một feature đã có từ trước cùng với Delta, và bây giờ được kết hợp với Iceberg. Mục đích của nó là cho mỗi một row trong record một cái identifier, để biết được là row này đã được xuất hiện từ version nào, snapshot nào, và được thay đổi từ lúc nào. Việc lưu giữ các thông tin về version history của Row giúp cho hệ thống compute engine có thể thông minh hơn trong việc xử lý dữ liệu. Ví dụ cho các cách xây materialization mà đi theo hướng incremental, engine có thể thông minh và chỉ lựa chọn các record mới được thay đổi để xử lý thêm, và không cần động vào các record cũ.
Thêm semi-structured Data (VARIANT) là một hướng đi cũng tương tự với thông báo trước đó về Spark 4.0.0, để mở rộng việc lưu trữ và xử lý dữ liệu semi-structured. Cùng với định dạng Geospatial, điều này cũng đồng nghĩa với việc Engine sắp tới có thể sẽ bổ sung thêm các tính năng về Geospatial Computation/Query. Đây đi cùng với hướng đi của Databricks, đó là mở rộng sự tương thích với ANSI SQL, và đầu tư hơn cho các tính năng SQL-based.
Và đương nhiên, việc Interoperability với Delta/Parquet mình cũng có nhắc đến ở trên, đi cùng với các update về Spark 4.0.0 kỳ trước, đây có vẻ là bước tiến tiếp theo của Databricks, để đẩy mạnh sự phát triển trong hệ sinh thái Spark.
Hướng đi nào cho tương lai
Về mặt lưu trữ dữ liệu, mình nghĩ đó là một sự chấp nhận của Databricks, đó là Delta sẽ không thể phát triển được như Iceberg. Mặc dù họ cũng nắm giữ Delta khá lâu, nhưng động thái của thế giới Big Data gần đây luôn ủng hộ sự phát triển của Iceberg. Từ việc AWS mở rộng việc tạo S3 Data bucket lưu trữ thẳng dưới dạng Iceberg, cho đến việc mua lại Tabular và đẩy mạnh sự tương thích của hệ sinh thái Big Data và Iceberg; mình nhận định là Iceberg sẽ là chủ lực của hệ sinh thái Lakehouse và sẽ có thêm nhiều tính năng được bổ sung thêm cho Iceberg trong thời gian mới.
Về Iceberg (và cả Spark nữa), mình thấy có một sự đẩy mạnh cho các tính năng cần thiết của Data Warehouse. Không chỉ là ACID-compliant nữa, mà các tiến bộ mới cũng khá đều đi theo các xu hướng tiếp theo mà các team Big Data đang đẩy mạnh: (1) tương thích với các tính năng của ANSI SQL → SQL sẽ là ngôn ngữ chung của data, và mọi người thay vì phải lựa chọn các phương thức xử lý khác nhau, thì sẽ quay lại về 1 nguồn là SQL, (2) các row-level functions.
Các row-level function, đặc biệt là các ảnh hưởng dẫn đến thay đổi 1-2 records, vốn luôn là trở ngại và là sự phân tách giữa hệ thống OLAP và OLTP. Việc support các tính năng để cải thiện xử lý cho các write nhỏ như thế này, đó sẽ là xu hướng/ước mơ tiếp theo của các anh em xử lý dữ liệu: Unify Batch/Streaming Interface: Batch để xử lý nhiều dữ liệu, và Stream xử lý Event-based và near realtime.
Nói chung, có nhiều thứ khá exciting đang diễn ra trong môi trường Big Data. Một năm mới nhiều thứ để hóng!
https://www.databricks.com/blog/apache-icebergtm-v3-moving-ecosystem-towards-unification
https://www.databricks.com/company/newsroom/press-releases/databricks-agrees-acquire-tabular-company-founded-original-creators
Hóng anh viết thêm về Ducklake ạ!
Bài viết hay đó sếp