YouTube का पैमाना कितना बड़ा है?

 (ethanzuckerman.com)
1 पॉइंट द्वारा GN⁺ 2023-12-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • पूरे प्लेटफ़ॉर्म को समझने के लिए कोई denominator न हो, तो misinformation या recommendation के प्रभाव जैसे शोध नतीजे भी संदर्भ खो सकते हैं; इसलिए शोध टीम ने random sample से YouTube के कुल आकार का अनुमान लगाने की कोशिश की
  • YouTube video ID 11 अक्षरों की होती है और संभावित address space 2^64 है, इसलिए सिर्फ़ random URL डालकर valid वीडियो ढूंढना लगभग असंभव है
  • शोध टीम ने “drunk dialing” तरीके और efficiency techniques से कई महीनों में 10,000 से ज़्यादा सचमुच random videos इकट्ठा किए, और अनुमान लगाया कि अभी YouTube पर लगभग 13.325 अरब videos हैं
  • sample analysis के मुताबिक़ सिर्फ़ 2023 में 4 अरब से ज़्यादा videos upload हुए, और median views 39 निकले—जिससे पता चलता है कि YouTube की long tail बहुत बड़ी है
  • Tubestats आकार के अनुमान को लगातार update करना चाहता है, लेकिन ऐसी video URLs को उजागर न करने की ethical constraints भी बनी हुई हैं जो public होने के बावजूद व्यवहार में लगभग discover नहीं होती थीं

YouTube research को कठिन बनाने वाली denominator problem

  • social media research अक्सर misinformation या hate speech जैसी दिखने वाली घटनाओं को खोजने पर केंद्रित हो जाती है, लेकिन अगर पता न हो कि वे पूरे platform में कितना हिस्सा रखती हैं, तो scale का आकलन डगमगा जाता है
    • उदाहरण के लिए “white genocide” या “ivermectin” जैसे search terms से result count गिनना संभव है
    • Avaaz की अगस्त 2020 COVID misinformation report ने 1 साल में 3.8 अरब views गिने, लेकिन पूरे platform views वाला denominator न हो तो यह तय करना मुश्किल है कि यह संख्या बड़ी है या छोटी
  • Reddit और Twitter ने कुछ समय तक पूरे platform का अंदाज़ा लगाने योग्य data access दिया था
    • Reddit ने Pushshift को सभी posts collect करने दिया, जिससे community-wise scale comparison संभव था
    • 2023 की गर्मियों में Pushshift का public access बंद होने के बाद Redditmap.social केवल उसी साल की शुरुआत में बने data का उपयोग कर सकता है
    • Twitter ने research API के ज़रिए सभी tweets का 1/10 या 1/100 sample दिया था, लेकिन बाद में access बंद कर दिया और कम access के लिए भी भारी fees लगाईं

YouTube पर representative sample पाना मुश्किल है

  • YouTube एक बड़ा platform है जिसे लगभग सभी internet users इस्तेमाल करते हैं
    • Pew के अनुसार teens में से 93% YouTube इस्तेमाल करते हैं
    • सबसे नज़दीकी services TikTok 63% और Snapchat 60% हैं
  • documented API होने के बावजूद पूरे YouTube का random representative sample पाने का अच्छा तरीका नहीं है
  • मौजूदा YouTube research मुख्यतः दो तरीकों पर निर्भर करती है
    • चुने गए user channels के सभी videos इकट्ठा कर analysis करना
    • किसी खास video से शुरू करके recommended videos को follow करते हुए collect करना
  • ये दोनों तरीके meaningful research में काम आ सकते हैं, लेकिन पूरे YouTube videos का sample बनाने या platform size calculate करने के लिए पर्याप्त नहीं हैं

