เครื่องมือบรรทัดคำสั่งอาจเร็วกว่า Hadoop คลัสเตอร์ได้ 235 เท่า (2014)

 (adamdrake.com)
9 คะแนน โดย GN⁺ 2026-01-19 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • ผลจากการประมวลผล ข้อมูลเกมหมากรุกประมาณ 1.75GB ด้วยเครื่องมือบรรทัดคำสั่งแทน Hadoop พบว่า เสร็จภายใน 12 วินาที เร็วกว่า Hadoop ที่ใช้ 26 นาทีมากกว่า 235 เท่า
  • นำคำสั่งเชลล์พื้นฐานอย่าง grep, sort, uniq, awk, xargs, mawk มาประกอบกันเป็น สตรีมมิงโพรเซสซิงไปป์ไลน์ โดยแทบไม่ใช้หน่วยความจำเลย
  • ผ่านการ ประมวลผลแบบขนานด้วย xargs และการ ปรับแต่งด้วย mawk เพื่อเพิ่มการใช้ประโยชน์จาก CPU core และลดคอขวดด้าน IO ให้น้อยที่สุด
  • เมื่อเทียบกับการประมวลผลชุดข้อมูลเดียวกันบน Hadoop คลัสเตอร์ (c1.medium 7 เครื่อง) พบว่า มีต้นทุนและภาระการดูแลรักษาต่ำกว่ามาก
  • แสดงให้เห็นว่าแม้เป็นเครื่องเดียวก็ทำ data analysis อย่างมีประสิทธิภาพได้ และเตือนให้ตระหนักถึง การใช้เครื่องมือ Big Data โดยไม่จำเป็น

บทนำ: การประมวลผลบนบรรทัดคำสั่งที่เร็วกว่า Hadoop

  • หลังเห็นกรณีศึกษาการวิเคราะห์ข้อมูลเกมหมากรุกราว 2 ล้านเกมด้วย Amazon EMR และ mrjob จึงทดลองทำซ้ำกับข้อมูลเดียวกันด้วย การประมวลผลแบบสตรีมมิงบนบรรทัดคำสั่ง
    • บน Hadoop คลัสเตอร์ (c1.medium 7 เครื่อง) ใช้เวลา 26 นาที, ความเร็วในการประมวลผล 1.14MB/sec
    • บนโน้ตบุ๊กเครื่องเดียวเสร็จใน 12 วินาที, ความเร็วในการประมวลผล 270MB/sec
  • พิสูจน์ว่า งานสรุปผลอย่างง่ายนั้น เชลล์ไปป์ไลน์มีประสิทธิภาพสูงกว่า Hadoop มาก
  • การผสมคำสั่งเชลล์เข้าด้วยกันทำให้สามารถสร้าง โครงสร้างการประมวลผลสตรีมแบบขนานคล้าย Storm ได้บนเครื่องเดียว

โครงสร้างข้อมูลและการเตรียมข้อมูล

  • ข้อมูลอยู่ในรูปแบบบันทึกเกมหมากรุก PGN(Portable Game Notation) โดยผลลัพธ์ของแต่ละเกมจะแสดงในบรรทัด "Result"
    • "1-0" คือขาวชนะ, "0-1" คือดำชนะ, "1/2-1/2" คือเสมอ
  • ดึงชุดข้อมูลขนาดประมาณ 3.46GB มาจาก GitHub repository rozim/ChessData
    • มีขนาดประมาณสองเท่าของข้อมูลทดลองของ Tom Hayden (1.75GB)

การสร้างไปป์ไลน์พื้นฐาน

  • เพื่อวัดขีดจำกัดด้าน IO จึงรัน cat *.pgn > /dev/null และใช้เวลาประมาณ 13 วินาที(272MB/sec)
  • ไปป์ไลน์วิเคราะห์พื้นฐาน: 
    cat *.pgn | grep "Result" | sort | uniq -c
    • ใช้เวลาราว 70 วินาที เร็วกว่า Hadoop ประมาณ 47 เท่า
  • ใช้ AWK มาสรุปผลโดยตรงแทน sort | uniq
    • ใช้เวลา 65 วินาที และแทบไม่ใช้หน่วยความจำ
    • grep ใช้ CPU core เดียวจนกลายเป็นคอขวด

