Nguồn NotebookLM: Streaming Engineering

Kafka là gì? Một log sự kiện cho nhiều hệ thống

Nguồn gốc: Kafka là gì? Một log sự kiện cho nhiều hệ thống. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Một đơn vừa thanh toán cần xuất hiện trong báo cáo, hệ thống giao hàng và kiểm tra gian lận. Nếu ứng dụng bán hàng gọi trực tiếp cả ba hệ thống, một bên chậm có thể kéo theo request bán hàng. Kafka cho phép ứng dụng ghi sự kiện vào một log, rồi các hệ thống đọc theo tiến độ riêng.

Kafka lưu record trong topic, chia topic thành partition. Producer gửi record; consumer đọc record. Broker phục vụ dữ liệu; controller quản lý metadata và điều phối cluster. Kafka 4.0 dùng KRaft, không dùng hướng dẫn ZooKeeper cũ để cài phiên bản này.

Đọc không xóa record khỏi log. Retention quyết định dữ liệu còn giữ bao lâu hoặc bao nhiêu; consumer chậm quá có thể mất cơ hội replay. Kafka cũng không tự suy ra trạng thái thanh toán đúng từ các sự kiện trùng hoặc sai.

Thử một broker cục bộ

Ví dụ dùng Kafka 4.0.2, JDK 17, macOS Intel, kiểm tra ngày 1/10/2026. Đây là môi trường học một node, không có TLS/xác thực hay khả năng chịu lỗi nhiều broker. Linux/WSL chưa được kiểm thử trong đợt này. Cài JDK 17 và đặt JAVA_HOME tới JDK trước; chạy java -version để kiểm tra.

Tải bản binary kafka_2.13-4.0.2.tgz từ kho Apache và giải nén vào thư mục thực hành riêng. Sau đó mở terminal tại thư mục kafka_2.13-4.0.2. Tạo file config/cafe-local.properties với nội dung sau. Hai listener chỉ nghe trên máy bạn; storage riêng trong cafe-data-v1. Nếu thư mục đã có dữ liệu từ bài khác, chọn tên mới thay vì format lại.

process.roles=broker,controller
node.id=1
controller.quorum.bootstrap.servers=localhost:19093
listeners=PLAINTEXT://127.0.0.1:19092,CONTROLLER://127.0.0.1:19093
advertised.listeners=PLAINTEXT://localhost:19092,CONTROLLER://localhost:19093
controller.listener.names=CONTROLLER
listener.security.protocol.map=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT
inter.broker.listener.name=PLAINTEXT
log.dirs=./cafe-data-v1
num.partitions=1
offsets.topic.replication.factor=1
transaction.state.log.replication.factor=1
transaction.state.log.min.isr=1

Tạo ID cho cluster:

bin/kafka-storage.sh random-uuid

Copy UUID nhận được vào lệnh format bên dưới. Chỉ format storage mới dành riêng cho ví dụ, không chạy trên cluster đang có dữ liệu.

bin/kafka-storage.sh format --standalone -t UUID_VUA_TAO -c config/cafe-local.properties
bin/kafka-server-start.sh config/cafe-local.properties

Giữ terminal broker mở. Terminal khác, tại cùng thư mục, chạy:

bin/kafka-topics.sh --bootstrap-server localhost:19092 --create --topic cafe-v1 --partitions 1 --replication-factor 1
bin/kafka-console-producer.sh --bootstrap-server localhost:19092 --topic cafe-v1

Nhập hai dòng, mỗi dòng là một sự kiện; event_id là ID sự kiện, order_id là ID đơn, tiền là đồng nguyên:

{"event_id":"E1","order_id":101,"amount_dong":40000}
{"event_id":"E2","order_id":102,"amount_dong":35000}

Kết thúc producer bằng Ctrl-C rồi đọc bằng group thực hành mới:

bin/kafka-console-consumer.sh --bootstrap-server localhost:19092 --topic cafe-v1 --group cafe-reader-v1 --from-beginning --max-messages 2

Kết quả là hai dòng JSON vừa nhập, theo thứ tự ghi trong partition duy nhất. Kafka coi value là byte; không tự kiểm tra JSON schema. Nếu chạy lại producer, topic sẽ có thêm record: Kafka không tự loại trùng event_id.

