Data Engineering 1 — Tổng quan & Vai trò

Data Engineering là gì?

Data Engineering (Kỹ thuật Dữ liệu) là ngành kỹ thuật chuyên thiết kế, xây dựng và vận hành các hệ thống cho phép thu thập, lưu trữ, biến đổi và phục vụ dữ liệu ở quy mô lớn, một cách tin cậy và lặp lại được. Nói ngắn gọn: Data Engineer xây "đường ống" và "kho chứa" để dữ liệu thô từ khắp nơi trở thành dữ liệu sạch, có cấu trúc, sẵn sàng cho phân tích và mô hình hóa.

Một định nghĩa thực dụng hơn: nếu Data Scientist và Data Analyst là người "nấu ăn" trên dữ liệu, thì Data Engineer là người lo nguyên liệu — đảm bảo nguyên liệu tươi, sạch, đến đúng giờ, đúng số lượng, và bếp (hạ tầng) luôn hoạt động.

Vì sao Data Engineering quan trọng?

Có một sự thật phũ phàng trong ngành dữ liệu: không có dữ liệu sạch và sẵn sàng thì mọi nỗ lực BI/AI đều vô nghĩa. Người ta thường trích dẫn rằng các nhóm phân tích và khoa học dữ liệu dành phần lớn thời gian (theo nhiều khảo sát là 60–80%) chỉ để tìm, làm sạch và chuẩn bị dữ liệu, thay vì thực sự phân tích.

Vài lý do cụ thể:

• "Rác vào, rác ra" (garbage in, garbage out): Một mô hình machine learning tinh vi đến đâu, nếu được huấn luyện trên dữ liệu sai, thiếu, hoặc lệch thời gian, thì kết quả cũng vô giá trị — thậm chí nguy hiểm vì người ta tin nó.
• Quy mô và tốc độ: Một báo cáo chạy tay trên Excel với 10.000 dòng là khả thi. Nhưng khi có hàng tỷ bản ghi giao dịch, cập nhật theo giờ, bạn bắt buộc cần hệ thống tự động hóa, song song hóa và chịu lỗi.
• Tính lặp lại và tin cậy: Báo cáo tài chính cuối ngày phải ra đúng con số, mỗi ngày, không phụ thuộc vào việc "ai bấm nút". Đây là bản chất kỹ thuật của Data Engineering: biến quy trình thủ công, dễ sai thành pipeline tự động, có giám sát.
• Quản trị và tuân thủ: Trong các ngành như ngân hàng, dữ liệu phải truy vết được nguồn gốc, kiểm soát quyền truy cập, và lưu trữ theo quy định. Đây cũng là trách nhiệm cốt lõi.

Phân biệt các vai trò trong nhóm dữ liệu

Người mới thường nhầm lẫn bốn vai trò: Data Engineer, Data Analyst, Data Scientist và ML Engineer. Chúng có giao thoa nhưng trọng tâm khác nhau rõ rệt.

Tiêu chí	Data Engineer	Data Analyst	Data Scientist	ML Engineer
Câu hỏi chính	Làm sao đưa dữ liệu đến đúng chỗ, đúng dạng, tin cậy?	Chuyện gì đã/đang xảy ra? Vì sao?	Điều gì sẽ xảy ra? Mẫu hình ẩn là gì?	Làm sao đưa mô hình vào sản xuất ổn định?
Sản phẩm đầu ra	Pipeline, kho dữ liệu, bảng sạch, API dữ liệu	Dashboard, báo cáo, phân tích	Mô hình, thử nghiệm, insight dự báo	Dịch vụ mô hình, hệ thống serving/monitoring
Kỹ năng lõi	SQL, Python, hệ phân tán, cloud, orchestration	SQL, BI tools, thống kê mô tả	Thống kê, ML, Python/R	MLOps, kỹ thuật phần mềm, hạ tầng
Quan tâm dữ liệu	Đường đi & chất lượng của dữ liệu	Ý nghĩa nghiệp vụ của dữ liệu	Quan hệ & dự báo trong dữ liệu	Vòng đời mô hình trên dữ liệu
Vị trí trong luồng	Thượng nguồn (chuẩn bị)	Hạ nguồn (tiêu thụ)	Hạ nguồn (tiêu thụ)	Song song (đưa kết quả ra ngoài)

