An inside look at LinkedIn's data pipeline monitoring system

LinkedIn · 2019 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

• Dữ liệu vào Hadoop chủ yếu qua Apache Gobblin (nguồn Kafka, Espresso, Oracle), job batch chạy hàng giờ trên hàng trăm dataset. Giám sát lúc đó chỉ là trạng thái pass/fail của job trên dashboard Azkaban tự làm (Kyaraben).
• Sự cố mở đầu: sau một migration, pipeline ingest Kafka bootstrap lại mọi topic đã ingest tới bốn ngày trước. Job vẫn báo thành công, chỉ có watermark ngừng tiến; 1,5 ngày sau người dùng hạ nguồn mới hỏi vì sao thiếu dữ liệu. Rollback ngay, nhưng với tốc độ ghi HDFS lúc đó, mất gần hai tuần để đuổi kịp 1,5 ngày trễ.

Thay đổi chính

• Job thành các bước đo được bằng sự kiện: Gobblin phát sự kiện fire-and-forget ở từng mốc (thời gian tạo work unit, thời gian chạy MapReduce, đăng ký Hive, task lỗi kèm dataset và lý do, file đã publish kèm số bản ghi đọc/ghi) vào Kafka.
• Tương quan alert: metric batch hiếm khi alert được từ một chỉ số. Dùng Nurse (nền tảng auto-remediation sẵn có của LinkedIn, plan viết YAML) để kiểm lần lượt các alert khác, kể cả metric hạ tầng Hadoop, trước khi kết luận nguyên nhân; ví dụ không có work unit mới lâu chưa chắc là treo, đối chiếu với sự kiện publish xem còn tiến không để tránh báo nhầm.
• Chỉ số theo dataset:
  • Ingestion lag: số "giờ nguồn" (giờ dữ liệu sinh ra) được ingest trong mỗi "giờ ingest"; bình thường chủ yếu là giờ gần nhất, lệch về các giờ cũ là đang trễ. Lấy từ HDFS audit log (Flume trên NameNode đổi thành sự kiện Avro vào Kafka).
  • Data loss: so số bản ghi ở nguồn theo từng mapper (sự kiện Gobblin) với số đã ghi (HDFS audit), chỉ ra đúng mapper mất dữ liệu và thường cả lý do (lỗi decode Avro, dữ liệu tới muộn), kèm link tới log.
  • Data availability: cách nhanh (đếm từ Kafka audit mỗi 5 phút, xác nhận khoảng 15 phút sau khi hết giờ nguồn, nhưng có thể đếm trùng do at-least-once và lệch timestamp) và cách chậm mà chính xác (consumption test: giờ nguồn chỉ còn đóng góp dưới 10% lượng ingest sau 2–3 giờ, có file cuối, không mất dữ liệu).
• Kiến trúc: Samza tổng hợp sự kiện theo cửa sổ → dashboard time series; Superset (MySQL) cho metric theo dataset và REST API trả ngữ cảnh cho alert; Nurse nối với Azkaban để khắc phục.
• Auto-remediation: job không tiến thì lấy thread dump theo chu kỳ rồi mới restart; dataset gây lỗi thì đưa vào denylist bằng code; alert nhầm thì ghi đè tham số job Azkaban lúc chạy.

Vì sao

• "Job thành công" không có nghĩa dữ liệu đúng và kịp; pipeline batch là hộp đen nếu chỉ nhìn trạng thái cuối.

Bài học cho SWE

• Giám sát pipeline dữ liệu bằng lag, độ đầy đủ, độ sẵn sàng theo dataset, không chỉ trạng thái job (Observability và monitoring).
• Một lỗi im lặng phát hiện muộn 1,5 ngày có thể tốn hai tuần để đuổi kịp: chi phí phục hồi tăng nhanh hơn thời gian phát hiện.
• Tương quan nhiều alert trước khi hành động giảm báo nhầm; khi đã biết chắc nguyên nhân thì cho máy làm bước khắc phục (thu thập bằng chứng trước, rồi restart hoặc cách ly dataset) (Tự động hoá vận hành và auto-remediation).
• Cùng hướng với Salesforce 2017: đếm ở từng chặng để biết mất ở đâu (Salesforce 2017).

Liên quan

• Pipeline dữ liệu và analytics
• Cùng công ty: LinkedIn 2017 · LinkedIn 2018 · LinkedIn 2018
• Observability và monitoring · Tự động hoá vận hành và auto-remediation