Dừng broker bằng Ctrl-C. Khởi động lại với cùng config/storage để giữ dữ liệu; không format lại. Nếu topic đã tồn tại, dùng topic mới hoặc tiếp tục đọc topic cũ và không kỳ vọng chỉ có hai record. Nếu cổng 19092 hoặc 19093 bị chiếm, dừng broker thực hành trước đó hoặc đổi cả listener, advertised listener và địa chỉ client cho phù hợp. Không xóa storage của dịch vụ khác.

Khi nào cần Kafka?

Kafka hữu ích khi nhiều hệ thống cần cùng luồng sự kiện, cần tách tốc độ xử lý và replay. Nếu chỉ chuyển một file mỗi ngày giữa hai ứng dụng, một pipeline batch có thể đơn giản hơn. Vận hành Kafka thêm chi phí theo dõi lag, dung lượng, replication, bảo mật và schema.

Đọc topic/partition rồi consumer group.

Tài liệu gốc

Quick Start 4.0 mô tả bootstrap KRaft và console tools. Kafka design giải thích mô hình log, retention và replay. Đối chiếu ngày 1/10/2026.

Flink là gì? Xử lý luồng có trạng thái

Nguồn gốc: Flink là gì? Xử lý luồng có trạng thái. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Báo cáo cần cập nhật ngay khi đơn đến, nhưng một đơn có thể đến muộn hoặc được gửi lại. Nếu chỉ cộng mỗi record vừa nhận vào một biến, restart có thể mất tổng cũ, còn retry có thể cộng trùng. Flink là engine xử lý dữ liệu hỗ trợ state và cơ chế phục hồi để xây các phép xử lý như vậy.

Bộ bài này đối chiếu Flink 1.20.3 ngày 1/10/2026, không coi đây là phiên bản mới nhất. Các ví dụ là mô hình kiểm tra bằng tay, không phải kết quả đã chạy cluster. Hướng dẫn cài local và lab restart có connector thật còn đang biên soạn; chưa có tuyên bố hỗ trợ một tổ hợp OS/JDK đã kiểm thử.

Theo dõi một phép tổng hợp

Mỗi sự kiện là một lần thanh toán, có event_id riêng, cửa hàng và số tiền nguyên đồng. Nhận lần lượt E1/A/40000, E2/B/50000, E3/A/35000. Với key cửa hàng, state sau ba record là A=75000, B=50000. Bạn có thể cộng tay để kiểm tra.

Nếu E1 đến thêm lần nữa và job chỉ cộng tiền, A thành 115000. Exactly-once của state khi phục hồi không tự hiểu hai record E1 là cùng một sự kiện nghiệp vụ. Muốn deduplicate cần lưu identity và định nghĩa thời hạn giữ identity phù hợp với khả năng replay.

Các thành phần cần hiểu

Source đọc dữ liệu, operator biến đổi/tổng hợp, sink ghi output. State giữ thông tin qua nhiều record. Event time quyết định sự kiện thuộc khoảng thời gian nào; watermark giúp job tiến triển dù dữ liệu không đến đúng thứ tự. Checkpoint ghi nhận state và tiến độ nguồn để phục hồi.

Flink không tự thay database lưu trữ lâu dài hay Kafka giữ lịch sử sự kiện. State backend và checkpoint storage cũng là hai vai trò khác nhau: nơi truy cập state khi chạy và nơi lưu snapshot phục hồi.

Khi nào đáng dùng?

Flink phù hợp khi cần xử lý luồng có trạng thái, cửa sổ thời gian, join sự kiện và kiểm soát phục hồi. Nếu chỉ chạy một truy vấn tổng hợp mỗi ngày, batch SQL có thể đơn giản hơn. Streaming thêm trách nhiệm về dữ liệu muộn, state tăng, checkpoint, sink và nâng cấp job.

Khi output ngừng cập nhật, không mặc định tăng parallelism: watermark có thể bị giữ bởi một input im lặng, sink có thể bị nghẽn hoặc job đang restart. Đọc kiến trúc, state rồi event time.

Tài liệu gốc

Tài liệu Apache Flink 1.20 — stateful-stream-processing là nguồn đối chiếu cơ chế trong bài.

Watermark trong Flink: khi nào cửa sổ được tiến lên?

Nguồn gốc: Watermark trong Flink: khi nào cửa sổ được tiến lên?. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Cửa sổ 10:00–10:05 đã qua trên đồng hồ máy nhưng Flink chưa xuất kết quả. Một input có thể chưa phát watermark đủ cao. Event-time processing cần một tín hiệu tiến độ từ dữ liệu, không chỉ từ đồng hồ máy.

