Pandas के निर्माता की नज़र में AI, Apache Arrow और सॉफ्टवेयर इंजीनियरिंग का भविष्य [YouTube]

 (youtube.com)
3 पॉइंट द्वारा GN⁺ 5 시간 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • Pandas और Apache Arrow बनाने के अनुभव के आधार पर, वे मानते हैं कि AI युग में भी हाई-परफॉर्मेंस डेटा सिस्टम और सॉफ्टवेयर डिजाइन करने के लिए विशेषज्ञता, निर्णय क्षमता और रुचि/टेस्ट ही मुख्य हैं
  • Apache Arrow टेबल-फॉर्म डेटा के लिए एक सार्वभौमिक इन-मेमोरी आधारित लेयर है, जो सिस्टमों के बीच ट्रांसफर और प्रोसेसिंग को स्टैंडर्डाइज करता है; जैसे-जैसे इसे अपनाने वाले सिस्टम बढ़ते हैं, इंटरऑपरेबिलिटी का मूल्य भी बढ़ता है
  • DuckDB और DataFusion जैसे परिष्कृत सिस्टमों को LLM की औसत कोड जनरेशन से बदलना कठिन है; ओपन सोर्स की प्रतिस्पर्धात्मक ताकत में सिर्फ कोड नहीं, बल्कि लंबे समय में जमा हुआ भरोसा और गुणवत्ता का रिकॉर्ड भी शामिल है
  • AI टूल पहल करने वाले डेवलपर की उत्पादकता बहुत बढ़ाते हैं, लेकिन अगर यह स्पष्ट न हो कि क्या बनाना है, तो औसत दर्जे के समाधान और कोड जमा होकर ऐसा agentic tarpit बना सकते हैं जिससे एजेंट भी बाहर निकलना मुश्किल पाए
  • आगे भाषा की syntax और हाथ से coding से ज्यादा architecture, problem definition, communication और परिणामों को परखने की क्षमता महत्वपूर्ण होगी; संगठनों को बढ़े हुए निर्णय-भार और token cost तक मैनेज करने होंगे

Pandas से AI developer tools तक का करियर

  • Wes McKinney ने लगभग 18 साल पहले Python Pandas बनाया और 2010 में इसे open source project के रूप में जारी किया
  • उनकी किताब Python for Data Analysis Python data science ecosystem में व्यापक रूप से इस्तेमाल हुई, और इसके बाद वे ऐसी कंपनियां और business models बनाने में शामिल रहे जो open source development को जारी रख सकें
  • Cloudera में उन्होंने कई open source developers के साथ Apache Arrow शुरू किया, और Arrow ecosystem तथा Parquet development में भी शामिल रहे
  • Ursa Computing बाद में Voltron Data बना, और Voltron Data के बंद/पुनर्गठन के बाद भी Posit के साथ उनका संबंध जारी रहा
  • फिलहाल वे data science libraries के बजाय AI developer tools और infrastructure पर केंद्रित एक नई कंपनी स्थापित कर चुके हैं, और AI के जरिए software engineering productivity बढ़ाने के तरीके खोज रहे हैं

Apache Arrow के फैलने तक की यात्रा

  • Arrow टेबल-फॉर्म डेटा के लिए एक सार्वभौमिक इन-मेमोरी डेटा आधारित लेयर है, जो memory में processing और systems के बीच data transfer को तेज करता है और interoperability बढ़ाता है
  • शुरुआती दौर में users और consuming systems कम थे, इसलिए adoption का प्रोत्साहन कम था; साथ ही यह संदेह भी था कि कई open source communities एक ही format पर सहमत हो पाएंगी या नहीं
    • नया unified standard बनाने पर मौजूदा 13 standards बढ़कर 14 हो जाने वाली XKCD-टाइप समस्या पैदा होना आसान है
    • Arrow ऐसे समय में भरोसेमंद implementation देकर और adoption का इंतजार करके बढ़ा, जब उसी समस्या को हल करने वाले विश्वसनीय विकल्प लगभग नहीं थे
  • technology खुद पिछले 5–6 सालों में बहुत ज्यादा नहीं बदली, लेकिन अधिक systems द्वारा adoption के साथ network effects जैसी value growth दिखी
  • DataFusion query engine को शुरू से बनाए बिना product के हिसाब से expand करने देता है, इसलिए अनुमान है कि करीब 30–40 कंपनियां इसे internal component के रूप में इस्तेमाल करती हैं
    • streaming data engine बना रही Arroyo को Cloudflare ने acquire किया, और बाद में Arrow तथा DataFusion Cloudflare के streaming data infrastructure के कुछ हिस्सों में इस्तेमाल हुए
    • DataFusion Comet का उपयोग Spark acceleration में होता है

