Hadoop MapReduce: Kích thước tệp đầu vào phù hợp?

Question

Tôi có tập dữ liệu ở mức độ lớn là 3 chữ số GB hoặc thậm chí là 1 hoặc 2 chữ số TB. Các tập tin đầu vào do đó là một danh sách các tập tin, mỗi tập tin có kích thước như 10GB. Bản đồ của tôi giảm bớt công việc trong hadoop xử lý tất cả các tệp này và sau đó chỉ cung cấp một tệp đầu ra (với thông tin tổng hợp).

Câu hỏi của tôi là:

1. kích thước tập tin thích hợp để điều chỉnh lên khuôn khổ hadoop/MapReduce từ Apache là gì? Tôi nghe rằng kích thước tệp lớn hơn được ưu tiên hơn so với kích thước nhỏ. Có ý tưởng nào không? Điều duy nhất tôi biết chắc chắn là hadoop đọc khối, mỗi khối với 64MB theo mặc định. Vì vậy, nó sẽ là tốt nếu kích thước tập tin là loại nhân 64MB.

2. Hiện tại, ứng dụng của tôi chỉ ghi tệp đầu ra vào một tệp. Kích thước tệp sau đó là gigabit 3 chữ số. Tôi tự hỏi làm thế nào hiệu quả tôi có thể phân vùng các tập tin. Tất nhiên tôi chỉ có thể sử dụng một số công cụ unix để thực hiện công việc này. Nhưng nó có thích làm điều này trực tiếp hơn trong hadoop không?

Thx cho nhận xét của bạn!

P.S .: Tôi không nén tệp. Định dạng tệp của tệp đầu vào là văn bản/csv.

Answer 1

Hadoop chia công việc dựa trên kích thước phân chia đầu vào. Nó chia tổng kích thước dữ liệu của bạn theo kích thước phân chia của bạn và đó là cách nó xác định có bao nhiêu công việc bản đồ sẽ xảy ra. Sự đồng thuận chung là bạn muốn giữa 10-100 bản đồ cho mỗi máy; từ http://hadoop.apache.org/common/docs/r0.18.3/mapred_tutorial.html

Số lượng bản đồ thường được thúc đẩy bởi tổng kích thước của đầu vào, tức là tổng số khối của tệp đầu vào. Mức độ song song phù hợp với bản đồ có vẻ là khoảng 10-100 bản đồ cho mỗi nút, mặc dù nó đã được thiết lập tới 300 bản đồ cho các nhiệm vụ bản đồ rất cpu-ánh sáng. Thiết lập tác vụ mất một lúc, vì vậy tốt nhất là nếu bản đồ mất ít nhất một phút để thực thi.

Với một số định dạng đầu vào, bạn có thể đặt kích thước phân chia, theo mặc định nhất (bao gồm cả TextInputFormat) tạo một bản đồ cho mỗi khối. Vì vậy, nếu bạn có nhiều tệp khác nhau, bạn sẽ kết thúc với nhiều khối 64mb không hoàn chỉnh hơn, đó là một sự lãng phí của bản đồ.

Xử lý một tệp khổng lồ hiệu quả hơn nhiều so với xử lý nhiều tệp. Quá trình thiết lập cho công việc mất nhiều thời gian hơn khi phải tính đến nhiều tệp. Cốt lõi của hadoop thực sự tập trung vào một số lượng nhỏ các tệp lớn. Ngoài ra, HDFS được thiết lập để xử lý một số lượng nhỏ các tệp lớn và các tệp khác bạn có nhiều ram tên nút sẽ ăn để theo dõi chúng.

Answer 2

Nếu bạn không nén các tệp thì Hadoop sẽ xử lý các tệp lớn của bạn (giả sử 10G), với một số người lập bản đồ liên quan đến kích thước khối của tệp.

