Zillow Transitions to Streaming Data Architecture

Zillow · 2016 · 2. Tăng trưởng · Độ khó: Cơ bản — bài gốc

Bài ngắn, mô tả hướng đi lúc bắt đầu chuyển; không có số liệu.

Bối cảnh

Team data science & engineering của Zillow nhận dữ liệu bất động sản liên tục từ hồ sơ công, feed của user/agent, Multiple Listing Services. Trước đây dữ liệu nằm trong SQL Server và xử lý bằng kỹ thuật cache tự làm.
Nhu cầu mới (Zestimate realtime, BI, cá nhân hoá) cần xử lý khối lượng lớn theo thời gian thực.

Đổi cách nghĩ từ bảng sang event stream: bán một căn nhà là một event giao dịch; có stream giao dịch, tin rao bán, tin cho thuê, tịch biên, khoản vay...
Amazon Kinesis Firehose (managed) đổ stream vào S3, làm "Zillow Data Lake" giữ toàn bộ lịch sử cho Spark và cho các thương hiệu khác trong tập đoàn (Trulia, StreetEasy...).
Kinesis Producer tự viết: chạy liên tục, gọi stored procedure trên DB để lấy bản ghi theo từng stream, gắn timestamp duy nhất, kiểm Avro schema, đổi sang JSON rồi publish. Có thể sinh bản ghi trùng; khử trùng ở downstream.
Chuyển từ bảng sang stream: lưu trạng thái hiện tại của các hàng đợi DB vào DynamoDB, chạy full extract các bảng, rồi mỗi giây chỉ lấy phần thay đổi (mới, sửa, xoá) kể từ checkpoint cuối, lưu checkpoint vào DynamoDB.

Cần một kiến trúc scale được, sẵn sàng cao, chịu lỗi, xử lý dữ liệu đa dạng theo thời gian thực; Firehose được chọn vì là dịch vụ tự quản lý.

Hệ cũ không sinh event thì vẫn có thể biến nó thành stream: full extract + delta có checkpoint, một dạng CDC tự làm ở mức ứng dụng (Event-driven, message queue và Kafka).
Chấp nhận at-least-once ở producer và khử trùng ở consumer thường đơn giản hơn cố đạt exactly-once ở nguồn.
Data lake trên object storage làm "nguồn lịch sử" chung cho nhiều team.