Big Data का अंत (2023)

 (motherduck.com)
1 पॉइंट द्वारा GN⁺ 2024-05-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • BigQuery के शुरुआती इंजीनियरिंग अनुभव के आधार पर देखें तो, कई संगठनों में bottleneck डेटा के आकार से ज़्यादा डेटा के उपयोग के तरीके और cost structure से जुड़ा था
  • BigQuery ग्राहकों और industry feedback में, अधिकांश data warehouse 1TB से कम थे, और heavy-use ग्राहकों का median भी 100GB से काफी छोटा था
  • cloud में storage-compute separation ने storage volume बहुत बढ़ाया, लेकिन analytics compute की मांग हाल का डेटा और aggregation-केंद्रित होने के कारण उसी अनुपात में नहीं बढ़ी
  • BigQuery में सालाना 1,000 डॉलर से अधिक खर्च करने वाले ग्राहकों की queries में 90% ने 100MB से कम process किया, और बहुत बड़े datasets वाले ग्राहक भी बड़े queries बार-बार नहीं चलाते थे
  • पुराना डेटा regulation, litigation, अर्थ के धुंधले पड़ने, और special handling logic की वजह से liability बन सकता है, इसलिए raw data को बस संभालकर रखने के बजाय aggregation, deletion, या summary बेहतर है या नहीं, यह जांचना चाहिए

Big Data के डर और असली bottleneck के बीच का फर्क

  • 10 साल से अधिक समय तक यह संदेश दोहराया गया कि data से actionable insight निकालना मुश्किल होने का कारण डेटा का आकार है
  • इसके बाद यह नुस्खा दिया गया कि बड़े scale को संभालने वाली नई technology खरीद लो, समस्या हल हो जाएगी; लेकिन नए tools खरीदने और legacy system migration के बाद भी कई संगठन data को समझने में संघर्ष करते रहे
  • 2023 की स्थिति उस दौर से अलग है जब Big Data की चेतावनियां शुरू हुई थीं
    • जिस डेटा महाविस्फोट की भविष्यवाणी की गई थी, वह नहीं आया
    • डेटा का आकार कुछ बढ़ा, लेकिन hardware उससे भी तेज़ी से बढ़ा
    • vendors अब भी scalability को बेचते हैं, लेकिन practitioners यह पूछने लगे हैं कि इसका वास्तविक समस्याओं से रिश्ता क्या है

BigQuery के अनुभव में ग्राहकों के डेटा का आकार

  • Google BigQuery के founding engineer रहे लेखक ने public presentations में 1PB query चलाकर बड़े पैमाने पर data processing capability दिखाई थी
  • उसके बाद उन्होंने BigQuery ग्राहक समस्याओं को debug किया, 2 किताबें सह-लिखीं, और 2018 से product manager के रूप में customer conversations और product metrics analysis संभाला
  • सबसे चौंकाने वाला अवलोकन यह था कि “BigQuery” के अधिकांश users के पास वास्तव में Big Data था ही नहीं
    • बड़े डेटा वाले ग्राहकों में भी ऐसे workloads बहुत थे जो पूरे dataset के छोटे हिस्से पर चलते थे
    • BigQuery के launch के समय तेज़ processing science fiction जैसी लगती थी, लेकिन बाद में अधिक traditional processing approaches भी बराबरी पर आ गए
  • लेख के graphs सटीक संख्याएं नहीं बल्कि स्मृति पर आधारित hand-drawn sketches हैं, और यहां महत्वपूर्ण चीज़ exact value नहीं बल्कि distribution का shape है
  • आधार query logs, transaction postmortems, benchmark results, customer support tickets, customer conversations, service logs, public blog posts, और intuition से आता है

अधिकांश संगठनों के पास इतना डेटा नहीं होता

  • “Big Data आ रहा है” वाली sales slides यह संदेश देती थीं कि जल्द ही सभी डेटा के बोझ तले दब जाएंगे, लेकिन 10 साल बाद भी वह भविष्य सच नहीं हुआ
  • BigQuery ग्राहकों के आकार को देखें तो अधिकांश ग्राहकों का कुल stored data 1TB से कम था
    • सैकड़ों PB डेटा वाले ग्राहक भी थे, लेकिन आकार तेजी से घटती power-law distribution का पालन करता था
    • हजारों ग्राहक ऐसे थे जिनका monthly storage bill 10 डॉलर से कम था, जो लगभग 0.5TB के बराबर है
    • सेवा का भारी उपयोग करने वाले ग्राहकों में भी median storage 100GB से काफी कम था
  • Gartner, Forrester जैसे industry analysts के साथ बातचीत में भी feedback मिला कि अधिकांश enterprise data warehouses 1TB से छोटे होते हैं
    • industry intuition के हिसाब से data warehouse का उचित आकार लगभग 100GB था
    • BigQuery टीम ने benchmarking efforts में इसी आकार को प्रमुख focus बनाया
  • एक investor ने portfolio companies का सर्वे किया तो पाया कि अपेक्षाकृत बड़े डेटा की संभावना वाली tech companies में भी सबसे बड़ी B2B company लगभग 1TB और सबसे बड़ी B2C company लगभग 10TB थी, जबकि अधिकांश इससे बहुत छोटी थीं
  • मध्यम आकार के business examples में भी डेटा आसानी से विशाल नहीं बनता
    • मान लें 1,000 ग्राहक रोज़ 1 order और 100 line items बनाते हैं, तब भी प्रतिदिन डेटा 1MB से कम रहेगा, और 3 साल बाद भी लगभग 1GB होगा
    • marketing DB में 10 लाख leads और दर्जनों campaigns हों, तब भी leads table 1GB से कम और campaign tracking कुछ GB के स्तर पर होने की संभावना है
    • जब SingleStore 2020~2022 में तेज़ी से बढ़ती Series E unicorn company थी, तब भी finance warehouse, customer data, marketing campaign tracking, और service logs मिलाकर डेटा कुछ GB ही था

