Building a Data Streaming Platform

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

Bối cảnh

Ba cách đưa dữ liệu vào data lake S3 trước đó, đều có vấn đề:

Sqoop job do team Data Science viết kéo thẳng từ bảng DB: người viết không hiểu ngữ nghĩa bảng, phải đuổi theo thay đổi schema, schema DB không hợp cho ML; job hằng ngày ảnh hưởng DB production nên DBA phải dựng replica chỉ đọc, có DB phải đọc snapshot cũ một ngày.
Team sản phẩm tự ghi lên S3: JSON, CSV, text tuỳ team, không ai kiểm schema, backfill không nhất quán; mỗi team tự tạo role, credential, Firehose; không biết chính sách PII và vòng đời dữ liệu.

Data Streaming Platform dạng dịch vụ: team chỉ gọi REST API; nền tảng dùng stream bên dưới và một bảng routing lưu bền để đưa message tới đích.
Stream riêng cho mỗi ứng dụng, team tự xin tài nguyên.
Tách stream producer và stream consumer: stream producer chỉ team hạ tầng đọc (để biến đổi), consumer đọc bản riêng nên số và kiểu consumer không ảnh hưởng việc nhận dữ liệu; scale hai phía riêng.
Dữ liệu vào được kiểm schema và tự lưu vào bảng Hive để analyst query (Mode, Tableau) mà không phải làm gì thêm.
Data Catalog tìm được: ai sinh dữ liệu, schema, lineage, tag PII và chính sách vòng đời. Luminaire kiểm chất lượng bằng mô hình chuỗi thời gian và báo cho producer.
Khó khăn: dùng Terraform tạo Kinesis/Firehose theo yêu cầu của team khác không scale (tài khoản data lake dùng chung). KPL (Kinesis Producer Library) giữ trạng thái shard và buffer cho mỗi stream, service ghi vào nhiều stream thì hết heap JVM và chết; họ tự viết thư viện tương thích KPL, chấp nhận dùng shard kém hiệu quả hơn để service ổn định. Hướng tới: chuyển sang Kafka + schema registry, tạo topic bằng CI/CD.
Kết quả: thời gian để một team đưa dữ liệu vào lake từ vài tuần xuống vài ngày.

Ingestion tự phát làm dữ liệu không nhất quán và vi phạm chính sách; một API chung đặt schema, quản trị và lưu trữ ở một chỗ (Nền tảng nội bộ cho service (đường ray chung), Pipeline dữ liệu và analytics).
Tách stream producer/consumer để consumer lạ không làm nghẽn đường ghi (Event-driven, message queue và Kafka).

Đừng để team ML kéo dữ liệu từ DB của team khác; để chủ dữ liệu phát event có schema.
Thư viện client tối ưu cho một stream có thể sập khi một process ghi vào rất nhiều stream.
Đánh đổi hiệu suất lấy ổn định là quyết định hợp lý khi service ingestion là điểm chung của nhiều team.