कमांड-लाइन टूल्स Hadoop क्लस्टर से 235 गुना तेज हो सकते हैं (2014)

• लगभग 1.75GB शतरंज मैच डेटा को Hadoop की जगह कमांड-लाइन टूल्स से प्रोसेस करने पर काम सिर्फ 12 सेकंड में पूरा हुआ, जो Hadoop के 26 मिनट की तुलना में 235 गुना से भी अधिक तेज था
• grep, sort, uniq, awk, xargs, mawk जैसे बेसिक shell commands को जोड़कर streaming processing pipeline बनाई गई, जिससे मेमोरी उपयोग लगभग शून्य बना रहा
• xargs parallel processing और mawk optimization के जरिए CPU cores का उपयोग बढ़ाया गया और IO bottleneck को न्यूनतम किया गया
• वही dataset Hadoop cluster (7 c1.medium instances) पर चलाने की तुलना में लागत और maintenance burden काफी कम रहा
• यह दिखाता है कि single machine पर भी प्रभावी data analysis संभव है, और अनावश्यक Big Data tools के उपयोग पर सावधानी की जरूरत बताता है

---

परिचय: Hadoop से तेज कमांड-लाइन प्रोसेसिंग

• Amazon EMR और mrjob के साथ लगभग 20 लाख शतरंज मैचों के डेटा का विश्लेषण करने वाले एक उदाहरण को देखकर, उसी डेटा को कमांड-लाइन आधारित streaming processing से दोबारा लागू किया गया
  • Hadoop cluster (7 c1.medium) पर 26 मिनट लगे, 1.14MB/sec processing speed
  • लोकल laptop पर सिर्फ 12 सेकंड में पूरा, 270MB/sec processing speed
• साधारण result aggregation जैसे कामों में shell pipeline, Hadoop की तुलना में कहीं अधिक efficient साबित होती है
• shell commands को जोड़कर Storm जैसी parallel stream processing structure एक single machine पर लागू की जा सकती है

डेटा संरचना और तैयारी

• डेटा PGN(Portable Game Notation) फ़ॉर्मेट में शतरंज मैच रिकॉर्ड है, और हर मैच का परिणाम "Result" लाइन में दिया गया है
  • "1-0" का मतलब सफेद की जीत, "0-1" का मतलब काले की जीत, "1/2-1/2" का मतलब ड्रॉ
• GitHub के rozim/ChessData repository से लगभग 3.46GB dataset लिया गया
  • Tom Hayden के प्रयोग वाले डेटा (1.75GB) से लगभग दोगुना आकार

बेसिक pipeline बनाना

• IO सीमा मापने के लिए cat *.pgn > /dev/null चलाने पर लगभग 13 सेकंड(272MB/sec) लगे
• बेसिक analysis pipeline:

  cat *.pgn | grep "Result" | sort | uniq -c
  

  • execution time लगभग 70 सेकंड, Hadoop की तुलना में लगभग 47 गुना तेज
• sort | uniq की जगह AWK का उपयोग कर results को सीधे aggregate किया गया
  • execution time 65 सेकंड, मेमोरी उपयोग लगभग शून्य
  • grep एक single CPU core पर अटककर bottleneck बन गया

Parallelization और optimization

• xargs से grep को parallel किया गया

  find . -type f -name '*.pgn' -print0 | xargs -0 -n1 -P4 grep -F "Result" | gawk ...
  

  • execution time 38 सेकंड, लगभग 77 गुना speed-up
• grep हटाकर सिर्फ AWK filtering से pipeline को सरल बनाया गया
  • हर फ़ाइल के परिणामों को मिलाने के लिए double AWK pipeline बनाई गई
  • execution time 18 सेकंड, लगभग 174 गुना तेज
• mawk में बदलने पर अतिरिक्त optimization मिला

  find . -type f -name '*.pgn' -print0 | xargs -0 -n4 -P4 mawk ... | mawk ...
  

  • execution time 12 सेकंड, Hadoop की तुलना में 235 गुना तेज, processing speed 270MB/sec

निष्कर्ष: सादगी की दक्षता

• बड़े पैमाने की distributed processing की ज़रूरत न हो, तो single machine पर shell tools का संयोजन अधिक तेज और किफायती हो सकता है
• Hadoop का उपयोग अक्सर ऐसे कामों में भी ज़रूरत से ज़्यादा किया जाता है जिन्हें relational DB या साधारण scripts से संभाला जा सकता है
• कमांड-लाइन आधारित streaming analysis, performance, implementation cost, maintenance के लिहाज से एक बेहतर विकल्प है

[dongho42]

पहले "Taco Bell programming" जैसी एक बात होती थी, यह भी कुछ वैसी ही सोच लगती है।

[GN⁺]

Hacker News टिप्पणियाँ