Watermark không phải lời hứa không còn dữ liệu muộn

Watermark biểu diễn tiến độ event time theo chính sách ứng dụng/source. Ví dụ chiến lược cho phép out-of-orderness hai phút tạo tiến độ dựa trên timestamp lớn nhất đã thấy trừ khoảng chờ. Dữ liệu cũ vẫn có thể đến sau đó; ứng dụng phải chọn nhận cập nhật, đưa sang side output hoặc loại theo chính sách.

Input chậm giữ watermark chung

Bài tập minh họa, giả sử operator có hai input đang hoạt động:

Watermark downstream lấy mức chậm nhất là 10:03. Chỉ P0 tiến lên 10:10 vẫn chưa kéo downstream vượt P1. Nếu P1 im lặng, cấu hình idleness phù hợp có thể loại input idle khỏi phép lấy minimum; khi dữ liệu của P1 quay lại, các record cũ có thể bị coi là muộn.

Window và allowed lateness

Với cửa sổ [10:00,10:05), khi watermark vượt qua timestamp cuối cửa sổ, event-time trigger có thể phát kết quả. Với allowed lateness dương, một số state còn được giữ thêm để nhận cập nhật. Kết quả ban đầu không nhất thiết là kết quả cuối.

Giả sử cửa sổ đã emit tổng 40000 và chính sách vẫn chấp nhận một đơn muộn 35000. Tổng cập nhật là 75000; sink cần hiểu đó là cập nhật, không cộng thêm một “cửa sổ mới” 75000 vào tổng cũ. Nếu state đã bị dọn, chính sách có thể đưa record sang luồng late-data thay vì sửa tổng.

Chẩn đoán

Theo dõi watermark của source/operator, timestamp cực trị, input idle và tốc độ ingest. Một record timestamp ở tương lai xa có thể làm watermark tiến sai và khiến dữ liệu hợp lệ bị muộn. Tăng allowed lateness làm state giữ lâu hơn; không miễn phí về bộ nhớ.

Bài này đối chiếu Flink 1.20.3, dùng watermark minh họa có thể kiểm tra bằng tay; không mô phỏng thuật toán phát watermark theo chu kỳ hay độ lệch một mili giây ở runtime.

Tài liệu gốc

Tài liệu Apache Flink 1.20 — generating_watermarks là nguồn đối chiếu cơ chế trong bài.

Windows và allowed lateness mô tả trigger, cleanup và xử lý dữ liệu muộn.

Batch hay Streaming?

Nguồn gốc: Batch hay Streaming?. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Report tài chính cần chốt mỗi ngày, còn hệ thống phát hiện thanh toán bất thường cần phản ứng trong vài giây. Cả hai xử lý data, nhưng yêu cầu về thời gian khác nhau.

Batch Processing xử lý một tập data hữu hạn. Stream Processing (xử lý luồng data liên tục) xử lý các event khi chúng tiếp tục đến.

    flowchart TD
 A["Business cần kết quả khi nào?"] --> B{"Trong vài giây?"}
 B -->|Không| C["Bắt đầu với Batch"]
 B -->|Có| D["Xem xét Streaming"]
 D --> E["Chấp nhận thêm độ phức tạp vận hành?"]
  

Cùng một bài toán, hai cách

Batch gom order trong cửa sổ năm phút rồi tính tổng. Streaming cập nhật tổng khi từng event đến. Sau năm phút, hai output có thể giống nhau; khác biệt là thời điểm nhìn thấy kết quả và cách hệ thống đạt đến đó.

Streaming không đồng nghĩa data luôn đúng ngay lập tức. Event có thể đến trễ, sai thứ tự hoặc được gửi lại. Hệ thống phải quyết định bao lâu sẽ chờ và khi nào cập nhật kết quả cũ.

Chọn theo yêu cầu thật

Nếu người dùng xem dashboard mỗi sáng, pipeline mỗi đêm có thể đủ. Nếu fraud decision phải chặn giao dịch trước khi hoàn tất, batch một giờ không đáp ứng được. Đừng chọn Streaming chỉ vì volume lớn: một batch engine vẫn xử lý được data rất lớn. Lý do chính thường là latency và nhu cầu phản ứng liên tục.

Nhiều hệ thống dùng cả hai: Streaming cho tín hiệu sớm, Batch để đối soát và sửa lịch sử. Hãy bắt đầu với phương án đơn giản đáp ứng SLA rồi chỉ thêm độ phức tạp khi giá trị của kết quả sớm đủ lớn.