storage और compute के अलग होने से बना भ्रम

  • आधुनिक cloud data platforms लगभग सभी storage और compute separation अपनाते हैं, ताकि ग्राहक एक ही form factor में बंधे न रहें
  • यह बदलाव पिछले 20 वर्षों की data architecture में scale-out से भी अधिक महत्वपूर्ण परिवर्तन हो सकता है
    • मुश्किल shared-nothing architecture की जगह shared-disk architecture ने storage और compute को स्वतंत्र रूप से बढ़ाना संभव बनाया
    • S3 और GCS जैसे scalable और पर्याप्त तेज़ object storage ने database design constraints को ढीला किया
  • व्यवहार में डेटा का आकार compute से कहीं तेज़ बढ़ता है
    • डेटा समय के साथ बनता है, और static business में भी storage समय के साथ रैखिक रूप से बढ़ता है
    • analytics आम तौर पर हाल के डेटा पर केंद्रित होते हैं, इसलिए compute demand को storage की तरह बढ़ने की ज़रूरत नहीं होती
    • पुराना डेटा बदलता नहीं, इसलिए उसे बार-बार scan करना लगभग waste है, और महत्वपूर्ण जवाब aggregation से निकाले जा सकते हैं
  • on-premises से storage-compute separation वाले cloud में गए ग्राहकों में अक्सर storage बहुत बढ़ा, लेकिन compute demand लगभग वैसी ही रही
    • BigQuery के एक बड़े retail ग्राहक का on-premises data warehouse लगभग 100TB था, लेकिन cloud migration के बाद 30PB तक बढ़ गया
    • storage 300 गुना बढ़ा, लेकिन compute cost उसी अनुपात में नहीं बढ़ी, और analytics पर अरबों डॉलर खर्च नहीं हुए
  • यह architecture दिखाता है कि scalable object store का उपयोग करने पर अपेक्षा से बहुत कम compute पर्याप्त हो सकता है, और distributed processing की ज़रूरत भी न पड़े

वास्तविक query workloads पूरे डेटा से कहीं छोटे होते हैं

  • analytics workloads जितना डेटा process करते हैं, वह intuition से छोटा होने की संभावना है
    • dashboards अक्सर aggregated data से बनते हैं
    • users अधिकतर पिछले 1 घंटे, 1 दिन, या 1 हफ्ते का डेटा देखते हैं
    • छोटी tables अधिक बार query होती हैं, और विशाल tables अधिक चयनात्मक तरीके से query होती हैं
  • BigQuery में सालाना 1,000 डॉलर से ज़्यादा खर्च करने वाले ग्राहकों की queries का विश्लेषण करने पर 90% queries ने 100MB से कम process किया
    • अलग-अलग तरीकों से विभाजित करके विश्लेषण किया गया ताकि किसी एक ग्राहक का query volume नतीजों को distort न करे
    • केवल metadata queries, जो कोई data read नहीं करतीं, उन्हें बाहर रखा गया
    • GB-range queries ऊंचे percentiles पर जाकर दिखीं, और TB-range queries बहुत दुर्लभ थीं
  • बहुत बड़े डेटा वाले ग्राहक भी बहुत बड़े डेटा को लगभग query नहीं करते थे
    • बड़े queries चलाए भी गए तो आम तौर पर report generation के लिए, और performance वहां प्राथमिकता नहीं थी
    • एक बड़ी social media company सोमवार के executive report के लिए weekend में बहुत बड़े queries चलाती थी, लेकिन यह सप्ताह के दौरान चलने वाली लाखों queries का बहुत छोटा हिस्सा था
  • आधुनिक analytics databases वास्तव में पढ़े जाने वाले data को कम करने के कई तरीके इस्तेमाल करते हैं
    • column projection से केवल आवश्यक fields पढ़े जाते हैं
    • partition pruning से केवल संकीर्ण date range पढ़ी जाती है
    • clustering या automatic micro-partitioning के जरिए segment elimination से data locality का उपयोग होता है
    • compressed data पर computation, projection, और predicate pushdown भी query-time I/O कम करते हैं
  • I/O में कमी से ज़रूरी computation कम होती है, और cost व latency दोनों घटते हैं

डेटा processing cost छोटे queries की ओर धकेलती है

  • scale-out से तेज़ processing संभव है, इसका मतलब यह नहीं कि processing सस्ती भी होगी
  • अगर 1,000 nodes का उपयोग करके result मिल रहा है, तो cost बहुत अधिक हो सकती है
  • BigQuery demos में चलने वाली 1PB query की retail pricing 5,000 डॉलर थी
  • ऐसी inefficiency, PB scale पर operate न करने वाली teams के लिए big data tax का हिस्सा बनती है
  • data processing कम करने की financial incentive केवल bytes-scanned billing model तक सीमित नहीं है
    • चाहे BigQuery का scan cost हो या Snowflake instance का idle cost, मुख्य cloud data warehouses bill बढ़ा सकते हैं
    • query को छोटा करने से छोटे instances इस्तेमाल किए जा सकते हैं, queries तेज़ होती हैं, और अधिक concurrency संभव होती है