การทำงานแบบขนานและการปรับแต่ง

  • ทำ grep ให้ขนานด้วย xargs 
    find . -type f -name '*.pgn' -print0 | xargs -0 -n1 -P4 grep -F "Result" | gawk ...
    • ใช้เวลา 38 วินาที เร็วขึ้นประมาณ 77 เท่า
  • ตัด grep ออกแล้วใช้ AWK กรองอย่างเดียว เพื่อลดจำนวนขั้นตอน
    • สร้าง AWK pipeline แบบสองชั้น เพื่อรวมผลลัพธ์จากแต่ละไฟล์
    • ใช้เวลา 18 วินาที เร็วขึ้นประมาณ 174 เท่า
  • ปรับเพิ่มอีกขั้นด้วยการเปลี่ยนเป็น mawk 
    find . -type f -name '*.pgn' -print0 | xargs -0 -n4 -P4 mawk ... | mawk ...
    • ใช้เวลา 12 วินาที, เร็วกว่า Hadoop 235 เท่า, ความเร็วในการประมวลผล 270MB/sec

บทสรุป: ประสิทธิภาพของความเรียบง่าย

  • หากไม่ได้ต้องการ distributed processing ขนาดใหญ่ การผสมเครื่องมือเชลล์บนเครื่องเดียวมักเร็วกว่าและคุ้มค่ากว่า
  • Hadoop มักถูกใช้เกินความจำเป็นแม้กับงานที่ ฐานข้อมูลเชิงสัมพันธ์หรือสคริปต์ง่าย ๆ ก็เพียงพอ
  • การวิเคราะห์แบบสตรีมมิงบนบรรทัดคำสั่งเป็นทางเลือกที่ยอดเยี่ยมในแง่ของ ประสิทธิภาพ ต้นทุนการพัฒนา และการดูแลรักษา

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
dongho42 2026-01-20

เมื่อก่อนเคยมีคำว่า Taco Bell programming อยู่ เหมือนจะเป็นปรัชญาที่คล้ายกันนะ
 
