DataHub: Popular metadata architectures explained

Bài tóm tắt LinkedIn 2020 4. Điều chỉnh Độ khó: Trung bình

LinkedIn · 2020 · 4. Điều chỉnh · Độ khó: Trung bình — bài gốc

Bài khái niệm, viết bởi người dẫn dắt DataHub; xếp các hệ khác vào "thế hệ" theo góc nhìn của LinkedIn. Đọc kèm LinkedIn 2019.

Bối cảnh

  • Tác giả từng xây Espresso, Databus, Kafka; khi sang team hạ tầng analytics (Hadoop) thấy người ta hỏi nhau "dataset nào đúng" suốt: lưu trữ và tính toán đã scale nhưng tìm dữ liệu thì chưa.
  • Catalog giờ phải chứa nhiều loại tài sản (bảng, stream, feature, metric, dashboard, model) và phục vụ nhiều use case (search, kiểm soát truy cập, lineage, compliance, xoá dữ liệu theo GDPR, data quality), mỗi cái mang metadata riêng nhưng cần nối với metadata của cái khác.

Thay đổi chính

  • Thế hệ 1, monolith + crawler: frontend nối thẳng một DB (MySQL/Postgres), một search index (Elasticsearch), có thể thêm graph (Neo4j); crawler chạy mỗi ngày kéo metadata từ nguồn. Dựng nhanh, một team làm được. Yếu điểm: crawler giòn (firewall, credential đổi), tải dồn từng đợt làm sập nguồn (và crawler luôn bị tắt trước), metadata cũ. Theo LinkedIn: WhereHows bản 2016, Amundsen, Lexikon (Spotify), Artifact (Shopify), Dataportal (Airbnb).
  • Thế hệ 2, service có push API: nguồn đẩy metadata theo schema (hợp đồng rõ), cho phép dùng metadata bằng chương trình (ví dụ Gobblin tự xoá dữ liệu theo yêu cầu "quyền được quên" dựa trên tag trong catalog). Yếu điểm: không có change log nên khó dựng lại index và không làm được hệ phản ứng; team trung tâm sở hữu model và mọi thứ nên thành nút thắt (team data quality ở LinkedIn từng tự dựng UI và store riêng). WhereHows đã đi từ thế hệ 1 sang 2.
  • Thế hệ 3, metadata event-sourced: mọi thay đổi (qua stream hoặc CRUD) sinh metadata changelog, từ đó tự động dựng các store và index (search, graph, data lake, OLAP) như một "database tách rời"; lỗi index thì dựng lại từ log. Model mở rộng được theo domain: các team tự thêm aspect có kiểu mạnh mà không chờ team trung tâm. DataHub ở LinkedIn: hơn 10 triệu change event/ngày, hơn 5 triệu entity và quan hệ được index. Theo LinkedIn: Atlas, Egeria, Uber Databook, DataHub thuộc thế hệ này. Đổi lại nhiều thành phần phải vận hành.

Vì sao

  • Theo tác giả, kiến trúc metadata tốt giống kiến trúc dữ liệu tốt: log ở trung tâm, các view dẫn xuất, quyền mở rộng phân tán.

Bài học cho SWE

  • Một kho dùng chung mà không có change log thì mọi hệ phía sau phải poll hoặc chờ ETL đêm.
  • Team nền tảng giữ cả model lẫn dịch vụ sẽ thành nút thắt; tách quyền định nghĩa model ra theo domain.

Liên quan