सिस्टम सॉफ्टवेयर जिसे AI आसानी से replace नहीं कर सकता

  • DataFusion और DuckDB ऐसे projects हैं जिनके replacement को vibe coding से जल्दी बनाना कठिन है
  • LLM मौजूदा code और approaches का औसत निकालने जैसी प्रवृत्ति रखते हैं, इसलिए cutting-edge query engine जैसे expert द्वारा बारीकी से बनाए गए systems को निकट भविष्य में बनाना कठिन है
  • ऐसे projects injection-molded plastic toy से ज्यादा किसी कारीगर द्वारा assemble की गई सटीक Swiss watch जैसे हैं
    • इसका मतलब यह नहीं कि AI इन्हें कभी नहीं बना पाएगा, लेकिन फिलहाल replacement की संभावना कम है
  • open source project का मूल्य सिर्फ implementation से नहीं, बल्कि community द्वारा लंबे समय में बनाए गए trust से भी आता है
    • यह भरोसा कि maintainers community के हितों को ध्यान में रखते हैं
    • supply-chain attacks से बचाव और गंभीर bugs ठीक करने की उम्मीद
    • लगातार अच्छी तरह designed और भरोसेमंद software देने का record
  • McKinney 2013 के बाद Pandas development में गहराई से शामिल नहीं रहे, और फिलहाल developers का एक बड़ा समूह project maintain करता है
    • इसलिए उनका मानना है कि असली maintainers को धन्यवाद और funding मिलनी चाहिए
  • AI से एक दिन में 10,000 lines of code generate की जा सकती हैं, फिर भी अतीत में बने quality standards से कमतर output public नहीं किया जा सकता; इसलिए generation quantity से ज्यादा review और quality maintenance बड़ी चुनौती बन जाते हैं

गेम और गणित से programming तक

  • 1990s के अंत में वे Nintendo 64 के GoldenEye 007 में डूबे रहे, और 1997 के अंत या 1998 की शुरुआत में GeoCities पर fan site बनाकर speedrunning community में शामिल हुए
  • उस समय वे website हाथ से manage करते थे, लेकिन competitive programming में दक्ष Kisman को C++ program से site updates automate करते देख उन्होंने उत्कृष्ट programmers द्वारा बनाई automation की ताकत देखी
  • high school में उनकी रुचि math competitions और computer use में थी, और MIT में उन्होंने बचपन से programming करने वाले साथियों के बीच अपनी skills में बड़ा अंतर महसूस किया
  • pure mathematics degree लेते हुए उन्होंने complexity और algorithms जैसी theoretical computer science का कुछ हिस्सा पढ़ा, लेकिन Java के नकारात्मक अनुभव के कारण programming में खुद बहुत रुचि नहीं बनी
  • programming को problem solving और personal productivity बढ़ाने वाले tool के रूप में पहचानने के बाद ही वे इसमें गंभीरता से डूबने लगे