GN⁺ 2026-01-19
ความคิดเห็นจาก Hacker News

  • สิ่งที่น่าเศร้าที่สุดคือบทความนี้มาจากปี 2014
    ตอนนี้มีชั้นนามธรรมเพิ่มขึ้นอีกอย่าง Airflow, dbt, Snowflake จนกลายเป็นว่านำสิ่งเหล่านี้มาครอบแม้กับชุดข้อมูลที่จริง ๆ แล้วใส่ใน RAM ได้ทั้งหมด
    สตาร์ตอัปเผาเงินเดือนละ 5,000 ดอลลาร์ไปกับคลัสเตอร์แบบกระจาย เพื่อประมวลผลล็อกไม่ถึง 10GB ต่อวัน เหตุผลคือถ้าใช้ ‘Modern Data Stack’ จะได้เลื่อนตำแหน่ง แต่ถ้าแก้ด้วย bash script จะถูกมองข้ามว่า ‘ขยายไม่ได้’ ประสิทธิภาพกับแรงจูงใจสวนทางกันโดยสิ้นเชิง

    • ช่วงหลังเวลาไปสัมภาษณ์ มักพูดกันว่าเป็น ‘ปัญหาเรื่องสเกล’ แต่ในความเป็นจริงหลายครั้งข้อมูลก็พออยู่ในเครื่องเดียวได้
      เคยมีกรณี ingest JSON วันละ 1GB พอผมอธิบายว่า “เครื่องเดียวก็พอ” ก็ถูกบอกว่า “มันถูกในทางเทคนิค แต่ไม่ใช่คำตอบที่เราอยากได้” แล้วก็ไม่ผ่าน
      ทุกวันนี้เครื่องมี RAM ระดับ TB และคอร์นับร้อย เครื่องเดียวตอนนี้ใหญ่โตมหาศาลอยู่แล้ว
    • นี่ไม่ใช่แค่เรื่องการเลื่อนตำแหน่ง แต่เป็นปัญหาของ โครงสร้างการจ้างงาน ด้วย
      เวลารับคนสาย DevOps ก็มักเน้นประสบการณ์กับเฟรมเวิร์กหรู ๆ สุดท้ายพอพวกเขาเข้าบริษัทมาก็ทำแบบเดิมซ้ำ
      ไม่มีใครคัดค้าน สุดท้ายเลยทำให้งานที่เดสก์ท็อปเครื่องเดียวก็พอ กลายเป็นเรื่องซับซ้อนเกินจำเป็น
    • ตลอด 20 ปีที่ผ่านมา ผมเลือกใช้ ‘เทคโนโลยีที่เหมาะสม’ แทน ‘เทคโนโลยีที่ดูเท่’ แล้วสุดท้ายก็ถูกเลย์ออฟ
      ตอนนี้หางานมานานกว่าปีด้วยเรซูเม่ที่แทบไม่มี เฟรมเวิร์กล่าสุด จนเริ่มรู้สึกว่าตัวเองโง่
    • ที่บริษัทผมก็เห็นอะไรคล้าย ๆ กัน เอาข้อมูลวันละไม่กี่ GB ไปวนผ่านหลายระบบ ทั้งที่เมื่อก่อนใช้ Python script ทำแค่อาทิตย์เดียวเสร็จ ตอนนี้กลับกินเวลาหลายเดือนและพังบ่อย
    • เดี๋ยวนี้แม้แต่ โน้ตบุ๊ก RAM 128GB ก็พบได้ทั่วไป และเซิร์ฟเวอร์ก็ใหญ่กว่านั้นมาก
      ปี 2014 ยังถือว่า 4GB เป็นเรื่องปกติ แต่ตอนนี้ความเร็วในการสตรีมจาก SSD ก็เร็วขึ้นมาก จนบางทีอ่านจาก SSD ในเครื่องยังดีกว่าคลัสเตอร์

  • ผู้เขียนเองครับ!
    ดีใจที่บทความเก่ายังมีประโยชน์อยู่
    ผมเห็นด้วยกับความเห็นที่ว่าสถานการณ์แย่ลง แต่ในอีกด้านก็ยังดีที่เริ่มเห็นการขยับออกจากการ ศรัทธาใน microservices แบบสุดโต่ง
    ขอส่งกำลังใจให้ทุกคนที่พยายามปรับปรุงประสิทธิภาพ ยังมี ความหวัง อยู่

    • Adam ขอบคุณมาก!
      ผมกลับไปอ่านบทความนี้หลายรอบ และได้แรงบันดาลใจจนพอร์ต Waters-Series ไปเป็น JavaScript เพื่อทำ stream pipelining

  • ตอนนี้ในวงการมีความเชื่อแรงมากว่า Spark หรือเครื่องมือแบบกระจาย คือคำตอบของ data engineering
    คล้ายกับการใช้เฟรมเวิร์ก SPA มากเกินไปในงานเว็บ
    คำแนะนำของผมคือ:

    • ผู้จัดการไม่ควรกำหนดว่าต้องใช้เทคโนโลยีใดเทคโนโลยีหนึ่ง (Spark, React) แต่ควรมอบให้วิศวกรที่ แก้ปัญหาได้ ตัดสินใจ
    • tech lead ควรพูดอย่างตรงไปตรงมาว่า “pipeline ของเรารองรับได้ถึง 20GB และถ้าใหญ่กว่านั้น เรามีแผนจะขยายด้วย X/Y/Z”
      สิ่งที่ผู้จัดการอยากได้ยินไม่ใช่ ‘ทุกอย่างขยายได้ไม่สิ้นสุด’ แต่คือความมั่นใจว่า ‘มันทำงานได้เสถียร’
    • บริษัทส่วนใหญ่จัดการกับ ข้อมูลขนาดเล็ก
      ขนาดข้อมูลเป็นไปตามกฎกำลัง ดังนั้นวิศวกรที่ทำข้อมูลระดับเพตะไบต์มีอยู่น้อยมาก
      แต่เพราะทุกคนอยากใส่ประสบการณ์แบบนั้นลงในเรซูเม่เพื่อเพิ่มเงินเดือน จึงเกิด over-engineering
    • ตอนเคยทำงานที่ยูนิคอร์นชื่อดังแห่งหนึ่ง ผู้จัดการบอกว่า “ไตรมาสหน้าต้องใช้ Spark”
      พอถามเหตุผลกลับได้คำตอบว่า “ก็ต้องใช้” น่าจะเป็นเพราะ เอาไว้ใส่ในเรซูเม่ หรือไม่ก็เหตุผลทางการเมืองของใครสักคน

  • นี่เป็นเรื่องเล่าทางประวัติศาสตร์ที่เกี่ยวกับบทความ
    เครื่องมือชื่อ mrjob สามารถรันในโหมด local ได้โดยไม่ต้องมี Hadoop
    กับชุดข้อมูลเล็ก มันเร็วกว่าใช้คลัสเตอร์มาก โดยเฉพาะเมื่อเทียบกับคลัสเตอร์ชั่วคราวอย่าง AWS EMR
    แต่แนวทางของผู้เขียนก็น่าจะมีประสิทธิภาพยิ่งกว่านั้นอีก
    MapReduce ทำให้การขยายขนาดใหญ่เป็นเรื่องง่ายก็จริง แต่กับข้อมูลเล็กมันมี ข้อจำกัดที่ไม่มีประสิทธิภาพ อยู่มาก
    ช่วงต้นยุค 2010 เคยใช้ mrjob ประมวลผลข้อมูลระดับเพตะไบต์ แต่ตอนนี้แทบไม่มีใครใช้แล้ว

  • ตอนทำงานเป็น data engineer ผมเคยเขียน Bash/Python script ใหม่เป็น C# จนดันความเร็วประมวลผล JSON ไปได้ถึง 1GB/s
    แค่การปรับให้เหมาะอย่าง streaming parse ก็สร้างความต่างได้มากแล้ว
    เลยสงสัยว่า — ต้องมากขนาดไหนข้อมูลถึงจะถึงจุดที่การทำคลัสเตอร์มีความหมายจริง ๆ?

    • แต่ในทางกลับกัน เมื่อ 15 ปีก่อนผมก็เคยเปลี่ยนระบบ C# ที่ซับซ้อนให้เป็น bash + Python แล้วมันกลับเร็วขึ้นมาก
      สำหรับผม ถ้างานไหนใช้เวลาเกินหนึ่งวัน ค่อยน่าพิจารณาเรื่องประมวลผลแบบกระจาย
    • เคยมีนักวิทยาศาสตร์ข้อมูลชื่อดังพูดในเวที PyCon ว่า “Excel ดีกว่า Pandas”
      ถ้าข้อมูลใหญ่ก็สุ่มตัวอย่างออกมาวิเคราะห์ใน Excel ตอนนี้ยิ่งมี LLM แล้ว การเขียน Python/Bash script ง่าย ๆ ก็ยิ่งทำได้สะดวก
    • นอกจากเวลาในการประมวลผลแล้ว อีกเกณฑ์หนึ่งคือ ข้อมูลใหญ่จนใส่ดิสก์ในเครื่องไม่ได้
      ตอนนี้ก็สามารถอ่านเขียนตรงกับ object storage อย่าง S3 ได้ และเดี๋ยวนี้ก็ทำความเร็วได้ถึง 100GB/s
    • ชุดข้อมูลหมากรุกในคอมเมนต์นี้ มีขนาดราว 14TB
      มันยังใส่ดิสก์ได้ แต่ใหญ่เกินสำหรับโน้ตบุ๊กทั่วไป
    • ผมอยากรู้วิธี parse JSON แบบสตรีมมิง เพราะ parser ส่วนใหญ่มักต้องอ่านทั้งหมดก่อนถึงจะตรวจ syntax ได้ เลยอยากรู้ว่าแก้ปัญหานี้อย่างไร

  • ‘ความใหญ่’ ของข้อมูลขึ้นอยู่กับ คุณจะทำอะไรกับมัน
    เช่น กับข้อมูลการผ่าตัด ถ้าจะเอาแค่สถิติง่าย ๆ bash ก็พอ แต่ถ้าจะคำนวณความสัมพันธ์ระหว่างประสบการณ์ของแพทย์กับอัตราความสำเร็จ ความซับซ้อนจะเพิ่มขึ้นอย่างรวดเร็ว
    ดังนั้นในมุมบริษัท การพูดว่า “เราใช้ Spark” จึงง่ายกว่าการพูดว่า “เราสร้างเอนจินให้เหมาะกับแต่ละคำถาม” มาก

    • แต่จริง ๆ แล้วแค่ SQLite ก็จัดการข้อมูล 50GB~2TB ได้
      ทุกปัญหาที่กล่าวมาสามารถแก้บนเซิร์ฟเวอร์เดี่ยวด้วยเครื่องมือง่าย ๆ ได้

  • บทความนี้เคยขึ้น HN มาหลายรอบแล้ว
    เวอร์ชันปี 2018, เวอร์ชันปี 2022, เวอร์ชันปี 2024 ทั้งหมดถูกส่งโดยผู้โพสต์คนเดิม

  • ทำให้นึกถึงข้อความแนะนำบนเว็บไซต์ Shakti สมัยก่อน
    “1K rows: Excel / 1M rows: Pandas / 1B rows: Shakti / 1T rows: Only Shakti”
    ที่มา

  • นักพัฒนาหลายคนเรียนรู้มาจาก สภาพแวดล้อม Windows เลยไม่คุ้นกับเครื่องมือ CLI
    แต่ CLI มีความสามารถทรงพลัง เช่น implicit loop, การแยกฟิลด์อัตโนมัติ, การใช้ regex แบบขนาน
    จึงเหมาะมากสำหรับการทำ ad-hoc solution อย่างรวดเร็ว และเป็นจุดเริ่มต้นที่ดีก่อนจะไปใช้ระบบขนาดใหญ่

  • เลยคิดว่าถ้าขยายข้อมูลหมากรุกให้ใหญ่ขึ้นแล้วทำ benchmark ใหม่จะเป็นอย่างไร
    ตอนนี้ ชุดข้อมูล Lichess มีราว 7B เกม บีบอัดแล้ว 2.34TB (ไม่บีบอัด 14TB)
    อยากรู้ว่าที่ขนาดแบบนี้ Hadoop จะชนะได้ไหม

    • ถ้ามี SSD เร็ว ๆ หลายลูกอยู่ในเซิร์ฟเวอร์เครื่องเดียว ก็น่าจะยังเร็วกว่า EMR+S3
      แต่ก็ต้องแลกกับการดูแล เซิร์ฟเวอร์เฉพาะทาง ระดับนั้น
      EMR เป็นโมเดลที่ออกแบบมาสำหรับการประมวลผลแบบขนาน เมื่อความถี่ในการเข้าถึงข้อมูลไม่สูงนัก (วันละ 1~10 ครั้ง)
    • ข้อมูลที่บีบอัดแล้วยังใส่ SSD ในเครื่องได้สบาย และยัง คลายการบีบอัดแบบสตรีมมิง ได้ด้วย
    • อยากรู้ว่าจะคำนวณอะไรกับข้อมูลแบบนี้ ถ้าเอาไปลองบน NVL72 ก็น่าจะสนุกดี