Bỏ qua nội dung
Sổ tay Kỹ thuật Dữ liệu

Boring Data Engineering: khi SQL, cron và database vẫn là lựa chọn đúng

“Boring” trong Data Engineering không có nghĩa là cũ kỹ hay lười đổi mới. Nó nghĩa là ưu tiên những thứ dễ hiểu, dễ debug, dễ bàn giao và đã đủ tốt cho bài toán hiện tại. Chương “Simplicity” trong Google SRE Book cũng đặt simplicity như một yêu cầu vận hành, không phải sở thích thẩm mỹ: Simplicity.

Đọc trong site trước khi áp dụng: Data Pipeline, ETL, ELT, Idempotency.

Nhiều hệ thống dữ liệu thất bại không phải vì thiếu Kafka, Spark hay Kubernetes. Chúng thất bại vì không có owner, không có test, không có log, không có idempotency, không ai biết bảng nào là nguồn sự thật.

Khi nào boring là đúng?

Bối cảnhLựa chọn thường đủ tốt
Dữ liệu vài GB/ngàySQL, warehouse, batch job
Báo cáo cập nhật hằng ngàyCron/Airflow đơn giản
Nguồn là database quan hệELT vào warehouse
Team nhỏManaged service, ít custom platform
SLA theo giờBatch đáng tin hơn streaming phức tạp

Nếu business chỉ cần báo cáo trước 8 giờ sáng, hệ thống streaming realtime có thể là chi phí không cần thiết.

SQL là nền tảng, không phải phương án tạm

SQL vẫn là ngôn ngữ chung giữa engineer, analyst và nhiều database engine. Với nhiều pipeline transformation, SQL trong warehouse dễ review và vận hành hơn Python tùy biến.

SQL tốt cần:

  • Model rõ grain.
  • CTE đặt tên theo bước logic.
  • Test cho khóa và reconciliation.
  • Query có filter partition.
  • Không nhúng business logic khác nhau ở nhiều dashboard.

Liên quan trong site: SQL Transformation, Materialization, Metrics Layer.

Cron không xấu, cron thiếu guardrail mới xấu

Cron phù hợp cho job nhỏ, ít phụ thuộc, dễ chạy lại. Google SRE có hẳn chương về distributed cron, một dấu hiệu rằng scheduling đơn giản vẫn là vấn đề production thật chứ không phải chuyện “đồ cũ”: Distributed Periodic Scheduling with Cron. Nhưng cron production cần guardrail:

  • Log đầy đủ.
  • Lock hoặc idempotency để tránh chạy trùng.
  • Alert khi job không chạy hoặc chạy lỗi.
  • Runbook khi phải rerun.
  • Cấu hình được version control.

Nếu job bắt đầu có nhiều dependency, backfill phức tạp, retry nhiều bước hoặc cần lineage, hãy chuyển sang Airflow/Dagster/Prefect.

Một cron job “boring nhưng chuẩn production” chỉ dài hơn cron job cẩu thả vài dòng:

#!/usr/bin/env bash
set -euo pipefail                     # fail sớm, không nuốt lỗi
exec 200>/var/lock/daily_load.lock
flock -n 200 || exit 0                # lock chống chạy trùng khi job trước còn treo


DS="${1:-$(date -d yesterday +%F)}"   # nhận ngày làm tham số → backfill được
psql -v ds="$DS" -f load_orders.sql 2>&1 | tee -a "/var/log/etl/daily_load_$DS.log"


curl -fsS "https://hc-ping.com/daily-load"   # dead-man switch: KHÔNG ping = alert

Bốn dòng guardrail (set -euo pipefail, flock, tham số ngày, dead-man ping) xử lý đúng bốn sự cố phổ biến nhất của cron: lỗi bị nuốt, chạy chồng, không backfill được, và chết im lặng không ai biết. Chi phí: 10 phút viết. Đây chính là tinh thần boring engineering — độ tin cậy đến từ kỷ luật nhỏ chứ không phải công cụ to.

Liên quan trong site: DAG, Orchestration, Backfill, Data Lineage.

Khi nào cần vượt khỏi boring stack?

Tín hiệuCó thể cần
Batch không còn kịp SLASpark, Dataflow, distributed compute
Cần phản ứng trong vài giâyKafka, Flink, streaming engine
Dữ liệu update/delete lớn trên object storageIceberg, Delta, Hudi
Nhiều team tự phục vụData platform, template, governance
Chi phí query tăng mạnhPartition, materialization, workload optimization

Đừng nâng cấp kiến trúc vì sợ bị lạc hậu. Nâng cấp khi bài toán đã vượt quá khả năng của kiến trúc hiện tại và bạn đo được lý do.

Một boring stack đáng tin

flowchart TD
    A["Source database / API"] --> B["Raw storage"]
    B --> C["SQL transformations"]
    C --> D["Warehouse marts"]
    D --> E["BI / reverse ETL"]
    C --> F["Tests and reconciliation"]
    F --> G["Alert + runbook"]

Checklist tối thiểu:

  • Mỗi bảng quan trọng có owner.
  • Mỗi pipeline quan trọng có log, alert và runbook.
  • Mỗi metric quan trọng có định nghĩa.
  • Mỗi thay đổi schema có quy trình báo trước.
  • Mỗi job có cách chạy lại an toàn.

Cạm bẫy của “boring”

Boring không đồng nghĩa với bỏ mặc legacy. Nếu hệ thống cũ không có test, không có documentation, không có audit và ai nghỉ việc cũng làm team hoảng, đó không phải boring engineering. Đó là nợ vận hành.

Mục tiêu là đơn giản có kỷ luật, không phải đơn giản vì thiếu đầu tư.

References

Trang chủ (Bản đồ tri thức)

Bình luận & Thảo luận