अगर Kafka को शुरू से फिर से बनाया जा सकता तो कैसा होता?

 (morling.dev)
13 पॉइंट द्वारा GN⁺ 2025-04-26 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • KIP-1150 (diskless Kafka) और AutoMQ के Kafka fork प्रोजेक्ट के जरिए cloud-optimized Kafka पर चर्चा तेज़ हुई है
  • अगर Kafka को फिर से बनाया जाए, तो मौजूदा partition structure को हटाकर key-centric approach अपनाने का प्रस्ताव है
  • concurrency control और broker-side schema support जैसी क्षमताओं की ज़रूरत बताई गई है
  • scalability, snapshots, multi-tenancy जैसे आधुनिक सिस्टम गुणों को एकीकृत करने की आवश्यकता पर भी ज़ोर दिया गया है
  • Kafka के आधार पर, मौजूदा Kafka की सीमाओं से आगे बढ़ने वाले वास्तविक cloud-native event log system की कल्पना की गई है

अगर Kafka को फिर से बनाया जाए?

  • हाल ही में KIP-1150 (diskless Kafka) और AutoMQ के Kafka fork की घोषणा हुई, जिनका लक्ष्य S3 जैसे object storage के साथ Kafka को एकीकृत करके cloud environment में elasticity बढ़ाना और लागत कम करना है
  • मौजूदा Kafka की सीमाओं से आगे बढ़ने वाले cloud-native event log system की कल्पना करते हुए कई सुधार प्रस्तावित किए गए हैं

partition-रहित संरचना का प्रस्ताव

  • क्योंकि cloud object storage लगभग असीमित storage की तरह काम करता है, इसलिए topic partitions की आवश्यकता कम हो जाती है
  • कई मामलों में या तो global message ordering महत्वपूर्ण होती है, या केवल एक ही key वाले messages का क्रम
  • users से partition की अवधारणा छिपाकर अधिक सरल उपयोगिता दी जा सकती है

key-centric approach

  • partition scan के बजाय किसी specific key के सभी messages तक तेज़ी से पहुँचने और उन्हें replay करने के लिए डिज़ाइन का प्रस्ताव है
  • यह लाखों entity-level streams को support कर सकता है, जिससे demand के अनुसार consumers की संख्या को लचीले ढंग से बदला जा सकता है
  • failures key स्तर पर isolate हो जाते हैं, इसलिए पूरे सिस्टम की processing efficiency बढ़ती है
  • यह event sourcing या actor model systems के लिए आदर्श संरचना है

topic hierarchy support

  • Solace जैसे systems की तरह, message payload के एक हिस्से को structured path-form topic identifier में promote करके pattern-based subscriptions को संभव बनाना चाहिए
  • इससे broker पूरे message को parse किए बिना भी efficient subscription filtering कर सकता है

concurrency control feature

  • मौजूदा Kafka में write के समय concurrency conflicts को रोकने का कोई तरीका नहीं है
  • अगर per-key optimistic locking support हो, तो यह verify किया जा सकता है कि message latest state देखने के बाद लिखा गया था या नहीं
  • इससे lost update problem को रोका जा सकता है

broker-side schema support

  • Kafka अभी messages को सिर्फ byte array की तरह मानता है, इसलिए उसे external schema registry पर निर्भर रहना पड़ता है
  • schema consistency सुनिश्चित करने के लिए broker स्तर पर AsyncAPI metadata जैसे schema information का built-in support होना चाहिए
  • इससे Apache Iceberg जैसे open table formats के साथ integration भी आसान हो सकता है

scalability और plugin structure

  • Postgres और Kubernetes की तरह extensibility और pluginability वाली संरचना का प्रस्ताव है
  • protocol-aware proxy (जैसे Kroxylicious) के बिना broker-level filters या transformations को आसानी से implement किया जा सकना चाहिए
  • rate limiting, topic encryption, और Iceberg table-based backend support जैसी चीज़ें plugins के रूप में implement की जा सकनी चाहिए

synchronous commit callbacks

  • मौजूदा Kafka केवल eventual consistency की गारंटी देता है
  • यह सुझाव दिया गया है कि producer message भेजने के बाद तुरंत यह verify कर सके कि उससे निकला derived data update हुआ या नहीं
  • read-your-own-writes guarantee को support करके Kafka को एक वास्तविक database log की तरह इस्तेमाल किया जा सकता है

snapshot feature

  • Kafka का मौजूदा compaction केवल आख़िरी message को रखता है, जो तभी उपयोगी है जब उसमें पूरा state शामिल हो
  • अगर केवल changes रिकॉर्ड किए जाते हैं, तो हर key के लिए सभी events को replay करना पड़ता है, जिससे समय बढ़ता है
  • key स्तर पर events को snapshot के रूप में संक्षेपित करने वाली logical compaction क्षमता की ज़रूरत है

built-in multi-tenancy support

  • हर आधुनिक data system को multi-tenancy को बुनियादी रूप से ध्यान में रखना चाहिए
  • नए tenant environments को कम लागत में और तुरंत बनाया जा सके, और resources, security, तथा access control का कड़ा पृथक्करण होना चाहिए