Stream Processing: xử lý data liên tục

Nguồn gốc: Stream Processing: xử lý data liên tục. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Mỗi khi order đổi trạng thái, application phát một event. Team vận hành muốn số order đang chờ tài xế được cập nhật trong vài giây.

Stream Processing (xử lý luồng data liên tục) đọc một dòng event không có điểm kết thúc đã biết và cập nhật output khi event đến.

    flowchart TD
 A["Order events"] --> B["Stream processor"]
 B --> C["State<br/>Order hiện tại"]
 C --> D["Output<br/>Số order đang chờ"]
  

Một event có thể là:

{"event_id":"EV-91","order_id":"ORD-1042","status":"driver_assigned","occurred_at":"2026-09-08T12:08:00+08:00"}

Event time và processing time

Event Time là lúc sự việc xảy ra. Processing Time là lúc processor nhận và xử lý nó. Mạng chậm có thể khiến event 12:08 đến sau event 12:10.

Window tính theo Event Time cần chờ một khoảng cho event đến muộn. Watermark là ước lượng rằng phần lớn event trước một mốc đã đến; event muộn hơn chính sách có thể cập nhật kết quả cũ hoặc đi vào nơi xử lý riêng.

State và duplicate

Để đếm order đang chờ, processor phải nhớ trạng thái trước đó. State cần được checkpoint để khôi phục sau lỗi. Event cũng có thể được giao lại, nên event_id hoặc phép cập nhật idempotent giúp tránh đếm hai lần.

Streaming đưa thêm các câu hỏi về ordering, state, replay, late data và capacity liên tục. Nếu output chỉ cần mỗi giờ, Batch thường dễ vận hành hơn. Streaming phù hợp khi giá trị của phản ứng sớm đủ lớn để trả chi phí phức tạp đó.

Idempotency: chạy lại pipeline mà không tạo duplicate

Nguồn gốc: Idempotency: chạy lại pipeline mà không tạo duplicate. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Pipeline đã ghi xong 900 order thì mất kết nối. Bạn không biết 100 order cuối đã được ghi hay chưa, nên chạy lại cả lô. Nếu job dùng INSERT, bảng có thể xuất hiện duplicate.

Idempotency (khả năng chạy lại mà không tạo thêm kết quả ngoài ý muốn) nghĩa là xử lý cùng input một hay nhiều lần vẫn đưa hệ thống đến cùng trạng thái.

    flowchart TD
 A["Input<br/>ORD-1042"] --> B["Chạy lần 1"] --> C["Một row ORD-1042"]
 A --> D["Chạy lại"] --> E["Vẫn một row ORD-1042"]
  

Dùng business key để nhận diện row

order_id cho biết hai lần nhận được có phải cùng một order hay không.

Thay vì luôn thêm row, pipeline có thể Upsert: thêm khi key chưa tồn tại, cập nhật khi key đã có.

INSERT INTO orders (order_id, status, amount)
VALUES ('ORD-1042', 'paid', 120000)
ON CONFLICT (order_id) DO UPDATE
SET status = EXCLUDED.status,
    amount = EXCLUDED.amount;

Với bảng tổng hợp theo ngày, một cách khác là tính lại toàn bộ partition rồi thay thế nguyên khối. Xoá rồi ghi lại cần transaction hoặc vùng tạm; nếu job dừng sau bước xoá, người dùng sẽ thấy data trống.

Không phải lúc nào key cũng rõ

Một payment retry có thể tạo nhiều transaction hợp lệ cho cùng order. Dùng order_id làm key sẽ ghi đè nhầm. Key phải phản ánh grain: nếu mỗi row là một lần thanh toán, payment_id mới phù hợp.

Idempotency cần được test bằng cách cố tình chạy cùng lô hai lần và so cả số row lẫn metric. Đây là nền tảng để Retry và Backfill an toàn.

Tính nhất quán dữ liệu

Nguồn gốc: Tính nhất quán dữ liệu. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Bạn đổi tên cửa hàng thành “Cà phê Góc Phố”, màn hình báo thành công, nhưng lần tải trang tiếp theo lại hiện tên cũ. Dữ liệu có thể đã ghi đúng ở một nơi và chưa tới nơi phục vụ lượt đọc. Nói hệ thống “nhất quán” cần chỉ rõ nó hứa điều gì với người đọc.

Đừng nhầm tính nhất quán giữa các bản sao với consistency trong ACID, nơi mình nói về ràng buộc và trạng thái hợp lệ của giao dịch.