Ranh giới thực tế thường mờ, đặc biệt ở công ty nhỏ nơi một người kiêm nhiều vai. Nhưng nguyên tắc cốt lõi: Data Engineer chịu trách nhiệm về cơ sở hạ tầng và độ tin cậy của dữ liệu; ba vai còn lại là những người tiêu thụ dữ liệu đó để tạo giá trị. Data Engineer thành công khi những người dưới hạ nguồn không phải lo lắng về việc dữ liệu có đúng và có sẵn hay không.

Vòng đời dữ liệu

Cách hữu ích nhất để hiểu công việc của Data Engineer là nhìn theo vòng đời dữ liệu — hành trình một mẩu dữ liệu đi từ nơi sinh ra đến nơi tạo ra quyết định.

Năm giai đoạn chính, cộng với một lớp xuyên suốt:

1. Nguồn dữ liệu (Sources)

Là nơi dữ liệu sinh ra. Ví dụ: cơ sở dữ liệu giao dịch của ứng dụng (PostgreSQL, Oracle), file CSV/Excel do nghiệp vụ upload, API của đối tác, log hệ thống, luồng sự kiện từ thiết bị, dữ liệu mạng xã hội. Mỗi nguồn có định dạng, tốc độ thay đổi và độ tin cậy riêng.

2. Thu thập (Ingestion)

Là quá trình kéo/đẩy dữ liệu từ nguồn vào hệ thống dữ liệu trung tâm. Có hai chế độ chính:

• Batch (theo lô): gom dữ liệu theo chu kỳ — ví dụ mỗi đêm lấy toàn bộ giao dịch trong ngày. Đơn giản, phù hợp với báo cáo định kỳ.
• Streaming (luồng): dữ liệu chảy gần như tức thời theo từng sự kiện — ví dụ cảnh báo gian lận ngay khi giao dịch xảy ra.

Một khái niệm quan trọng đi kèm là CDC (Change Data Capture) — chỉ lấy phần thay đổi (insert/update/delete) thay vì sao chép lại toàn bộ, giúp tiết kiệm tài nguyên và giữ dữ liệu gần thời gian thực.

3. Lưu trữ (Storage)

Nơi dữ liệu nằm lại. Lựa chọn phụ thuộc vào mục đích:

• Database (OLTP): tối ưu cho ghi/đọc giao dịch nhỏ, nhanh.
• Data Warehouse (OLAP): tối ưu cho truy vấn phân tích trên khối lượng lớn.
• Data Lake: lưu dữ liệu thô đủ loại định dạng, chi phí thấp, linh hoạt.

Đây là chủ đề sẽ được đào sâu ở các bài sau (định dạng file, nén, phân vùng, định dạng cột như Parquet).

4. Xử lý / Biến đổi (Transformation)

Dữ liệu thô hiếm khi dùng được ngay. Giai đoạn này làm sạch (xử lý giá trị thiếu, sai định dạng), chuẩn hóa (gộp đơn vị, chuẩn hóa mã), kết hợp (join nhiều nguồn) và tổng hợp (tính toán chỉ số). Đây là nơi các mô hình ETL (Extract–Transform–Load) và ELT (Extract–Load–Transform) phát huy tác dụng — sự khác biệt nằm ở chỗ biến đổi trước hay sau khi nạp vào kho.

5. Phục vụ (Serving)

Đưa dữ liệu đã sẵn sàng đến tay người/hệ thống tiêu thụ: bảng phân tích cho BI, feature store cho ML, API dữ liệu cho ứng dụng, hoặc tập dữ liệu xuất ra cho đối tác.

Lớp xuyên suốt: Quản trị (Governance)

Không phải một bước riêng mà bao trùm toàn bộ: bảo mật và phân quyền, chất lượng dữ liệu (data quality), truy vết nguồn gốc (data lineage), danh mục dữ liệu (data catalog), và tuân thủ quy định. Trong ngân hàng, đây là phần không thể xem nhẹ.

OLTP vs OLAP — giới thiệu

