Tôi đã nghĩ tải dữ liệu là đích đến. Hóa ra đó mới là điểm khởi đầu.

Kỹ thuật dữ liệu Tôi đã nghĩ rằng việc tải dữ liệu là điểm kết thúc. Hóa ra đó lại là điểm khởi đầu. Xây dựng các mô hình dbt đầu tiên của tôi và tìm hiểu ý nghĩa thực sự của dữ liệu "sẵn sàng để phân tích". Ibrahim Salami Ngày 9/8/2026 11 phút đọc Sơ đồ kiến trúc được tạo bởi Gemini AI Khi bắt đầu hành trình này, tôi đã đặt ra lộ trình 12 tháng để chuyển từ nhà phân tích dữ liệu sang kỹ sư dữ liệu. Tôi mới thực hiện được khoảng hai tháng. Trong khoảng thời gian ngắn ngủi đó, tôi đã xây dựng hai đường ống ETL từ đầu, đường ống đầu tiên kéo dữ liệu kho lưu trữ GitHub vào SQLite, đường ống thứ hai kéo các bài viết RSS vào PostgreSQL với Docker và Kestra xử lý việc điều phối. Tôi đã viết về việc lên lịch cho đường ống thứ hai chạy tự động mỗi giờ, và vào thời điểm đó, đó là một cột mốc thực sự. Dữ liệu tự động chảy vào, không cần chạy thủ công, không cần tôi phải nhớ kích hoạt bất cứ điều gì. Nhưng ở đâu đó giữa việc viết bài báo đó và bắt đầu bài này, tôi đã chạy một truy vấn trên dữ liệu của mình và nhận ra điều gì đó. Tôi không thể sắp xếp các bài viết của mình theo ngày một cách chính xác. Tôi không thể biết blog nào đang xuất bản nhiều nhất. Dữ liệu đã nằm trong Postgres trong nhiều tuần, về mặt kỹ thuật là "đã tải", và tôi chưa thực sự xem xét kỹ lưỡng cho đến khi tôi cần nó cho một việc gì đó. Hóa ra tôi đã xây dựng hai đường ống và bỏ qua phần làm cho dữ liệu hữu ích. Trích xuất, tải, và sau đó không có gì. Không chuyển đổi, không mô hình hóa, không có cấu trúc thực sự nào ngoài "nó hiện đang nằm trong một bảng". Bài viết này nói về việc khắc phục điều đó. Cuối cùng tôi đã ngồi xuống và học dbt, và trong quá trình đó đã học được ý nghĩa thực sự của "sẵn sàng để phân tích", bởi vì hóa ra việc tải dữ liệu và có dữ liệu có thể sử dụng được là hai điều rất khác nhau. Dữ liệu đã được tải. Nó chỉ không thể sử dụng được. Đây là những gì bảng bài viết của tôi thực sự trông như thế nào khi tôi dừng lại và chú ý đến nó. Bản thân lược đồ rất đơn giản, thành thật mà nói là đơn giản nhất có thể: CREATE TABLE IF NOT EXISTS articles ( id TEXT PRIMARY KEY, title TEXT NOT NULL, link TEXT NOT NULL, summary TEXT, published TEXT ); Hãy chú ý đến cột cuối cùng đó. published là một trường TEXT. Không phải dấu thời gian, không phải ngày, chỉ là một chuỗi văn bản đơn giản trông giống như một ngày nếu bạn nhìn kỹ. Khi tôi truy vấn mười bài viết gần đây nhất, đây là những gì trả về: title | published ----------------------------------------------------------+--------------------------------- Django Weblog: Last Call 2026 Django Developer Survey | Wed, 08 Jul 2026 19:31:21 +0000 Mike Driscoll: New Book Release: Python Typing | Wed, 08 Jul 2026 18:46:18 +0000 Điều đó trông ổn ở cái nhìn đầu tiên. Nó dễ đọc. Nhưng hãy thử thực sự làm bất cứ điều gì với nó. Bạn muốn các bài viết từ 7 ngày qua? Bạn không thể lọc theo đó mà không chuyển đổi nó trước, mỗi lần, trong mỗi truy vấn. Bạn muốn sắp xếp theo thứ tự thời gian và tin tưởng vào thứ tự đó? Sắp xếp văn bản và sắp xếp ngày không giống nhau, và tùy thuộc vào định dạng, chúng có thể âm thầm không khớp với nhau. Sau đó là vấn đề thứ hai, vấn đề mà tôi gần như bỏ lỡ hoàn toàn vì nó ẩn mình ngay trước mắt. Hãy nhìn lại những tiêu đề đó: Django Weblog: Last Call 2026 Django Developer Survey Mike Driscoll: New Book Release: Python Typing Mọi tiêu đề trong nguồn cấp dữ liệu này đều tuân theo một cấu trúc: Tên tác giả hoặc blog, dấu hai chấm, sau đó là tiêu đề thực tế. Đây là thông tin có cấu trúc, nằm trong một trường văn bản duy nhất, hoàn toàn không thể sử dụng để lọc hoặc nhóm. Tôi không thể trả lời một câu hỏi đơn giản như "blog nào đăng bài nhiều nhất trên Planet Python" vì thông tin đó không phải là một cột. Nó chỉ là văn bản, bị chôn vùi. Đó là tình trạng thực tế của mọi thứ. Hai đường ống đã được xây dựng, dữ liệu đang chảy vào đúng lịch trình, nhưng tôi vẫn không thể trả lời các câu hỏi cơ bản về dữ liệu của mình. Việc tải dữ liệu chưa bao giờ là đích đến. Tôi chỉ chưa đến được điểm xuất phát. Tại sao lại là dbt, cụ thể Bản năng đầu tiên của tôi là khắc phục điều này bằng Python, vì đó là công cụ tôi đã tin tưởng. Viết một tập lệnh đọc từ các bài viết, phân tích ngày tháng, tách tiêu đề, ghi kết quả vào các cột mới hoặc một bảng mới. Và điều đó về mặt kỹ thuật sẽ hoạt động. Nhưng càng nghĩ về nó, tôi càng cảm thấy như đang vá cùng một lỗ hổng mà tôi đã đào hai lần. Cả hai đường ống của tôi đều là trích xuất và tải, chấm hết, và nếu tôi lại gắn logic chuyển đổi vào một tập lệnh Python, tôi sẽ chỉ thêm một bước thứ ba chưa được kiểm tra, chưa được ghi lại vào một hệ thống đã có hai bước. Tôi sẽ không học được điều gì mới. Tôi sẽ chỉ viết thêm những thứ tương tự mà tôi đã biết cách viết. dbt thực hiện điều này khác biệt, và sự khác biệt đó là toàn bộ mục đích của công cụ. Thay vì một tập lệnh chạy một lần và tạo ra một số đầu ra mà bạn phải tin tưởng một cách mù quáng, các mô hình dbt là SQL được kiểm soát phiên bản, kiểm thử và ghi lại như một phần của cùng một quy trình làm việc. Bạn viết một phép biến đổi, và trong cùng một dự án, bạn có thể khẳng định những điều về nó: cột này không bao giờ được rỗng, ID này phải luôn là duy nhất. Nếu những giả định đó bị phá vỡ, bạn sẽ phát hiện ra ngay lập tức, chứ không phải ba tuần sau khi một biểu đồ trông sai và bạn không biết tại sao. Nó cũng phù hợp với cách ngành công nghiệp thực sự hoạt động. Mọi bài đăng tuyển dụng kỹ sư dữ liệu mà tôi đã xem trong hai tháng qua đều đề cập đến dbt, hoặc một công cụ tương tự dbt. Việc học nó không chỉ là để khắc phục dữ liệu RSS của tôi, mà còn là để học công cụ đã trở thành cách mặc định mà các nhóm xử lý chữ "T" trong ETL. Vì vậy, thay vì một tập lệnh Python khác, tôi quyết định thực sự ngồi xuống và học dbt một cách đúng đắn, trên dữ liệu tôi đã có, với những vấn đề tôi đã hiểu. Đây là cách mọi việc diễn ra. Thiết lập (và ngay lập tức gặp trở ngại) Việc cài đặt dbt lẽ ra phải là phần nhàm chán. Nhưng không phải vậy. Tôi đã thử `pip install dbt-postgres` và nhận được một loạt các lỗi giải quyết phụ thuộc.