वित्तीय research से शुरू हुआ Pandas

  • 2007 में 22 साल की उम्र में वे quant hedge fund में शामिल हुए; expected formula-centric research के उलट उन्होंने पाया कि बहुत सा analysis Excel spreadsheets और manual work पर निर्भर था
  • MATLAB और R भी इस्तेमाल होते थे, लेकिन वे ज्यादातर सहायक tools जैसे थे; MATLAB code को server पर deploy करने के लिए हर server के लिए महंगा license चाहिए होता था
  • research से production तक चलने वाले काम के लिए उन्हें लगा कि system building के अनुकूल open source language की जरूरत है
  • एक colleague की सलाह पर 2008 की शुरुआत में उन्होंने Python और scientific computing libraries का इस्तेमाल शुरू किया, और मौजूदा research tools को Python में फिर से बनाते हुए Pandas का शुरुआती रूप सामने आया
  • productivity बढ़ाने वाले tools बनाने और दूसरों को उन tools से अधिक efficient काम करते देखने की प्रक्रिया में उन्हें game speedrunning जैसी ही तल्लीनता महसूस हुई

सरल user experience और internal technical debt

  • McKinney व्यक्तिगत रूप से ही फिट बैठने वाले जटिल AI tools से ज्यादा ऐसे सरल और consistent tools को महत्व देते हैं जिन्हें दूसरे लोग भी समझ और इस्तेमाल कर सकें
  • अत्यधिक personalized tool collection का structure इतना जटिल हो सकता है कि उसे बनाने वाले के अलावा कोई navigate न कर पाए, जैसे Winchester Mystery House
  • Pandas की शुरुआती implementation ने internal architecture से अधिक ऐसी API और usability पर ध्यान दिया जिसे लोग आसानी से समझ और लिख सकें
  • internal structure की अव्यवस्था ने लंबे समय तक maintenance burden छोड़ा, लेकिन Pandas की सफलता दिखाती है कि software perfect architecture के बिना भी बहुत सफल हो सकता है

NumPy की भूमिका और सीमाएं

  • NumPy, Jim Hugunin द्वारा 1990s के मध्य में शुरू की गई multidimensional array library Numeric और memory mapping जैसी large array capabilities जोड़ने वाली Numarray line को Travis Oliphant द्वारा 2005–2006 के आसपास merge करने से बना
  • उस समय Matplotlib, SciPy, statistics और linear regression tools NumPy arrays के आसपास काम करते थे, इसलिए नए data tool को ecosystem में शामिल होना हो तो NumPy compatibility जरूरी थी
  • NumPy large multidimensional arrays of numbers और integers पर केंद्रित था, और databases या non-numeric data के foundation के रूप में design नहीं किया गया था
  • शुरुआती Pandas ने NumPy को आधार बनाया और non-numeric data की limitations को workaround किया
    • number या boolean नहीं होने वाली values NumPy array के भीतर Python objects के रूप में store होती थीं
    • string data में object overhead और indirect references के कारण efficiency कम थी
  • ये सीमाएं बाद में Pandas जैसे systems के लिए वैकल्पिक in-memory foundation यानी Arrow बनाने की प्रेरणा बनीं

Python data science ecosystem की growth

  • venture-funded कई कंपनियों ने यह प्रचार किया कि हर enterprise को Google जैसा data infrastructure बनाना चाहिए, जिससे big data open source projects में भारी investment आया
  • हर कंपनी को समान scale के infrastructure की जरूरत नहीं थी, लेकिन इस funding के बिना Arrow के लिए जरूरी developers जुटाना शायद बहुत मुश्किल होता
  • उस समय industry data science और data scientist के अर्थ, और business, statistics तथा software skills साथ रखने वाले लोग कहां मिलेंगे, इस पर प्रतिस्पर्धा कर रही थी
  • Python ने उन लोगों को भी data science तक पहुंच दी जिनके पास programming experience बहुत नहीं था लेकिन statistics जानते थे
    • Python for Data Analysis और scikit-learn जैसे tools सीखकर 2–3 हफ्तों में काम के लिए उपयोगी analysis शुरू किया जा सकता था
    • उनका मानना है कि अगर पहले Scala जैसी language सीखनी पड़ती, तो entry barrier ऊंचा और learning period लंबा होता