Đây là một trong những phân biệt nền tảng nhất của ngành. Sẽ được đào sâu ở bài riêng, nhưng cần nắm ý niệm ngay từ đầu:

Tiêu chí	OLTP	OLAP
Mục đích	Xử lý giao dịch (vận hành)	Phân tích (ra quyết định)
Thao tác điển hình	Đọc/ghi nhiều bản ghi nhỏ	Quét tổng hợp khối lượng lớn
Ví dụ	Chuyển tiền, mở tài khoản	"Tổng dư nợ theo chi nhánh theo tháng"
Thiết kế dữ liệu	Chuẩn hóa (normalized)	Phi chuẩn hóa, mô hình sao (star schema)
Đại diện	PostgreSQL, Oracle, MySQL	Snowflake, BigQuery, Redshift

Một nguyên tắc vàng: đừng chạy truy vấn phân tích nặng trực tiếp trên hệ thống OLTP đang phục vụ giao dịch — nó sẽ làm chậm hoặc sập nghiệp vụ. Đây chính là lý do tồn tại của data warehouse, và cũng là lý do tồn tại phần lớn công việc Data Engineering: tách dữ liệu vận hành ra một nơi an toàn để phân tích.

Bức tranh hệ sinh thái công cụ

Thị trường công cụ dữ liệu (thường gọi là "modern data stack") rất rộng và dễ gây ngợp. Dưới đây là bản đồ tổng quan theo từng tầng chức năng, để bạn định vị mọi công cụ gặp sau này.

• Databases (OLTP): PostgreSQL, MySQL, Oracle, SQL Server — nơi dữ liệu vận hành sinh ra.
• Data Warehouse (OLAP): Snowflake, Google BigQuery, Amazon Redshift, ClickHouse — kho phân tích.
• Data Lake / Lakehouse: lưu trữ object (Amazon S3, GCS, HDFS) kết hợp định dạng bảng mở như Apache Iceberg, Delta Lake, Apache Hudi.
• Pipeline & Orchestration: Apache Airflow, Dagster, Prefect — điều phối các bước chạy theo thứ tự, lịch và phụ thuộc.
• Transformation: dbt (biến đổi bằng SQL trong warehouse), Apache Spark (xử lý phân tán quy mô lớn).
• Streaming: Apache Kafka, Apache Flink, Spark Structured Streaming — cho dữ liệu thời gian thực.
• Ingestion / Connector: Airbyte, Fivetran, Debezium (cho CDC).
• BI / Phục vụ: Power BI, Tableau, Looker, Metabase, Superset.
• Governance: data catalog, data quality (Great Expectations, dbt tests), lineage.

Đừng cố học hết tất cả. Hãy hiểu tầng chức năng trước; công cụ cụ thể chỉ là cách hiện thực một chức năng. Khi gặp công cụ mới, câu hỏi đầu tiên luôn là: "Nó nằm ở tầng nào trong vòng đời dữ liệu?"

Kỹ năng cốt lõi của Data Engineer

Bốn nhóm kỹ năng nền tảng, theo thứ tự ưu tiên cho người mới:

1. SQL — ngôn ngữ phổ quát của dữ liệu. Phải thật vững: join, group by, window functions, subquery, tối ưu truy vấn. Hầu như mọi công việc đều chạm tới SQL.
2. Python — ngôn ngữ keo dán: viết script ingestion, gọi API, xử lý dữ liệu với pandas/PySpark, định nghĩa pipeline trong Airflow. Cần kỹ năng lập trình sạch, có test, có log.
3. Hệ phân tán — hiểu nguyên lý song song hóa, phân vùng (partitioning), shuffle, và vì sao xử lý dữ liệu lớn lại khác xử lý dữ liệu nhỏ. Đại diện điển hình: Apache Spark.
4. Cloud — phần lớn hạ tầng dữ liệu hiện đại chạy trên AWS, GCP hoặc Azure. Cần biết object storage, IAM/quyền, compute co giãn, và dịch vụ warehouse được quản lý.

Bên cạnh đó là tư duy kỹ thuật phần mềm: kiểm soát phiên bản (Git), CI/CD, viết test, modular hóa, và đặc biệt là tư duy về độ tin cậy — idempotency (chạy lại không gây sai lệch), retry, monitoring và alerting.