अन्य संदर्भ

  • कुछ features पहले से S2 (high-cardinality streams), Waltz (optimistic locking), और Apache Pulsar (multi-tenancy) जैसे systems में उपलब्ध हैं
  • लेकिन प्रस्तावित सभी features को एक साथ support करने वाला open source system अभी मौजूद नहीं है
  • यह लेख Confluent से जुड़े लेखक की व्यक्तिगत राय है, आधिकारिक रुख नहीं
  • सैद्धांतिक रूप से LSM tree-based architecture को सबसे संभावित विकल्प बताया गया है

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

2 टिप्पणियां

 
kaydash 2025-04-27

हम इसे पहले से ही Redis कहते हैं।
 
GN⁺ 2025-04-26
Hacker News राय

  • सहमत हूँ। कुछ खास use cases के लिए head-of-line समस्या को हल करना काफ़ी मूल्यवान है

    • लेकिन आज के सभी streaming systems (या उनके workaround) message key के हिसाब से acknowledgment पर O(n^2) लागत पैदा करते हैं
    • Pulsar जैसे systems इस फीचर के लिए अक्सर उपयोग किए जाते हैं
    • यह जटिलता हर दिन सामने न आए, लेकिन जब आती है तो इंतज़ार करना पड़ता है
    • सहकर्मियों के साथ लंबे समय तक इस समस्या का अध्ययन करने के बाद, हम इस निष्कर्ष पर पहुँचे कि scalable per-message-key acknowledgment को support करने के लिए बुनियादी architecture बदलाव ज़रूरी है
    • architecture को sorted index चाहिए, जिसका मतलब है कि n messages को O(n log n) में प्रोसेस किया जाता है
    • मैं इस विषय पर blog लिखना चाहता था, लेकिन समय नहीं मिला
    • अगर आप per-message-key acknowledgment पर निर्भर होना चाहते हैं, तो बीच-बीच में रुकावट या latency की उम्मीद रखिए

  • NATS.io, Kafka की तुलना में उपयोग में आसान है, और partition हटाने, key-based stream support, और flexible topic hierarchy जैसी कई चीज़ें पहले ही हल कर चुका है

  • Kafka के साथ मेरा सफ़र भी ज़्यादातर ऐसा ही रहा

    • शुरुआत में लगा, "ओह, scalable append-only log, बढ़िया और सरल"
    • लेकिन इस्तेमाल करने पर पता चलता है कि यह बहुत जटिल है

  • कुछ खास use cases में, अगर create request के acknowledge होने तक यह गारंटी मिल जाए कि derived data view update हो चुका है, तो यह उपयोगी होगा

    • Kafka का उपयोग मत कीजिए, सीधे downstream data store में लिखिए
    • तब आपको पता होगा कि data commit हो चुका है, और आपके पास query करने लायक database होगा

  • मैंने 6 साल पहले यही सवाल पूछा था

    • क्यों न इसे Rust में लिखा जाए और WASM का उपयोग किया जाए
    • पिछले 6 साल से मैं इसी पर काम कर रहा हूँ
    • पिछले 2 साल से Rust और WASM का उपयोग करके Flink बना रहा हूँ

  • Kafka का object storage? इससे latency और cost 10 गुना बढ़ जाएगी

    • Kafka अपनी सफलता का शिकार है
    • design इतना सरल और elegant है कि इसका उपयोग बहुत से ऐसे कामों के लिए हो रहा है जिनके लिए इसे मूल रूप से डिज़ाइन नहीं किया गया था
    • बेशक, यह उन use cases के लिए परफ़ेक्ट नहीं है

  • "partition हटाने" और "key-level stream" के बारे में

    • जब storage backend physical partitioning पर निर्भर करता है, तो यह बस partition का नाम key और key का नाम event रख देने जैसा है

  • Northguard पर नज़र रखनी चाहिए

    • यह LinkedIn के Kafka rewrite का नाम है, जिसे लगभग एक हफ़्ता पहले एक stream processing meetup में प्रस्तुत किया गया था

  • सोचता हूँ कि Apache Kafka की कितनी समस्याएँ Apache Pulsar पर स्विच करने से हल हो जाती हैं

    • मैंने Kafka सीखना छोड़कर सीधे Pulsar इस्तेमाल किया
    • यह हमारे use case में अच्छी तरह फिट बैठता है
    • कोई शिकायत नहीं है
    • लेकिन हैरानी है कि इतने कम लोग इसका उपयोग क्यों करते हैं

  • यह एक उपयोगी thought experiment है

    • यह दिलचस्प है कि Kafka को किसी नई चीज़ से बदल देने का निष्कर्ष सुझाने वाले जवाब अपेक्षाकृत शांत हैं
    • Kafka की सबसे बड़ी ताकत उसके ऊपर बना व्यापक और उपयोगी ecosystem है
    • यही उसकी कमज़ोरी भी है
    • उसे कुछ ऐसे design decisions बनाए रखने पड़ते हैं, जो आज अगर शून्य से शुरू करते तो शायद नहीं किए जाते
    • नहीं तो backward compatibility छोड़नी पड़ेगी, और पहले से मौजूद ecosystem को फिर से बनाना पड़ेगा