Pandas release और Arrow organization का formation

  • Pandas को 2009 के New Year’s Eve पर release करने का फैसला हुआ, और फरवरी 2010 में पहले PyCon talk के साथ Python community से इसका वास्तविक जुड़ाव शुरू हुआ
  • McKinney ने 2010 में Duke में statistics PhD program शुरू किया, लेकिन Python data tools में financial companies की रुचि और Pandas की growth potential देखकर leave ले लिया
  • उस समय Pandas 0.1 में सभी join types तक supported नहीं थे और features सीमित थे; project growth पर focus करने के लिए उन्होंने graduate school छोड़ दिया
  • financial technology business पर विचार करने के बाद वे Python for Data Analysis लिखने और BI startup शुरू करने की ओर बढ़े, और 2013 में BI market में Looker से competition कठिन मानकर Cloudera में शामिल हुए
  • Cloudera में उनका संपर्क Impala developers से हुआ, और बाद में Iceberg, Databricks आदि में सक्रिय कई engineers से मुलाकात हुई; यह अनुभव आगे के करियर की नींव बना
  • Arrow project 2016 की शुरुआत में Cloudera में शुरू हुआ, लेकिन उस समय enterprise software market में experimental technology के लिए dedicated team budget पाना कठिन था
  • 2016–2018 के दौरान financial companies में Arrow को वास्तविक systems में लागू करके data processing workloads तेज किए गए और Parquet को improve किया गया
  • 2018 में कई companies Arrow development को fund करना चाहती थीं, लेकिन financial company regulations के कारण external funds manage करना कठिन था, इसलिए corporate sponsorship ले सकने वाला independent organization अप्रैल में स्थापित किया गया
    • Nvidia सहित hardware companies और financial companies जैसे लगभग 6 sponsors शामिल हुए
    • करीब 8 लोगों की development team बनाई गई
  • commercial opportunity की पुष्टि के बाद 2020 में COVID-19 के दौरान यह Ursa Computing में बदला

अभी भी बाकी data engineering समस्याएं

  • आज भी data field बार-बार data को A से B तक ले जाने, format बदलने, memory में load करने, और queries तथा transformations को efficiently execute करने की समस्याएं हल कर रहा है
  • Pandas उम्मीद से कहीं ज्यादा enterprise data flows को संभालने वाला foundation बन गया; अब संभव है कि इंसानों ने अतीत में जितना Pandas code लिखा था, उससे अधिक Pandas code LLM generate कर रहे हों
  • DuckDB इतना शक्तिशाली tool है कि 20 साल पहले का developer इसकी कल्पना भी मुश्किल से कर पाता
    • इसे मुफ्त में install कर कई environments में run किया जा सकता है
    • यह phone और web browser में भी काम कर सकता है
    • single machine पर complex setup के बिना high-performance analytics देता है
  • लंबे discomfort और trial-and-error से DuckDB और Arrow जैसी technologies की जरूरत स्पष्ट हुई; Parquet सहित कई solutions उन technologies से प्रभावित हैं जिन्हें Google जैसी large internet companies ने cost और time घटाने के लिए बनाया
  • Parquet सर्वोत्तम format नहीं है, लेकिन पहले से बहुत सुधरा है और लगभग सभी systems इसे support करते हैं
    • Vortex और Lance जैसे specialized alternatives होने पर भी काफी अच्छी compatibility के कारण यह इस्तेमाल होता रहता है
  • AI ने industry attention कब्जा लिया है, इसलिए data engineering की चर्चा कम हो गई है; Databricks नया data engine announce करे तो भी पहले जितना ध्यान नहीं मिलता
  • उल्टा, data tool developers के लिए trend chase न करके technical completeness पर focus करने की गुंजाइश बनी है, और testing लिखने जैसे repetitive और असुविधाजनक कामों में AI का उपयोग किया जा सकता है