random URL आज़माने वाला “drunk dialing”

  • Jason Baumgartner ने YouTube की unofficial API InnerTube का इस्तेमाल कर random URLs आज़माने का तरीका सुझाया
  • YouTube URL में video ID, watch?v= के बाद आने वाली 11-character string होती है
    • पहले 10 characters a-z, A-Z, 0-9, _, - हो सकते हैं
    • आख़िरी character केवल 16 values में से एक हो सकता है
    • संभावित YouTube addresses 2^64, यानी लगभग 18.4 quintillion हैं
  • अगर मान लें कि YouTube videos 1 अरब हैं, तब भी किसी एक random URL के valid होने की संभावना लगभग 18.4 अरब में 1 है
  • शोध टीम ने इस तरीके को “drunk dialing” कहा, और Jason Baumgartner ने efficiency को लगभग 32,000 गुना बढ़ाने वाला workaround खोजा
  • Kevin Zheng ने search script लिखकर कई महीनों में 10,000 से ज़्यादा वास्तविक random YouTube videos collect किए

random sample से दिखा YouTube का आकार और distribution

  • YouTube के मौजूदा size estimate के अनुसार 13.325 अरब videos हैं, और इसे tubestats.org पर हर कुछ हफ्तों में update किया जाता है
  • random videos की उम्र देखकर YouTube की growth rate calculate की जा सकती है
    • अनुमान है कि सिर्फ़ 2023 में YouTube पर 4 अरब से ज़्यादा videos post किए गए
  • views distribution में मजबूत long tail दिखती है
    • YouTube videos के median views 39 हैं
    • YouTube 10,000 से ज़्यादा views वाले videos recommend करना पसंद करता है
    • 10,000 से ज़्यादा views वाले videos dataset के लगभग 4% हैं, लेकिन YouTube के कुल views का बड़ा हिस्सा इन्हीं के पास है
  • collect किए गए random videos का उपयोग language distribution estimate करने में भी हुआ
    • Kevin Zheng ने search script को कई language detection systems से जोड़ा
    • यह estimate defendable है, लेकिन perfect नहीं है

ज़्यादा efficient dash method

  • random URL search पूरे address space को target करती है, इसलिए इसे दूसरे sampling methods की randomness verify करने के benchmark के तौर पर इस्तेमाल किया जा सकता है
  • शोध टीम ने माना कि अगर video list बनाने के दूसरे तरीके random search जैसे नतीजे देते हैं, तो उन्हें “plausibly random” माना जा सकता है
  • Jia Zhou आदि ने 2011 में जो तरीका खोजा था, वह ज़्यादा efficient sample collection method के तौर पर काम करता है
    • 5-character string generate की जाती है, जिसमें एक character dash होता है
    • YouTube autocomplete उस URL को complete करता है और अगर मौजूद हो तो matching video लौटाता है
  • Kevin Zheng अभी इसी dash method से YouTube को periodic रूप से query करते हैं और Tubestats dashboard maintain करते हैं

long-tail videos और ethical constraints

  • random sample सिर्फ़ successful influencers नहीं, बल्कि user-generated media की long tail के निचले हिस्से में creators tools का कैसे इस्तेमाल करते हैं, यह देखने में भी काम आता है
  • collect किए गए ज़्यादातर videos को केवल कुछ दर्जन लोगों ने देखा था
    • URL publish करने पर “public” status में होने के बावजूद व्यवहार में कम दिखाई देने वाले videos public scrutiny में आ सकते हैं
    • इसलिए paper में खोजे गए video URLs की list शामिल नहीं की गई
  • Ryan McGrady ने 1,000 random videos को खुद देखकर manually coding करने का काम lead किया
  • संबंधित paper Journal of Quantitative Description में प्रकाशित हुआ, और hand-coding results का परिचय Ryan की post में summarized है

Tubestats को बनाए रखने की वजह

  • शोध टीम का plan है कि वे संभव हो तो Tubestats को maintain करते रहें
  • संभव है कि YouTube इस resource या इसे generate करने के तरीके का विरोध करे
  • बड़े user-generated media platforms digital public sphere का महत्वपूर्ण हिस्सा हैं, इसलिए platform पर क्या है, उसे कौन बनाता है और वह किस तक पहुंचता है—इस पर high-level data नियमित रूप से public होना चाहिए

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

