Data Engineer từng được mô tả khá đơn giản là người xây dựng các pipeline để đưa dữ liệu từ nơi này sang nơi khác. Định nghĩa đó không sai, nhưng nếu bước vào năm 2027 với cách hiểu như vậy thì chúng ta đang nhìn một ngành nghề rất lớn qua một ô cửa quá nhỏ.

Một doanh nghiệp hiện đại có thể sở hữu hàng chục, thậm chí hàng trăm hệ thống tạo dữ liệu mỗi ngày. Dữ liệu đến từ website, ứng dụng, ERP, CRM, POS, thương mại điện tử, quảng cáo, tổng đài, thiết bị IoT, hệ thống tài chính, Excel, Google Sheets, API của đối tác và rất nhiều phần mềm nội bộ khác.

Vấn đề không còn đơn giản là "lấy dữ liệu về".

Doanh nghiệp phải biết dữ liệu nào là đúng, dữ liệu nào mới nhất, các hệ thống đang nói về cùng một khách hàng hay những khách hàng khác nhau, con số doanh thu giữa Finance và Sales tại sao không giống nhau, một thay đổi trong source database có làm hỏng dashboard hay không, dữ liệu nhạy cảm đang được ai sử dụng và chi phí để duy trì toàn bộ hệ thống là bao nhiêu.

Đồng thời, dữ liệu ngày càng không chỉ được sử dụng bởi con người. Phần mềm, mô hình Machine Learning và các hệ thống AI bắt đầu trở thành những consumer mới của Data Platform.

Chính vì vậy, Data Engineering đang bước vào một giai đoạn trưởng thành mới.

Data Engineer 2027 không chỉ xây pipeline. Họ xây nền móng để dữ liệu có thể được tin tưởng, khai thác và đưa vào vận hành ở quy mô doanh nghiệp.

Mục lục

1. Data Engineering thực chất là gì?
2. Data Engineer đứng ở đâu trong hệ sinh thái Data?
3. Vì sao Data Engineering tiếp tục quan trọng trong năm 2027?
4. Bản đồ tổng thể của một Data Platform hiện đại
5. Data Sources: Mọi thứ bắt đầu từ dữ liệu nguồn
6. Data Ingestion: Batch, Incremental, CDC và Streaming
7. Data Storage: Database, Data Warehouse, Data Lake và Lakehouse
8. Data Processing: SQL, Python, Spark và Distributed Computing
9. Data Modeling: Biến dữ liệu thành ngôn ngữ của doanh nghiệp
10. Orchestration, Reliability và Production Data Pipeline
11. Data Quality, Observability và Data Lineage
12. Data Governance, Security và quyền truy cập dữ liệu
13. Cloud Data Engineering và bài toán chi phí
14. Data Engineering trong thời đại AI
15. Bản đồ nghề nghiệp Data Engineer 2027
16. Skill Map của một Data Engineer
17. Roadmap học Data Engineering từ cơ bản đến chuyên sâu
18. Portfolio Data Engineer nên xây như thế nào?
19. Những sai lầm phổ biến khi học Data Engineering
20. Case Study: Xây Data Platform cho một doanh nghiệp bán lẻ
21. Data Engineer sẽ thay đổi như thế nào sau 2027?
22. Kết luận

1. Data Engineering thực chất là gì?

Có rất nhiều cách định nghĩa Data Engineering. Một định nghĩa dễ hiểu nhưng vẫn đủ chính xác là:

Data Engineering là lĩnh vực kỹ thuật chịu trách nhiệm thiết kế, xây dựng và vận hành hệ thống giúp dữ liệu được thu thập, lưu trữ, xử lý, kiểm soát và cung cấp một cách đáng tin cậy cho các nhu cầu sử dụng phía sau.

Điểm quan trọng nằm ở hai chữ: đáng tin cậy.

Đưa một file CSV từ máy A sang máy B không khó. Viết một đoạn Python đọc API rồi insert dữ liệu vào database cũng không quá khó.

Nhưng hãy tưởng tượng đoạn code đó phải chạy mỗi 10 phút trong ba năm.

API đôi lúc mất kết nối. Token hết hạn. Source thay đổi schema. Một request bị timeout. Một record được gửi hai lần. Database đích đang bảo trì. Pipeline chạy lại sau sự cố. Business thay đổi cách định nghĩa doanh thu. Người xây pipeline ban đầu đã nghỉ việc.

Lúc đó bài toán không còn là "code có chạy không".

Nó trở thành bài toán Engineering.

Một Data Engineer phải thiết kế sao cho hệ thống có thể tiếp tục hoạt động khi mọi thứ không diễn ra đúng như dự kiến.

Một ví dụ rất đơn giản

Giả sử một công ty bán hàng có ba hệ thống:

Hệ thống	Dữ liệu
Website	Hành vi khách hàng, đơn hàng online
POS	Giao dịch tại cửa hàng
CRM	Thông tin và lịch sử chăm sóc khách hàng

CEO muốn biết:

"Hôm qua toàn công ty bán được bao nhiêu?"

Nghe có vẻ đây chỉ là một câu SUM đơn giản.

Nhưng để trả lời chính xác, hệ thống phải giải quyết một loạt vấn đề.

Đơn hàng online đã thanh toán nhưng chưa giao có tính doanh thu chưa? Đơn POS bị hoàn trả xử lý thế nào? Một khách mua trên website sau đó mua tại cửa hàng có được nhận diện là cùng một người không? Dữ liệu từ POS cập nhật lúc nào? Nếu một cửa hàng mất mạng ba tiếng thì dashboard có biết dữ liệu đang thiếu không?

Một câu hỏi business đơn giản có thể kéo theo cả một hệ thống kỹ thuật phía sau.

Đó chính là Data Engineering.

2. Data Engineer đứng ở đâu trong hệ sinh thái Data?

Một cách dễ hình dung là xem dữ liệu như một chuỗi giá trị.

Dữ liệu ban đầu được sinh ra từ hoạt động kinh doanh. Data Engineer xây hệ thống đưa dữ liệu vào nền tảng và tổ chức nó. Data Analyst sử dụng dữ liệu để tìm insight. Data Scientist sử dụng dữ liệu để xây dựng mô hình. Machine Learning Engineer đưa mô hình vào production. BI Engineer xây hệ thống báo cáo. Những năm gần đây còn xuất hiện Analytics Engineer, Data Platform Engineer, Data Reliability Engineer và nhiều vai trò chuyên sâu khác.

Ranh giới giữa các vị trí không tuyệt đối. Một startup có thể chỉ có hai người và cả hai làm gần như mọi thứ. Một tập đoàn lớn có thể có hàng chục team khác nhau.

Có thể phân biệt tương đối như sau:

Vai trò	Trọng tâm chính
Data Analyst	Phân tích dữ liệu, insight, business
BI Engineer	Reporting, dashboard, semantic model
Analytics Engineer	SQL, transformation, data modeling
Data Engineer	Pipeline, storage, processing, platform
Data Platform Engineer	Hạ tầng và nền tảng dùng chung cho Data Team
Data Scientist	Mô hình thống kê và Machine Learning
ML Engineer	Production hóa hệ thống Machine Learning
AI Engineer	Xây dựng ứng dụng và hệ thống AI

Data Engineer nằm gần giữa rất nhiều hệ thống.

Họ phải hiểu source system do Software Engineer xây dựng, hiểu database, hiểu infrastructure, hiểu nhu cầu của Analyst, hiểu một phần business và ngày càng cần hiểu workload của Machine Learning cũng như AI.

Đó là lý do Data Engineering là một ngành vừa rộng vừa sâu.

3. Vì sao Data Engineering tiếp tục quan trọng trong năm 2027?

Có một nghịch lý thú vị. Các công cụ xử lý dữ liệu ngày càng dễ sử dụng, nhưng nhu cầu Data Engineering không vì thế mà biến mất.

Ngược lại, hệ sinh thái dữ liệu ngày càng phức tạp. Mười năm trước, một công ty có thể có một ERP, vài database và Excel.

Ngày nay cùng một doanh nghiệp có thể vận hành trên hàng chục SaaS khác nhau.

Marketing có Facebook Ads, Google Ads, TikTok, GA4.

Sales có CRM, tổng đài, hệ thống bán hàng.

Finance có ERP, kế toán, ngân hàng.