database technology की ओर convergence

  • big data era का मुख्य सबक यह है कि database researchers के papers और conference results का लाभ पहले ही उठाना चाहिए था
  • TU Munich, CWI, MIT, CMU, Berkeley जैसी institutions की database research पढ़ना, implement करना और collaborate करना महत्वपूर्ण approach है
  • NoSQL और non-relational storage-केंद्रित era में scalable systems अक्सर बड़ा overhead जोड़ देते थे, जिससे वे अच्छी तरह बने single-machine, single-thread implementation से भी धीमे हो जाते थे
  • Frank McSherry और Michael Isard आदि द्वारा किया गया Scalability! But at what COST? research scalability पाने की cost के मुद्दे को address करता है
  • आधुनिक data stack फिर से database technology और columnar processing के इर्द-गिर्द converge कर रहा है
    • Polars, Daft और DataFusion Arrow का इस्तेमाल करते हैं
    • dbt का नया engine ADBC का उपयोग करता है
    • Databricks Photon, Arrow इस्तेमाल करता है या नहीं, इससे अलग columnar structure अपनाता है
  • major systems समान architecture और approaches की ओर converge कर रहे हैं, इसलिए अब core processing method से ज्यादा यह महत्वपूर्ण challenge है कि software को वास्तव में कितना आसानी से इस्तेमाल किया जा सकता है

Hadoop से DuckDB तक usability में सुधार

  • Hadoop era में Java और XML config files, और अनगिनत tuning options के कारण actual work शुरू करने से पहले लगभग दो दिन setup में लग जाते थे
  • Spark एक बड़ा सुधार था क्योंकि word count एक line में लिखा जा सकता था, लेकिन फिर भी infrastructure और config files तैयार करनी पड़ती थीं
  • DuckDB का installation और execution model दिखाता है कि data systems कितने सरल हो सकते हैं—यह एक usability model है
  • distributed systems को भी sensible defaults और immediately working configuration देकर operational complexity घटानी चाहिए
  • DuckDB client-server area में भी expand कर रहा है और MotherDuck के साथ closely collaborate करता है

generative AI के लिए multimodal data layer

  • existing lakehouse table formats और Parquet पर केंद्रित हैं, लेकिन generative AI और large model training/fine-tuning के लिए images, video, text, documents और logs साथ में चाहिए होते हैं
  • LanceDB जिस multimodal data lakehouse को handle करता है, वह वास्तविक enterprise problem है
  • large unstructured data से embeddings generate करने पर power और GPU time खर्च होता है, इसलिए resulting embeddings में भी compute cost के कारण economic value बनती है
  • production environments में original data और generated results को reliably store, manage और process करने के लिए data store चाहिए
  • अगर हर enterprise अपना multimodal store बनाए, तो bugs, data loss और performance problems बार-बार झेलने पड़ सकते हैं; इसलिए specialized software providers द्वारा common solutions देना अधिक efficient है
  • Iceberg tables को direct operate किया जा सकता है, फिर भी Databricks, Snowflake, AWS जैसे providers को management सौंपने पर operational complexity घटती है; यही logic generative AI के multimodal data पर भी लागू होता है
  • generative AI data market में document vector search और high-QPS processing से लेकर data lifecycle management तक अलग-अलग layers solve करने की गुंजाइश बाकी है

AI युग में developer की competitiveness

  • McKinney ने कभी सोचा था कि software engineer के रूप में उनका भविष्य है या नहीं, लेकिन वे मानते हैं कि AI लोगों को उनके initiative level के आधार पर और स्पष्ट रूप से अलग करता है
  • initiative रखने वाला व्यक्ति क्या बनाना है, इस पर सोचता है, और अच्छे results पहचानने की taste और judgment के आधार पर AI से भारी productivity amplification पा सकता है
  • LLM ज्यादातर problems के लिए औसत और सुरक्षित B+ level approach देता है, लेकिन user की जगह experience, taste और judgment नहीं बना देता
  • अच्छे judgment के बिना generated code जोड़ते रहने से complex tarpit बनता है, और agent भी context और structure के बोझ से आगे काम करना मुश्किल पाता है
  • अतीत में खुद implement करते हुए technology और judgment साथ विकसित होते थे, लेकिन आगे hand-coding time घटने पर systems understanding और design ability को अलग से विकसित करना होगा