Ba câu hỏi khác nhau

• Sau khi chính mình ghi, mình có đọc được thay đổi đó không? Đây là read-your-writes.
• Các lần đọc của mình có tránh đi lùi về phiên bản cũ hơn không? Đây là monotonic reads.
• Một lượt đọc bắt đầu sau khi một lượt ghi đã hoàn thành có phản ánh lượt ghi đó hoặc một ghi sau nó không? Đây là một hệ quả quan trọng của linearizability.

Hai đảm bảo đầu thường được xét trong một phiên người dùng. Chúng không tự đảm bảo mọi client cùng nhìn một trạng thái mới nhất.

Kiểm tra một lịch đọc bằng tay

Giả sử chỉ có một lần ghi từ tên cũ sang tên mới, không có ghi cạnh tranh:

Lịch này vi phạm read-your-writes của A và không phù hợp với linearizable register. Nó vẫn có thể phù hợp với eventual consistency nếu các bản sao cuối cùng hội tụ khi không có ghi mới và hệ thống truyền, giải quyết thay đổi như thiết kế.

Eventual consistency không tự nói “trong 5 giây”. Nếu cần độ cũ tối đa, phải đặt một cam kết và đo riêng. Hệ thống cũng cần cách xử lý các cập nhật cạnh tranh; “chờ một lúc” không tự chọn được phiên bản đúng.

Chọn theo tác động tới người dùng

Một trang thống kê lượt xem có thể chấp nhận dữ liệu cũ. Kiểm tra tồn kho hoặc trạng thái vừa thanh toán có thể cần lời hứa mạnh hơn. Có thể đọc từ leader, truyền phiên bản cần thấy hoặc chờ replica bắt kịp, tùy hệ thống. Mỗi cách có ảnh hưởng tới độ trễ và khả năng phục vụ khi lỗi.

Không nên suy ra linearizability chỉ vì đọc từ leader: implementation còn phải bảo đảm leader có thẩm quyền và phản ánh các ghi đã commit.

Tham khảo định nghĩa linearizability trong Gilbert và Lynch, mục 2.1, và một thiết kế xử lý các bản sao trong Dynamo. Đọc tiếp CAP.

Khả năng chịu lỗi

Nguồn gốc: Khả năng chịu lỗi. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Một worker bị dừng giữa lúc xử lý file. Pipeline có thể chạy lại, nhưng báo cáo sau đó có đúng không? Chịu lỗi không chỉ là tự khởi động lại tiến trình; còn là khôi phục trạng thái và kiểm soát những việc đã thực hiện.

Đặt ranh giới lỗi trước

Ví dụ tổng tiền ba file là 40000 + 60000 + 50000 = 150000. Với mỗi nhiệm vụ, thử bốn điểm lỗi:

Đây là bài tập bằng tay để tìm ranh giới commit. Nếu có mã nhiệm vụ và một kết quả được chấp nhận mỗi mã, chạy lại có thể tránh cộng trùng. Nhưng cần bảo vệ trạng thái nhiệm vụ cùng nơi lưu kết quả; hai thao tác tách rời vẫn có khoảng lỗi.

Checkpoint và replay cần tương thích

Checkpoint ghi vị trí và trạng thái để tiếp tục. Nguồn phải còn dữ liệu cần đọc lại; sink phải xử lý được các kết quả được gửi lại. Nếu checkpoint cũ hơn việc ghi sink, replay có thể tạo trùng. Nếu đánh dấu đã đọc trước khi ghi sink thành công, có thể mất kết quả.

Vì thế phải hỏi “đúng một lần” áp dụng cho trạng thái bên trong hay cả kết quả bên ngoài. Đọc idempotency và retry để thấy hai phần này phối hợp thế nào.

Quorum cũng có giới hạn

Ví dụ Raft dùng đa số để duy trì log được đồng thuận. Trong cụm 3 node, đa số là 2; mất một node vẫn có thể tiến triển nếu hai node còn lại liên lạc được. Mất liên lạc với đa số có thể khiến hệ thống ngừng tiến triển để giữ an toàn. Các giả định và cơ chế xem trong Raft paper; không áp công thức này cho mọi hệ replication.

Ba container trên cùng laptop không bảo vệ khỏi laptop mất điện. Replication cũng không thay backup chống xóa nhầm. Cần xác định lỗi nào mình muốn chịu và phần nào có chung điểm hỏng.