Customer Service có ticket system, chatbot, call center.

E-commerce có website, marketplace, payment gateway.

Mỗi hệ thống trở thành một "ốc đảo dữ liệu".

Nếu không có kiến trúc dữ liệu chung, doanh nghiệp sẽ gặp tình trạng rất quen thuộc:

Mỗi phòng ban có một phiên bản sự thật riêng.

Sales nói doanh thu tháng này 120 tỷ.

Finance nói 113 tỷ.

Dashboard Management lại hiển thị 117 tỷ.

Ba con số đều có thể "đúng" theo ba cách định nghĩa khác nhau.

Vấn đề lúc đó không nằm ở Power BI, Tableau hay Looker.

Vấn đề nằm sâu hơn trong Data Platform.

Một nguyên nhân thứ hai là dữ liệu ngày càng được sử dụng cho nhiều workload hơn.

Hệ thống dữ liệu vì vậy đang dần trở thành một phần hạ tầng cốt lõi của doanh nghiệp, tương tự cách phần mềm và cloud đã trở thành hạ tầng cốt lõi trước đó.

4. Bản đồ tổng thể của một Data Platform hiện đại

Một trong những lỗi phổ biến khi học Data Engineering là học từng công nghệ rời rạc.

Học Kafka. Học Spark. Học Airflow. Học BigQuery. Học dbt.

Sau một thời gian chúng ta biết rất nhiều tên sản phẩm nhưng vẫn không biết chúng nằm ở đâu trong kiến trúc.

Cách học tốt hơn là nhìn toàn bộ Data Platform trước.

Một kiến trúc tổng quát có thể được mô tả như sau:

Đây mới là bức tranh mà một Data Engineer nên giữ trong đầu.

Kafka chỉ giải quyết một số vấn đề trong ingestion và streaming.

Spark giải quyết một số workload processing.

BigQuery hoặc Snowflake có thể đảm nhiệm storage, compute và analytics.

Airflow tập trung vào orchestration.

dbt tập trung nhiều vào transformation, modeling, testing và analytics workflow.

Không có công nghệ nào chính là "Data Engineering".

Công nghệ chỉ là những mảnh ghép.

5. Data Sources: Mọi thứ bắt đầu từ dữ liệu nguồn

Trước khi xây pipeline, Data Engineer phải hiểu dữ liệu được sinh ra ở đâu.

Đây là một kỹ năng thường bị xem nhẹ.

Rất nhiều lỗi Data Platform xuất phát từ việc team Data hiểu chưa đủ rõ hệ thống nguồn.

Operational Database

Các ứng dụng thường lưu dữ liệu trong những database như PostgreSQL, MySQL, SQL Server, Oracle hoặc các hệ thống NoSQL.

Ví dụ một hệ thống thương mại điện tử có thể có:

customers
orders
order_items
payments
products
inventory

Database này được thiết kế để phục vụ hoạt động của ứng dụng.

Khi khách hàng bấm "Đặt hàng", hệ thống phải tạo order thật nhanh.

Khi khách thanh toán, trạng thái payment phải được cập nhật ngay.

Đó là workload OLTP, tức Online Transaction Processing.

Analytics lại có workload khác.

CEO có thể muốn tính doanh thu ba năm theo sản phẩm, tỉnh thành và nhóm khách hàng. Một query như vậy có thể scan hàng trăm triệu record.

Không nên để những truy vấn analytics nặng cạnh tranh trực tiếp với workload của ứng dụng production.

Đây là một trong những lý do Data Warehouse tồn tại.

SaaS và API

Doanh nghiệp ngày càng phụ thuộc vào SaaS.

Một công ty có thể có dữ liệu nằm trong Salesforce, HubSpot, Shopify, Zendesk, Google Ads, Facebook Ads, Stripe và nhiều nền tảng khác.

Phương thức phổ biến để lấy dữ liệu là API.

Nhìn bề ngoài, API ingestion khá đơn giản:

response = requests.get(url)
data = response.json()

Nhưng production pipeline phải xử lý pagination, authentication, rate limit, timeout, retry, incremental load, schema change và duplicate.

Đây là điểm rất quan trọng trong Data Engineering.

Code demo và production code là hai thế giới khác nhau.

Event Data

Ngày càng nhiều hệ thống tạo dữ liệu dưới dạng event.

Một khách hàng vào website có thể tạo chuỗi:

09:01 page_view
09:02 search
09:03 product_view
09:05 add_to_cart
09:08 checkout
09:09 purchase

Nếu chỉ nhìn transaction cuối cùng, chúng ta biết khách hàng mua gì.

Nếu có event data, chúng ta hiểu cả hành trình trước khi mua.

Event data là nền tảng cho rất nhiều use case như product analytics, recommendation, personalization, fraud detection và real-time monitoring.

File vẫn là một phần của thế giới doanh nghiệp

Một quan niệm không thực tế là Data Engineer phải loại bỏ Excel.

Trong doanh nghiệp thật, Excel và Google Sheets vẫn xuất hiện rất nhiều.

Supplier gửi CSV.

Finance gửi Excel.

Một chi nhánh nhập kế hoạch vào Google Sheets.

Đối tác gửi file qua SFTP.

Kỹ sư giỏi không phàn nàn rằng nguồn dữ liệu "không đủ hiện đại".

Họ thiết kế cách tiếp nhận nguồn dữ liệu đó an toàn, có kiểm soát và có khả năng vận hành lâu dài.

6. Data Ingestion: Batch, Incremental, CDC và Streaming

Sau khi biết dữ liệu nằm ở đâu, câu hỏi tiếp theo là làm thế nào đưa nó vào Data Platform.

Không phải hệ thống nào cũng nên real-time.

Đây là một điểm rất quan trọng.

Batch Processing

Batch xử lý dữ liệu theo từng đợt.

Ví dụ mỗi ngày lúc 1 giờ sáng:

ERP
 ↓
Lấy dữ liệu ngày hôm qua
 ↓
Data Warehouse

Batch phù hợp với rất nhiều nhu cầu như báo cáo tài chính, tổng hợp cuối ngày, payroll, historical analytics hoặc workload không đòi hỏi độ trễ thấp.

Ưu điểm lớn nhất của batch là đơn giản.

Một kiến trúc đơn giản thường dễ vận hành hơn, ít điểm lỗi hơn và rẻ hơn.

Incremental Loading

Giả sử bảng orders có 500 triệu record.

Nếu mỗi giờ đọc lại toàn bộ bảng thì rất lãng phí.

Thay vào đó, chúng ta có thể chỉ lấy dữ liệu mới:

SELECT *
FROM orders
WHERE updated_at > last_loaded_time;

Đó là incremental loading.

Nhưng ngay lập tức xuất hiện nhiều câu hỏi khác.

Nếu record cũ được update thì sao? Nếu clock giữa hai server khác nhau? Nếu hai record có cùng timestamp? Nếu job fail sau khi load nhưng trước khi cập nhật checkpoint?

Đây là lý do một concept nghe rất đơn giản lại cần được thiết kế kỹ khi production.

Change Data Capture

CDC, hay Change Data Capture, theo dõi những thay đổi trong database như INSERT, UPDATE và DELETE.

Thay vì hỏi database liên tục:

"Bạn có dữ liệu gì mới không?"

CDC có thể đọc thay đổi từ transaction log.

Ví dụ:

10:00 INSERT order_1001
10:01 INSERT order_1002
10:03 UPDATE order_1001
10:05 DELETE order_900

CDC đặc biệt hữu ích khi cần đồng bộ dữ liệu gần real-time nhưng không muốn scan database nguồn liên tục.

Streaming

Streaming xử lý dữ liệu liên tục khi event xuất hiện.

Ví dụ một hệ thống phát hiện gian lận:

Card Transaction
       ↓
Event Stream
       ↓
Fraud Detection
       ↓
Decision

Nếu đợi batch ngày hôm sau thì không còn nhiều ý nghĩa.

Ngược lại, dashboard báo cáo doanh thu tháng trước không nhất thiết cần một hệ thống streaming phức tạp.

Câu hỏi đúng không phải:

Streaming có tốt hơn Batch không?

Câu hỏi đúng là:

Business cần dữ liệu nhanh đến mức nào và giá trị của độ trễ thấp là bao nhiêu?

Đây là tư duy quan trọng của một Data Engineer.