AI युग में क्या पढ़ना चाहिए

  • नए developers को सिर्फ Python या Java syntax सीखने के बजाय software design और architecture, और data system structures पढ़ने की जरूरत है
  • data engineering में Lambda architecture और Kappa architecture जैसे अलग-अलग systems कैसे काम करते हैं और किन problems के लिए उपयुक्त हैं, यह समझना चाहिए
  • agent को desired result सटीक रूप से बताना और गलत दिशा में बढ़ने पर उसे पहचानना आना चाहिए
  • अगर user A और B में से कौन बेहतर है यह judge नहीं कर सकता, तो agent भी सही choice की guarantee user की जगह नहीं दे सकता
  • software engineers, data engineers और data scientists सभी को code writing से ज्यादा problem definition और communication पर समय देना पड़ सकता है
  • अगर आप जो चाहते हैं उसे explain नहीं कर सकते, तो AI से भी desired result नहीं मिलेगा; केवल organization में AI जोड़ देने से productivity और economic outcomes अपने-आप नहीं बढ़ते
  • experience और judgment की कमी वाले व्यक्ति को AI देने पर वह useful output की जगह ऐसा slop cannon बन सकता है जो दूसरों के संभालने लायक debt भारी मात्रा में पैदा करे

बढ़े हुए decisions और organizations का AI investment

  • अगले 2–5 वर्षों में developer hiring, technical interviews और role distinctions भ्रमित और तेजी से बदल सकते हैं
  • अतीत में meetings, sprint planning और planning poker के जरिए teams काम पर common confidence बनाकर implementation बांटती थीं
  • अब existing agile planning process Claude के planning mode के भीतर compress हो जाती है, और एक developer को अकेले बहुत सारे choices लेने पड़ते हैं
  • जिस developer को दिन में पहले से 10 गुना ज्यादा decisions लेने हों, वह decision fatigue और ambiguity के कारण रुक सकता है
  • जो लोग जल्दी judge करके efficient path तय कर सकते हैं, वे AI की productivity का लाभ उठा सकते हैं; लेकिन जो यह तय नहीं कर पा रहे कि करना क्या है, AI उनकी यह समस्या हल नहीं करता
  • enterprises Anthropic और OpenAI को बहुत पैसा देते हुए भी AI investment returns verify करने में कठिनाई पा सकती हैं
    • कुछ positive results के साथ waste, low-quality outputs और उन outputs को साफ करने की cost भी पैदा होती है
    • AI model providers token sales जारी रहने तक revenue कमाते हैं, लेकिन customer companies संभवतः अधिक strict token budgets लागू करेंगी

open-weight models और token economics

  • McKinney ने open-weight Chinese model GLM 5.2 को physical infrastructure पर चलाया और results अच्छे बताए
  • GLM 5.2 छोटा model नहीं है; इसे ठीक से चलाने के लिए लगभग 8 B200 GPUs चाहिए
    • एक B200 की कीमत लगभग 30,000–50,000 डॉलर मानी जाती है
    • total hardware cost लगभग 250,000–400,000 डॉलर तक पहुंच सकती है
  • लंबी अवधि में वे उम्मीद करते हैं कि open-weight models की quality बढ़े और hardware सस्ता हो, ताकि external AI companies को लगातार पैसे देने के बजाय personal server की electricity cost भरना संभव हो सके
  • पिछले 30 दिनों में इस्तेमाल tokens को API list price से calculate करें तो लगभग 37,000 डॉलर था, लेकिन actual model providers को भुगतान इससे काफी कम था
  • मौजूदा token prices में बड़े पैमाने पर subsidy शामिल होने की संभावना है, और लंबी अवधि में कौन सा cost structure sustainable होगा यह अनिश्चित है
  • AI adoption rate भी industry attention जितना uniform नहीं है; कुछ companies board और CTO level पर सिर्फ चर्चा कर रही हैं और actual adoption शुरू नहीं हुआ है, यानी वे long-tail segment में हैं

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

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.