अधिकांश डेटा लगभग कभी query नहीं होता

  • process होने वाले data का बड़ा हिस्सा 24 घंटे से कम पुराना latest data होता है
  • डेटा लगभग 1 हफ्ता पुराना होने पर, उसके query होने की संभावना सबसे हाल के 1 दिन के डेटा की तुलना में लगभग 20 गुना कम हो जाती है
  • 1 महीने बाद डेटा आम तौर पर बस पड़ा रहता है, और केवल कभी-कभार report चलने पर query होता है
  • stored data का age distribution, access pattern की तुलना में कहीं अधिक समतल होता है
    • बहुत सा data जल्दी discard भी हो जाता है, लेकिन बहुत सा data table के अंत में जुड़ता रहता है
    • अगर पिछले 1 साल का data पूरे data का केवल 30% हो, तब भी वह data access का 99% हो सकता है
    • अगर पिछले 1 महीने का data पूरे data का केवल 5% हो, तब भी वह data access का 80% हो सकता है
  • जैसे-जैसे data समय के साथ शांत पड़ता है, वास्तविक working set अपेक्षा से अधिक manageable आकार का हो जाता है
    • 10 साल का 1PB table हो, तब भी वास्तव में बार-बार access होने वाला हिस्सा केवल आज का data हो सकता है
    • आज का data compressed basis पर 50GB से कम हो सकता है

single machine की सीमा लगातार आगे खिसक रही है

  • अगर Big Data की परिभाषा “जो single machine में फिट न हो” है, तो ऐसे workloads की संख्या हर साल घट रही है
  • 2004 में जब Google MapReduce paper लिखा गया था, तब सामान्य data workloads का single general-purpose machine में न समाना आम बात थी
  • 2006 में जब AWS ने EC2 launch किया, तब उपलब्ध instance केवल single core और 2GB RAM वाला था, और कई workloads उसमें फिट नहीं होते थे
  • आज AWS का standard instance physical server basis पर 64 cores और 256GB RAM तक उपयोग करता है
    • 2006 के शुरुआती EC2 instance की तुलना में RAM कई दर्जन गुना बढ़ चुकी है
    • memory-optimized instance के लिए अधिक भुगतान करके RAM को और भी कई दर्जन गुना बढ़ाया जा सकता है
    • यह सवाल उठता है कि 24TB RAM या 445 CPU cores से भी अधिक की ज़रूरत वाले workloads आखिर कितने हैं
  • cloud में बड़े VM की cost compute power के अनुसार लगभग linear रूप से बढ़ती है
    • पूरे server का VM, server के 1/8 हिस्से के VM से केवल 8 गुना महंगा होता है
    • लेखक का मानना है कि मूल Dremel paper के 3,000 parallel nodes benchmark जैसी performance आज single node पर हासिल की जा सकती है

डेटा asset नहीं, liability भी बन सकता है

  • Big Data की एक और परिभाषा है: “वह स्थिति जहां क्या फेंकना है यह तय करने की लागत, सब कुछ संभालकर रखने की लागत से अधिक हो”
  • कई संगठनों की data lakes ज़रूरत से नहीं बल्कि delete न करने के कारण बनी विशाल दलदल जैसी हैं
    • किसी को नहीं पता उसमें क्या है
    • किसी को नहीं पता क्या सुरक्षित रूप से साफ़ किया जा सकता है
  • data retention की cost केवल physical bytes store करने की लागत से बड़ी होती है
    • GDPR, CCPA जैसे regulations में यह track करना पड़ता है कि specific data का उपयोग कैसे हुआ
    • कुछ data को निश्चित समय के भीतर delete करना आवश्यक होता है
    • data lake की parquet files में phone numbers बहुत लंबे समय तक पड़े रहने पर कानूनी requirements का उल्लंघन हो सकता है
  • पुराना डेटा litigation में भी संगठन के खिलाफ इस्तेमाल हो सकता है
    • जैसे कई संगठन potential liability कम करने के लिए email retention period सीमित रखते हैं, वैसे ही data warehouse का data भी प्रतिकूल evidence बन सकता है
    • अगर 5 साल पुराने logs code के security bug या SLA miss दिखाते हों, तो उन्हें लंबे समय तक रखने से legal exposure भी उतना लंबा हो सकता है
  • data का अर्थ code के bit rot की तरह धुंधला भी पड़ सकता है
    • लोग किसी special field का सटीक अर्थ भूल सकते हैं
    • पुराने data bugs याददाश्त से मिट सकते हैं
    • उदाहरण के लिए, कुछ समय तक सभी customer id null सेट हुए हों, या 2017 की तीसरी तिमाही में भारी fraud transactions ने performance को वास्तविकता से बेहतर दिखाया हो
    • पुराने समय के data को निकालने वाली business logic धीरे-धीरे जटिल हो सकती है, जैसे “2019 से पहले revenue, 2019~2021 में revenue_usd, और 2022 के बाद revenue_usd_audited”