7. Data Storage: Database, Data Warehouse, Data Lake và Lakehouse

Đây là nhóm khái niệm khiến rất nhiều người mới nhầm lẫn.

Database

Database truyền thống thường phục vụ ứng dụng và giao dịch.

Ví dụ PostgreSQL đứng phía sau website bán hàng.

Nó rất tốt cho việc tìm order_id cụ thể, update trạng thái đơn hàng hay tạo một customer mới.

Data Warehouse

Data Warehouse được thiết kế cho analytics.

Dữ liệu từ nhiều hệ thống được đưa về một nơi để phân tích.

Những nền tảng phổ biến gồm BigQuery, Snowflake, Amazon Redshift và các hệ thống tương tự.

Warehouse thường xử lý rất tốt các truy vấn kiểu:

"Doanh thu ba năm gần nhất theo tỉnh, sản phẩm và nhóm khách hàng là bao nhiêu?"

Data Lake

Data Lake thường lưu dữ liệu trên object storage.

Có thể lưu rất nhiều loại dữ liệu:

Dữ liệu có cấu trúc	Dữ liệu phi cấu trúc
CSV	PDF
Parquet	Image
JSON	Audio
Avro	Video
Database exports	Documents

Ưu điểm lớn của Data Lake là storage rẻ, linh hoạt và có thể chứa dữ liệu ở quy mô rất lớn.

Nhưng nếu chỉ đổ tất cả file vào một bucket mà không có metadata, governance, catalog hay cách tổ chức rõ ràng thì Data Lake rất dễ biến thành "Data Swamp".

Có dữ liệu nhưng không ai biết nó là gì.

Data Lakehouse

Lakehouse xuất hiện với tham vọng kết hợp sự linh hoạt của Data Lake với khả năng quản lý dữ liệu gần giống Data Warehouse.

Một phần rất quan trọng trong xu hướng này là các open table format như Apache Iceberg.

Iceberg cung cấp các khả năng như schema evolution, hidden partitioning, partition evolution, snapshot và hỗ trợ nhiều compute engine. REST Catalog của Iceberg cũng hướng tới việc tạo một giao thức chung giúp các engine và ngôn ngữ khác nhau tương tác với catalog dễ hơn.

Có thể hình dung:

            Spark
              │
              │
BigQuery ── Iceberg ── Trino
              │
              │
             Flink
              │
              ↓
        Object Storage

Thay vì dữ liệu bị khóa hoàn toàn vào một compute engine, open table format tạo cơ hội cho nhiều engine làm việc trên cùng một lớp dữ liệu.

Tuy nhiên, Lakehouse không phải phép màu.

Doanh nghiệp vẫn phải giải quyết compaction, metadata, catalog, security, file sizing, performance và cost.

Một Data Engineer không nên học Lakehouse bằng cách chỉ nhớ định nghĩa.

Hãy hiểu bài toán mà nó đang cố giải quyết.

8. Data Processing: SQL, Python, Spark và Distributed Computing

Sau khi dữ liệu được ingest và lưu trữ, chúng ta phải biến nó thành dữ liệu có thể sử dụng.

Đây là Data Processing.

SQL vẫn là kỹ năng nền tảng

SQL có thể là kỹ năng quan trọng nhất đối với phần lớn Data Engineer.

Không phải vì SQL khó nhất.

Mà vì một lượng rất lớn dữ liệu doanh nghiệp cuối cùng vẫn được tổ chức dưới dạng bảng.

Một câu query đơn giản:

SELECT
    customer_id,
    SUM(amount) AS revenue
FROM orders
GROUP BY customer_id;

có vẻ rất hợp lý.

Nhưng nếu bảng orders chứa cả đơn cancelled và refunded thì kết quả có thể sai.

SQL chạy thành công.

Không có exception.

Không có error.

Dashboard vẫn đẹp.

Nhưng business sai.

Đó là loại lỗi nguy hiểm nhất.

Data Grain

Một khái niệm rất đáng học thật sâu là grain.

Giả sử bảng orders có quy ước:

Một dòng là một đơn hàng.

Bảng order_items lại có:

Một dòng là một sản phẩm trong đơn hàng.

Order 1001 có ba sản phẩm.

Nếu join orders với order_items rồi SUM order_amount, doanh thu của order đó có thể bị tính ba lần.

Đây không phải lỗi SQL syntax.

Đây là lỗi tư duy dữ liệu.

Người hiểu grain sẽ nhìn bảng dữ liệu khác hoàn toàn người chỉ biết viết câu JOIN.

Python

Python rất hữu ích cho API integration, automation, processing, SDK cloud, custom logic, testing và rất nhiều bài toán khác.

Nhưng học Python cho Data Engineering không nên tập trung vào việc nhớ mọi cú pháp.

Hãy tập trung vào cách xây chương trình có thể sống trong production.

Ví dụ một API request cần được xem xét dưới những góc độ như retry, timeout, authentication, pagination, logging và error handling.

Một câu hỏi rất hay để tự kiểm tra tư duy Engineering là:

Nếu chương trình chạy được 9.999 record rồi fail ở record thứ 10.000, chuyện gì xảy ra khi chạy lại?

Nếu câu trả lời là:

"Em chạy lại từ đầu."

thì hệ thống có thể chưa sẵn sàng cho production.

Idempotency

Idempotency là khả năng chạy lại một operation mà không tạo ra kết quả sai hoặc duplicate ngoài mong muốn.

Giả sử pipeline đã load 100.000 transaction rồi bị fail trước bước cuối.

Nếu chạy lại và tạo thêm 100.000 transaction giống hệt, hệ thống có vấn đề.

Một cách phổ biến là sử dụng key và MERGE.

MERGE INTO target t
USING staging s
ON t.order_id = s.order_id

WHEN MATCHED THEN
UPDATE SET
    t.amount = s.amount,
    t.status = s.status

WHEN NOT MATCHED THEN
INSERT (...);

Hiểu idempotency có giá trị hơn việc thuộc lòng hàng trăm API của framework.

Spark

Apache Spark rất mạnh trong distributed processing.

Nhưng một Data Engineer nên học Spark sau khi hiểu database, SQL, partitioning và cách dữ liệu được xử lý.

Nếu một dataset chỉ vài GB và warehouse xử lý tốt bằng SQL, dựng một hệ thống Spark phức tạp có thể không cần thiết.

Spark trở nên có giá trị rõ hơn khi workload lớn, cần distributed computing hoặc có những transformation phù hợp với mô hình xử lý của Spark.

Điều cần học không chỉ là PySpark syntax.

Hãy hiểu partition, shuffle, join strategy, memory, execution plan và cách dữ liệu di chuyển giữa các node.

Đó mới là phần tạo ra năng lực kỹ thuật lâu dài.

9. Data Modeling: Biến dữ liệu thành ngôn ngữ của doanh nghiệp

Một Data Platform có thể ingest rất nhanh và xử lý hàng petabyte dữ liệu, nhưng nếu dữ liệu cuối cùng khó hiểu thì platform vẫn thất bại.

Data Modeling là nơi dữ liệu kỹ thuật bắt đầu trở thành dữ liệu kinh doanh.

Fact và Dimension

Một mô hình phổ biến là Star Schema.

Ví dụ:

                 dim_customer
                      │
                      │
dim_product ── fact_sales ── dim_store
                      │
                      │
                   dim_date

fact_sales chứa giao dịch.

dim_customer mô tả khách hàng.

dim_product mô tả sản phẩm.

dim_store mô tả cửa hàng.

dim_date mô tả thời gian.

CEO muốn xem doanh thu theo vùng thì kết hợp fact_sales với dim_store.

Marketing muốn xem doanh thu theo nhóm khách hàng thì sử dụng dim_customer.

Điều hay của modeling là business không còn phải hiểu cấu trúc database application phức tạp.

Họ sử dụng một mô hình được thiết kế cho analytics.

Bronze, Silver và Gold

Một cách tổ chức khác rất phổ biến trong Data Lake và Lakehouse là chia dữ liệu thành nhiều tầng.

Layer	Ý nghĩa
Bronze	Dữ liệu gần source, ít biến đổi
Silver	Dữ liệu đã clean, chuẩn hóa và kiểm tra
Gold	Dữ liệu phục vụ business

Ví dụ dữ liệu POS gửi:

