Hôm nay tôi lượm được một bài khá hay của anh em Linkedin, chia sẻ về cách họ scale cái hệ thống HDFS (Hadoop Distributed File System) lên tới 1 Exabyte dữ liệu. Một con số quá khủng khiếp
Trong bài này, chúng ta sẽ cùng mổ xẻ vài thứ hay ho mà họ đã làm:
- Làm sao để scale HDFS lên 1 Exabyte dữ liệu?
- Cách họ replica các server NameNode để tăng tính high availability.
- Tinh chỉnh Java heap size để hệ thống garbage collection hiệu quả.
- Làm sao để đọc dữ liệu nhất quán cao từ các Standby NameNode để giảm tải cho Active NameNode.
Hành trình của Linkedin scale HDFS lên 1 Exabyte dữ liệu
Chắc không ai lạ gì Linkedin, mạng xã hội nghề nghiệp lớn nhất hành tinh với hơn 800 triệu người dùng. Để xử lý và phân tích khối dữ liệu khổng lồ do người dùng tạo ra, Linkedin phụ thuộc rất nhiều vào Hadoop, cụ thể là HDFS để lưu trữ.
Trong 5 năm qua, hạ tầng của họ phình to theo cấp số nhân. Đến 2021, họ chạm mốc lưu trữ 1 exabyte dữ liệu trên tất cả các cluster Hadoop. Riêng cái cluster lớn nhất đã chứa 500 petabytes dữ liệu, chạy trên 10,000 node. Đây chắc chắn là một trong những cluster Hadoop lớn nhất thế giới rồi.
Điều đáng nể là dù quy mô cực lớn, độ trễ trung bình cho các RPCs (remote procedure calls) tới cluster vẫn dưới 10 mili giây.
Vậy họ đã làm những gì để HDFS có thể “gánh” được mức tải này?
1. Replica NameNode
Với HDFS, metadata của hệ thống file (tên file, cây thư mục, file nào nằm ở block nào…) được tách riêng khỏi dữ liệu thực tế.
- DataNode: Là các server chịu trách nhiệm lưu trữ dữ liệu thật. Client đọc/ghi dữ liệu sẽ giao tiếp trực tiếp với mấy con này.
- NameNode: Là “bộ não” của hệ thống, quản lý toàn bộ metadata. Client muốn tìm file nào thì phải hỏi nó trước.
Vấn đề là, con NameNode này là một single point of failure. Nếu nó mà “tạch” thì thôi rồi, cả cái cluster toang. Với một cluster hàng trăm petabyte, việc restart lại NameNode có thể mất hơn một tiếng, và trong thời gian đó thì mọi job đều phải tạm dừng.
Rất may là từ Hadoop 2 đã có tính năng High Availability. Thay vì một NameNode, giờ đây ta có thể có một cluster:
- Một Active NameNode duy nhất xử lý mọi request từ client.
- Nhiều Standby NameNode chạy dự phòng.
Active NameNode sẽ ghi lại mọi giao dịch của nó vào một Journal Service, và các con Standby sẽ đọc từ đó để cập nhật trạng thái của mình. Nhờ vậy, chúng luôn sẵn sàng để tiếp quản ngay khi con Active gặp sự cố. Việc nâng cấp hệ thống (rolling update) cũng dễ thở hơn nhiều, chỉ cần nâng cấp từng con Standby một, sau đó chuyển failover con Active qua rồi nâng cấp nốt là xong.
2. Java Tuning
Vì toàn bộ metadata của HDFS được NameNode lưu trong RAM để truy cập cho nhanh, nên khi hệ thống phình to, RAM cho NameNode cũng phải tăng theo. Con NameNode lớn nhất của Linkedin được set tới 380 GB heap để quản lý 1.1 tỷ object. Để duy trì một cái heap khổng lồ như vậy, việc tuning là bắt buộc. Trong Java, heap thường được chia làm 2 vùng:
- Young generation: Nơi các object mới tạo ra, thường bị dọn rác (GC) sớm và nhanh.
- Tenured (Old) generation: Nơi chứa object “sống dai”, tồn tại lâu và được chuyển từ Young gen sau nhiều lần GC.
Khi workload tăng, lượng object tạm thời ở vùng Young tăng lên. Khi hệ thống file lớn lên, vùng Old cũng tăng theo. Anh em ở Linkedin cố gắng giữ tỷ lệ dung lượng giữa vùng Young và Old ở mức 1:4.
Bằng cách này, họ có thể né được hoàn toàn các đợt full garbage collection (dọn dẹp cả 2 vùng), thứ có thể khiến NameNode tạm dừng vài phút liền.
3. Các tối ưu hóa khác
- Satellite Clusters: HDFS được tối ưu cho file lớn. Nếu lưu quá nhiều file nhỏ, metadata sẽ phình to rất nhanh và trở thành nút thắt cổ chai cho NameNode. Để giải quyết, Linkedin tạo ra các satellite cluster chuyên để xử lý các file nhỏ này.
- Consistent Reads từ Standby NameNodes: Vì đã có nhiều Standby NameNode, họ tận dụng luôn mấy con này để phục vụ các request chỉ đọc metadata. Nhờ vậy, con Active NameNode chính chỉ cần tập trung xử lý các request ghi, giảm tải cực kỳ hiệu quả.
