dbt là không đủ

Mặc dù là một sản phẩm đem lại một làn sóng trong ngành Data, nhưng mà mình luôn thấy dbt vẫn thiếu một chút gì đó.

Note: cứ cuối tuần mở máy lên viết thì lại lười, phải cố lên chứ nếu không còn không đủ được 1 bài 1 tháng…

---

Theo dòng sự kiện

Tầm 4-5 năm trở lại gần đây, nếu mà bạn làm trong ngành Data, dù là Analyst, Engineer hay là Scientist, thì chắc chắn đều có nghe qua về dbt. Gần như là một tool gắn liền với phong trào Analytics Engineering, kết hợp giữa Analytics với những best practices của Engineering, như là version control, D.R.Y các thứ các thứ.

Photo by Stock Birken on Unsplash

Data luôn là một ngành gắn với rất nhiều tools, nhiều tech stack, nhiều standards, nhiều SaaS được ra lò liên tục, và đặc biệt trong khoảng 10 năm gần đây. Không phải sản phẩm nào cũng được đón nhận mạnh mẽ, gây được tiếng vang, và có tầm ảnh hưởng như dbt. Cũng có nhiều ý tưởng xây dựng theo cùng hướng như dbt, trong đó có SQLMesh cũng là một cái tên khá là nổi bật.

Từ đầu năm đến giờ, nhiều động thái xảy ra trong cái domain này. Đầu tiên, với sự ra lò của dbt Fusion, viết lại cái khung của dbt (vốn được viết bằng Python và chuyển qua Rust), kèm theo những phát triển về hướng language server: những đoạn code SQL bây giờ không chỉ là templated queries, mà có thể còn được hiểu cả ngữ nghĩa, để tích hợp vào môi trường IDE một cách hoàn chỉnh hơn. Mặc dù tính năng cũng như performance tăng lên rất nhiều, dbt Fusion lại chỉ được đi kèm với bản trả phí, như một động thái hạn chế bớt sức mạnh của bản free và để có thể monetize tốt hơn.

Chỉ vài tháng sau đó, TobikoData, công ty đứng đằng sau SQLMesh, bất ngờ thông báo được mua lại bởi Fivetran, một ông lớn về data integration/data movement, chuyên về xây dựng các connector và mang dữ liệu qua lại các hệ thống thông tin. Và trong tháng 10 này, Fivetran và dbt Labs đã thông báo sát nhập, và thế là 2 đối thủ lâu năm như SQLMesh và dbt lại quy chung về một mối.

Thời gian từ lúc sát nhập vẫn còn rất ngắn và vẫn chưa thấy các bước đi tiếp theo, tuy nhiên, cũng dẫn đến nhiều người lo ngại về tương lai của dbt, liệu nó có còn tiếp tục được giữ là một sản phẩm open source hay không, hay là các công ty sẽ đẩy mạnh hơn về mặt monetization, và đầu tư nhiều hơn cho các sản phẩm enterprise.

Là một sản phẩm có tầm ảnh hưởng, và cũng là cần câu cơm cho rất nhiều người trong ngành Data. Ai mới tiếp cận với data trong thời gian gần đây, chắc đều phải hiểu qua dbt nó hoạt động thế nào, cũng như áp dụng trong công việc hàng ngày. Về phương diện kinh tế, chưa biết quá trình tiếp theo sẽ thế nào, nhưng chắc chúng ta cũng chỉ có thể ngồi chờ xem chuyện gì sẽ xảy ra trong những tháng tới.

dbt, thích và không thích

Để nói về bản thân mình, mình đã có trải qua kinh nghiệm làm việc từ trước thời của dbt. Từ lúc dbt và analytics engineering nổi lên, mình cũng khá hứng thú với những sự phát triển của sản phẩm này, và cũng có theo dõi sát sao với nó trong những năm gần đây. Với gốc gác là Engineering của mình, đương nhiên sẽ rất hứng thú với những gì dbt mang lại, vì nó kết hợp giữa Analytics và Engineering, và nếu mọi người có trải qua giai đoạn trước đó, thì chắc có thể sẽ hiểu sự lộn xộn trong quá trình Data Transformation, khi mà không có một quy chuẩn làm việc nghiêm ngặt nào. Các đoạn code lộn xộn không đầu đũa, các transformation logic mỗi nơi 1 kiểu, không có sự kết nối giữa các datasets. Nên đương nhiên, mình rất thích những gì mà dbt mang lại.