store_code = HCM_001

Silver layer có thể chuẩn hóa sang một store_id.

Gold layer cuối cùng có bảng:

daily_store_sales

với metric đã được chuẩn hóa cho báo cáo.

Có thể hiểu rất đời thường:

Bronze giống nguyên liệu vừa nhập kho.

Silver giống nguyên liệu đã được sơ chế.

Gold là nguyên liệu đã được chuẩn bị theo đúng nhu cầu của người sử dụng.

Semantic Layer

Đây là một lớp ngày càng quan trọng.

Hãy lấy từ "Revenue".

Sales có thể coi Revenue là giá trị đơn hàng.

Finance có thể chỉ ghi nhận Revenue khi hàng đã giao.

Marketing lại sử dụng attributed revenue của campaign.

Nếu không có định nghĩa thống nhất, ba dashboard có thể hiển thị ba con số.

Semantic Layer cố gắng đưa những khái niệm như metric, dimension, relationship và business definition về một nơi được quản trị thống nhất.

Nó trở nên đặc biệt quan trọng khi người sử dụng dữ liệu không còn trực tiếp viết SQL mà bắt đầu hỏi dữ liệu bằng ngôn ngữ tự nhiên. Snowflake chẳng hạn đang nhấn mạnh semantic views như nền tảng giúp Cortex Agents tạo câu trả lời và SQL chính xác hơn, trong đó metric, relationship và mô tả business được mô hình hóa rõ ràng.

Một hệ thống thông minh đến đâu cũng khó trả lời chính xác câu hỏi "khách hàng tốt nhất là ai?" nếu chính doanh nghiệp chưa định nghĩa "tốt nhất" nghĩa là doanh thu cao, lợi nhuận cao, LTV cao hay tỷ lệ hoàn trả thấp.

10. Orchestration, Reliability và Production Data Pipeline

Data Platform hiếm khi chỉ có một job.

Một doanh nghiệp lớn có thể có hàng nghìn workflow phụ thuộc lẫn nhau.

Ví dụ:

Load Customers
      ↓
Load Orders
      ↓
Transform Sales
      ↓
Calculate Metrics
      ↓
Refresh Dashboard

Nếu Load Orders thất bại, các bước phía sau không nên chạy như chưa có chuyện gì xảy ra.

Đây là vai trò của orchestration.

Apache Airflow là một công nghệ quen thuộc trong nhóm này, bên cạnh Dagster, Prefect và nhiều managed service khác.

Nhưng quan trọng hơn công cụ là tư duy dependency.

Pipeline chạy được chưa chắc đã tốt

Giả sử báo cáo CEO phải sẵn sàng trước 7:30 sáng.

Pipeline hôm nay hoàn tất lúc 9:30.

Dữ liệu hoàn toàn chính xác.

Về mặt kỹ thuật pipeline "success".

Về mặt business pipeline đã fail.

Data Platform phải quan tâm đến SLA, freshness và timeliness.

Một production pipeline tốt cần nghĩ tới retry, timeout, backfill, alerting, logging, dependency, recovery và lịch sử chạy.

Kỹ sư càng có kinh nghiệm càng dành nhiều thời gian nghĩ đến câu hỏi:

Hệ thống sẽ thất bại như thế nào?

thay vì chỉ:

Hệ thống chạy như thế nào?

11. Data Quality, Observability và Data Lineage

Đây là nhóm năng lực rất dễ bị bỏ qua trong project học tập nhưng lại cực kỳ quan trọng trong doanh nghiệp.

Data Quality

Dữ liệu có thể hoàn toàn hợp lệ về mặt kỹ thuật nhưng vô lý về mặt business.

Ví dụ:

customer_age = 287

hoặc:

order_date = 2099-01-01

hoặc doanh thu của một cửa hàng bình thường 500 triệu một ngày đột nhiên thành âm 20 tỷ.

Database không nhất thiết báo lỗi.

Vì vậy Data Quality phải kiểm tra nhiều khía cạnh như completeness, uniqueness, validity, consistency, freshness và business rules.

Ví dụ:

order_id must not be null
order_id must be unique
quantity > 0
order_date <= current_date
customer_id must exist

Nhưng Data Quality không nên chỉ là một tập hợp test kỹ thuật.

Một test có giá trị nhất thường là test phản ánh business invariant.

Ví dụ:

"Đơn hàng trạng thái COMPLETED bắt buộc phải có payment."

Đó là business rule.

Data Observability

Data Observability mở rộng góc nhìn từ:

"Dữ liệu có pass rule không?"

sang:

"Hệ thống dữ liệu đang có hành vi bất thường không?"

Ví dụ số order trung bình mỗi ngày là 100.000.

Hôm nay chỉ có 12.000.

Không có schema error.

Không có null bất thường.

Pipeline vẫn chạy thành công.

Nhưng rõ ràng có điều gì đó đáng nghi.

Observability giúp phát hiện những anomaly như volume giảm mạnh, freshness tăng, distribution thay đổi hoặc dependency bị ảnh hưởng.

Data Lineage

CEO nhìn thấy Revenue sai trên dashboard.

Bạn cần truy ngược:

Executive Dashboard
        ↑
sales_metric
        ↑
fact_sales
        ↑
orders_clean
        ↑
ERP.orders

Đó là Data Lineage.

Lineage trả lời câu hỏi:

Dữ liệu này đến từ đâu và nếu tôi thay đổi nó thì cái gì bị ảnh hưởng?

Khi Data Platform có hàng nghìn table và hàng trăm consumer, lineage không còn là "nice to have".

Nó trở thành một phần quan trọng của việc vận hành hệ thống.

12. Data Governance, Security và quyền truy cập dữ liệu

Data Engineer không chỉ chịu trách nhiệm đưa dữ liệu đến đúng nơi.

Càng ngày họ càng phải đảm bảo dữ liệu chỉ đến đúng người.

Giả sử bảng customer có:

customer_id
name
phone
email
address
birthday
purchase_history

Không phải tất cả nhân viên đều cần xem toàn bộ thông tin đó.

Marketing có thể cần customer segment và purchase behavior.

Finance cần invoice và payment.

Một analyst có thể cần dữ liệu đã mask.

Một application chỉ nên truy cập một tập column nhất định.

Data Governance giải quyết những vấn đề như ownership, classification, catalog, access control, lineage, audit, retention và policy.

Trong một Data Platform trưởng thành, câu hỏi không chỉ là:

"Table này nằm ở đâu?"

Mà còn phải biết:

"Table này thuộc domain nào?"

"Ai là owner?"

"Cột nào chứa PII?"

"Ai đang sử dụng?"

"Có được export ra ngoài hay không?"

"Retention policy là bao lâu?"

Các nền tảng hiện đại ngày càng đưa data và AI asset vào cùng một lớp governance. Databricks mô tả Unity Catalog như một lớp governance thống nhất cho data và AI, cung cấp access control, discovery, lineage và auditing.

Đây là một tín hiệu quan trọng về hướng phát triển của Data Platform.

Governance không phải lớp được gắn thêm sau khi hệ thống hoàn thành.

Nó dần trở thành một phần của kiến trúc ngay từ đầu.

13. Cloud Data Engineering và bài toán chi phí

Data Engineering hiện đại có quan hệ rất chặt với cloud.

Ba ecosystem lớn vẫn là AWS, Google Cloud và Microsoft Azure.

Người học không nhất thiết phải giỏi cả ba.

Một cách học hiệu quả hơn là hiểu các concept trước, sau đó đi sâu vào một cloud.

Ví dụ:

Concept	AWS	Google Cloud	Azure
Object Storage	S3	Cloud Storage	Blob Storage / ADLS
Data Warehouse	Redshift	BigQuery	Fabric / Synapse
Streaming	Kinesis / MSK	Pub/Sub	Event Hubs
Identity	IAM	IAM	Entra ID / RBAC

Tên sản phẩm thay đổi nhưng rất nhiều nguyên lý vẫn giống nhau.

Data Engineer nên hiểu object storage, compute, networking, IAM, secrets, logging, warehouse, streaming và monitoring.

Cloud làm Scale dễ hơn, nhưng cũng làm tiêu tiền dễ hơn

Giả sử một query scan 5 TB dữ liệu.

Một dashboard chạy query đó 200 lần mỗi ngày.

