‘Kafka’ मर गया, लेकिन ‘Kafka’ हमेशा ज़िंदा रहेगा

 (warpstream.com)
3 पॉइंट द्वारा GN⁺ 2023-08-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Kafka डेटा-सेंटर युग के distributed log के रूप में सफल रहा, लेकिन public cloud में AZ के बीच network cost और local disk संचालन का बोझ बढ़ जाता है
  • WarpStream एक diskless streaming platform है जो Apache Kafka protocol के साथ compatible है, और S3 जैसे object storage के ऊपर local disk और broker rebalancing के बिना चलता है
  • 3 availability zones वाला Kafka cluster 1GiB streaming के लिए सबसे अच्छी स्थिति में भी लगभग $0.053 AZ-to-AZ transfer cost लगाता है, जो S3 में 1GiB को एक महीने तक store करने की लागत $0.021 से ज़्यादा है
  • WarpStream stateless Go binary Agent और अलग metadata store के ज़रिए storage·compute तथा data·metadata को अलग करता है, और data उपयोगकर्ता के cloud account के object storage में ही रहता है
  • ज़्यादातर Kafka workloads में cost 5~10 गुना घट सकती है, लेकिन मौजूदा implementation में Produce request P99 लगभग 400ms और producer-consumer end-to-end P99 लगभग 1 सेकंड की latency स्वीकार करनी पड़ती है

Cloud में महँगा हो चुका Kafka का बुनियादी ढांचा

  • Apache Kafka 2011 में open source के रूप में जारी होने के बाद streaming architecture की बुनियादी infrastructure बन गया
  • समस्या Kafka से ज़्यादा इस बात में है कि 2011 के LinkedIn data center के लिए बना design आधुनिक cloud workloads से अच्छी तरह मेल नहीं खाता
  • Cost और operational burden खास तौर पर बड़े दिखते हैं
    • Cloud economics: Kafka की replication strategy AZ-to-AZ bandwidth cost को काफी बढ़ा सकती है
    • Operational burden: अपना Kafka cluster चलाने के लिए dedicated team और custom tools की ज़रूरत होती है
  • Local disk पर data store करने वाले समान systems भी वही cost और operations समस्याएँ झेल सकते हैं

Kafka-nomics: AZ-to-AZ transfer cost

  • सामान्य 3 availability zones वाले Kafka cluster में, produced data partition leader की location की वजह से 2/3 probability से zone के पार लिखा जाता है, और फिर leader data को बाकी दो zones के followers में replicate करता है
  • जब 1GiB zone के बीच transfer होता है, तो cost $0.022 मानी जाती है
    • source zone egress $0.01
    • destination zone ingress $0.01
  • सबसे अच्छी स्थिति में भी 1GiB streaming cost लगभग 0.02 * 2/3 + 0.02 * 2 = $0.053 होती है
  • S3 में 1GiB को एक महीने तक store करने की cost $0.021 है, और Kafka में producer से consumer तक data copy करने की cost से वही data S3 में दो महीने से ज़्यादा रखा जा सकता है
  • High-throughput Kafka clusters में hardware से ज़्यादा AZ-to-AZ bandwidth charges cost को dominate करते हैं, और workload cost का 70~90% तक हो सकते हैं
  • Throughput कम हो तब भी retention period लंबा होने पर storage capacity बढ़ती है, और local SSD पर triple replication करने का तरीका 100% disk utilization मानने पर भी S3 जैसे object storage की तुलना में प्रति GiB लगभग 10~20 गुना महँगा हो सकता है

