Công cụ dòng lệnh có thể nhanh hơn cụm Hadoop tới 235 lần (2014)

 (adamdrake.com)
9 điểm bởi GN⁺ 2026-01-19 | 2 bình luận | Chia sẻ qua WhatsApp
  • Kết quả xử lý khoảng 1.75GB dữ liệu ván cờ bằng công cụ dòng lệnh thay vì Hadoop cho thấy hoàn tất chỉ trong 12 giây, nhanh hơn hơn 235 lần so với 26 phút của Hadoop
  • Kết hợp các lệnh shell cơ bản như grep, sort, uniq, awk, xargs, mawk để xây dựng pipeline xử lý streaming, giữ mức sử dụng bộ nhớ gần như bằng 0
  • Thông qua xử lý song song bằng xargs và tối ưu hóa với mawk, mức độ tận dụng CPU core được nâng cao và giảm thiểu nút thắt IO
  • Khi xử lý cùng bộ dữ liệu đó bằng cụm Hadoop (7 máy c1.medium), chi phí và gánh nặng bảo trì thấp hơn rõ rệt
  • Cho thấy vẫn có thể phân tích dữ liệu hiệu quả ngay cả trên một máy đơn lẻ, đồng thời gióng lên hồi chuông cảnh báo về việc dùng công cụ Big Data không cần thiết

Giới thiệu: Xử lý bằng dòng lệnh nhanh hơn Hadoop

  • Sau khi xem một trường hợp phân tích khoảng 2 triệu ván cờ bằng Amazon EMR và mrjob, tác giả tái hiện cùng bộ dữ liệu bằng xử lý streaming dựa trên dòng lệnh
    • Cụm Hadoop (7 máy c1.medium) mất 26 phút, tốc độ xử lý 1.14MB/sec
    • Trên laptop cục bộ thì hoàn tất chỉ trong 12 giây, tốc độ xử lý 270MB/sec
  • Chứng minh rằng các tác vụ tổng hợp kết quả đơn giản hiệu quả hơn nhiều với pipeline shell so với Hadoop
  • Khi kết hợp các lệnh shell, có thể triển khai cấu trúc xử lý luồng song song tương tự Storm trên một máy đơn lẻ

Cấu trúc dữ liệu và chuẩn bị

  • Dữ liệu ở định dạng PGN (Portable Game Notation) ghi lại các ván cờ, kết quả mỗi ván được hiển thị ở dòng "Result"
    • "1-0" là trắng thắng, "0-1" là đen thắng, "1/2-1/2" là hòa
  • Lấy được bộ dữ liệu khoảng 3.46GB từ kho GitHub rozim/ChessData
    • Quy mô gần gấp đôi dữ liệu thử nghiệm của Tom Hayden (1.75GB)

Xây dựng pipeline cơ bản

  • Để đo giới hạn IO, chạy cat *.pgn > /dev/null thì mất khoảng 13 giây (272MB/sec)
  • Pipeline phân tích cơ bản: 
    cat *.pgn | grep "Result" | sort | uniq -c
    • Thời gian chạy khoảng 70 giây, nhanh hơn khoảng 47 lần so với Hadoop
  • Dùng AWK thay cho sort | uniq để tổng hợp kết quả trực tiếp
    • Thời gian chạy 65 giây, gần như không dùng bộ nhớ
    • grep chiếm một CPU core và trở thành nút thắt cổ chai

Song song hóa và tối ưu hóa

  • Song song hóa grep bằng xargs 
    find . -type f -name '*.pgn' -print0 | xargs -0 -n1 -P4 grep -F "Result" | gawk ...
    • Thời gian chạy 38 giây, cải thiện tốc độ khoảng 77 lần
  • Loại bỏ grep và đơn giản hóa các bước bằng lọc chỉ với AWK
    • Xây dựng pipeline AWK kép để hợp nhất kết quả của từng file
    • Thời gian chạy 18 giây, nhanh hơn khoảng 174 lần
  • Tối ưu thêm khi thay bằng mawk 
    find . -type f -name '*.pgn' -print0 | xargs -0 -n4 -P4 mawk ... | mawk ...
    • Thời gian chạy 12 giây, nhanh hơn Hadoop 235 lần, tốc độ xử lý 270MB/sec

Kết luận: Hiệu quả của sự đơn giản

  • Trừ khi thật sự cần xử lý phân tán quy mô lớn, tổ hợp công cụ shell trên một máy đơn lẻ nhanh hơn và kinh tế hơn
  • Hadoop thường bị dùng quá mức ngay cả cho những công việc mà DB quan hệ hoặc script đơn giản là đủ
  • Phân tích streaming dựa trên dòng lệnh là một lựa chọn thay thế vượt trội về hiệu năng, chi phí triển khai và khả năng bảo trì

Bài viết liên quan

2 bình luận

 
dongho42 2026-01-20