Phục hồi là một thứ cần thử

Đo lượng dữ liệu có thể mất và thời gian khôi phục; ghi rõ người hoặc hệ thống nào thực hiện. Với ví dụ nhỏ, kết quả cuối phải là 150000 sau từng ca lỗi và chạy lại. Với hệ thống thật, còn cần kiểm tra dữ liệu trùng, bị thiếu, quyền truy cập và tác động tới người dùng.

Một hệ thống tự chạy lại mãi nhưng không báo nguyên nhân lỗi chưa phải dễ vận hành. Hãy để log chỉ ra nhiệm vụ, checkpoint và trạng thái cuối mà người trực có thể đối chiếu.

Data Contract giữa producer và consumer

Nguồn gốc: Data Contract giữa producer và consumer. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Team thanh toán đổi amount từ cent sang dollar mà không báo. Pipeline vẫn chạy, nhưng doanh thu nhỏ đi 100 lần.

Data Contract (cam kết về data giữa producer và consumer) ghi lại data nào được cung cấp, ý nghĩa của nó, mức chất lượng mong đợi và cách thay đổi được quản lý.

name: payment_completed
owner: payments-team
fields:
  payment_id: {type: string, required: true}
  order_id: {type: string, required: true}
  amount_cents: {type: integer, minimum: 0}
  currency: {type: string, allowed: [SGD]}

Contract có thể gồm:

• Schema và field bắt buộc.
• Grain, key và ý nghĩa business.
• Freshness hoặc availability đã hứa.
• Quy tắc quality quan trọng.
• Owner, consumer và quy trình thay đổi.

    flowchart TD
 A["Producer<br/>Team thanh toán"] --> B["Data Contract"]
 B --> C["Consumer<br/>Pipeline doanh thu"]
 D["Đề xuất thay đổi"] --> E["Kiểm tra compatibility"]
 E --> B
  

Contract không chỉ là schema

Hai field cùng type integer vẫn có thể mang đơn vị khác nhau. Kiểm tra schema không phát hiện cent đổi thành dollar. Contract cần ghi ý nghĩa mà code và con người có thể kiểm tra.

Ai chịu trách nhiệm?

Producer chịu trách nhiệm giữ lời hứa hoặc thông báo thay đổi. Consumer chịu trách nhiệm dùng đúng mục đích và nêu dependency quan trọng. Data team hỗ trợ công cụ, checks và cách phối hợp; họ không thể tự định nghĩa data của mọi domain.

Không cần viết contract dài cho mọi bảng tạm. Hãy dùng nó ở ranh giới giữa team, nơi thay đổi có thể âm thầm làm hỏng downstream. Contract tốt làm thay đổi có chủ đích; nó không đóng băng hệ thống mãi mãi.

Data Observability: theo dõi sức khoẻ của pipeline

Nguồn gốc: Data Observability: theo dõi sức khoẻ của pipeline. Nội dung dưới đây là bản sao bài Wiki tại lúc website được build.

Data Quality check biết order_id không được rỗng. Nhưng ai phát hiện pipeline chưa chạy, data trễ ba giờ hoặc số order giảm bất thường?

Data Observability (khả năng quan sát hệ thống data) là khả năng hiểu trạng thái của pipeline và data từ các tín hiệu mà hệ thống tạo ra.

Quan sát cả job lẫn data

    flowchart TD
 A["Pipeline và data"] --> B["Metrics, logs, checks"]
 B --> C["Monitor"]
 C --> D{"Có bất thường?"}
 D -->|Có| E["Alert đúng owner"]
 E --> F["Điều tra và khôi phục"]
  

Một freshness monitor có thể kiểm tra:

max(ingested_at) phải cách hiện tại < 30 phút

Nếu source vốn chỉ gửi file lúc 6 giờ sáng, rule 30 phút sẽ báo động giả cả ngày. Monitor phải dựa trên nhịp data đã hứa.

Alert cần dẫn đến hành động

“Table failed” chưa đủ. Alert nên có dataset, partition, giá trị thực tế, ngưỡng, upstream gần nhất và owner. Cũng cần phân biệt warning với sự cố chặn người dùng.

Observability không tự đảm bảo Data Quality. Nó kết hợp checks, logs, metrics và lineage để phát hiện rồi khoanh vùng vấn đề nhanh hơn. Bắt đầu với các bảng quan trọng và tín hiệu gắn với cam kết thật; quá nhiều alert không có owner chỉ tạo tiếng ồn.