Vấn đề tệp nhỏ

Các tệp nhỏ là một vấn đề lớn trong Hadoop - hoặc ít nhất là nếu số lượng câu hỏi trong danh sách người dùng về chủ đề này là bất kỳ. Trong bài đăng này, tôi sẽ xem xét vấn đề và xem xét một số giải pháp phổ biến.

Sự cố với tệp nhỏ và HDFS

Tệp nhỏ là tệp nhỏ hơn đáng kể so với kích thước khối HDFS (mặc định 64MB). Nếu bạn đang lưu trữ các tệp nhỏ, thì có thể bạn có rất nhiều tệp (nếu không, bạn sẽ không chuyển sang Hadoop) và vấn đề là HDFS không thể xử lý nhiều tệp.

Mọi tệp, thư mục và khối trong HDFS được thể hiện dưới dạng một đối tượng trong bộ nhớ của nút tên, mỗi tệp này chiếm 150 byte, theo quy tắc chung. Vì vậy, 10 triệu tệp, mỗi tệp sử dụng một khối, sẽ sử dụng khoảng 3 gigabyte bộ nhớ. Mở rộng nhiều hơn mức này là một vấn đề với phần cứng hiện tại. Chắc chắn một tỷ tệp là không khả thi.

Hơn nữa, HDFS không được thiết kế để truy cập hiệu quả các tệp nhỏ:nó chủ yếu được thiết kế để truy cập trực tuyến các tệp lớn. Việc đọc qua các tệp nhỏ thường gây ra nhiều lần tìm kiếm và rất nhiều lần nhảy từ nút dữ liệu sang nút dữ liệu để truy xuất từng tệp nhỏ, tất cả đều là một kiểu truy cập dữ liệu không hiệu quả.

Sự cố với các tệp nhỏ và MapReduce

Các tác vụ bản đồ thường xử lý một khối dữ liệu đầu vào tại một thời điểm (sử dụng FileInputFormat mặc định ). Nếu tệp rất nhỏ và có nhiều tệp, thì mỗi tác vụ bản đồ xử lý rất ít dữ liệu đầu vào, và có nhiều tác vụ bản đồ hơn, mỗi tác vụ bản đồ sẽ áp dụng thêm chi phí ghi sổ kế toán. So sánh một tệp 1GB được chia thành 16 khối 64MB và 10.000 hoặc hơn 100KB tệp. 10.000 tệp mỗi tệp sử dụng một bản đồ và thời gian công việc có thể chậm hơn hàng chục hoặc hàng trăm lần so với tệp tương đương với một tệp đầu vào.