Cluster operations का बोझ developers पर

  • Developers business problems हल करने के लिए Kafka अपनाते हैं, लेकिन पहले उन्हें Kafka और ZooKeeper या KRaft, leader election, partitions, consumer groups, rebalancing, broker tuning, और client tuning सीखनी पड़ती है
  • Kafka का data plane यानी brokers और consensus-based control plane यानी controllers·ZooKeeper आदि सभी local SSD पर सीधे operate होते हैं
  • Self-hosted Kafka cluster में node replacement या cluster expansion जैसे basic tasks को भी सुरक्षित तरीके से करने के लिए specialist team और custom tools चाहिए
  • Apache Kafka का built-in partition reassignment tool broker decommission के समय automatic reassignment plan नहीं बना सकता, और administrator को partition replicas move करने का plan खुद लिखना पड़ता है
  • AWS MSK जैसी hosted services भी operational burden पूरी तरह खत्म नहीं करतीं
    • MSK का cluster rebalancing documentation Apache Kafka documentation से link करता है
    • उस procedure में कौन सा partition किस broker पर ले जाना है, इसका JSON manually edit करना शामिल है
  • Cruise Control burden कम कर सकता है, लेकिन अलग concepts सीखने, service deployment·monitoring, और operational sharp edges भी जोड़ता है
    • Cruise Control खुद भी Apache Kafka और ZooKeeper पर निर्भर JVM application है

Object storage के ऊपर streaming रखने का approach

  • Datadog द्वारा बनाया गया Husky observability data के लिए S3 पर सीधे चलने वाला columnar database था, और अधिकतर stateless auto-scaling data lake की तरह काम करता था
  • Husky बनाने के बाद Kafka clusters तुलना में पुरानी architecture जैसे दिखने लगे
  • Datadog की Kafka bandwidth दो-अंकीय GiB/s में थी, और broker storage PiB-scale NVMe में measured था
  • बड़े-scale storage workloads के लिए cloud environment में object storage की economics·reliability·scalability·elasticity से compete करना कठिन है
  • Snowflake और Databricks जैसी big data technologies भी general-purpose object storage को केंद्र में रखकर systems design करती हैं
  • Kafka जैसे system को सीधे S3 के ऊपर बनाने से दो तरह का burden एक साथ घट सकता है
    • Cost reduction
    • पारंपरिक Kafka operations समस्याओं में कमी
  • मुख्य कठिनाई S3 जैसे high-latency storage medium के ऊपर local disk के बिना Kafka protocol की semantics बनाए रखते हुए low-latency streaming infrastructure बनाना है

WarpStream architecture

  • WarpStream एक Apache Kafka protocol-compatible streaming platform है जो AWS S3, GCP GCS, Azure Blob Storage जैसे general-purpose object stores के ऊपर सीधे चलता है
  • इसमें AZ-to-AZ bandwidth cost नहीं है, manage करने के लिए local disk नहीं है, और यह user के VPC के अंदर चल सकता है
  • Kafka brokers की जगह Agent का उपयोग करता है
    • Agent एक stateless Go binary है
    • JVM का उपयोग नहीं करता
    • Kafka protocol बोलता है
    • कोई भी Agent topic leader, consumer group offset commit, cluster coordinator की भूमिका निभा सकता है
  • WarpStream दो separations के ज़रिए Kafka की stateful architecture को replace करता है
    • Storage और compute को अलग कर data को S3 पर offload करता है
    • Data और metadata को अलग कर metadata को custom metadata store पर offload करता है
  • सारी storage object storage को सौंप देने पर load changes के हिसाब से Agents की संख्या बढ़ाने या घटाने के दौरान data rebalancing की ज़रूरत नहीं होती
  • Failure होने पर request को दूसरे Agent पर तुरंत retry किया जा सकता है, जिससे recovery तेज होती है
  • Per-partition data imbalance के कारण कुछ Kafka brokers पर load बढ़ने वाले hotspot issues भी काफी हद तक कम हो जाते हैं
  • WarpStream Virtual Cluster का metadata custom metadata database में store होता है
  • Data replication, durability, और availability object storage bucket संभालता है, और user का data cloud account के अंदर रहता है
  • Cloud account के बाहर केवल consensus के लिए ज़रूरी workload metadata, जैसे partition के भीतर batch ordering, जाता है
  • विस्तृत structure WarpStream architecture docs में दिया गया है

