The exabyte club: LinkedIn's journey of scaling the Hadoop Distributed File System

LinkedIn · 2021 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bối cảnh

• Hạ tầng analytics gần gấp đôi mỗi năm. Cụm lớn nhất: 20 PB cuối 2015 → 500 PB năm 2020; 145 triệu object namespace (2015) → 1,6 tỷ trong ba namespace volume, volume lớn nhất trên 1 tỷ. Tổng 1 exabyte trên mọi cụm Hadoop; một NameNode giữ 1 tỷ object với RPC trung bình dưới 10 ms.

Thay đổi chính

• HA và rolling upgrade: NameNode Active + Standby đồng bộ qua Quorum Journal Manager (3 node), client theo một VIP. Trước HA mỗi lần nâng cấp phải restart NameNode (tới một giờ), mọi job phải dừng; nay nâng Standby trước, failover, rồi tới DataNode theo từng rack.
• Tune Java: heap NameNode 380 GB cho 1,1 tỷ object; giữ tỉ lệ young:tenured khoảng 1:4. Khoá không công bằng cho khoá đọc-ghi toàn namespace: 95% thao tác là đọc, cho reader vượt writer làm RPC latency giảm 10 lần (dự đoán bằng Dynamometer rồi xác nhận trên production).
• Satellite cluster cho file nhỏ: block 512 MB; tỉ lệ block/file khoảng 1,1 nghĩa là 90% file là file nhỏ. Thư mục /system (log, config của YARN, Spark history) chứa nửa số file nhưng chỉ 0,07% dung lượng. Chuyển sang cụm vệ tinh có NameNode cỡ bằng cụm chính nhưng ít DataNode hơn 100 lần. DistCp 100 triệu file làm NameNode treo, nên viết FailoverFS: ghi mới vào cụm vệ tinh, đọc gộp cả hai cụm, để chính sách retention một tuần tự dọn bên cũ. Cụm vệ tinh chỉ 32 DataNode, mỗi node 9 triệu replica làm block report quá lớn khi xử lý dưới khoá; chia mỗi ổ thành 10 volume ảo để báo theo khúc nhỏ. Tỉ lệ block/file lên 1,4, đủ cho thêm một vòng gấp đôi.
• Đọc nhất quán từ Standby (Observer, HDFS-12943): CPU không còn nhanh lên, một NameNode không theo kịp lượng thao tác. Thêm node Observer (Standby phục vụ đọc), Active vẫn là nơi ghi duy nhất.
  • Fast Path tailing: JournalNode cache transaction gần nhất trong RAM, Standby kéo bằng RPC theo txId thay vì đợi cả segment file (mặc định trễ 2 phút, trên cụm lớn tới 8 phút); trễ còn 25–30 ms.
  • Read-your-own-writes: client mang LastSeenStateId trong header RPC; Observer chưa tới state đó thì giữ request lại chờ.
  • Giao tiếp bên thứ ba (job client tạo file rồi báo ResourceManager cho task đọc): API msync() hỏi Active state mới nhất; để không phải sửa ứng dụng, client tự đồng bộ lúc khởi động (task mới luôn có client mới), có chế độ định kỳ, luôn-msync, hoặc chỉ dùng Active.
  • Kết quả: throughput namespace gấp 3, latency còn một phần ba; 150K ops/giây trung bình, đỉnh 250K, latency 1–2 ms.
• Ra ngoài Hadoop: mã hoá đường truyền chọn lọc theo port (port mã hoá cho truy cập xuyên DC, port thường trong DC; nhanh hơn WebHDFS qua HTTPS), mã hoá lúc lưu theo dataset với KMS nội bộ, Wormhole thay các pipeline tự chế (có cả BitTorrent) đưa dữ liệu từ HDFS ra service online qua cụm drop box ở từng DC.

Vì sao

• Kích thước metadata còn tăng được bằng heap, nhưng lượng thao tác phải chia cho nhiều server; đọc chiếm 95% nên tách đọc là đòn bẩy lớn nhất.

Bài học cho SWE

• Read replica của một hệ metadata vẫn giữ được nhất quán mạnh nếu client mang số state đã thấy và replica chờ tới state đó.
• Trường hợp "người khác báo cho tôi" cần một thao tác đồng bộ tường minh; đặt mặc định để đa số ứng dụng không phải gọi nó.
• File nhỏ là bài toán metadata; tách chúng sang cụm riêng thay vì đè lên cụm chính.

Liên quan

• LinkedIn 2018 · LinkedIn 2021 · LinkedIn 2014
• Scale dọc trước khi scale ngang · Failover, replica và dự phòng dữ liệu · Pipeline dữ liệu và analytics