Spark 4.0.0, dbt fusion và Ducklake
Tự dưng mấy hôm nay có nhiều thứ về Data để đọc nên thử tóm tắt suy nghĩ một chút
Quay đi quay lại với Big Data
Thường thì mình viết nhiều mấy cái trải nghiệm lung tung hơn, nhưng mà dạo này cũng đọc lại nhiều thứ về Big Data. Đợt này một số bên mà mình theo dõi thì đều có thêm những tính năng mới được ra lò, và cũng mang lại nhiều thứ khác biệt mới. Cũng là cơ duyên thôi, nhưng cũng là một cơ hội để mình đọc qua lại những kiến thức mà mình cũng có bỏ ngang qua trong một thời gian.
Mình cũng bắt đầu với Big Data qua Spark, thử nghiệm và chạy project dbt đúng cùng thời dbt bùng nổ và trở thành thứ không thể thiếu trong môi trường data trong doanh nghiệp, và DuckDB cũng có những design philosophy khá là thú vị mà làm mình cũng khá hóng và theo dõi xem họ đang làm gì, bước đi tiếp thế nào. Cùng trong 1 tuần, mà có 3 cái announcement lớn:
Bắt đầu là dbt và Ducklake, một Table Format mới, với những hứa hẹn là bài giải cho những vấn đề còn tồn đọng với Iceberg. (https://duckdb.org/2025/05/27/ducklake.html)
Spark ra bản 4.0.0 release. Đã có bản preview một thời gian rồi, nhưng hôm nay là chính thức ra bản chính (https://spark.apache.org/releases/spark-release-4-0-0.html)
dbt announce về dbt-fusion, gần như là bản mới của dbt. Thay cho core cũ chạy trên Python, và đổi thành rust, tuy nhiên mới chỉ có tích hợp của Snowflake mà chưa ra đầy đủ. (https://docs.getdbt.com/blog/dbt-fusion-engine)
Đây có lẽ là 3 trong những sản phẩm có ảnh hướng nhất đến xu hướng của Data Engineering cũng như Big Data hiện giờ; vừa là về độ phổ biến cũng như độ ảnh hưởng. Tự nhiên làm mình cũng muốn đọc qua và bàn luận về nó một xíu
Thay đổi mà không thay đổi
Đầu tiên phải nói về Ducklake. Khi tầm 2021, khái niệm Lakehouse bắt đầu được ra đời và đẩy mạnh bởi sức mạnh từ Databricks. Cùng với Hudi sẵn có từ Uber (với câu chuyện Unified Batch and Streaming computation), thì hai sản phẩm nổi trội cho nhu cầu của Lakehouse được ra đời và cạnh tranh với nhau, Delta Lake và Iceberg.
Là một bước tiến từ Hive Metastore, khi thông tin của một Dataset (hoặc là Table) bị chia làm hai phần: một là các file dữ liệu, và phần còn lại là các thông tin Metadata được lưu trong Metastore DB. Các table này có một vấn đề là nó không portable: bạn có thể copy hết các file dữ liệu, nhưng mà không có thông tin ở trong Metadata DB thì bạn sẽ không ghép nó lại thành một bộ dữ liệu hoàn chỉnh được. Delta và Iceberg được tạo ra là các format mới, với việc sử dụng các file log để lưu lại các bước biến chuyển của tệp dữ liệu, lưu lại dưới định dạng file (AVRO hoặc Parquet). Định dạng này có một điểm tối ưu đó là bạn có thể copy cả dataset đi cùng với nhau, và khi vẫn có đầy đủ thông tin transaction logs từ metadata files, thì mang đi đâu bạn cũng vẫn dùng nó được (portability).
Ducklake thì vừa là một lùi vừa là một bước tiến. Các dữ liệu metadata để support cho nhu cầu của Lakehouse, bây giờ lại được ghi lại vào database. Metadata layer bây giờ không còn đi cùng với dataset nữa mà nằm cùng với Metadata DB của DuckDB, và nó lại quay lại hơi tương tự như cách thiết kế của một Database(hoặc Data Warehouse truyền thống): như information_schema của mysql, hoặc Hive metastore. Nó giải được vấn đề của Lakehouse table format, đó là có quá nhiều file nhỏ được lưu rải rác để xây lại transaction history, bằng cách là sử dụng một thiết kế hơi cũ hơn.
Mình chưa comment gì về vấn đề này, vì mình thấy cách thiết kế của DuckLake và của Iceberg đều có những điểm hay ho khác nhau. Có lẽ cần thêm sử dụng thực tế để hiểu hơn về nó.
dbt fusion, thì có lẽ là release đơn giản và dễ hiểu hơn. Giữ nguyên cái logic và workflow của dbt cũ, tuy nhiên cái engine đằng sau được viết lại bằng Rust. Nhìn một cách đơn giản, nó là một cái “rewrite it in Rust” meme. Tuy nhiên, bổ sung thêm vào tốc độ xử lý nhanh hơn nhiều lần của Rust (so với Python), thì lần viết lại này đã xây dựng một hệ thống dbt với độ chuẩn mực và extensible hơn, với built in compiler, để hiểu semantic của các đoạn SQL, xây như một cái language server để kết hợp với IDE. Mình nghĩ đây là một bước chuẩn bị của dbt, để có thể mở rộng tính năng của họ từ phía trong nhiều hơn. Đương nhiên, chỉ cần chạy dbt run mà nhanh hơn được mấy giây là vui lắm rồi; nhưng chắc là cũng cần một thời gian kha khá để các integration/adapter được update dần.
Spark 4.0.0, thì mình thấy là một bước đẩy mạnh cho Spark Connect. Có vẻ là nhiều thứ được tách biệt trong Spark Core, để mở đường cho Spark Connect phát triển hơn, tách biệt giữa server và client của Spark ra làm 2 phần. Điều này sẽ giúp các bên có thể phát triển thêm được các lightweight client để làm việc cùng Spark, mà không cần nguyên cả Spark library để nó có thể chạy nữa. Ngoài ra, rất nhiều tính năng để tăng performance đã được bổ sung, cũng như thêm nhiều tích hợp cho các SQL syntax, cũng như data collation. Một bước đẩy mạnh, cũng như là chính thức dồn công sức vào SQL interface. Thay cho những Interface ngày xưa như Dataframe/Dataset, bây giờ việc mở rộng SQL Interface có vẻ đang là một thứ khá được chú trọng. Ngoài ra, cũng có thêm khá nhiều improvement về mặt Stream Processing cũng được bổ sung. Mình không dám comment quá nhiều về vấn đề này, do chưa đủ hiểu kỹ càng… chắc để bao giờ luyện công thêm một chút thì mình sẽ comment thêm.
Một số nhận định
Một hướng chung mình có thể nhận thấy, đó là mọi người đều có hướng đến là dùng SQL là ngôn ngữ của Data, là giao diện mà nhiều bên cần phải đầu tư. Khác với thời đại tầm 2020 khi mỗi bên đều đầu tư vào cách lưu trữ dữ liệu, partition, index khác nhau, cùng với những query pattern đa dạng; bây giờ có vẻ xu thế đó là giải quyết vấn đề hiệu quả bằng những thứ truyền thống chất lượng, đó là interact với dữ liệu bằng SQL vẫn là chuẩn nhất. SQL là thứ đi xuyên suốt cả hành trình data, và kỹ năng SQL có thể đi qua các hệ thống từ DB, Cloud Data Warehouse hay là các Data Processing Engine thì cái nào cũng chạy được. Data Engineering, cuối cùng quay lại về gốc là phải giỏi SQL.
Thin client của Spark sẽ là một bước tiến khá là thú vị, đặc biệt là nếu thin client làm việc với dbt (như SQL) hoặc là các notebook hiện tại. Giảm khá nhiều độ phức tạp trong việc thiết lập hệ thống, vì có sự tách biệt giữa bên cần viết logic (client) và bên xử lý. Mình nghĩ đây có thể sẽ giúp cho hệ thống ETL trở nên gọn ghẽ hơn nhiều; ví dụ như airflow worker của bạn không cần Spark mà chỉ cần có spark-client để nối vào hệ thống data processing, thế sẽ giảm nhẹ đi nhiều về phần maintenance.
Ngoài ra, có vẻ Rust đang được trở nên yêu thích hơn với anh em làm Data. Hiệu năng thì cao, và cũng chặt chẽ trong việc code so với Python. Các dự án như Arrow cũng khá thú vị, và cũng sẽ tăng cường và đẩy mạnh tầm ảnh hưởng của Rust lên Big Data Ecosystem.
Chắc sắp tới mình cũng sẽ phải đụng đến Big Data nhiều hơn. Những thay đổi này làm mình cũng thấy khá là hứng thú rùi đó.
Ten kiu Sir