Dù từng query chạy rất nhanh, chi phí tích lũy có thể rất đáng kể.

Data Engineer cần hiểu partitioning, clustering, caching, materialization, lifecycle, incremental processing và workload management.

Performance và Cost thường phải được tối ưu cùng nhau.

Ví dụ có hai kiến trúc:

	Kiến trúc A	Kiến trúc B
Latency	4 giây	8 giây
Chi phí	20.000 USD/tháng	4.000 USD/tháng

Nếu người dùng chấp nhận 8 giây thì kiến trúc B có thể tốt hơn nhiều.

Engineering hiếm khi là bài toán tìm phương án mạnh nhất.

Engineering là tìm phương án phù hợp nhất với yêu cầu và constraint.

14. Data Engineering trong thời đại AI

Đây là phần cần nhìn một cách cân bằng. AI chắc chắn sẽ thay đổi công việc Data Engineering.

Những việc như viết boilerplate SQL, tạo skeleton pipeline, document code, generate test hoặc phân tích error log đang được tự động hóa ngày càng nhiều.

Google Cloud đã đưa Data Engineering Agent trong BigQuery lên Generally Available vào tháng 4/2026, với định hướng giảm khối lượng tác vụ Data Engineering lặp lại để kỹ sư tập trung hơn vào thiết kế, chuẩn hóa và các bài toán giá trị cao.

Điều đó có nghĩa một phần công việc Data Engineer sẽ trở nên rẻ hơn.

Nhưng cần phân biệt:

AI có thể viết code.

với:

AI có chịu trách nhiệm cho Data Platform của doanh nghiệp hay không.

Hai việc hoàn toàn khác nhau.

Một ví dụ

Bạn yêu cầu AI:

Viết pipeline lấy order từ API và load vào BigQuery.

AI có thể tạo code rất nhanh.

Nhưng kỹ sư vẫn phải quyết định:

API có pagination không? Load full hay incremental? Retry bao nhiêu lần? Nếu source gửi duplicate thì xử lý ra sao? Nếu schema thay đổi thì pipeline có fail không? Dữ liệu này có PII không? Partition table theo trường nào? SLA là bao nhiêu? Nếu pipeline chạy hai lần có double-count không? Chi phí query phía sau có chấp nhận được không?

Phần code đang ngày càng dễ hơn.

Phần chịu trách nhiệm cho hệ thống vẫn khó.

Đây là lý do em cho rằng Data Engineer sẽ không biến mất, nhưng định nghĩa về một Data Engineer giỏi sẽ thay đổi.

Data Platform bắt đầu phục vụ machine consumer

Trước đây Data Engineer chủ yếu chuẩn bị dữ liệu để analyst và dashboard sử dụng.

Trong những năm tới, một consumer mới sẽ ngày càng phổ biến: hệ thống AI.

Google Cloud đã mô tả sự dịch chuyển từ workload phục vụ con người sang "agent-first workloads", trong đó dữ liệu cần được tổ chức từ raw data thành semantic knowledge để hệ thống có thể reasoning chính xác hơn.

Snowflake cũng đang đưa structured analytics, semantic views, unstructured retrieval, tool calling và multi-step orchestration vào Cortex Agents.

Điều này tạo ra một câu hỏi mới cho Data Engineer:

Nếu một AI Agent sử dụng dữ liệu này để đưa ra hành động, dữ liệu cần đáng tin đến mức nào?

Nếu dashboard sai, một manager có thể phát hiện ra và dừng lại.

Nếu một hệ thống tự động dùng dữ liệu sai để gửi 100.000 ưu đãi, điều chỉnh tồn kho hoặc tạo quyết định vận hành, impact có thể lớn hơn nhiều.

Vì vậy AI không làm giảm tầm quan trọng của Data Quality, Semantic Layer, Governance và Metadata.

Trong nhiều trường hợp, nó khiến những thứ này quan trọng hơn.

Structured và Unstructured Data bắt đầu hội tụ

Data Engineering truyền thống tập trung mạnh vào rows và columns.

Nhưng doanh nghiệp còn sở hữu một lượng dữ liệu rất lớn trong email, PDF, hợp đồng, transcript cuộc gọi, tài liệu nội bộ, ticket support, hình ảnh và nhiều định dạng khác.

Một hệ thống AI phục vụ doanh nghiệp có thể cần kết hợp:

Sales Transactions + CRM + Emails + Contracts + Call Transcripts + Product Documents

Data Engineer tương lai vì vậy có thể phải hiểu thêm document pipeline, metadata, embedding, vector search, retrieval, semantic context và cách quản trị dữ liệu phi cấu trúc.

Đây không có nghĩa mọi Data Engineer phải trở thành AI Engineer.

Nó có nghĩa phạm vi của Data Infrastructure đang mở rộng.

Governance cho Agent và Tool

Một vấn đề mới cũng đang xuất hiện.

Nếu một AI Agent có khả năng query database, search tài liệu hoặc gọi API thì chúng ta phải quản lý quyền của Agent giống như quản lý một software identity.

Databricks đã đưa các tool và MCP server vào lớp quản trị của Unity Gateway và Unity Catalog, kiểm soát Agent được tiếp cận những tool và dữ liệu nào.

Đây là một ví dụ khá rõ về việc Data Governance và AI Governance đang tiến gần nhau.

15. Bản đồ nghề nghiệp Data Engineer 2027

Data Engineering không còn là một title duy nhất.

Tùy công ty, chúng ta có thể gặp nhiều hướng.

Data Engineer

Generalist làm ingestion, transformation, storage, orchestration và serving.

Analytics Engineer

Đứng gần business hơn, mạnh SQL, data modeling, transformation, semantic layer và analytics workflow.

Streaming Data Engineer

Đi sâu vào Kafka, Flink, event architecture, real-time processing và distributed messaging.

Data Platform Engineer

Xây platform để các Data Engineer, Analyst và Data Scientist khác có thể tự phục vụ.

Thay vì từng team tự cấu hình logging, deployment, permissions và orchestration, Platform Team xây một "con đường chuẩn".

Data Infrastructure Engineer

Đi sâu hơn vào distributed systems, compute, storage, Kubernetes, performance và infrastructure.

Data Reliability Engineer

Tập trung vào reliability, observability, quality, incidents và SLA của Data Platform.

Data Governance Engineer

Tập trung vào catalog, metadata, lineage, classification, security và policy.

AI Data Engineer

Đây có thể trở thành một nhánh đáng chú ý hơn trong những năm tới.

Vai trò này tập trung vào nền tảng dữ liệu phục vụ LLM, retrieval, AI Application hoặc Agent, bao gồm structured data, unstructured data, metadata, semantic context và các pipeline liên quan.

Điều quan trọng là đừng cố học tất cả các nhánh ngay lập tức.

Hãy trở thành Data Engineer có nền tảng vững trước.

Chuyên môn hóa nên đến sau fundamentals.

16. Skill Map của một Data Engineer

Nếu phải xây một bản đồ năng lực, em sẽ chia thành các tầng sau.

Tầng	Kiến thức quan trọng
Computer Fundamentals	Linux, process, network, HTTP, file system
Programming	Python, SQL, Shell
Database	Relational DB, transaction, index, OLTP
Data Modeling	Fact, Dimension, SCD, normalization
Data Pipeline	ETL, ELT, incremental, CDC
Processing	SQL engine, Spark, distributed processing
Streaming	Event, Kafka, Flink, Pub/Sub
Cloud	Storage, IAM, compute, warehouse, networking
Platform	Orchestration, CI/CD, IaC, observability
Governance	Catalog, lineage, security, data quality
Architecture	Warehouse, Lake, Lakehouse, Data Product
AI Data Foundation	Unstructured data, semantic context, retrieval, governance

Người mới thường có xu hướng chạy thẳng tới Spark, Kafka hoặc Kubernetes.

Nhưng nền móng nên bắt đầu từ SQL, Database, Python, Linux và Data Modeling.

Một engineer hiểu database sâu có thể học warehouse rất nhanh.

Một engineer hiểu partitioning có thể học Spark nhanh hơn.

Một engineer hiểu distributed messaging sẽ hiểu Kafka dễ hơn rất nhiều so với người chỉ học Kafka commands.

Concept có tuổi thọ dài hơn Tool.

17. Roadmap học Data Engineering từ cơ bản đến chuyên sâu