Cost example और latency tradeoff

  • Test environment का continuous streaming workload लगातार 140MiB/s data produce करता है, और 3 dedicated consumers इसे consume करते हैं, जिससे कुल 560MiB/s का continuous data transfer बनता है
  • पूरे cloud account की AZ-to-AZ network cost रोज़ औसतन $15 से कम measured हुई
  • उसी workload को Kafka cluster में चलाने पर केवल AZ-to-AZ network cost रोज़ $641 calculated होती है
    • Calculation formula 0.14GiB * $0.053/GiB * 60 * 60 * 24 है
  • उसी workload की S3 API operation cost रोज़ $40 से कम है
  • Agent hardware के लिए केवल 27 vCPU size की VMs चाहिए
  • ज़्यादातर Kafka workloads की total cost of ownership WarpStream में 5~10 गुना कम हो सकती है
  • सबसे बड़ी कमी latency है
    • Produce request P99 अभी लगभग 400ms है
    • क्योंकि data S3 में durably store होने और cloud control plane में commit होने से पहले acknowledgement नहीं भेजा जाता
    • Producer से consumer तक end-to-end P99 latency लगभग 1 सेकंड है
  • अगर workload लगभग 1 सेकंड P99 producer-consumer latency स्वीकार कर सकता है, तो per-GiB streaming cost 5~10 गुना घटाई जा सकती है और operational burden लगभग खत्म किया जा सकता है
  • Interface proprietary protocol नहीं बल्कि Kafka है, और यह AWS S3, GCP GCS, Azure Blob Storage इस्तेमाल करने वाले environments में चल सकता है

Developer experience और उपयोग का तरीका

  • WarpStream Kafka की मुख्य समस्याओं में से cloud economics और operational burden को पहले address करता है
  • Kafka में developer experience की समस्या भी है, और partitions को complex stream processing applications लिखने के लिए बहुत low-level abstraction माना जाता है
  • आगे stream processing applications को traditional application development style के ज़्यादा करीब बनाने के तरीकों पर चर्चा करने की योजना है
  • Demo 30 सेकंड के अंदर चलाया जा सकता है
$ curl https://console.warpstream.com/install.sh | bash
$ warpstream demo
  • WarpStream Apache Kafka के ऊपर object storage-based alternative बेचने वाली company का product introduction है, और main text के numbers तथा comparisons को इसी context में पढ़ना चाहिए

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