Giả sử kích thước khối của bạn là 64M, khi đó bạn sẽ có ~ 160 người lập bản đồ xử lý tệp 10G này (160 * 64 ~ = 10G). Tùy thuộc vào cách CPU tập trung vào logic của trình ánh xạ của bạn, đây có thể là kích thước khối chấp nhận được, nhưng nếu bạn thấy rằng người lập bản đồ của bạn đang thực hiện trong thời gian phụ, thì bạn có thể muốn tăng công việc do mỗi người lập bản đồ thực hiện (bằng cách tăng kích thước khối đến 128, 256, 512m - kích thước thực tế phụ thuộc vào cách bạn định xử lý dữ liệu).

Kích thước khối lớn hơn sẽ giảm số lượng người lập bản đồ được sử dụng để xử lý tệp 10G.Tất nhiên bạn có thể tăng kích thước phân chia tối thiểu được sử dụng bởi TextInputFormat, nhưng sau đó bạn có thể chạy vào vùng dữ liệu thấp hơn vì người lập bản đồ có thể đang xử lý 2 hoặc nhiều khối, có thể không phải tất cả nằm cục bộ trên nút đó.

Về đầu ra, điều này lại phụ thuộc vào logic xử lý của bạn đang làm gì - bạn có thể phân vùng chỉ bằng cách giới thiệu thêm bộ giảm tốc không? Điều này sẽ tạo ra nhiều file đầu ra, nhưng những gì logic phân vùng nào bạn yêu cầu cho những tập tin (theo mặc định họ sẽ băm phân chia bởi chìa khóa của bạn)

Answer 3

Kích thước của các tập tin đầu vào:

Một cách để điều chỉnh này là xem xét công việc bản đồ của bạn đang hoàn thành nhanh như thế nào. Mỗi tác vụ bản đồ sẽ lấy 1 tệp làm đầu vào và nếu chúng hoàn thành trong vòng dưới 30-40 giây, bạn nên xem xét tăng kích thước của mỗi tệp để mỗi người lập bản đồ có nhiều việc phải làm hơn. Điều này là do một nhiệm vụ bản đồ mất khoảng 30 giây để khởi tạo trước khi nó thực hiện bất kỳ công việc thực tế nào.

Nó cũng phụ thuộc vào số lượng tác vụ bản đồ mà cụm của bạn có thể chạy cùng một lúc. Bạn có thể thử điều chỉnh tệp của mình và chặn kích thước để bạn tận dụng tối đa nhiều tác vụ bản đồ nhất có thể. Xem bài viết trên blog này cho thêm ý tưởng: http://www.cloudera.com/blog/2009/12/7-tips-for-improving-mapreduce-performance/

Kích thước của tập tin đầu ra:

Cách đơn giản để làm điều này là để xác định nhiều hơn một giảm (mỗi giảm sẽ tạo ra một tập tin đầu ra duy nhất). Nếu bạn muốn phân vùng kết quả của mình bằng một số khóa (ví dụ: year-month), bạn có thể đưa nó vào khóa đầu ra của tác vụ bản đồ của bạn và chúng sẽ được sắp xếp theo cùng một trình giảm tốc. Sau đó, bạn chỉ cần kiểm tra từng tệp để xem nó có khóa năm nào.

nén:

tôi khuyên bạn nên nhìn vào nén tập tin của bạn. Làm điều này sẽ làm cho các tệp đầu vào "lớn hơn" vì mỗi tệp sẽ chứa nhiều dữ liệu hơn cho một tác vụ bản đồ duy nhất để hoạt động. Nó cũng sẽ giảm số lượng đĩa bạn sử dụng trong cụm của bạn. Nếu có bất cứ điều gì, nó cũng có thể tăng hiệu suất của mapreduce trên cụm của bạn vì ít đĩa I/O và lưu lượng mạng sẽ xảy ra từ việc đọc và di chuyển các tệp xung quanh.

Đồng thời, nén đầu ra trung gian của tác vụ bản đồ của bạn (đầu ra từ tác vụ bản đồ trước khi nó đi đến bộ giảm tốc). Nó sẽ tăng hiệu suất theo cách tương tự. Điều này được thực hiện bằng cách đặt mapred.compress.map.output=true.