Bối cảnh ngân hàng: đưa dữ liệu core sang kho phân tích

Trong môi trường ngân hàng, bài toán kinh điển của Data Engineering là: dữ liệu sinh ra trong hệ thống core banking (OLTP) cần được đưa sang một kho phân tích (OLAP) để báo cáo và mô hình hóa, mà không ảnh hưởng đến hệ thống giao dịch đang vận hành.

Một luồng điển hình:

1. Nguồn: core banking (thường là Oracle/DB2), các hệ thống thẻ, khoản vay, tiền gửi.
2. Ingestion: dùng CDC (ví dụ qua Debezium/golden gate) hoặc batch ban đêm để trích xuất, tránh tải nặng lên hệ thống đang chạy.
3. Storage: đổ vào data lake (vùng raw/staging) rồi nạp vào data warehouse.
4. Transformation: làm sạch, chuẩn hóa mã sản phẩm/chi nhánh, dựng các bảng dimension/fact phục vụ phân tích (ví dụ mô hình dữ liệu cho dư nợ, huy động, rủi ro).
5. Serving: cung cấp cho báo cáo giám sát (ví dụ báo cáo cho ngân hàng nhà nước), dashboard quản trị, và dữ liệu cho mô hình tín dụng/chấm điểm rủi ro.
6. Governance: kiểm soát quyền theo vai trò, che/giả lập dữ liệu nhạy cảm (PII), truy vết nguồn gốc mỗi con số, và lưu trữ theo quy định.

Đặc thù ngân hàng đặt ra yêu cầu cao hơn bình thường về độ chính xác tuyệt đối (sai một con số tài chính là vấn đề nghiêm trọng), kiểm toán (mọi thay đổi phải truy vết được) và bảo mật (dữ liệu khách hàng cực kỳ nhạy cảm). Điều này khiến Data Engineering trong ngân hàng không chỉ là kỹ thuật, mà còn gắn chặt với quy trình và tuân thủ.

Tóm tắt

• Data Engineering là ngành xây dựng và vận hành hệ thống đưa dữ liệu thô thành dữ liệu sạch, tin cậy, sẵn sàng cho phân tích và AI. Không có nền tảng dữ liệu tốt, mọi BI/AI đều vô nghĩa.
• Vòng đời dữ liệu: nguồn → thu thập (ingestion) → lưu trữ (storage) → xử lý (transformation) → phục vụ (serving), với quản trị (governance) bao trùm toàn bộ.
• Phân biệt vai trò: Data Engineer lo hạ tầng và độ tin cậy của dữ liệu; Analyst, Scientist và ML Engineer là người tiêu thụ dữ liệu đó.
• OLTP vs OLAP là phân biệt nền tảng: không chạy phân tích nặng trên hệ thống giao dịch — đây là lý do tồn tại của data warehouse.
• Kỹ năng lõi: SQL, Python, hệ phân tán, cloud, cộng với tư duy kỹ thuật phần mềm về độ tin cậy.
• Trong ngân hàng: bài toán cốt lõi là đưa dữ liệu core (OLTP) sang kho phân tích (OLAP) an toàn, chính xác, có kiểm toán và bảo mật.

Tự kiểm tra

1. Vì sao không nên chạy các truy vấn phân tích nặng trực tiếp trên hệ thống OLTP đang phục vụ giao dịch? Điều này dẫn đến sự tồn tại của loại hệ thống nào?
2. Hãy sắp xếp đúng thứ tự năm giai đoạn của vòng đời dữ liệu và nêu một ví dụ ngân hàng cho mỗi giai đoạn.
3. Khác biệt cốt lõi giữa Data Engineer và Data Scientist là gì? Ai là người "tiêu thụ" dữ liệu, ai là người "chuẩn bị"?
4. Phân biệt ingestion theo batch và theo streaming. CDC giải quyết vấn đề gì?
5. Kể tên ít nhất một công cụ đại diện cho mỗi tầng: warehouse, orchestration, transformation, streaming, BI.

Đọc tiếp

Data Engineering 2 — Định dạng & Lưu trữ