Nebula as a Storage Platform to Build Airbnb's Search Backends

Airbnb · 2016 · 3. Quy mô lớn · Độ khó: Nâng cao — bài gốc

Bối cảnh

2015: dữ liệu cá nhân hoá cho search vượt sức một máy. Thay vì chỉ làm lại service đó, Airbnb xây nền tảng chung vì thấy nhiều service sẽ cần cùng thứ: phục vụ độ trễ ms cho traffic site, nhận cập nhật realtime từ Kafka, thao tác hàng loạt (snapshot, compact, nạp feature tính offline, thay cả cột), chi phí vận hành thấp.

Nebula: kho dữ liệu versioned dạng bảng (row, column, version) kiểu BigTable/HBase, không schema; API key-value thống nhất gộp hai lớp:
- Delta store trên DynamoDB nhận ghi realtime (chọn vì latency đọc thấp và AWS vận hành); chia bảng theo ngày để mỗi bảng chỉ vài shard DynamoDB.
- Snapshot store trên HFileService (tự xây, phục vụ HFile tĩnh từ đĩa local, shard động) cho dữ liệu lịch sử.
Pipeline offline mỗi repository: dump delta ra S3 → Spark merge với snapshot cũ + dữ liệu offline (feature ML) + kiểm tra sanity → nạp snapshot mới; delta chỉ bị xoá sau khi snapshot mới phục vụ xong. Chính sách merge/compact do từng ứng dụng cấu hình.
Versioning cho phép rollback về snapshot tốt khi dữ liệu hỏng. Thay đổi được phát lại thành stream qua DynamoDB Streams → Kinesis consumer → Kafka.
Làm lại search indexing trên Nebula: index sinh offline từ snapshot hằng ngày, chia shard sẵn và deploy như một binary; rollback index nhanh, máy search mới chỉ cần tải index; tài liệu index có lịch sử để audit.
Kết quả: vài TB mỗi ứng dụng, median khoảng 10 ms; dùng cho personalization, search indexing, dữ liệu pricing.

Theo Airbnb, không muốn xây thêm một storage vật lý; trừu tượng hoá để có thể đổi DynamoDB sang HBase mà ứng dụng không biết.

Tách đường ghi realtime (delta) khỏi đường dữ liệu lớn (snapshot tĩnh) và ghép ở lúc đọc là cách có cả latency thấp lẫn thao tác hàng loạt rẻ.
Index/dữ liệu dẫn xuất build offline và deploy như artifact thì rollback và scale-out dễ.