Ở một chiều hướng khác, khi sử dụng dbt đủ lâu, thì mình cũng sẽ thấy có những điểm làm mình không thích ở dbt. Cùng với Analytics Engineering, đó là một tư duy khác về quản lý và xây dựng hệ thống dữ liệu; tuy nhiên, cái framework này lại chưa đủ chặt chẽ, chưa đủ bao quát, nên sẽ có những điểm hạn chế nhất định. Cảm nhận của mình và dbt, đó là một sản phẩm chưa đủ: nó làm rất tốt việc của nó, nhưng không bao giờ bao quát hết được hoàn toàn.

Note: mình viết đoạn này thì sẽ assume là mọi người đã có kiến thức sơ bộ về cách thức vận hành của dbt và các thứ ETL căn bản.

Transformation Logic

Một điểm dbt làm rất tốt, đó là vẽ ra được sự liên kết giữa các data model, làm sao để xây dựng được cái bước transformation để xây dựng model đích này từ các models trước. Transformation logic được codified, để dễ quản lý, cũng như làm một ngôn ngữ chung để tất cả mọi người đều có thể hiểu được. Nó cũng giúp vẽ ra một bức tranh tổng thể về data và column lineage, giúp việc quản lý data platform trở nên dễ dàng hơn.

Tuy nhiên, khi cái transformation logic nó vượt qua khả năng diễn tả của SQL, thì mọi thứ trở nên rắc rối hơn, đặc biệt khi bạn phải làm nhiều hơn thiên về lĩnh vực của Data Science, như là model training hoặc là feature engineering. Khi transformation của bạn là một thuật toán, hoặc là qua nhiều bước probabilistic transformation, thì khó có thể “diễn giải” nó bằng cái ngôn ngữ của dbt.

Khi hệ thống của bạn bắt đầu tiếp cận các transformation phức tạp, dbt sẽ là không đủ.

Nghịch lý từ Macros

Một trong những thứ hay ho nhất, mà những người có gốc từ Engineering nghe thấy sẽ rất hứng thú, đó là dbt Macros. Ai chả muốn làm D.R.Y., viết code dùng đi dùng lại nhiều lần. Thay vì phải viết code đó nhiều lần, bạn có thể thay thế bằng 1 đoạn macro, và bạn có thể tái sử dụng lại logic trong code của bạn.

Tuy nhiên, một trong những điểm mạnh nhất của SQL, đó là transformation logic của bạn được hoàn toàn thể hiện một cách declarative, để bạn có thể nắm bắt logic từ đầu đến cuối chỉ tại một nơi. Nhưng, để tiết kiệm thời gian và công sức với macros, bạn lại tìm cách tái sử dụng một đoạn code, và sau đó phần declarative logic của bạn sẽ bị phân tán giữa SQL code và Macro code của bạn — giả dụ như bạn viết một đoạn logic rẽ nhánh ở trong code macros của bạn, nó có thể dẫn đến việc làm code của bạn nó không còn mang tính declarative nữa, và rất khó debug. Mặc dù bạn tiết kiệm được chút code, nhưng mà logic của bạn sẽ dễ bị convoluted hơn. Đây là một điểm vừa mạnh cũng như vừa dễ có thể trở thành footgun trong một dbt stack, dễ giúp mình bắn vào chân nếu không cẩn thận.

Ngoài ra, cũng có nhiều người dùng macros như là một cách để simplify một số tác vụ, ví dụ như là viết ETL log sau mỗi transformation steps, hoặc là update các thông tin metadata. Đây thực ra lại là một possible dark pattern của system design: Khi bạn chạy SQL code, đó là bạn thực hiện thay đổi ở Data layer; tuy nhiên, việc viết transformation log hoặc là update metadata lại là một việc của Management/Coordination Layer. Nếu mà bạn có một tầng coordination layer ở phía ngoài, ví dụ như Airflow DAGs hay gì đó, thì đang có một sự giẫm chân nhau của hai system.