Có một số tính năng giúp giảm bớt chi phí kế toán:tái sử dụng tác vụ JVM để chạy nhiều tác vụ bản đồ trong một JVM, do đó tránh được một số chi phí khởi động JVM (xem mapred.job.reuse.jvm.num.tasks thuộc tính) và MultiFileInputSplit có thể chạy nhiều hơn một phần tách trên mỗi bản đồ.

  Tại sao các tệp nhỏ được tạo ra? 
 
 Có ít nhất hai trường hợp 
   Các tệp là các phần của một tệp logic lớn hơn. Vì HDFS mới chỉ hỗ trợ các phần bổ sung gần đây, nên một mô hình rất phổ biến để lưu các tệp không bị liên kết (ví dụ:tệp nhật ký) là ghi chúng thành nhiều phần vào HDFS. 
  Các tệp này vốn đã nhỏ. Hãy tưởng tượng một kho hình ảnh lớn. Mỗi hình ảnh là một tệp riêng biệt và không có cách tự nhiên nào để kết hợp chúng thành một tệp lớn hơn. 
 
 
 Hai trường hợp này yêu cầu các giải pháp khác nhau. Đối với trường hợp đầu tiên, trong đó tệp được tạo thành từ các bản ghi, sự cố có thể tránh được bằng cách gọi  sync ()  của HDFS thường xuyên để ghi liên tục các tệp lớn. Ngoài ra, có thể viết một chương trình để nối các tệp nhỏ lại với nhau. 
 
 Đối với trường hợp thứ hai, một số loại vùng chứa là cần thiết để nhóm các tệp theo một cách nào đó. Hadoop cung cấp một số tùy chọn tại đây. 
  Tệp HAR 
 
 Lưu trữ Hadoop (tệp HAR) đã được đưa vào HDFS trong 0.18.0 để giảm bớt vấn đề có nhiều tệp gây áp lực lên bộ nhớ của nút tên. Tệp HAR hoạt động bằng cách xây dựng hệ thống tệp phân lớp trên HDFS. Tệp HAR được tạo bằng  kho lưu trữ hadoop  , chạy lệnh MapReduce để đóng gói các tệp đang được lưu trữ thành một số lượng nhỏ tệp HDFS. Đối với khách hàng sử dụng hệ thống tệp HAR, không có gì thay đổi:tất cả các tệp gốc đều có thể nhìn thấy và có thể truy cập được (mặc dù sử dụng  har://  URL). Tuy nhiên, số lượng tệp trong HDFS đã bị giảm. 
 
 Đọc qua các tệp trong HAR không hiệu quả hơn đọc qua các tệp trong HDFS và trên thực tế có thể chậm hơn vì mỗi lần truy cập tệp HAR yêu cầu hai lần đọc tệp chỉ mục cũng như đọc tệp dữ liệu (xem sơ đồ). Và mặc dù các tệp HAR có thể được sử dụng làm đầu vào cho MapReduce, không có phép thuật đặc biệt nào cho phép bản đồ hoạt động trên tất cả các tệp trong đồng cư trú HAR trên một khối HDFS. Có thể xây dựng một định dạng đầu vào có thể tận dụng vị trí được cải thiện của tệp trong HAR, nhưng nó chưa tồn tại. Lưu ý rằng MultiFileInputSplit, ngay cả với những cải tiến trong HADOOP-4565 để chọn tệp trong một phần tách là cục bộ nút, sẽ cần tìm kiếm trên mỗi tệp nhỏ. Sẽ rất thú vị khi xem hiệu suất của điều này so với SequenceFile, chẳng hạn. Tại thời điểm hiện tại, HAR có lẽ được sử dụng tốt nhất cho mục đích lưu trữ. 
  Tệp trình tự 
 
 Câu trả lời thông thường cho các câu hỏi về “vấn đề tệp nhỏ” là:sử dụng SequenceFile. Ý tưởng ở đây là bạn sử dụng tên tệp làm khóa và nội dung tệp làm giá trị. Điều này hoạt động rất tốt trong thực tế. Quay lại với 10.000 tệp 100KB, bạn có thể viết một chương trình để đưa chúng vào một SequenceFile duy nhất và sau đó bạn có thể xử lý chúng theo cách truyền trực tuyến (trực tiếp hoặc sử dụng MapReduce) hoạt động trên SequenceFile. Có một số tiền thưởng nữa. SequenceFiles có thể chia nhỏ, vì vậy MapReduce có thể chia chúng thành nhiều phần và hoạt động trên mỗi phần một cách độc lập. Chúng cũng hỗ trợ nén, không giống như HAR. Nén khối là tùy chọn tốt nhất trong hầu hết các trường hợp, vì nó nén các khối của một số bản ghi (thay vì mỗi bản ghi). 
 
 Có thể chậm chuyển đổi dữ liệu hiện có thành SequenceFiles. Tuy nhiên, bạn hoàn toàn có thể tạo một bộ sưu tập SequenceFiles song song. (Stuart Sierra đã viết một bài rất hữu ích về việc chuyển đổi một tệp tar thành một SequenceFile - các công cụ như thế này rất hữu ích và sẽ rất tốt nếu bạn xem thêm chúng). Về sau, tốt nhất là bạn nên thiết kế đường dẫn dữ liệu của mình để ghi dữ liệu tại nguồn trực tiếp vào SequenceFile, nếu có thể, thay vì ghi vào các tệp nhỏ như một bước trung gian. 
 
 Không giống như các tệp HAR, không có cách nào để liệt kê tất cả các khóa trong một SequenceFile, thiếu khả năng đọc toàn bộ tệp. (MapFiles, giống như SequenceFiles với các khóa được sắp xếp, duy trì một chỉ mục một phần, vì vậy chúng cũng không thể liệt kê tất cả các khóa của chúng - xem sơ đồ.) 
 
 SequenceFile tập trung vào Java. TFile được thiết kế để trở thành đa nền tảng và có thể thay thế cho SequenceFile, nhưng nó vẫn chưa có sẵn. 
  HBase 
 
 Nếu bạn đang tạo nhiều tệp nhỏ, thì tùy thuộc vào kiểu truy cập, một loại bộ nhớ khác có thể thích hợp hơn. HBase lưu trữ dữ liệu trong MapFiles (SequenceFiles được lập chỉ mục) và là một lựa chọn tốt nếu bạn cần thực hiện phân tích luồng theo kiểu MapReduce với việc thỉnh thoảng tra cứu ngẫu nhiên. Nếu độ trễ là một vấn đề, thì có rất nhiều lựa chọn khác - hãy xem khảo sát tuyệt vời của Richard Jones về các cửa hàng có giá trị quan trọng.