1 टिप्पणियां

 
GN⁺ 2023-12-23
Hacker News की राय

  • सैंपल चुनने का तरीका वाकई चतुर है, लेखकों को सलाम। Pew में रहते हुए हमने YouTube API के "related videos" endpoint को फ़ॉलो करते हुए random walk से YouTube को मैप करने की कोशिश की थी, और करीब 1 साल बाद लगा था कि saturation point पर पहुंच गए हैं, लेकिन यहां निकले पैमाने को देखकर लगता है कि रडार के नीचे एक काफी लंबी long tail मौजूद है
    जैसे ही हमने रिसर्च पब्लिश की, Google ने API को लगभग तुरंत बंद करना शुरू कर दिया, लेकिन यह देखकर अच्छा लगा कि कुछ लोग अब भी पुराने तरीके की scraping से रिसर्च जारी रखे हुए हैं। उस समय विश्लेषण channel level पर था और लोकप्रिय channels पर ही केंद्रित था, लेकिन TubeStats के कुछ आंकड़े हमारे निष्कर्षों से काफी मिलते-जुलते हैं, यह भी दिलचस्प है। उदाहरण के लिए भाषा वितरण: https://www.pewresearch.org/internet/2019/07/25/a-week-in-th...

    • यह देखते हुए कि Google bot लगातार वेब को खंगालता है और साइटों पर इतना जोर डालता है कि वे लगभग ठप हो जाएं, Google का API बंद करना काफी ironic है
    • इस तरीके से recommendation में link न किए गए कुछ public-but-limited videos जैसी चीजें भी मिल सकती हैं
    • यह तकनीक नई नहीं है। जीवविज्ञानी झील में मछलियों की संख्या गिनने के लिए इसका इस्तेमाल करते हैं
      जैसे 100 मछलियां पकड़कर उन्हें tag करना, एक हफ्ता इंतजार करना, फिर दोबारा 100 मछलियां पकड़कर उनमें tagged मछलियों की संख्या गिनना
    • लगता है YouTube ने API को Cambridge Analytica scandal के बाद बंद किया था

  • यह German tank problem के mitigation को target करने का एक दिलचस्प तरीका है https://en.m.wikipedia.org/wiki/German_tank_problem
    सबसे अच्छा हल शायद address space को इतना बड़ा करना होगा कि random sample statistically meaningful निष्कर्ष तक पहुंचने लायक पर्याप्त data इकट्ठा न कर सके। distribution को अलग-अलग तरीकों से बदलने वाले दूसरे अच्छे उपाय भी हो सकते हैं, लेकिन अगर sample सचमुच random है तो उस दिशा में बचाव सीमित होगा

    • लेख में नहीं देखा, लेकिन यह discrete uniform distribution वाली धारणा पर निर्भर करता है। Google ने identifiers के साथ क्या खेल किया है, यह पता नहीं
    • समझ नहीं आता कि random sample clustered distribution जैसी चीज को कैसे हल करेगा। क्या estimation continuity assumption पर निर्भर नहीं करता?
      उदाहरण के लिए अगर addresses /v=0x00 से 0xff तक हैं, लेकिन असल में सिर्फ f0 से ff इस्तेमाल होते हैं, तो videos के random रूप से distributed होने की धारणा में estimate हमेशा biased नहीं होगा?
      यानी addressable space पर कोई मनमाना filter लगाकर फिर addresses assign किए जा रहे हैं। उसी तरीके का random sample उतनी ही हद तक चूकेगा, लेकिन filter से लागू की गई sparsity मुझे पता नहीं होगी

  • "YouTube dislikes" dataset भी देखने लायक है: https://clickhouse.com/docs/en/getting-started/example-datas...
    इसका ऐसा नाम इसलिए है क्योंकि यह dislike feature हटाए जाने से पहले जानकारी इकट्ठा करने की एक archival कोशिश थी। इसका उपयोग सबसे विवादास्पद videos या किसी खास भाषा के description वाले top videos खोजने के लिए किया जा सकता है

    • YouTube इतना बड़ा और public platform है कि यह लगभग public good जैसा है, इसलिए dislike count जैसे stats अहम हैं
      लेख में भी कहा गया है, “YouTube इस resource या इसे बनाने के तरीके पर आपत्ति कर सकता है। इसके जवाब में, हमारा मानना है कि ऐसा high-level data सभी बड़े user-generated media platforms के लिए नियमित रूप से public किया जाना चाहिए। ये platforms digital public sphere के सबसे महत्वपूर्ण हिस्सों में हैं, और इनके अंदर क्या है, कौन बना रहा है और यह किस तक पहुंच रहा है, इस बारे में हमें कहीं अधिक जानकारी चाहिए”
      सरकार को platforms को ऐसे stats expose करने के लिए regulate करना चाहिए, ताकि statistical agencies उन्हें collect कर सकें
    • यह comment लिखने वाले ClickHouse CEO हैं

  • मैं जानना चाहता था कि YouTube के पास कितना डेटा है, लेकिन वह संख्या उपलब्ध नहीं थी। दिए गए आँकड़ों से मोटा-मोटा हिसाब लगाया तो औसत वीडियो लंबाई करीब 500 सेकंड निकली
    अगर bitrate 400KB/s और वीडियो की संख्या 13 अरब मानें, तो 2.7 exabytes आता है। 400KB/s वह वैल्यू है जो मैंने सीधे डाउनलोड किए गए कुछ FHD 24~30fps वीडियो से निकाली, इसलिए यह बहुत ही मोटा अनुमान है। YouTube शायद कम महसूस होने वाली जानकारी वाले हिस्सों को और कम bitrate पर encode करता होगा, और वीडियो की resolution व framerate अलग-अलग होती हैं; उनका वितरण भी service के इतिहास के साथ बदलता रहा है। अगर सभी वीडियो को 1.5MB/s bitrate वाले 4K के रूप में मानें, तो 10 exabytes आता है
    यह अनुमान YouTube के लिए जरूरी storage को कम मानता है। लोकप्रिय वीडियो कई data centers में, VP9 और AV1 दोनों में stored होंगे। उल्टा, अगर अलोकप्रिय वीडियो को compress किया जाता हो या दूसरे formats से on-demand transcode किया जाता हो, तो यह अनुमान ज्यादा भी हो सकता है, लेकिन इसकी संभावना कम लगती है

    • storage का वह अनुमान एक digit के order तक गलत होने की काफी संभावना है
      400KB/s, यानी 3.2Mbps जो अक्सर video encoding में इस्तेमाल होता है, original-quality FHD यानी 1080p upload के हिसाब से काफी कम है। 4K वीडियो वाला आंकड़ा औसत original upload के काफी करीब है
      इसमें यह भी ध्यान रखना होगा कि YouTube कम-से-कम H.264 और VP9, दो video codecs में compress करता है। हर codec में original upload quality के आधार पर 320p से 1080p से ऊपर तक सभी resolutions होते हैं। लोकप्रिय वीडियो और 4K वीडियो का बड़ा हिस्सा AV1 में भी encode होता है। कुछ में 360-degree surround video के लिए HEVC तक है। आपने सही पढ़ा। YouTube पर H.265 HEVC है
      और इन सब में replication या duplicate storage शामिल भी नहीं है। कुल मात्रा आसानी से 100EB से ऊपर हो तो भी हैरानी नहीं होगी। यह 2020 के 100 Dropbox जितना है
    • एक तरफ, यह “सिर्फ दो formats?” वाली बात नहीं है। H.264 जैसे और भी हैं, और resolutions भी कई हो सकते हैं। साथ ही कुछ resolutions को किसी खास format में हमेशा उपलब्ध कराने की contractual obligation हो सकती है, या रही होगी
      दूसरी तरफ, बहुत बड़ी संख्या में ऐसे वीडियो भी हो सकते हैं जिनके views बेहद कम हैं। और एक और पहलू यह है कि YouTube को अपना transcoding chip तक बनाना पड़ा था। सचमुच मामला जटिल है
      10 साल पहले मुझे इस सवाल का जवाब पता था, और मैंने storage टीम वालों को cost कम करने में मदद की थी। कुछ दिन पहले पता चला कि उनमें से एक, R.L., इस साल फरवरी में गुजर गए। RIP
    • replication और erasure coding overhead छूट रहा है। 10 exabytes सच कहें तो बहुत कम लगता है। अभी यह 50~100EB के ज्यादा करीब होगा
    • 2013 में हर मिनट upload होने वाले घंटों के annual reported figure के आधार पर जब calculate किया था, content 375PB था और रोज 185TB बढ़ रहा था, annual growth rate 70% थी
      इस calculation में multiple encodings या original storage शामिल नहीं थे
    • यह भी ध्यान रखना होगा कि YouTube original upload copy को permanent रखता है। original file और बड़ी भी हो सकती है

  • इस लेख के output के तौर पर साथ में linked site भी है: https://tubestats.org/

  • Google पहले कुछ job interviews में YouTube से जुड़े scalability questions पूछा करता था। आमतौर पर बात बढ़ते distributed infrastructure में log data sync करने की समस्या तक जाती थी, और नतीजा लगभग समझाना भी मुश्किल, हास्यास्पद Big-O(f(n)) जैसा निकलता था
    source: मैंने Google interviews कुछ बार दिए हैं

  • लेखक ने लिखा है कि उन्होंने “cheats” का इस्तेमाल किया। यह क्या करता है, इसके आधार पर sample independent होने की iid assumption टूट सकती है
    अगर यह snowball sampling जैसा है, तो “अत्यधिक” success rate मिल सकता है और संख्या inflate हो सकती है। एक हिस्सा है: “Jason ने कुछ cheats ढूँढे जो इस method को लगभग 32,000 गुना ज्यादा efficient बनाते हैं, इसलिए हमारी ‘call’ कहीं ज्यादा बार connect होती है”

    • बस लेख को अंत तक पढ़ना चाहिए
      उसमें लिखा है, “2011 में Jia Zhou आदि ने इसे खोजा था, और यह हमारी naive method से कहीं ज्यादा efficient है। अगर एक character dash वाला पाँच-character string बनाया जाए, तो YouTube उस URL को autocomplete करता है और मौजूद होने पर matching video देता है”
    • URL में checksum होने की काफी संभावना है, जिससे वास्तव में वीडियो access किए बिना भी typo detect किया जा सकता है
      checksum कैसे बनता है यह न पता हो, तब भी actual ID space के किसी एक sample के लिए उसके सभी values try किए जा सकते हैं
    • वह cheat शायद playlist API जैसा कुछ इस्तेमाल करता होगा, जो video मौजूद है या नहीं इसे individual result के रूप में return करता है
      उदाहरण के लिए ID x, x+1, x+2, ... वाली playlist बनाने की API call करें और फिर list fetch करें, तो उसमें सिर्फ assigned ID x+2 शामिल हो
    • अगर sample skewed होता, तो data इतना clean नहीं दिखता। Google ने अगर कुछ interesting किया होता, तो वह सिर्फ थोड़ा skew होकर खत्म नहीं होता
    • सहमत
      मेरे जैसे statistics beginner को यह proof चाहिए कि cheats और autocomplete इस्तेमाल करने पर भी sample independence नहीं टूटती और sampling जितनी हो सके random बनी रहती है
      नशे में random फोन मिलाने जैसा, लेकिन हर बार कोई operator की तरह गलत number dial करने पर भी किसी न किसी से connect कराने में मदद करे—यह random जैसा नहीं लगता
      हालांकि मैंने 85-page paper नहीं पढ़ा। हो सकता है वहाँ यह cover किया गया हो

  • दिलचस्प dataset है। paper channel statistics को लेकर थोड़ा गलत impression छोड़ता है
    मेरी समझ से, subscriber count देखते समय sampling bias को correct करके reweight नहीं किया गया है। अगर sample पूरी population का छोटा हिस्सा है, तो किसी specific channel के आने की probability उस channel के public videos की संख्या के proportional होगी, इसलिए roughly 1/channel-wise video count से weight करना चाहिए

    • मैंने भी यही बात देखी। subscribers 10 लाख होना 98th percentile है, यह बहुत plausible नहीं लगता; इसके 99.999th percentile न होने की संभावना कम लगती है

  • जिन लोगों को curiosity है, उनके लिए इनकी estimation method roughly ऐसी है
    values की range assume करते हैं, और उस range से sample लेने वाला fair probability function assume करते हैं। estimated size, hit ratio को total value range से multiply करने पर मिलता है

    • मैंने article को skim किया, और अगर ऐसा है तो assumptions काफी ज्यादा हैं
      मान लें possible values की range सही है। अगर यह किसी specific range के 10 characters में 1 जोड़ने जैसी form है, तो यह उन possible videos का एक बहुत बड़ा circle दिखाता है
      identifier, यानी valid videos का distribution, असली मुद्दा है। अगर YouTube ने IDs पर कोई constraint या skew लगाया है जिसके बारे में हमें पता नहीं, तो वास्तव में मौजूद video IDs उस बड़े possible circle के अंदर एक छोटे circle में हो सकते हैं और पूरे space में uniformly फैले न हों। clusters भी हो सकते हैं। तब उस skew की silhouette पाने या यह देखने के लिए कि यह roughly random है या नहीं, शायद Poisson distribution जैसी किसी चीज़ से space में darts फेंकने की तरह samples लेने होंगे
      उसके बाद ही size estimate किया जा सकता है। क्या ये लोग वही कर रहे हैं? और क्या किसी ने बस YouTube से पूछा नहीं?

  • इस तरीके को रोकना सच में बहुत आसान है। जो identifiers मौजूद नहीं हैं, उनमें से एक निश्चित अनुपात के लिए random videos लौटाए जा सकते हैं। उसमें थोड़ी randomness मिला दें तो काफी है
    किसी तरीके को समझाने में जो जोखिम होता है, वह यही है

    • तब ऐसा लगता है कि पूरे सिस्टम में कई invariants को तोड़े बिना इसे implement करना बहुत मुश्किल होगा
      जैसे ये शर्तें कि video ID immutable होना चाहिए, और एक video को केवल एक ही unique video ID से दर्शाया जाना चाहिए
    • अगर randomly generate किए गए ID से कोई video मिल जाए, तो तुरंत फिर से query करके देख सकते हैं कि क्या वही video मिलता है जो पहले मिला था
      अगर वही नहीं है, तो उस result को छोड़ दें और मान लें कि generate किया गया ID असल में मौजूद नहीं है। अगर वही है, तो पता चल जाएगा कि यह वास्तविक ID है
      जब तक YouTube video URL immutable हैं, यह तरीका ऊपर बताए गए blocking को झेल सकता है
    • हालांकि अगर YouTube यह न बताए कि वह ऐसा कर रहा है, तो हमें पता नहीं चलेगा कि यह तरीका अमान्य हो गया है या नहीं। ऊपर से उस दूसरे video की अपनी मौजूदा UID होगी, इसलिए theoretically यह भी पता चल सकता है कि क्या ऐसे measurement में बाधा डालने के लिए उसे replicate किया गया था
    • ऐसे system में production errors debug करने की कल्पना करना भी मुश्किल है
    • क्या video IDs उपलब्ध domain के भीतर sequential हैं, या पूरी तरह बिखरी हुई हैं? क्या known live video IDs में कोई commonality है, जिससे quintillion-level possibilities को scan करना आसान हो सके?