Với mình, macros mặc dù là một thứ rất mạnh, nhưng mà rất dễ dẫn đến dùng sai.

Data Pipelines

Một điểm quan trọng khi nói đến dbt, đó là vấn đề xây dựng data pipelines. Thực ra, để nói đến xây dựng data pipelines, thì mình luôn tính nó là 2 steps tách biệt. Đầu tiên, bạn phải xây dựng transformation logic, ở đây chính là dbt SQL của bạn. Sau đó, phần thứ 2 sẽ là xây dựng data pipelines: lập lịch, thiết lập dependencies, các cấu trúc về retries, SLAs, vân vân và mây mây.

Các mechanism này, nó lại chỉ được xử lý 1 phần bởi dbt; thế nên, dbt lúc nào cũng phải được đi kèm và kết nối cùng với một hệ thống khác để thiết kế pipelines: dbt Cloud có sẵn việc lập lịch, còn nếu không thì sẽ phải tích hợp với Airflow hay gì đó. Và khi đó, bạn sẽ phải bị giằng xé giữa những khái niệm của các hệ thống khác nhau.

Một ví dụ đơn giản, Airflow có thể thiết kế 1 backfill run cho 1 daily DAG, bằng việc chạy lại tất cả các run của DAG đó trong khoảng thời gian cần backfill. Tuy nhiên, nếu việc xây dựng dbt model của bạn lại bằng việc lấy incremental data cho mỗi lần chạy, thì backfill lại chỉ là chạy lại dbt job đó bằng đúng khoảng thời gian cần backfill, và nó sẽ không tích hợp một cách gọn gàng với Airflow job. Còn nếu muốn tích hợp cùng với cấu trúc của Airflow DAG, thì dbt model của bạn lại phải nhận thêm biến là processing time từ phía bên ngoài, và như thế lại có thể giẫm chân lên cấu trúc của một incremental materialization.

Thế nên, dbt vẫn sẽ gây cho bạn một cảm giác thiếu thiếu, khi bạn vẫn phải xây dựng dựa vào cấu trúc của orchestration layer/data pipelines phía bên ngoài, và sẽ có dẫn đến những design conflicts.

Nắm giữ data

Để quay lại câu chuyện M&A đã viết ở đầu. Mình nghĩ một điểm yếu từ dbt, đó là nó không thể là một sản phẩm đầy đủ — lúc nào sản phẩm cũng sẽ phải đi kèm với 1-2 thứ khác, để làm nốt phần việc của nó, trong việc xây dựng một hệ thống data transformation hoàn chỉnh. Và data transformation, sẽ không bao giờ có thể có một quy chuẩn hoàn chỉnh cho nó cả, vì đơn giản việc sử dụng data nó muôn màu muôn vẻ — không có một cấu trúc nào có thể mô tả và giới hạn hết cách con người muốn sử dụng dữ liệu.

Những ông lớn mạnh nhất về data, Databricks, Snowflake, họ đều mở rộng về cách lưu trữ và xử lý data: nó phải đi càng gần với code hơn, để con người có thể viết Python, thêm library, chạy notebook vân vân và mây mây. Và khi bạn đã onboard vào trong Unity Catalog hoặc là data của bạn đã được load vào Snowflake, mọi thứ trở nên dễ dàng hơn rất nhiều: bạn có thể dùng scheduler của bạn, dùng dbt hay là tự viết sql, miễn là data catalog của bạn nằm ở trong đó. Và khi catalog của bạn nằm với họ, thì sẽ rất khó để bạn có thể thoát ra trở lại hệ thống riêng của mình; bởi vì nó quá là tiện lợi.

Vậy nên với mình, dbt/fivetran sẽ rất khó cạnh tranh với các ông lớn. Bởi vì, thứ mà để giữ chân mọi người lâu nhất, đó là Data và Data Catalog. Còn data transformation, it will come and go.

Chưa biết tương lai thì câu chuyện sẽ đi tiếp thế nào, nhưng hôm nay thì mình biết được đến đó.