Trước đây từng có khái niệm lập trình Taco Bell, cảm giác như triết lý cũng tương tự.
 
GN⁺ 2026-01-19
Ý kiến Hacker News

  • Điều buồn nhất là bài này từ năm 2014
    Giờ còn có thêm nhiều lớp trừu tượng như Airflow, dbt, Snowflake, nên người ta thực tế còn chồng chúng lên cả những tập dữ liệu vốn nằm gọn trong RAM
    Các startup đốt 5.000 USD mỗi tháng vào cụm phân tán chỉ để xử lý chưa tới 10GB log mỗi ngày. Lý do là dùng ‘Modern Data Stack’ thì được thăng tiến, còn giải quyết bằng bash script thì bị gạt đi là ‘không thể mở rộng’. Hiệu quả và động lực hoàn toàn lệch pha

    • Gần đây trong phỏng vấn người ta cứ nói về ‘bài toán scale’, nhưng thực tế nhiều trường hợp vẫn dư sức nhét vào một máy
      Có cả trường hợp ingest 1GB JSON mỗi ngày, tôi giải thích rằng “một máy là đủ” thì họ bảo “về mặt kỹ thuật là đúng nhưng không phải câu trả lời chúng tôi muốn” rồi đánh trượt
      Máy móc bây giờ có RAM cỡ TB và hàng trăm core. Một máy đơn lẻ giờ đã cực kỳ lớn
    • Đây không chỉ là vấn đề thăng tiến mà còn là vấn đề của cấu trúc tuyển dụng
      Khi tuyển người có kinh nghiệm DevOps, họ nhấn mạnh kinh nghiệm với các framework hào nhoáng, nên rốt cuộc những người đó vào công ty cũng lặp lại đúng mô hình ấy
      Không ai phản đối, và kết quả là những việc chỉ cần một máy desktop cũng bị làm cho phức tạp hóa
    • Suốt 20 năm qua tôi luôn dùng ‘công nghệ phù hợp’ thay vì ‘công nghệ trông ngầu’, và cuối cùng bị sa thải
      Với CV gần như không có framework mới nhất, tôi đã tìm việc hơn một năm và bắt đầu thấy mình như thằng ngốc
    • Ở công ty tôi cũng thấy chuyện tương tự. Để luân chuyển vài GB dữ liệu mỗi ngày qua nhiều hệ thống, thứ trước đây viết bằng script Python là xong trong một tuần thì giờ mất vài tháng và còn hay hỏng
    • Giờ laptop 128GB RAM cũng đã phổ biến, còn server thì lớn hơn nhiều
      Năm 2014 thì 4GB là bình thường, nhưng giờ tốc độ stream từ SSD cũng nhanh nên có lúc đọc từ SSD cục bộ còn tốt hơn cả cluster

  • Tôi là tác giả đây!
    Rất vui khi bài viết cũ vẫn còn hữu ích
    Tôi đồng ý với ý kiến cho rằng tình hình đã tệ hơn, nhưng mặt khác cũng mừng vì đang thấy xu hướng thoát khỏi việc sùng bái microservices
    Xin gửi lời cổ vũ tới tất cả những ai đang nỗ lực cải thiện hiệu năng. Vẫn còn hy vọng

    • Adam, cảm ơn nhé!
      Tôi đã đọc lại bài này nhiều lần, và lấy cảm hứng để port Waters-Series sang JavaScript nhằm hiện thực hóa stream pipelining

  • Dạo này trong ngành có cảm giác quá mạnh rằng Spark hay công cụ phân tán mới là đáp án đúng cho data engineering
    Nó khá giống hiện tượng lạm dụng framework SPA trong phát triển web
    Lời khuyên của tôi là:

    • Manager đừng yêu cầu công nghệ cụ thể (Spark, React), mà hãy giao cho kỹ sư có năng lực giải quyết vấn đề
    • Tech lead hãy nói thẳng kiểu “pipeline của chúng tôi xử lý được tới 20GB, và nếu lớn hơn thì sẽ mở rộng bằng X/Y/Z”
      Điều manager muốn nghe không phải là ‘mọi thứ mở rộng vô hạn’, mà là sự chắc chắn rằng ‘nó chạy ổn định’
    • Phần lớn công ty xử lý dữ liệu quy mô nhỏ
      Kích thước dữ liệu tuân theo luật lũy thừa, nên số kỹ sư làm với dữ liệu cỡ petabyte là cực ít
      Nhưng vì muốn đưa kiểu kinh nghiệm đó vào CV để tăng lương nên mới sinh ra over-engineering
    • Hồi trước khi làm ở một kỳ lân nổi tiếng, manager nói “quý sau phải dùng Spark”
      Tôi hỏi tại sao thì câu trả lời là “cứ phải dùng thôi”. Có lẽ là vì để đẹp CV hoặc vì lý do chính trị của ai đó

  • Một câu chuyện lịch sử liên quan đến bài viết
    Công cụ mrjob có thể chạy ở chế độ local mà không cần Hadoop
    Với tập dữ liệu nhỏ thì nó nhanh hơn cluster rất nhiều. Đặc biệt còn xong nhanh hơn cả các cluster tạm thời như AWS EMR
    Nhưng có lẽ cách tiếp cận của tác giả còn hiệu quả hơn cả thế
    MapReduce giúp mở rộng quy mô lớn dễ hơn, nhưng với dữ liệu nhỏ thì có rất nhiều ràng buộc kém hiệu quả
    Đầu thập niên 2010, người ta từng xử lý dữ liệu cỡ petabyte bằng mrjob, nhưng giờ gần như không còn dùng nữa

  • Khi làm data engineer, tôi từng viết lại script Bash/Python bằng C# và đẩy tốc độ xử lý JSON lên 1GB/s
    Chỉ riêng các tối ưu kiểu streaming parse cũng đã tạo ra khác biệt lớn
    Nên tôi tò mò — từ mức dữ liệu nào thì việc dùng cluster mới thực sự có ý nghĩa?

    • Ngược lại, 15 năm trước tôi cũng từng thay một hệ thống C# phức tạp bằng bash + Python và nó nhanh hơn hẳn
      Theo tiêu chí của tôi, nếu một tác vụ mất hơn một ngày thì đáng để cân nhắc xử lý phân tán
    • Từng có một nhà khoa học dữ liệu nổi tiếng nói trong panel ở PyCon rằng “Excel tốt hơn Pandas”
      Khi dữ liệu lớn, họ lấy mẫu rồi phân tích bằng Excel. Giờ nhờ LLM mà việc viết các script Python/Bash đơn giản cũng dễ hơn nhiều
    • Ngoài thời gian xử lý, một tiêu chí khác là dữ liệu không lọt vừa ổ đĩa cục bộ
      Có thể đọc ghi trực tiếp từ object storage như S3, và giờ tốc độ 100GB/s cũng khả thi
    • Bộ dữ liệu cờ vua trong bình luận này khoảng 14TB
      Nó nhét vừa vào đĩa, nhưng là kích cỡ không thể với laptop thông thường
    • Tôi tò mò cách parse JSON theo kiểu streaming. Phần lớn parser phải đọc toàn bộ thì mới kiểm tra cú pháp được, nên tôi muốn biết họ giải quyết việc đó thế nào

  • ‘Độ lớn’ của dữ liệu còn tùy vào bạn làm gì với nó
    Ví dụ, với dữ liệu phẫu thuật thì thống kê đơn giản có thể dùng bash là đủ, nhưng nếu muốn tính tương quan giữa kinh nghiệm bác sĩ và tỷ lệ thành công thì độ phức tạp tăng vọt
    Vì thế từ góc nhìn doanh nghiệp, nói “chúng tôi dùng Spark” dễ hơn nhiều so với nói “chúng tôi tạo engine tùy biến cho từng câu hỏi”

    • Nhưng chỉ với SQLite thôi cũng có thể xử lý dữ liệu từ 50GB đến 2TB
      Tất cả các vấn đề được nhắc tới đều có thể giải quyết trên một server duy nhất bằng những công cụ đơn giản

  • Bài này trước đây đã nhiều lần lên HN
    Bản năm 2018, bản năm 2022, bản năm 2024 đều do cùng một người đăng

  • Nó làm tôi nhớ đến câu giới thiệu trên website Shakti ngày xưa
    “1K hàng: Excel / 1M hàng: Pandas / 1B hàng: Shakti / 1T hàng: Only Shakti”
    Nguồn

  • Nhiều lập trình viên học trong môi trường Windows nên không quen với công cụ CLI
    Nhưng CLI cung cấp những khả năng mạnh như vòng lặp ngầm, tự động tách trường, áp dụng regex song song, v.v.
    Nhờ đó có thể nhanh chóng tạo ra giải pháp ad-hoc, và là điểm khởi đầu tốt trước khi dùng các hệ thống quy mô lớn

  • Tôi tự hỏi nếu mở rộng dữ liệu cờ vua lớn hơn nữa rồi benchmark lại thì sao
    Hiện bộ dữ liệu Lichess khoảng 7B ván, 2,34TB nén (14TB không nén)
    Tôi tò mò liệu ở quy mô này Hadoop có thắng được không

    • Nếu nhét nhiều SSD nhanh vào một server thì có lẽ vẫn nhanh hơn EMR+S3
      Chỉ là sẽ cần quản trị server chuyên dụng tương ứng
      EMR là mô hình được thiết kế để xử lý song song khi tần suất truy cập dữ liệu thấp (1–10 lần/ngày)
    • Dữ liệu nén vẫn nhét vừa SSD cục bộ, và cũng có thể giải nén theo luồng
    • Tôi tò mò người ta sẽ tính toán gì với loại dữ liệu này. Thử nghiệm trên NVL72 chắc sẽ vui lắm