Không có roadmap duy nhất đúng cho tất cả mọi người, nhưng đây là một trình tự hợp lý nếu mục tiêu là đi từ beginner đến khả năng xây hệ thống end-to-end.

Giai đoạn 1: SQL và Database

Đây nên là nền móng đầu tiên.

Học SELECT, JOIN, GROUP BY, CTE, Window Function, subquery, transaction, index, normalization và execution plan.

Đừng chỉ giải bài SQL.

Hãy tạo một database bán hàng thực sự.

Ví dụ:

customers
products
orders
order_items
payments

Sau đó tự trả lời các câu hỏi:

Doanh thu theo tháng là bao nhiêu?

Top 10 khách hàng theo LTV?

Khách nào 90 ngày chưa mua lại?

Sản phẩm nào thường được mua cùng nhau?

Ngay từ đây bạn đã bắt đầu kết nối SQL với business.

Giai đoạn 2: Python và API

Học đủ Python để có thể xây chương trình thực tế.

Một project tốt:

Public API
    ↓
Python
    ↓
Data Cleaning
    ↓
PostgreSQL

Sau đó thêm retry, logging, incremental loading và error handling.

Project bắt đầu đơn giản nhưng mỗi lần thêm một production concern, kiến thức sẽ sâu hơn.

Giai đoạn 3: Linux, Git và Docker

Data Engineer cần thoải mái với terminal.

Hãy hiểu file permission, process, environment variable, SSH, cron, log file và package installation.

Git không chỉ là git push.

Hãy hiểu branch, pull request, conflict và release workflow.

Docker giúp tạo môi trường có khả năng tái lập.

Giai đoạn 4: Data Warehouse và Data Modeling

Đưa dữ liệu bán hàng vào một warehouse.

Thiết kế:

fact_sales
dim_customer
dim_product
dim_store
dim_date

Sau đó xây transformation từ raw data thành model analytics.

Đây là giai đoạn rất quan trọng vì bạn bắt đầu hiểu khoảng cách giữa source schema và analytical schema.

Giai đoạn 5: ETL, ELT và Orchestration

Tạo pipeline:

PostgreSQL
     ↓
Extract
     ↓
Warehouse
     ↓
Transform
     ↓
Business Tables

Sau đó thêm scheduler, retry, alert và dependency.

Lúc này Airflow, Dagster hoặc công cụ tương tự mới có ý nghĩa rõ ràng.

Giai đoạn 6: Cloud

Chọn một ecosystem và đi sâu.

Nếu chọn Google Cloud chẳng hạn, có thể học Cloud Storage, BigQuery, IAM, Pub/Sub, Dataflow, logging và các dịch vụ liên quan.

Mục tiêu không phải lấy thật nhiều certificate.

Mục tiêu là có thể triển khai project Data Platform trên cloud và giải thích kiến trúc.

Giai đoạn 7: Spark và Distributed Processing

Sau khi hiểu SQL và processing trên một máy, hãy học cách xử lý khi data không còn phù hợp với một máy.

Hiểu partition, shuffle, narrow transformation, wide transformation, join strategy, cache và execution plan.

Một câu hỏi tốt hơn "PySpark viết thế nào?" là:

Dữ liệu đang di chuyển như thế nào trong cluster?

Giai đoạn 8: Streaming

Học event, producer, consumer, partition, offset, consumer group, delivery semantics, window và watermark.

Xây project real-time:

Order Events
     ↓
Kafka
     ↓
Stream Processing
     ↓
Real-time Analytics

Sau đó chủ động làm hệ thống fail để hiểu recovery.

Giai đoạn 9: Lakehouse và Open Table Format

Học Parquet, partitioning, metadata, Iceberg, snapshot, schema evolution, compaction và catalog.

Quan trọng nhất vẫn là hiểu lý do tại sao Lakehouse tồn tại.

Giai đoạn 10: Production Engineering

Đây là phần rất nhiều khóa học bỏ qua.

Học testing, CI/CD, Infrastructure as Code, secrets management, monitoring, lineage, data quality, security và cost optimization.

Một project ở giai đoạn này không chỉ cần chạy.

Nó phải có khả năng được người khác vận hành.

Giai đoạn 11: Data cho Machine Learning và AI

Sau khi nền tảng Data Engineering đủ chắc, hãy mở rộng sang feature pipeline, unstructured data, vector data, retrieval, semantic layer và cách các application sử dụng Data Platform.

Đây là thời điểm hợp lý để kết nối Data Engineering với làn sóng AI, thay vì lao vào Vector Database từ tuần đầu tiên.

18. Portfolio Data Engineer nên xây như thế nào?

Ba project sâu thường tốt hơn mười project tutorial.

Project 1: Modern Data Warehouse

Ví dụ:

PostgreSQL
     ↓
Data Ingestion
     ↓
Cloud Warehouse
     ↓
Transformation
     ↓
Data Model
     ↓
BI

Project này chứng minh bạn hiểu SQL, database, ETL, modeling và analytics.

Đừng dừng lại ở việc screenshot dashboard.

Trong README hãy giải thích architecture, data model, incremental strategy, quality test và cost consideration.

Project 2: Real-time Data Platform

Ví dụ xây hệ thống order event.

Application
     ↓
Kafka
     ↓
Streaming Processing
     ↓
Lakehouse / Warehouse
     ↓
Monitoring

Hãy tạo tình huống consumer fail.

Tạo duplicate event.

Tăng volume.

Thử restart.

Bạn sẽ học rất nhiều từ failure.

Project 3: Enterprise Data Platform

Đây nên là project lớn nhất.

Giả lập một doanh nghiệp có:

ERP
CRM
Website
Advertising
Customer Service

Đưa dữ liệu về một platform chung.

Xây raw layer, clean layer, business layer, data quality, orchestration, lineage và dashboard.

Sau đó có thể thêm một lớp AI ở cuối để truy vấn dữ liệu bằng ngôn ngữ tự nhiên hoặc kết hợp tài liệu.

Điểm quan trọng là AI chỉ là một consumer của Data Platform.

Phần giá trị lớn nhất vẫn là nền tảng phía dưới.

Điều nhà tuyển dụng nên nhìn thấy

Portfolio tốt phải trả lời được ba câu.

Bạn xây cái gì?

Tại sao thiết kế như vậy?

Nếu hệ thống thực sự chạy production thì chuyện gì có thể xảy ra?

Ví dụ, thay vì nói:

"Em sử dụng Kafka."

Hãy nói:

"Hệ thống cần xử lý order event trong vòng vài giây và nhiều consumer cần sử dụng cùng event stream, vì vậy em sử dụng Kafka. Báo cáo tài chính cuối ngày vẫn dùng batch vì không có giá trị kinh doanh khi đưa workload đó sang real-time."

Câu thứ hai thể hiện tư duy Engineering sâu hơn rất nhiều.

19. Những sai lầm phổ biến khi học Data Engineering

Học quá nhiều công nghệ cùng lúc

Một CV có thể ghi Spark, Kafka, Airflow, Kubernetes, Databricks, Snowflake, AWS, Azure và GCP.

Nhưng nếu không giải thích được index hoạt động thế nào hoặc LEFT JOIN có thể làm nhân bản dữ liệu ra sao thì nền tảng vẫn còn yếu.

Hãy nhớ:

Tool có thể thay đổi nhanh. Fundamental thay đổi chậm hơn rất nhiều.

Đánh đồng Data Engineering với Big Data

Không phải doanh nghiệp nào cũng có petabyte dữ liệu.

Không phải pipeline nào cũng cần Spark.

Không phải hệ thống nào cũng cần Kafka.

Có những công ty có thể vận hành rất tốt chỉ bằng PostgreSQL, object storage, BigQuery và orchestration đơn giản.

Một kiến trúc đơn giản đáp ứng đúng nhu cầu thường tốt hơn một kiến trúc phức tạp nhưng không tạo thêm giá trị.

Không học Data Modeling

Đây là lỗi rất phổ biến.

Pipeline chạy nhanh nhưng bảng cuối cùng không ai hiểu.

Data được ingest đầy đủ nhưng analyst phải join 17 bảng chỉ để tính revenue.

Data Engineering cuối cùng vẫn phải phục vụ người sử dụng dữ liệu.

Modeling là cầu nối giữa technical data và business data.