• इस लेख के 2014 का होने की बात ही सबसे दुखद है
  अब Airflow, dbt, Snowflake जैसे और भी ज़्यादा abstraction layers आ गए हैं, और हालत यह है कि जो dataset आराम से RAM में समा सकता है, उस पर भी इन्हें चढ़ा दिया जाता है
  startup कंपनियाँ रोज़ के 10GB से भी कम logs प्रोसेस करने के लिए distributed cluster पर हर महीने 5,000 डॉलर जला देती हैं। वजह यह है कि ‘Modern Data Stack’ इस्तेमाल करने पर promotion मिलता है, लेकिन bash scripts से काम कर दो तो उसे ‘non-scalable’ कहकर नज़रअंदाज़ कर दिया जाता है। efficiency और incentives पूरी तरह से एक-दूसरे से कटे हुए हैं

  • हाल की interviews में इसे ‘scaling problem’ कहकर पेश किया गया, लेकिन वास्तव में कई मामले ऐसे थे जो एक ही machine में आराम से फिट हो जाते
    एक मामला तो रोज़ 1GB JSON ingest करने का था, और जब मैंने समझाया कि “एक machine काफ़ी है”, तो जवाब मिला, “तकनीकी रूप से सही है, लेकिन यह वह जवाब नहीं है जो हम चाहते हैं”, और मुझे reject कर दिया गया
    आजकल की machines में TB-स्तर की RAM और सैकड़ों cores होते हैं। एक अकेली machine पहले से ही बहुत विशाल है
  • यह सिर्फ promotion का मामला नहीं, hiring structure की भी समस्या है
    जब DevOps लोगों की hiring में चमकदार framework अनुभव पर ज़ोर दिया जाता है, तो वे कंपनी में आकर वही चीज़ें दोहराते हैं
    कोई विरोध नहीं करता, और आख़िरकार desktop एक से हो जाने वाले काम को भी अनावश्यक रूप से जटिल बना दिया जाता है
  • पिछले 20 सालों से मैंने ‘कूल दिखने वाली tech’ की बजाय ‘सही tech’ का इस्तेमाल किया, और अंत में मुझे नौकरी से निकाल दिया गया
    latest frameworks लगभग न होने वाले resume के साथ मैं एक साल से ज़्यादा समय से नौकरी खोज रहा हूँ, और अब ख़ुद को बेवकूफ़ जैसा महसूस होने लगा है
  • कंपनी में भी ऐसा ही देखा है। रोज़ के कुछ GB data को कई systems में घुमाने के लिए, जो काम पहले Python script से एक हफ़्ते में हो जाता था, अब उसमें महीनों लगते हैं और वह बार-बार टूटता भी है
  • आजकल 128GB RAM laptops भी आम हैं, और servers तो इससे कहीं बड़े होते हैं
    2014 में 4GB सामान्य था, लेकिन अब SSD streaming speeds भी इतनी तेज़ हैं कि कई बार local SSD से पढ़ना cluster से बेहतर साबित होता है

• मैं ही इस लेख का लेखक हूँ!
  यह जानकर खुशी हुई कि पुराना लेख अब भी लोगों के काम आ रहा है
  मैं इस बात से सहमत हूँ कि स्थिति और बिगड़ी है, लेकिन दूसरी तरफ़ microservices के अंधविश्वास से बाहर निकलने की कुछ हलचल भी दिख रही है, यह राहत की बात है
  performance सुधारने की कोशिश कर रहे सभी लोगों को मेरा समर्थन। अभी भी उम्मीद है

  • Adam, धन्यवाद!
    मैंने इस लेख को कई बार फिर से पढ़ा, और प्रेरित होकर Waters-Series को JavaScript में port करके stream pipelining लागू की

• आजकल industry में यह धारणा बहुत मज़बूत हो गई है कि Spark या distributed tools ही data engineering का सही जवाब हैं
  यह कुछ-कुछ वैसा ही है जैसे web development में SPA frameworks का ज़रूरत से ज़्यादा इस्तेमाल
  मेरी सलाह यह है:

  • managers को किसी खास tech (Spark, React) की मांग नहीं करनी चाहिए, बल्कि problem-solving ability वाले engineers पर भरोसा करना चाहिए
  • tech lead को ईमानदारी से कहना चाहिए, “हमारी pipeline 20GB तक संभाल सकती है, और उससे आगे बढ़ने पर हम X/Y/Z से scale करेंगे”
    manager वास्तव में यह नहीं सुनना चाहता कि ‘सब कुछ अनंत तक scale हो जाएगा’, बल्कि यह भरोसा चाहता है कि ‘यह स्थिर रूप से चलेगा’
  • ज़्यादातर कंपनियाँ छोटे पैमाने का data संभालती हैं
    data size power law का पालन करता है, इसलिए petabyte-स्तर का data संभालने वाले engineers बहुत कम होते हैं
    लेकिन salary बढ़ाने के लिए लोग ऐसा अनुभव resume में डालना चाहते हैं, और वहीं से over-engineering शुरू होती है
  • पहले एक मशहूर unicorn में काम करते समय manager ने कहा था, “अगली तिमाही में हमें Spark इस्तेमाल करना है”
    जब मैंने वजह पूछी, तो जवाब था, “बस करना है।” शायद resume value के लिए, या किसी की political वजह से