1 टिप्पणियां

 
GN⁺ 2023-08-09
Hacker News की राय

  • “लगभग हर tech company Kafka इस्तेमाल करती है” यह बात मुझे गलत लगती है
    हालांकि हमने एक-दूसरे को सबूत नहीं दिए, लेकिन हाल में जिन 6 कंपनियों में मैंने काम किया, उनमें से Kafka इस्तेमाल करने वाली 0 थीं, और उससे पहले वाली कंपनी में मैंने इसे अपनाने की पहल की थी, लेकिन बाद में इसे छोड़ दिया गया
    LinkedIn ने Kafka इसलिए बनाया था कि वह बहुत बड़े पैमाने की समस्याएं हल कर सके, जो 99% लोगों के पास नहीं होतीं, और भले ही engineers की ऐसी reputation हो कि वे गैर-जरूरी technologies इस्तेमाल कर लेते हैं, मुझे लगता है ज्यादातर लोग Kafka के इस्तेमाल से बचने में सफल हो रहे हैं

    • मुझे समझ नहीं आता कि कोई Kafka को नापसंद कैसे कर सकता है। Kafka सचमुच publish/subscribe semantics के साथ data को A से B तक पहुंचाता है
      अगर आपको बस इतना ही चाहिए, तो इसे retention period के बिना एक साधारण message broker की तरह इस्तेमाल करना आसान है; और अगर आपको persistence का फायदा उठाकर कोई खास काम करना है, तो उस दिशा में जा सकते हैं
      अगर कोई अपने basic रूप में ही मजबूत और व्यापक रूप से इस्तेमाल होने वाले open-source tool के प्रति negative भावना रखता है, तो आमतौर पर वजह कुछ खास features या use cases ही होंगे
      बल्कि ऐसी wording इस vendor के लिए अच्छी नहीं लगती। Kafka की technical खूबियों-कमियों पर आलोचना या competition हो सकता है, लेकिन market में उसकी position को तोड़-मरोड़कर दिखाना ठीक नहीं है
    • Kafka message queue से ज्यादा persistent WAL जैसा है। अगर आपके काम को WAL की जरूरत नहीं है, तो यह लगभग निश्चित रूप से overkill लगेगा और आप इसे नापसंद करेंगे; अगर WAL चाहिए, तो यह सबसे अच्छा tool बन जाता है
    • मैं contractor हूं, इसलिए कई कंपनियों में आता-जाता रहता हूं; मैंने कुछ कंपनियों को Kafka अपनाने की कोशिश करते देखा है और हर बार यह समस्या ढूंढता हुआ समाधान जैसा लगा
      मुझे शक नहीं कि इसके अच्छे use cases हैं, लेकिन अब तक मैंने सिर्फ ऐसे उत्साही users देखे हैं जो इसे हर स्थिति में जबरन फिट करना चाहते हैं, इसलिए इसका अनुभव अच्छा नहीं रहा और मैं “नापसंद करने वालों” में हूं
    • सहमत नहीं हूं। लोग Kafka को वहां फिट करने की कोशिश कर सकते हैं जहां जरूरत नहीं है, लेकिन जिन applications में event streaming होती है, वहां Kafka अब भी पहली पसंद है। Analytics, messaging, sensors वगैरह इसी में आते हैं
      “Accidental SRE” वाले हिस्से से सहमत हूं, लेकिन Kafka एक मजबूत technology है, और इसी वजह से Redpanda जैसे “Kafka से बेहतर Kafka” tools भी भरपूर हैं
      आखिर में बात मुद्दे से हटती लगती है। व्यापक रूप से इस्तेमाल न होना इस बात से अलग है कि technology polarizing है या नहीं। जिन लोगों को वह बताए गए 1% scale वाली problems हल करनी हैं, उनके लिए यह अब भी पसंद या नापसंद की चीज हो सकती है
      यह कुछ वैसा है जैसे कहना कि “Lamborghini पर लोगों की राय बंटी हुई है” गलत है, क्योंकि ज्यादातर लोगों के पास Lamborghini नहीं है। लेखक ने भी साफ तौर पर “data field में” कहकर दायरा सीमित किया था
    • लगता है यह expression मेरे निजी network और काम के अनुभव से काफी प्रभावित है

  • मेरे कुछ सवाल हैं

    1. अगर हर message सीधे S3 में डालें, तो S3 API call cost बहुत ज्यादा नहीं हो जाएगी? Local storage के बिना messages को durably buffer/queue/merge कैसे करते हैं?
    2. हर availability zone में एक Kafka cluster चलाने और ETL तक availability zones के बीच replication न करने के तरीके में क्या समस्या है? जैसे AZ1 clients AZ1 cluster को भेजें, AZ2 clients AZ2 cluster को
    3. Kafka partition के अंदर operations का order कैसे preserve करते हैं?
    • WarpStream Agent हाल के करीब 100ms में request पाने वाले सभी topic-partitions का data एक file में बांधकर S3 में flush करता है
      इसलिए S3 PUT cost topic-partitions की संख्या पर नहीं, बल्कि चल रहे Agents की संख्या और flush interval पर निर्भर करती है। जब तक data S3 और cloud control plane में durably store नहीं हो जाता, तब तक Produce requests को acknowledge नहीं किया जाता
      मेरा मानना है कि reliability और cost में से एक चुनना जरूरी नहीं होना चाहिए। WarpStream 3 availability zones में चलाने जैसी reliability और availability एक availability zone की cost पर देता है
      Order को cloud control plane में चलने वाला custom metadata database handle करता है
    • Kafka के काम करने के तरीके में messages broker तक पहुंचने से पहले ही naturally buffer और merge होते हैं, इसलिए जाहिर है messages merge हो रहे हैं
      हर availability zone में Kafka cluster रखकर बाद में मिलाने तक ही replicate करने के तरीके में अपने-आप में कोई समस्या नहीं है। लेकिन distributed systems और availability zones दिए हों, तो engineers और business requirements आम तौर पर multi-availability-zone configuration चुनते हैं। Regions के साथ भी यही बात है
      इसलिए ज्यादातर Kafka clusters multi-availability-zone होते हैं, जबकि कई मामलों में इसकी जरूरत नहीं होती, और उस cost bill का दोष Kafka पर डाल दिया जाता है
      Kafka protocol वास्तव में Kafka partition के भीतर operations का order preserve नहीं करता। यह producer-partition pair के भीतर operations का order preserve करता है, और वह भी तभी जब उसे खास तरीके से configure किया गया हो
      Standard implementation producer से broker को message मिलने का order preserve करती है, लेकिन external systems के नजरिए से इसका मतलब ज्यादा यह है कि सही configuration होने पर किसी specific key और specific producer के messages received order में preserve होते हैं
    • नंबर 3 को लेकर खास तौर पर उत्सुक हूं। Architecture overview देखकर लगता है कि सभी Agents actively write और compact करते हैं, तो यह कैसे coordinate करते हैं कि कौन-सा topic-partition compact करना है?
      क्या Cloud Metadata Store असल में offsets बांटने का काम करता है?
    • नंबर 1 के बारे में, अगर Kafka AWS के अंदर hosted है, तो मेरी समझ में Amazon AWS के अंदर data transfer के लिए charge नहीं करता

  • मैं WarpStream का co-founder और CTO Ryan Worl हूँ। S3 के ऊपर सीधे बनाए गए Kafka protocol-compatible streaming system का developer preview घोषित करते हुए बहुत खुशी हो रही है।
    चलाने के लिए कोई stateful disks/nodes नहीं, data rebalancing नहीं, ZooKeeper नहीं, और availability zones के बीच bandwidth cost नहीं—इसलिए यह 5–10 गुना सस्ता है।
    अगर WarpStream के बारे में सवाल हों, तो मैं co-founder richieartoul के साथ जवाब दूँगा।

    • बधाई। अपनी side project सूची से “Kafka का SQLite” वाला आइटम हटाकर खुशी हो रही है।
      इसे न बनाने की एक वजह यह थी कि अगर scale मायने नहीं रखता, तो users को छोटा Kafka चाहिए या वे सीधे SQLite ही इस्तेमाल कर लें—इसमें थोड़ा paradox लगता था।
      लेकिन हो सकता है लोगों को Kafka protocol की semantics पसंद हों, या वे पहले से Kafka इस्तेमाल कर रहे हों और बाद में समझें कि scale उतना नहीं है जितना सोचा था, इसलिए complexity झेलने की जरूरत नहीं। शुभकामनाएँ।
    • क्या यह S3-compatible services, खासकर Cloudflare R2, को support करता है? सुना है कि हर S3-compatible provider के API behavior और consistency model में थोड़े अंतर होते हैं, इसलिए अलग handling की जरूरत पड़ सकती है।
      अगर Cloudflare R2 support हो, तो multi-cloud के लिए भी अच्छा रहेगा।
    • ब्लॉग पोस्ट में कहा गया था कि partitions किसी program द्वारा सीधे handle करने के लिए बहुत low-level abstraction हैं; तो क्या इसका मतलब है कि WarpStream partitions का उपयोग नहीं करता?
      क्या यह Kafka की तरह partition level पर मिलने वाली ordering guarantee भी देता है?
    • अब producer को S3 write का इंतजार करना पड़ेगा, तो latency काफी ज्यादा नहीं हो जाएगी?
      अगर “5–10 गुना सस्ता” होना ज्यादातर availability zones के बीच cost बचत की वजह से है, तो क्या AWS MSK भी वह नहीं देता?
    • ZooKeeper को कैसे replace करते हैं?

  • एक बात तो पक्की है। Cloud providers के ऊपर अलग-अलग VMs में Kafka को “textbook तरीके” से चलाना बेहिसाब महंगा है।
    मुझे Kafka और Hadoop को लेकर कई customers से हुई बहुत सीधी-सादी बातचीत याद है: जब disk पहले से ही पूरी redundant system के रूप में मिलती है, तो VM/disk level पर data को फिर से replicate क्यों करें?
    यहाँ Azure Storage था, जो local redundancy, availability zone redundancy, और global redundant storage देता था, और उनमें से कई managed disks चलाने के लिए इस्तेमाल किए जा सकते थे।
    इसलिए सही तरह से design की गई Hadoop/Kafka cloud managed service, provider की built-in redundancy का फायदा उठाने के लिए storage adapters इस्तेमाल करती है। कुछ cloud providers के पास Kafka-compatible event broker होने की वजह भी यही है।
    WarpStream के बाकी हिस्से icing on the cake जैसे हैं, लेकिन इसकी internal structure और availability zones के बीच cost से कैसे बचते हैं, यह जानने की उत्सुकता है।
    संदर्भ के लिए, मैं Microsoft में काम करता हूँ, लेकिन लगभग 10 साल पहले join करने से पहले Hadoop/Spark/Kafka clusters बनाता था।

    • पुराने समय में redundant systems अक्सर एक tiebreaker process से implement किए जाते थे, जो असली process की तुलना में बहुत कम resources इस्तेमाल करता था।
      कुछ Raft implementations ऐसे nodes की अनुमति देती हैं जिनके पास vote होता है, लेकिन वे quorum leader नहीं बन सकते। उदाहरण के लिए, कोई branch office जहाँ सारा traffic asymmetric VPN tunnel से गुजरता है, उसे leader नहीं चुना जाना चाहिए, लेकिन उसे पता होता है कि वह किन candidates को देख सकता है।
      इसलिए cluster चलाने की base cost hardware के 3x के बजाय करीब 2.2x होती थी, और छोटे solutions या developer sandboxes में यह बड़ा फर्क था। जहाँ 3 shards load के लिए थोड़ा कम पड़ते हों लेकिन 5 बहुत ज्यादा हों, या 6 और 7 के फर्क में भी यह अहम होता है।
      समस्या यह है कि geographic replication में यह इस लेख की central बात वाले दो मुद्दे हल नहीं करता। cloud economics के लिहाज से Kafka की replication strategy design के कारण availability zones के बीच भारी bandwidth cost बनाती है, और operations burden के लिहाज से अपना Kafka cluster चलाने के लिए dedicated team और sophisticated custom tooling लगभग जरूरी हो जाती है।
      फिर भी cloud में इस capability को वापस पाना जरूरी है। खासकर तब, जब हमेशा की तरह रुझान फिर से self-hosting की ओर झूलने लगे।
    • या फिर intended तरीके से brokers पर temporary data storage इस्तेमाल करें।
    • “जब disk पहले से ही पूरी redundant system के रूप में मिलती है, तो VM/disk level पर data replicate क्यों करें” का जवाब आसान है।
      EBS जैसी solutions की अपनी cost होती है। खासकर जब ज्यादा IOPS चाहिए हों, तो यह बहुत महंगी होती है। availability zones के बीच traffic cost बच सकती है, लेकिन storage पर बेहिसाब पैसा देना पड़ता है।
      replication खुद करने पर बहुत सस्ता attached storage इस्तेमाल किया जा सकता है।
    • Azure disk replication data durability के लिए है, Kafka के नजरिए से data availability के लिए नहीं।

  • richieartoul के लिए: blog post में मसाला थोड़ा ज्यादा है।
    Kafka को बहुत बड़े clusters चलाने से पहले तक स्वाभाविक रूप से expert dedicated team और करोड़ों dollars की जरूरत नहीं होती।
    हालांकि इस बात से पूरी तरह सहमत हूँ कि 3 availability zones में फैला cluster inter-AZ transfer cost में पैसा खींच लेता है। AWS MSK को बेचने का तरीका भी यही है। कहा जाता है कि availability zones के बीच transfer “free” है, लेकिन असल में वह price में पहले से शामिल है।

  • दिलचस्प लगता है, लेकिन “Accidental SRE” पढ़कर दो सवाल आए।
    Bare metal बहुत पहले से मौजूद है, लेकिन अपना bare metal manage करना खास आसान हो गया हो, ऐसा नहीं लगता। अगर सच में आसान होता, तो end users इन चीजों को खुद ज्यादा manage करते।
    तो यह service कैसे manage की जाती है? cloud provider पर है या bare metal पर?
    आप दोनों को FoundationDB का काफी experience है, जिसे आमतौर पर लोग खुद manage करते हैं। तो क्या metadata store के लिए फिर FoundationDB चुना? अगर चुना या नहीं चुना, तो वजह जानना चाहूँगा।

    • WarpStream की current delivery method hybrid BYOC approach है। customer अपने cloud account में Agent चलाता है, और हम metadata store को remotely manage करते हैं।
      इससे customer का सारा data customer के cloud account और S3 bucket में ही रहता है, जिसे हम देख या छू नहीं सकते। customer को WarpStream Agent खुद चलाना पड़ता है, लेकिन वह सिर्फ एक stateless container है जिसे manage करना आसान है।
      metadata store के रूप में FoundationDB पर विचार किया था, लेकिन आखिरकार इस्तेमाल नहीं किया। free tier को cost-effective बनाने के लिए इस specific use case के लिए metadata store को जितना हो सके efficient बनाना था, और इसके लिए कुछ ज्यादा custom चीज चाहिए थी।
      फिर भी FoundationDB शानदार technology है। मैंने जितने distributed databases इस्तेमाल किए हैं, उनमें यह सबसे अच्छा है।

  • “कितने partitions इस्तेमाल करने चाहिए? यह साफ नहीं है, लेकिन एक बार तय कर लिया तो इसे कभी बदला नहीं जा सकता, इसलिए सही चुनाव करना होगा” — यह बात बस गलत है। partitions की संख्या बदली जा सकती है
    और बार-बार कही जाने वाली यह बात भी समझ नहीं आती कि “Kafka ऑपरेट करने के लिए पूरी engineers की टीम चाहिए।” अनुभव के आधार पर यह सच नहीं है। ऑपरेशन cost महंगी है, यह सही है, लेकिन हमारी टीम में इसके लिए बहुत ज़्यादा engineering time नहीं लगता

  • बहुत दिलचस्प। मैंने भी कुछ ऐसा ही design किया था और उसे Zig में implement करने की सोच रहा था https://github.com/fremantle-industries/transit
    Kafka की ताकत का बड़ा हिस्सा API से आता है, और मैं भी इसी तरह के निष्कर्ष पर पहुंचा कि आखिरकार cluster management की complexity कई implementations के जरिए abstract हो जाएगी
    अगर S3 key space के ऊपर Kafka persistence implement किया जा सके, तो WarpStream की तरह सीधे S3 में persist करने से शुरुआत की जा सकती है, और बाद में end-to-end latency घटाने के लिए तेज hot disk और memory tiering mechanisms जोड़े जा सकते हैं
    दिशा पसंद आई। अगर और गहराई से बात करना चाहें, तो Twitter पर संपर्क कर सकते हैं https://twitter.com/rupurt

  • पिछली नौकरी में मैंने शायद इस product से काफी मिलता-जुलता कुछ बनाया था। रोज़ाना दो अंकों वाले TB में machine learning traffic था और real-time latency की ज़रूरत नहीं थी, इसलिए सब कुछ S3 पर ले गए और करीब 90% cost saving हुई
    इसे JVM पर बनाया था और metadata बनाए रखने के लिए अब भी 6-broker Kafka cluster इस्तेमाल किया था। जब सब कुछ मूल रूप से Kafka में था, तब शायद 300 brokers रहे होंगे
    Kafka का compute/storage model उन extreme use cases में अच्छी तरह scale नहीं करता जहां latency सहन की जा सकती है, और Apache Pulsar model ज़्यादा उपयुक्त था। हालांकि उस समय Pulsar production में इस्तेमाल करने के लिए पर्याप्त stable नहीं था
    cost efficiency की एक अहम बात यह थी कि data size इतना बड़ा था कि economical file size तक पहुंचने के लिए ज़्यादा इंतज़ार नहीं करना पड़ता था। यह कल्पना करना मुश्किल है कि 10MB प्रति सेकंड से कम वाली pipeline इस तरीके से efficiently चलेगी

    • इस क्षेत्र में अपना solution बनाने वाले काफी लोगों से मिला हूं। “traditional Kafka के जरिए S3 pointers push करने” वाला approach बहुत practical है
      क्या यह Pinterest का memq था, या कुछ और?

  • लेख का title “Kafka is dead. Long live WarpStream.” होना चाहिए था। “long live” वाला हिस्सा successor की ओर इशारा करता है

    • बात थोड़ी subtle है, लेकिन यहां हम Kafka protocol को successor मानते हैं, क्योंकि यह Kafka implementation से ज़्यादा लंबे समय तक जीवित रहेगा
    • सही है। हालांकि मैंने उस expression को सिर्फ एक विरोधाभासी वाक्यांश के रूप में इस्तेमाल होते सुना है
      https://en.wikipedia.org/wiki/The_king_is_dead,_long_live_th...!