Không nghĩ về Failure

Project tutorial thường được demo trong điều kiện hoàn hảo.

Internet hoạt động.

API trả đúng schema.

Database không down.

Không có duplicate.

Production không như vậy.

Hãy chủ động hỏi:

Nếu source down thì sao?

Nếu pipeline chạy hai lần?

Nếu column biến mất?

Nếu API trả 429?

Nếu một file đến trễ một ngày?

Nếu volume tăng 100 lần?

Những câu hỏi đó tạo ra kỹ sư.

Không quan tâm Cost

Trên local machine, compute gần như có cảm giác miễn phí.

Trên cloud, mỗi quyết định kiến trúc đều có thể xuất hiện trên hóa đơn.

Data Engineer nên biết hệ thống mình xây tốn bao nhiêu tiền và tại sao.

Chỉ biết code nhưng không hiểu Business

Một pipeline có thể hoàn hảo về kỹ thuật nhưng tính sai Revenue.

Đó vẫn là một pipeline thất bại.

Data Engineer càng senior càng cần hiểu dữ liệu đại diện cho hoạt động kinh doanh nào.

20. Case Study: Xây Data Platform cho một doanh nghiệp bán lẻ

Hãy giả định một chuỗi bán lẻ có 100 cửa hàng và website thương mại điện tử.

Hệ thống hiện tại gồm ERP, POS, website, CRM, Google Ads, Facebook Ads, GA4, call center và nhiều Google Sheets do các phòng ban tự quản lý.

Bài toán ban đầu

CEO nhận dashboard doanh thu mỗi sáng.

Finance báo 98 tỷ.

Sales báo 101 tỷ.

Marketing nói campaign tạo ra 110 tỷ attributed revenue.

Không ai sai hoàn toàn.

Họ đang dùng ba định nghĩa khác nhau.

Ngoài ra báo cáo tồn kho chậm sáu giờ. Có trường hợp hệ thống báo còn hàng nhưng cửa hàng thực tế đã hết.

Đây là một bài toán Data Engineering điển hình.

Bước 1: Xác định Source Systems

Team Data lập inventory:

Domain	Source
Sales	POS, ERP, Website
Customer	CRM, Website
Inventory	ERP, WMS
Marketing	Google Ads, Meta Ads, GA4
Customer Service	Call Center
Finance	ERP, Accounting

Việc đầu tiên không phải mua Spark cluster.

Việc đầu tiên là hiểu dữ liệu.

Bước 2: Xây Ingestion Layer

Các nguồn phù hợp batch được load định kỳ.

Những bảng cần độ trễ thấp hơn sử dụng incremental hoặc CDC.

Event từ website có thể được ingest theo stream nếu business thực sự cần.

Một thiết kế thực tế có thể kết hợp cả ba thay vì ép mọi thứ theo một pattern.

Bước 3: Raw Layer

Dữ liệu source được lưu gần nguyên bản.

Ví dụ:

raw_pos_orders
raw_erp_products
raw_crm_customers
raw_google_ads

Raw layer giúp giữ lại lịch sử source và hỗ trợ reprocessing khi cần.

Bước 4: Standardization

Đây thường là phần tốn rất nhiều công sức.

POS có:

product_code = IP15PM256

ERP lại có:

sku = APPLE_IP15_PROMAX_256

Website dùng:

product_id = 98122

Ba identifier cùng đại diện cho một sản phẩm.

Data Engineer phải xây mapping hoặc master data để đưa tất cả về một canonical product identifier.

Nếu không giải quyết bước này, Customer 360, Product 360 hay inventory analytics đều không đáng tin.

Bước 5: Data Modeling

Team xây các dimension:

dim_customer
dim_product
dim_store
dim_date

và fact:

fact_sales
fact_inventory
fact_marketing
fact_payment

Revenue được định nghĩa chính thức.

Ví dụ:

Net Revenue
=
Completed Sales
- Returns
- Discounts

Finance, Sales và Management cùng sử dụng định nghĩa này cho nhóm báo cáo được thống nhất.

Bước 6: Data Quality

Team tạo các rule.

Ví dụ một completed order phải có payment.

Product phải tồn tại trong master product.

Inventory không được thiếu store_id.

Dữ liệu POS phải cập nhật trong phạm vi SLA.

Nếu volume của một cửa hàng giảm bất thường, observability system cảnh báo.

Bước 7: Serving

Data cuối cùng được cung cấp cho nhiều nhu cầu.

Management có Executive Dashboard.

Marketing có Customer Segmentation.

Operations có Inventory Health.

Finance có Revenue Reconciliation.

Data Scientist có datasets phục vụ forecasting.

Bước 8: Mở rộng sang AI

Sau khi semantic và governance đủ tốt, công ty có thể xây một interface cho phép CEO hỏi:

"Doanh thu miền Nam tuần này giảm ở đâu?"

Hệ thống có thể truy xuất metric đã được định nghĩa thay vì tự tạo một công thức revenue mới.

Một Inventory Agent có thể phát hiện:

"SKU A tại TP.HCM còn đủ bán khoảng 2,3 ngày với sales velocity hiện tại."

Nhưng nếu inventory data chậm tám giờ thì recommendation đó có thể vô nghĩa.

Đây chính là một bài học quan trọng.

Chất lượng của hệ thống AI doanh nghiệp cuối cùng vẫn phụ thuộc rất nhiều vào chất lượng của Data Platform phía dưới.

21. Data Engineer sẽ thay đổi như thế nào sau 2027?

Không ai có thể dự đoán chính xác mọi công nghệ sẽ tồn tại trong năm 2030.

Nhưng một số hướng dịch chuyển đã khá rõ.

Coding thuần túy sẽ giảm giá trị tương đối

AI có thể viết SQL, Python và configuration ngày càng tốt.

Một Data Engineer dành phần lớn giá trị của mình cho việc nhớ syntax sẽ gặp áp lực.

Ngược lại, người biết dùng AI để tăng tốc implementation rồi dành thời gian cho architecture, quality, cost và reliability có thể tăng năng suất rất mạnh.

Có thể xem AI-generated code giống code của một junior engineer cực kỳ nhanh.

Nó có thể tạo ra rất nhiều code.

Nhưng Senior vẫn phải review.

Data Platform Engineering sẽ quan trọng hơn

Thay vì từng engineer tự tạo pipeline theo cách riêng, doanh nghiệp sẽ cố gắng chuẩn hóa.

Một Data Platform Team có thể cung cấp sẵn:

Pipeline Template
CI/CD
Secrets
Logging
Monitoring
Data Quality
Lineage
Permissions
Infrastructure

Data Engineer phía business domain chỉ cần tập trung nhiều hơn vào logic dữ liệu.

Đây tương tự xu hướng Platform Engineering trong Software Engineering.

Open Data Architecture tiếp tục phát triển

Open table format như Apache Iceberg đang tạo ra khả năng nhiều engine làm việc trên một lớp dữ liệu chung. Iceberg hiện cung cấp các capability như schema evolution, hidden partitioning, partition evolution, snapshots và REST Catalog phục vụ interoperability.

Điều này có thể làm ranh giới giữa Data Warehouse và Data Lakehouse tiếp tục mờ đi.

Metadata và Semantic trở nên quan trọng hơn

Khi người dùng truy cập dữ liệu bằng dashboard, họ có thể nhìn report definition.

Khi phần mềm hoặc AI tự query dữ liệu, metadata phải rõ hơn rất nhiều.

Một table không chỉ cần schema.

Nó còn cần owner, description, business definition, lineage, classification và relationship.

Data Catalog vì vậy đang có xu hướng phát triển từ "danh bạ table" thành lớp kiến thức về dữ liệu.

Data Engineer ngày càng gần Business

Người viết SQL thuần túy có thể được AI hỗ trợ rất mạnh.

Nhưng câu hỏi:

"Gross Margin của công ty này nên được định nghĩa thế nào?"

vẫn cần hiểu business.

Ở cấp Senior, Staff và Principal, Data Engineer sẽ ngày càng đứng tại giao điểm của:

Business
Data
Software
Architecture

và ở một số hệ thống còn thêm AI.

22. Data Engineer từ Junior đến Principal khác nhau ở đâu?

Có một cách nhìn khá thực tế.

Junior Data Engineer