क्या आप Big Data के 1% में आते हैं, यह जांचें

  • Big Data वास्तव में मौजूद है, लेकिन संभव है कि अधिकांश लोगों को इसकी चिंता करने की ज़रूरत न हो
  • यह तय करने के लिए कि आप Big Data One-Percenter हैं या नहीं, ये सवाल पूछे जा सकते हैं
    • क्या आप सच में बहुत विशाल मात्रा में data generate करते हैं
    • अगर हाँ, तो क्या आपको सच में एक बार में बहुत विशाल मात्रा में data उपयोग करना पड़ता है
    • अगर हाँ, तो क्या वह सच में इतना बड़ा है कि single machine में फिट न हो
    • अगर हाँ, तो क्या आप बस data जमा करने वाले व्यक्ति तो नहीं हैं
    • अगर हाँ, तो क्या summary बनाना बेहतर नहीं होगा
  • अगर इन सवालों में से किसी एक का भी जवाब “नहीं” है, तो आप अपने वास्तविक data आकार के अनुरूप नई पीढ़ी के data tools के candidate हो सकते हैं
  • संबंधित उदाहरण के रूप में आधुनिक BigQuery alternatives का उल्लेख है
  • संगठनों को उस data size से डरने के बजाय जो शायद कभी भविष्य में होगा, अपने पास अभी मौजूद data size और वास्तविक query patterns के अनुसार tools और retention policy चुननी चाहिए

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-05-28
Hacker News की राय

  • मेरी पिछली नौकरी में जब हम data scientist भर्ती करते थे, तो एक पसंदीदा ट्रिक सवाल होता था: “अगर requirement अधिकतम 6TiB data की हो, तो आप किस stack/architecture का निर्माण करेंगे?”
    अक्सर BigQuery, Hadoop जैसी भव्य चीज़ों की बातें सुनने को मिलती थीं, और जब hardware/software/license cost तक पूछते थे, तो सालाना कई दसियों हज़ार डॉलर के estimates निकल आते थे
    अंत में चुना वही व्यक्ति जाता था जो समझता था कि 6TiB वह मात्रा है जिसे कमरे में मौजूद 6 लोग अपने smartphones में बाँटकर रख सकते हैं, और 199 डॉलर का एक enterprise HDD, या redundancy के लिए तीन, काफ़ी हैं; और CSV को memory में कई बार लोड करके awk script से भी process किया जा सकता है
    मैं भी “हथौड़ा सीख लिया तो हर चीज़ कील लगती है” वाली गलती में फँस जाता हूँ, लेकिन hiring में “असल big data” के पैमाने की समझ न होना असफल होने का कारण था

    • यह भी संभव है कि hiring interview जैसी स्थिति ने जवाबों को प्रभावित किया हो। उम्मीदवार technical interview पास कर रहा होता है, इसलिए स्वाभाविक है कि वह सोचे कि interviewer उसकी tech stack की समझ देखना चाहता है
      केवल ऐसे जवाबों के आधार पर यह निष्कर्ष निकालना कि वह हर काम को over-engineer करेगा, उचित नहीं है; यह अधिक सही है कि उम्मीदवार interviewer के पक्ष में झुकी हुई एक कृत्रिम स्थिति में trap question में फँस गया
      हाल ही में मैंने भी अपने जैसे ही seniority और experience वाले interviewer के साथ technical interview दिया, उत्तर बिगाड़ दिया, और interviewer ने मेरे खराब जवाब पर काफ़ी judgmental रवैया दिखाया। अगर भूमिकाएँ उलट जातीं, तो मैं भी उसे ऐसे topic पर उतना ही असहज कर सकता था जिसे मैं उससे बेहतर जानता हूँ
      अगर आप interviewer हैं, तो अपनी ऊपरी स्थिति का दुरुपयोग न करने के लिए विशेष सावधानी रखनी चाहिए। यह कंपनी के लिए भी उलटा पड़ता है, और सामने वाले व्यक्ति के लिए भी अच्छा नहीं होता
    • https://x.com/garybernhardt/status/600783770925420546 Gary Bernhardt की 2015 की पोस्ट:
      “Consulting service: आप अपना big data problem लेकर आइए, मैं कहूँगा ‘आपका dataset RAM में फिट हो जाता है’, और आप 500,000 डॉलर बचाने के बदले मुझे 10,000 डॉलर देंगे”
    • कुछ लोग यह सुनकर काफ़ी नाराज़ हो जाते हैं कि उनका data वास्तव में big data नहीं है
      कुछ साल पहले एक director ने मुझे वह system दिखाया था जो IT ने Hadoop, API gateway, कई developers, और सालाना कई लाख डॉलर की लागत से बनाया था। जब मैंने कहा कि मौजूदा scale और निकट भविष्य की अपेक्षित scale के हिसाब से यह उसके laptop में लगे USB drive और कुछ Python scripts से भी आराम से चल सकता है, तो वह बहुत चिढ़ गया, और उसके बाद मैं उस project में फिर कभी शामिल नहीं हुआ
      मुझे लगता है यह कंपनी में फैले दिखावे के चक्र का हिस्सा है। “हम एक साधारण काम कर रहे हैं” यह मान लेने की गुंजाइश ही नहीं होती
    • मैं vertical scaling वाले समाधान को समझता हूँ, लेकिन सच कहूँ तो लगभग हर use case में यह गलत समाधान है। Data consumers awk नहीं चाहते, और चाहें भी तो partitioning या columnar storage के बिना 6TB को हर query पर एक single CPU से scan करना हमेशा धीमा रहेगा
      ऐसे use case के लिए आम तौर पर BigQuery ठीक रहा है। इसका console interface ad hoc analysis के लिए काफ़ी है, और Metabase, Tableau जैसे tools भी इसमें अच्छे से connect हो जाते हैं
      अगर सही तरीके से partitioning की जाए, तो cost भी बहुत ज़्यादा नहीं होती, और समस्या हो तो rollup tables जोड़ सकते हैं
    • .parquet files बेहद कम आंकी जाती हैं, और अब भी बहुत से लोग इस format को नहीं जानते
      CSV के विपरीत, यह data types को सुरक्षित रखती हैं, CSV से 10 गुना छोटी होती हैं, इसलिए 6TB घटकर 600GB हो जाता है, और read speed 50 गुना तेज़ होती है। यह Apache Foundation का एक open standard भी है
      CSV की तरह इन्हें आसानी से देखा नहीं जा सकता, लेकिन इतना tradeoff करना सार्थक है। जहाँ भी CSV download के लिए दिया जाता है, वहाँ .parquet भी साथ में उपलब्ध होना चाहिए

  • कुल मिलाकर मैं लेख के बड़े हिस्से से सहमत हूँ, लेकिन कुछ caveats हैं। पहला, MongoDB को baseline मानना ठीक नहीं है। मैंने ऐसा कुछ नहीं देखा जो MongoDB कर सके और PostgreSQL उससे बेहतर न कर सके; और big data solutions आम तौर पर NoSQL/MongoDB नहीं, बल्कि columnar databases, map-reduce, या Cassandra जैसी चीज़ें होती हैं
    दूसरा, सफलता के लिए योजना बनानी चाहिए। 95% कंपनियाँ unicorn नहीं बनतीं, लेकिन अगर आपका लक्ष्य बाकी 5% है, तो तैयारी के बिना वहाँ पहुँचना संभव नहीं। जब आपके पास 5 ग्राहक हों, तब भी scalability को ध्यान में रखकर design करने का कारण यह है कि exponential growth का क्षण आए तो उसे पकड़ा जा सके
    फिर भी, मूल सीख सही है। ज़्यादातर data बड़ा नहीं होता, और दुनिया के सभी लोगों का data भी 100 डॉलर के Chromebook में आ सकता है। अधिकांश data बहुत कम देखा जाता है और queries भी छोटी होती हैं, और big data work का पहला चरण अक्सर terabytes को घटाकर वास्तव में ज़रूरी GB, MB, कभी-कभी KB तक लाना होता है। regulations के कारण data cost भी बढ़ रही है

    • “सफलता के लिए योजना बनाओ” वही बात है जो हर जगह architecture astronauts कहते हैं। मेरे अनुभव में यह पूरी तरह सच नहीं है, बल्कि अक्सर productivity और startup के लिए अधिक महत्वपूर्ण agility को काफ़ी कम कर देता है
      लोग सिर्फ योजना नहीं बनाते, वे आम तौर पर implementation भी कर बैठते हैं। अगर आप अगले 3 महीनों की योजना बनाएँ, तो आप कहीं अधिक agile और productive हो सकते हैं। अगर आप ship ही नहीं कर पाए, तो unicorn नहीं बनेंगे
    • मैंने अचानक सफलता संभालते हुए panic में जाते मामलों से कहीं अधिक ऐसे मामले देखे हैं जहाँ सफलता की तैयारी ज़रूरत से ज़्यादा करके असफलता लगभग तय कर दी गई
      यह second-system syndrome और survivorship bias के मेल जैसा लगता है। अच्छे MVP की गड़बड़ियाँ साफ़ करने वाले लोग शिकायत करते हैं कि “यह पहले करना चाहिए था”, लेकिन जिन कंपनियों ने पहले से इतनी planning और design की थी, वे जीवित ही नहीं बचीं कि उनकी शिकायत सुनी जाए
    • एक छोटी-सी आपत्ति: 8 bits में तो प्रति व्यक्ति एक unique integer ID भी नहीं रखी जा सकती। उसके लिए प्रति व्यक्ति 8 bytes चाहिए, और तब आकार पहले ही 60GB के स्तर पर पहुँच जाता है
      बाकी लगभग हर बात से मैं सहमत हूँ, लेकिन यह हिस्सा गलत लगा, इसलिए इसे यूँ ही छोड़ नहीं सका
    • “Unicorn बनने की संभावना बनाने के लिए अभी और बाद, business के हर हिस्से की योजना बनानी चाहिए” — मुझे लगता है कि व्यवहार में यह उलटा असर करता है
      Startups का runway सीमित होता है, और अगर engineers ऐसे कामों पर पैसा खर्च कर रहे हैं जिनका लाभ कई साल बाद मिलेगा, तो वे उस समय के आने से पहले ही विफल होने की संभावना बढ़ा रहे हैं
    • इस बात पर भी संदेह है कि 5 ग्राहक होते ही scalability के लिए design करना चाहिए ताकि exponential growth आते ही उसे पकड़ा जा सके
      किसी product को इतनी मज़बूत traction मिलना आम तौर पर user base के अस्तित्व और उसकी ज़रूरत से पैदा हुए संयुक्त प्रभाव का परिणाम होता है। Growth के दौरान नए users जोड़ने में रुकावट आए भी, तो पहले से मौजूद users के पुराने product पर लौट जाने या कहीं और चले जाने की संभावना कम होती है
      पुराने Twitter में रोज़ fail whale देखना आम बात थी, फिर भी ज़्यादातर लोग नहीं गए, और बेहतर scale होने वाले किसी विकल्प की ओर बड़े पैमाने पर पलायन भी नहीं हुआ। वैसे भी ऐसी exponential growth वाले products दुर्लभ होते हैं, और उस दौरान scaling की वजह से availability गिरना आम बात है। जिज्ञासा है कि वास्तव में कौन-से exponential growth वाले products scaling न कर पाने के कारण असफल हुए

  • जब “Big Data” का दौर चल रहा था, तब मैं Large Hadron Collider में शोधकर्ता था। हमारे लिए सभी डेटा का विश्लेषण करना एक सार्थक use case था, और frequentist statistics में डेटा जितना ज़्यादा हो, उतना बेहतर माना जाता था
    लेकिन दुनिया भर के सुपरकंप्यूटर नेटवर्क का उपयोग करते हुए भी, मुझे समझ आया कि किसी विशाल job के खत्म होने का इंतज़ार करने से तेज़ local storage बेहतर है। आखिरकार हर graduate student ने analysis flexibility को बहुत कम खोते हुए संबंधित डेटा को ठीक 1~5TB तक घटा दिया
    लगता है यहाँ Amdahl के scaling law के बराबर कोई सुविधा का नियम जैसा कुछ है

    • अगर इसे गढ़ें तो कुछ ऐसा हो सकता है: “अगर आप 1~5TB डेटा से statistical analysis नहीं कर सकते, तो methodology गलत है”
      यह गणित से ज़्यादा मानवीय सीमाओं के करीब लगता है। हम जिस flexibility का उपयोग कर सकते हैं, उसकी एक स्पष्ट ऊपरी सीमा है। अगर नए तरह के analysis को और आसानी से चलाने का तरीका मिल जाए तो यह बदल सकता है, लेकिन यह शायद उन कामों की संख्या के सापेक्ष logarithmic ढंग से बढ़ेगा जो हम करना चाहते हैं
    • मुझे लगता है सुविधा का यह नियम सच में है। यह इस बात को भी समझाता है कि कई technologies एक स्थिर घातीय गति से क्यों सुधरती हैं
      लोग हर साल चीजों को थोड़ा बेहतर बनाने के सुविधाजनक तरीके खोजने में बहुत कुशल होते हैं, लेकिन किसी भी idea को लागू करने में न्यूनतम समय तो लगता ही है
    • 80~90 के दशक में NASA ने National Aerodynamic Simulator बनाया था, जो Cray जैसी बड़ी मशीनों पर finite element analysis simulation चलाने वाला system था। आज के मानक से देखें तो वह शायद सस्ते graphics card के स्तर का हो
      अगर मुझे सही याद है, तो उस machine की queue उतनी ही लंबी या उससे भी लंबी थी जितना समय सस्ते hardware पर वही काम चलाने में लगता, और Beowulf जैसे large-scale parallel processing systems ऐसे ही प्रयासों से निकले
    • मुझे लगता है सुविधा का नियम बिल्कुल सही है। commercial systems developers से बात करें तो ग्राहक हमेशा system को जितना हो सके उतना सस्ता बनाने का दबाव डालते हैं
      database में संग्रहीत डेटा और computation size को घटाना ग्राहक का monthly bill कम रखने का शानदार तरीका है

  • मेरे अनुभव में डेटा लगातार घातीय रूप से बढ़ता है, लेकिन सूचना की मात्रा उतनी नहीं बढ़ती
    finance में चाहें तो आप एक time series के लिए रोज़ 10 करोड़ data points आसानी से पा सकते हैं, और हज़ारों time series के साथ काम भी कर सकते हैं। लेकिन वह sampling rate और time series की संख्या आमतौर पर 99.99% redundant होती है। क्योंकि eigenvalues लगभग 10 dimensions के बाद, और कभी-कभी उससे भी बहुत पहले, लगभग 0 पर गिर जाते हैं
    ऐसे tick data को petabytes में store करने का लगभग कोई कारण नहीं होता जिसे आप कभी query ही नहीं करेंगे। कई मामलों में collection के समय ही आक्रामक और lossy dimensionality reduction करना, सिर्फ शुरुआती कुछ principal components और outliers को store करना, और eigenvalue stability पर नज़र रखना कि कहीं पहले महत्वहीन रहा कोई नया factor महत्वपूर्ण तो नहीं बन रहा, कहीं ज़्यादा तर्कसंगत है
    नतीजतन dataset बहुत छोटा, संभालने में आसान हो जाता है, और अक्सर इसलिए ज़्यादा insight देता है क्योंकि उसे वास्तव में इस्तेमाल किया जा सकता है

    • दिलचस्प है, लेकिन अगर समय के साथ eigenvectors बदलें तो आप उसे कैसे handle करते हैं, यह जानना चाहूँगा
    • अगर आप eigenvalues और dimensions की इस बात को समझाने वाली कोई सामग्री बता सकें तो अच्छा होगा
      यह दिलचस्प लग रहा है, लेकिन मेरे लिए यह पूरी तरह नया विषय है

  • “Big Data” की मज़ेदार बात यह थी कि software स्तर पर सबसे बुनियादी और स्पष्ट optimizations से भी बचने के लिए तिरछे incentives बने हुए थे। क्योंकि hardware requirements जितनी बड़ी हों, उतना आसानी से दिखाया जा सकता था कि कोई कितना बड़ा काम कर रहा है
    उदाहरण के लिए, अगर आप कहते, “बॉस, पूरे dataset पर compute करने के बजाय sample पढ़ लें तो इस report के averages सिर्फ laptop से निकाले जा सकते हैं,” तो बॉस इसे ऐसे लेता: “sample से क्या मतलब है? तुम इस mathematician/engineer जैसी बकवास से क्या इशारा कर रहे हो? यह तो नहीं कह रहे कि मैंने लाखों डॉलर बेकार खर्च किए?”

    • उस trend में Google के लोगों द्वारा stock options cash out करने की लहर भी शामिल थी
      sales hype और big data के इर्द-गिर्द का शोर, और किसका डेटा पर्याप्त बड़ा है इस पर दिखावे वाली प्रतिस्पर्धा, कुछ समय तक बहुत ज़्यादा थी
    • यह काफ़ी व्यंग्यपूर्ण outsider viewpoint है और वास्तव में सही नहीं है। अपने career की शुरुआत में मैंने data engineer के रूप में computing cost reduction की कोशिश की थी
      लंबे समय तक एक ही machine पर 64GB से अधिक memory पाना बहुत कठिन था, और जब hardware ceiling आ जाए तो implementation complexity तेज़ी से बढ़ती है
      जब डेटा थोड़ा ही बढ़े और process 50 में 1 बार fail होने लगे, तो वह बहुत विनाशकारी होता है। teams ऐसी नियमित cron jobs दर्जनों में चलाती हैं, और अगर हर एक अक्सर टूटे तो on-call काम बस टुकड़े काटकर बचाने तक सीमित रह जाता है
      Hadoop और MapReduce बेहद efficient नहीं थे, लेकिन सही तरीके से इस्तेमाल करने पर ठीक थे, और उनका reliably चलना कहीं अधिक महत्वपूर्ण था। यानी उस bit-optimized C++ code से बेहतर, जिस पर कोई भरोसा न करे, जिसे कोई maintain न कर सके, और जो हर गुरुवार किसी अजीब segmentation fault से मर जाए
      आज होता तो बस Snowflake इस्तेमाल करते, लेकिन उस समय यह एक तर्कसंगत tool था

  • यह लेख पूरी तरह सटीक नहीं है। मूल रूप से big data को तीन आयामों से परिभाषित किया गया था: volume, गति, और variety
    volume का मामला ज़्यादातर सुलझ चुका है, और गति का भी, लेकिन वह महँगी है। variety अभी तक हल नहीं हुई है
    आज के समय में big data का मतलब “storage या computing की कमी” से ज़्यादा, “इसे एकीकृत करने और समझने की संज्ञानात्मक क्षमता की कमी” के करीब है

    • मैंने ये 3V पहली बार Michael Stonebraker के एक lecture में सुना था। वह DBMS क्षेत्र के दिग्गज हैं और Turing Award विजेता भी
      उनके संबंधित lectures भी ज़ोरदार सिफारिश के लायक हैं। ज़्यादातर YouTube पर हैं
      [1] https://www.youtube.com/watch?v=KRcecxdGxvQ
      [2] https://amturing.acm.org/award_winners/stonebraker_1172121.c...
    • यहाँ “variety” का क्या मतलब है, यह जानने की जिज्ञासा है
    • मेरे लिए तो अभी भी storage और computing कम पड़ते हैं। साल में छह बार, दो-दो हफ्ते के लिए फील्ड में जाकर data collection करते हैं, और वहाँ दो aircraft से चार bands और dual polarization वाले synthetic aperture radar का data इकट्ठा किया जाता है
      हर aircraft में एक radar system है, और उसके अंदर 20TiB के 16-drive RAID-0 SSD storage units के 8 सेट हैं। आम तौर पर RAID पूरा नहीं भरता, इसलिए लगभग 176TiB प्रतिदिन, 2 हफ्तों में 7 flights पर प्रति batch 1.2PiB, और सालाना लगभग 7.2PiB बनता है
      flights के बीच एक दिन का break इसलिए लेना पड़ता है क्योंकि apron के पास hangar के कोने में ठूँसे गए storage server पर optical fiber के ज़रिए data उतारना होता है। उसके बाद सुरक्षा के लिए दूसरे server पर replicate करते हैं, और mission खत्म होने पर सब कुछ मुख्यालय भेजकर store और process किया जाता है
      यह data क़ीमती है, लेकिन “कई अरब डॉलर” स्तर का नहीं। इसका उपयोग resource extraction, mapping, environmental और geodetic research आदि में होता है, और 2008 के बाद से हर byte संभालकर रखा गया है। वजह यह है कि जब नए algorithms आते हैं, तो पुराने data को नए standards के अनुसार फिर से process किया जा सकता है
      files को 800GiB~2TiB के chunks में GPU processing server पर stream किया जाता है, और यह compress नहीं होता। हम जो ज़्यादातर capture करते हैं, यानी cosmic microwave background, वह काफ़ी random है। एक समय लगा था कि tape पर लिखने से infra आधा हो जाएगा, लेकिन tape capacity का हिसाब शायद ऐसे किया जाता है जैसे 0 से भरी gigabytes की text files store करनी हों
      GPU धीमे हैं, CPU धीमे हैं, PCIe bus धीमी है, RAM धीमी है, और मेरी typing speed भी धीमी है। हर चीज़ को हमेशा और तेज़ होना चाहिए
      सब कुछ बहुत धीमा है, बहुत कठिन है, और बहुत छोटा है। hard disks बहुत छोटी हैं, और Linux kernel tuning तथा processing cluster तक जाने वाले तेज़ और भरोसेमंद network को सेट करना बहुत मुश्किल है। kernel/package updates, जो सिर्फ़ साधारण internal behavior changes होते हैं, भी हमारे systems को ऐसे तोड़ देते हैं जैसे यह समस्या सिर्फ़ हमीं झेलते हों
      default settings इस भ्रम में बनी होती हैं कि RAM दुर्लभ है, इसलिए network tasks में memory बचाने की कोशिश करती हैं। लेकिन file server में 0.5TB RAM है, इसलिए मैं चाहता हूँ कि network और filesystem को तेज़ बनाने के लिए वह सब इस्तेमाल हो। नतीजतन मुझे network stack documentation 6 घंटे पढ़नी पड़ती है ताकि I/O को 2024 स्तर की सामान्य समझ तक लाया जा सके
      शायद मैं पृथ्वी पर लगभग हर इंसान से ज़्यादा sysctl.conf जानता हूँ
      अपने-आप को big data के लिए distributed persistent object stores कहने वाले solutions हमारे workload पर पूरी तरह टूट जाते हैं या सैकड़ों मिलियन डॉलर माँगते हैं। जैसे ही आप कहते हैं कि object size लगभग 1TB है, distributed filesystem sales वाले जवाब देना बंद कर देते हैं। एक vendor ने तो requirements पढ़कर मुझे intelligence-agency customers वाले व्यक्ति से जोड़ दिया था। मैं NSA नहीं हूँ, और न ही मेरे पास NSA वाला बजट है
      कभी-कभी Bloomberg पर cloud के बारे में लेख पढ़ने वाला कोई MBA या PMP on-premises datacenter की लागत देखकर AWS या Azure migration का सवाल उठाता है, लेकिन जब आप उसे पैसे और समय दोनों के आँकड़े दिखाते हैं, तो उसके चेहरे पर उल्टी जैसा भाव आ जाता है और वह विषय बदल देता है
      ऊपर से vendors सब के सब AI/cloud trend पर चढ़े हुए हैं और हमारे काम के product lines बंद कर रहे हैं। अब हमें GPU के लिए ऐसे hedge funds और AI startups से प्रतिस्पर्धा करनी पड़ रही है जो customer data खोदकर ads दिखाना चाहते हैं
      storage और computing कम हैं, और जो storage और computing हमारे पास हैं वे भी बहुत धीमे हैं। DPU/IPU दिलचस्प हैं, लेकिन जैसे ही objects SQL database queries या compressed streaming video chunks से बड़े हो जाते हैं, वे तुरंत अपनी सीमा पर पहुँच जाते हैं

  • मैं पहले ऐसी कंपनी में काम करता था जो रोज़ 20GB analytics data बनाती थी, और शायद वही सबसे बड़ा data था जिससे मैं कभी निपटूँगा
    junior project के रूप में मैंने batch और real-time aggregation करने वाली data processing jobs लिखीं, और results को Azure के Parquet blob में store किया
    मेरा boss इतना समझदार था कि वह नियमित stakeholder meetings बुलवाता था ताकि तय किया जा सके कि क्या रखना है और क्या फेंकना है, और अच्छे algorithms की वजह से data को रोज़ लगभग 200MB तक compress किया जा सकता था
    पिछले 2 महीनों का data SQL Server में रखा जाता था, पिछले 2 साल का data और aggregate करके दूसरे server में, और पूरी कंपनी उसे Excel से उचित समय में query कर लेती थी। मूल big data tape storage में पड़ा सड़ रहा है, अगर कभी भविष्य में उसकी ज़रूरत पड़े
    मेरा boss बुरा manager था, लेकिन data को अच्छी तरह समझता था; पीछे मुड़कर देखूँ तो उसने बहुत कुछ सही किया था, और मैंने भी बहुत कुछ सीखा

  • मैंने कई सालों तक “बड़े” data tools और pipelines की over-engineering देखी है। बहुत से use cases में data warehouse और data lake बस GB या single-digit TB रेंज में होते हैं, इसलिए उन्हें किसी अच्छे EC2 instance पर DuckDB चलाने जैसी कहीं ज़्यादा सरल व्यवस्था में बदला जा सकता है
    मेरे अनुभव में ऐसा करने पर दूसरे systems के query execution शुरू करने से पहले ही result आ जाता है। यह बात मैं Athena को देखकर कह रहा हूँ
    आजकल मुझे लगता है कि browser में भी बहुत सी queries चलाई जा सकती हैं, इसलिए DuckDB WASM(https://github.com/duckdb/duckdb-wasm) और perspective.js(https://github.com/finos/perspective) की मदद से मैंने https://sql-workbench.com/ बनाया है

  • लगता है कि वह hype cycle आख़िरकार “मृत्यु के पठार” तक पहुँच गया है। इस industry में, जो trends से बेहद आसानी से बहक जाती है, यह कोई असामान्य अंत नहीं है

    • उसका नाम बस बदलकर AI कर दिया गया है
      AI भी सारे data का इस्तेमाल करता है, और उसका अर्थ निकालने के लिए उस पर जादुई neural networks चिपका देता है

  • व्यक्तिगत रूप से मुझे लगता है कि big data की मुख्य प्रेरक शक्ति कंपनी के संस्थापकों का अहं था। मानो यह तय हो कि हमारी कंपनी विस्फोटक रूप से बढ़ेगी और वैश्विक स्तर की सफलता पाएगी, इसलिए उसी पैमाने के हिसाब से डिज़ाइन करना चाहिए
    यह दुखद है कि लोग ऐसी गलती कर बैठते हैं, जबकि product के Series C तक पहुँचने से पहले एक SQLite DB ही काफ़ी होती है। सारी ऊर्जा अभी scale पर नहीं, product पर केंद्रित होनी चाहिए

    • नहीं। big data को वास्तव में उन लोगों ने आगे बढ़ाया जिनके पास वास्तविक बड़े डेटा की समस्याएँ थीं
      Hadoop की शुरुआत Google में मौजूद चीज़ों से प्रेरित होकर हुई थी, और यह दुनिया भर की उन कंपनियों में लोकप्रिय हुआ जो Oracle से सस्ते और बेहतर तरीके से डेटा संभालना चाहती थीं
      Spark, Hive/Pig जैसी चीज़ों की जटिलता के समाधान के रूप में आया, और जब कंपनियाँ भरोसेमंद data pipeline बना सकीं, तब वे उसके ऊपर AI भी रख सकीं
    • यह इस पर निर्भर करता है कि आप किस तरह का डेटा संभाल रहे हैं। geospatial, sensing, telemetry जैसे महत्वपूर्ण data model “Hello, world” चरण में भी petabyte स्तर तक पहुँच सकते हैं
      link click, message send, purchase जैसे मानवीय इरादे वाले व्यवहार से बनने वाले data model सामान्यतः छोटे होते हैं। क्योंकि इंसानों की संख्या और प्रति सेकंड वे जितनी इरादतन घटनाएँ पैदा कर सकते हैं, उसकी सीमा होती है
      इसके विपरीत, मशीन-जनित data model की गति और मात्रा कई orders of magnitude अधिक हो सकती है, और data model के आकार की कोई सीमा नहीं होती। ऐसा डेटा अक्सर सबसे दिलचस्प और कम इस्तेमाल किया गया डेटा होता है, क्योंकि यह दुनिया के बारे में बहुत-सी ऐसी बातें बताता है जो इंसानी इरादतन डेटा मॉडल से नहीं मिल सकतीं
    • कुल मिलाकर सही है, लेकिन IoT या GIS जैसे अपवाद भी हैं, जहाँ 10TB से बड़े dataset बहुत आम हैं