• यह लेख से जुड़ी एक ऐतिहासिक बात है
  mrjob नाम का tool Hadoop के बिना local mode में भी चल सकता था
  छोटे datasets पर यह cluster से कहीं तेज़ था। खासकर AWS EMR जैसे ephemeral cluster से भी जल्दी काम पूरा हो जाता था
  लेकिन लगता है कि लेखक का तरीका उससे भी ज़्यादा efficient रहा होगा
  MapReduce बड़े पैमाने पर scaling आसान बनाता था, लेकिन छोटे data पर उसके साथ कई अक्षम बाधाएँ भी आती थीं
  2010 के शुरुआती वर्षों में mrjob से petabyte-स्तर का data प्रोसेस किया गया था, लेकिन अब इसका लगभग इस्तेमाल नहीं होता

• data engineer के रूप में काम करते समय मैंने Bash/Python scripts को C# में फिर से लिखकर JSON processing speed को 1GB/s तक पहुँचा दिया था
  सिर्फ streaming parsing जैसी optimizations से ही बहुत बड़ा फ़र्क पड़ा
  इसलिए जिज्ञासा है — आखिर किस data size के बाद clustering वास्तव में मायने रखती है?

  • उल्टा, 15 साल पहले मैंने एक जटिल C# system को bash + Python में बदलकर उसे कहीं तेज़ बना दिया था
    मेरे हिसाब से अगर कोई काम एक दिन से ज़्यादा लेता है, तब distributed processing पर विचार किया जा सकता है
  • एक बार PyCon panel में एक मशहूर data scientist ने कहा था, “Excel Pandas से बेहतर है”
    उनका कहना था कि data बड़ा हो तो sampling करके Excel में analysis कर लो। आजकल LLM की वजह से साधारण Python/Bash scripts भी आसानी से लिखी जा सकती हैं
  • processing time के अलावा, local disk में न समा पाने वाला data भी एक और मानदंड है
    S3 जैसे object storage से सीधे पढ़ना-लिखना संभव है, और आजकल 100GB/s की speed भी मिल सकती है
  • इस टिप्पणी में बताया गया chess dataset लगभग 14TB का है
    disk में तो समा सकता है, लेकिन सामान्य laptop के लिए यह असंभव आकार है
  • JSON को streaming के साथ parse करने का तरीका जानना चाहता हूँ। ज़्यादातर parsers को syntax validation के लिए पूरी चीज़ पढ़नी पड़ती है, तो यह कैसे सुलझाया गया, जानना दिलचस्प होगा

• data का ‘size’ इस बात पर निर्भर करता है कि आप उससे क्या करना चाहते हैं
  उदाहरण के लिए, surgical data पर साधारण statistics के लिए bash काफ़ी हो सकता है, लेकिन डॉक्टर के अनुभव और success rate के बीच correlation निकालना हो तो जटिलता अचानक बढ़ जाती है
  इसलिए कंपनियों के लिए “हम Spark इस्तेमाल करते हैं” कहना, “हम हर सवाल के लिए custom engine बनाते हैं” कहने से कहीं आसान है

  • लेकिन सिर्फ SQLite से भी 50GB~2TB data संभाला जा सकता है
    यहाँ बताए गए सभी तरह के काम एक single server पर सरल tools से हल किए जा सकते हैं

• यह लेख पहले भी कई बार HN पर आया है
  2018 संस्करण, 2022 संस्करण, 2024 संस्करण — तीनों को उसी submitter ने पोस्ट किया था

• मुझे पुराने Shakti website की intro line याद आ गई
  “1K rows: Excel / 1M rows: Pandas / 1B rows: Shakti / 1T rows: Only Shakti”
  स्रोत

• बहुत से developers ने Windows environment में सीखना शुरू किया, इसलिए वे CLI tools के साथ सहज नहीं हैं
  लेकिन CLI implicit loops, automatic field splitting, regular expressions की parallel application जैसी शक्तिशाली सुविधाएँ देता है
  इसी वजह से तेज़ी से ad-hoc solutions बनाए जा सकते हैं, और बड़े systems अपनाने से पहले यह एक अच्छा शुरुआती बिंदु बनता है

• सोचता हूँ कि chess data को और बड़ा scale करके benchmark फिर से चलाया जाए तो क्या होगा
  आजकल Lichess dataset लगभग 7B games, 2.34TB compressed (14TB uncompressed) है
  इस scale पर Hadoop जीत पाएगा या नहीं, यह जानना दिलचस्प होगा

  • अगर एक server में कई तेज़ SSD लगा दिए जाएँ, तो यह अब भी EMR+S3 से तेज़ हो सकता है
    लेकिन उसके साथ उतने ही स्तर का dedicated server management भी चाहिए होगा
    EMR का model उन स्थितियों के लिए बना है जहाँ data access frequency कम हो (रोज़ 1~10 बार) और parallel processing चाहिए
  • compressed data आराम से local SSD में आ सकता है, और streaming decompression भी संभव है
  • जिज्ञासा है कि ऐसे data से क्या compute किया जाएगा। NVL72 पर इसे आज़माना मज़ेदार हो सकता है