Junior chủ yếu cần chứng minh mình có thể thực hiện một bài toán đã được xác định tương đối rõ.

Ví dụ:

"Xây pipeline load customer từ API vào warehouse."

Junior cần biết SQL, Python, database, Git, ETL và cloud cơ bản.

Middle Data Engineer

Middle bắt đầu chịu trách nhiệm cho production.

Không chỉ viết pipeline mà còn phải nghĩ tới retry, monitoring, performance, test và deployment.

Senior Data Engineer

Senior bắt đầu chịu trách nhiệm cho design và trade-off.

Không chỉ hỏi:

"Làm thế nào xây?"

mà hỏi:

"Có nên xây theo cách này không?"

Một Senior tốt có thể quyết định không sử dụng Kafka, và quyết định đó đôi khi thể hiện kinh nghiệm nhiều hơn việc triển khai Kafka thành công.

Staff và Principal

Ở cấp độ này câu hỏi thay đổi từ:

"Pipeline này thiết kế thế nào?"

thành:

"Công ty nên xây Data Platform như thế nào?"

Họ quan tâm đến platform strategy, architecture standards, governance, build versus buy, cost, scalability và cách nhiều team cùng phát triển trên một nền tảng.

Đây là lúc Data Engineering vượt khỏi phạm vi code.

23. Một nguyên tắc quan trọng: Đừng học Tool trước khi hiểu Problem

Ngành Data Engineering có rất nhiều công nghệ hấp dẫn.

Spark. Kafka. Flink. Iceberg. Airflow. dbt. Databricks. Snowflake. BigQuery. Kubernetes.

Nhưng người học nên chống lại cảm giác phải học tất cả.

Thay vào đó, hãy bắt đầu từ problem.

Nếu cần lưu dữ liệu analytics quy mô lớn, bạn tìm hiểu Warehouse hoặc Lakehouse.

Nếu cần xử lý event liên tục, bạn học Streaming.

Nếu có hàng nghìn job phụ thuộc nhau, bạn học Orchestration.

Nếu dữ liệu quá lớn cho một máy, bạn học Distributed Processing.

Nếu nhiều engine cần chia sẻ data lake, open table format bắt đầu có ý nghĩa.

Khi problem xuất hiện trước, tool sẽ có vị trí rõ ràng.

Khi tool xuất hiện trước, rất dễ rơi vào tình trạng:

Có chiếc búa nên mọi thứ nhìn giống cái đinh.

24. Vậy Data Engineer 2027 thực sự cần giỏi điều gì?

Nếu phải thu gọn toàn bộ bài viết thành một bản đồ năng lực, có thể nhìn theo năm lớp.

Lớp 1: Fundamentals

SQL, Python, Database, Linux, Git và Computer Science cơ bản.

Lớp 2: Data Fundamentals

ETL, ELT, Data Modeling, Warehouse, Data Lake, Batch, CDC và Streaming.

Lớp 3: Production Engineering

Orchestration, Testing, CI/CD, Monitoring, Data Quality, Security và Cost.

Lớp 4: Scale và Architecture

Distributed Processing, Spark, Kafka, Lakehouse, Open Table Format, Governance và Platform Engineering.

Lớp 5: Business và thế hệ Data Platform mới

Semantic Layer, Data Product, Metadata, unstructured data và cách Machine Learning hoặc AI sử dụng Data Platform.

Người mới không cần học hết lớp 5 để xin việc.

Nhưng nếu muốn trở thành Senior hoặc Architect, cuối cùng phải nhìn được toàn bộ bức tranh.

25. Kết luận: Data Engineer không phải người vận chuyển dữ liệu

Có một cách mô tả Data Engineer khá phổ biến:

"Người xây đường ống dữ liệu."

Cách ví von này dễ hiểu nhưng ngày càng không đủ.

Một hệ thống dữ liệu doanh nghiệp không chỉ có đường ống.

Nó có nguồn dữ liệu, storage, processing, modeling, security, governance, lineage, quality, observability, cost và rất nhiều consumer khác nhau.

Data Engineer phải đảm bảo tất cả những thứ đó có thể hoạt động cùng nhau.

Vì vậy một cách định nghĩa đầy đủ hơn là:

Data Engineer là người xây dựng và vận hành hạ tầng giúp dữ liệu trở thành một tài sản đáng tin cậy của doanh nghiệp.

Trong vài năm tới, AI sẽ viết ngày càng nhiều code.

Pipeline đơn giản sẽ dễ tạo hơn.

SQL thông thường sẽ dễ viết hơn.

Documentation sẽ dễ sinh hơn.

Một phần công việc hiện tại chắc chắn sẽ được tự động hóa.

Nhưng chính lúc đó, năng lực Engineering thật sự sẽ lộ rõ hơn.

Ai hiểu business?

Ai hiểu data grain?

Ai biết metric đang sai?

Ai biết tại sao pipeline bị duplicate?

Ai biết lúc nào nên batch và lúc nào nên streaming?

Ai biết kiến trúc đang over-engineering?

Ai biết query nào đang đốt tiền?

Ai biết dữ liệu nào có thể cho một hệ thống tự động sử dụng?

Ai có thể thiết kế một platform mà hàng chục team vẫn vận hành được sau nhiều năm?

Đó không còn là câu chuyện của một người chỉ biết viết ETL.

Đó là Data Engineering.

Nếu trước đây Data Platform chủ yếu phục vụ dashboard và báo cáo, thế hệ tiếp theo của Data Platform sẽ phải phục vụ đồng thời con người, phần mềm, analytics, Machine Learning và các hệ thống AI.

Phần nổi mà người dùng nhìn thấy có thể là một dashboard đẹp, một hệ thống dự báo hay một AI Agent có khả năng trả lời trong vài giây.

Nhưng phía dưới luôn cần một nền móng.

Dữ liệu phải đến đúng lúc.

Metric phải có nghĩa.

Schema phải được quản lý.

Pipeline phải có khả năng recover.

Quyền truy cập phải được kiểm soát.

Chi phí phải được tối ưu.

Và quan trọng nhất, dữ liệu phải đủ đáng tin để doanh nghiệp dựa vào nó mà ra quyết định.

Đó là lý do Data Engineering vẫn sẽ là một trong những nền tảng quan trọng nhất của kỷ nguyên Data và AI.

Không phải vì doanh nghiệp cần thêm thật nhiều pipeline.

Mà bởi vì khi doanh nghiệp ngày càng phụ thuộc vào dữ liệu, họ cần những người có khả năng biến hàng tỷ record rời rạc thành một hệ thống có cấu trúc, có ý nghĩa và có thể vận hành trong thế giới thật.

Tài liệu tham khảo và xu hướng công nghệ được sử dụng trong bài

Bài viết đưa ra góc nhìn cho năm 2027 dựa trên sự phát triển của hệ sinh thái Data & AI đến tháng 9/2026. Một số xu hướng kỹ thuật quan trọng có thể quan sát trực tiếp từ tài liệu của Apache Iceberg, Google Cloud, Databricks, Snowflake và dbt:

• Apache Iceberg tiếp tục phát triển theo hướng open table format, REST Catalog và interoperability giữa nhiều compute engine.
• Google Cloud đang phát triển Lakehouse dựa trên Apache Iceberg với khả năng interoperability giữa BigQuery, Spark, Flink, Trino và các môi trường cross-cloud.
• Databricks tiếp tục đưa data và AI governance về cùng một lớp Unity Catalog, đồng thời mở rộng governance sang AI agents và tools.
• Google Cloud đang chuyển Data Catalog từ metadata repository thành Knowledge Catalog phục vụ business semantics và agent context.
• Snowflake đang đưa semantic analytics, retrieval, tool calling và orchestration vào Cortex Agents.
• Các công cụ Data Engineering có AI hỗ trợ ngày càng mạnh, từ Google Cloud Data Engineering Agent đến natural-language data transformation, cho thấy phần implementation cơ học sẽ tiếp tục được tự động hóa.

Bạn đọc tới đây chứng tỏ bạn đam mê ngành Data Engineer thật sự. Nếu bạn đang có định hướng theo ngành Data Engineer hãy tham khảo khoá Data Engineer do TechData.AI tổ chức.

Bạn có thể tham khảo các khoá học khác theo link: https://techdata.ai/techdata-ai-course/

TechData.AI - Leading the Future.

Hoàng Minh.