Flink SQL अपनाने का अनुभव

 (hyperconnect.github.io)
3 पॉइंट द्वारा GN⁺ 2025-02-25 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Flink SQL अपनाने की पृष्ठभूमि

  • Azar Matching Dev Team द्वारा मैनेज किए जा रहे Flink-आधारित ऐप्स में एक भारी legacy ऐप था, जो 96 CPU का उपयोग करता था
  • यह ऐप कई फीचर्स को monolithic structure में लागू करता था, इसलिए इसका maintenance कठिन था
  • इंफ्रास्ट्रक्चर कार्य के दौरान execution node बदलने पर ऐप के सामान्य रूप से काम न करने की समस्या हुई
  • यह तय करना था कि ऊँची operational fatigue सहते हुए maintenance जारी रखा जाए, या इसे किसी दूसरे तरीके से बदला जाए

उपलब्ध विकल्प

  • मौजूदा ऐप की महत्वपूर्ण क्षमताएँ पहले ही नए Flink ऐप्स में लागू की जा चुकी थीं
  • conditional event publishing और logic execution वाले हिस्से को बदलने के तरीके पर विचार किया गया
    1. एक ही Flink App में लागू करना
      • फायदा: संचालन सरल
      • नुकसान: ऐप के बहुत बड़ा होने की संभावना, और एक हिस्से की विफलता का दूसरे फीचर्स पर असर पड़ना आसान
    2. कई Flink App में लागू करना
      • फायदा: स्वतंत्र रूप से मैनेज करना संभव
      • नुकसान: ऐप्स की संख्या बढ़ने पर बोझ बढ़ता है
    3. Flink SQL का उपयोग
      • फायदा: query से logic define किया जा सकता है, और केवल एक cluster मैनेज करना होता है
      • नुकसान: जटिल logic को व्यक्त करना कठिन, और cluster management का अनुभव न हो तो इसे चलाना मुश्किल

Flink SQL चुनने के कारण और वैकल्पिक तकनीकों से तुलना

  • Flink SQL अपनाने से पहले ksqlDB और Spark Structured Streaming की समीक्षा की गई
  • Flink SQL चुनने के कारण:
    1. High Availability
      • Checkpoint और Savepoint के जरिए ऐप की state को स्थिर रूप से सेव और restore किया जा सकता है
      • JobManager को HA mode में कॉन्फ़िगर किया जा सकता है
    2. उन्नत streaming फीचर्स का समर्थन
      • SQL syntax के माध्यम से streaming processing की विभिन्न क्षमताओं का समर्थन
      • window, join, event time processing, watermark आदि का समर्थन
    3. UDF और Custom Connector के जरिए extensibility
      • user-defined functions तथा विभिन्न data sources और sink को जोड़ा जा सकता है

vs ksqlDB

  • यह Confluent platform में शामिल है, लेकिन stateful streaming processing में HA behavior अप्रभावी है

vs Spark Structured Streaming

  • यह Spark SQL engine पर आधारित है, और UDF तथा Custom Sink लिखे जा सकते हैं
  • micro-batch इकाइयों में चलने के कारण real-time processing में यह कम अनुकूल हो सकता है

cluster environment सेटअप और query deployment का तरीका

लोकल में सरल परीक्षण

  • लोकल में Flink Cluster चलाकर SQL query submit करने की विधि का परिचय

production environment में cluster architecture

  • Kubernetes पर Flink SQL Cluster का निर्माण
  • Application mode और Session mode की तुलना

GitOps तरीके से query deployment

  • GitHub Actions का उपयोग करके query deployment और Job stop लागू किया गया

प्रमुख operation केस और troubleshooting अनुभव

जब JobManager या TaskManager fail हो जाए

  • HA configuration के कारण JobManager fail होने पर भी काम जारी रह सकता है
  • TaskManager fail होने पर काम redistribute होकर जारी रहता है

जब query fail हो जाए

  • असामान्य data input या computing resources की कमी होने पर ऐसा हो सकता है
  • JSON format error को ignore करने और default values सेट करने की सुविधा उपलब्ध है

cluster restart के समय कुछ Job fail हो जाएँ

  • timeout और retry settings में बदलाव की आवश्यकता हो सकती है

जब query की किसी एक शर्त को बदलकर फिर से deploy करना हो

  • केवल सरल बदलावों में savepoint का उपयोग करके state restore किया जा सकता है

प्रमुख monitoring points

  • numRunningJobs, taskmanager.cpu.load, taskmanager.memory.used जैसे metrics की जाँच

अंत में

  • Flink SQL अपनाने से productivity और operational efficiency में सुधार हुआ
  • इसकी stability उत्कृष्ट है, और GitOps Controller pattern लागू करने की योजना है

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

1 टिप्पणियां

 
flgkselql98 2025-02-26

ऐसा लगता है कि flink जैसे distributed systems में 2~3 rack बनाए रखकर HA बनाए रखना पड़ता है, लेकिन Kubernetes को जोड़कर HA सुनिश्चित किया गया है। लेकिन आखिरकार kube slave node के resources पर भी विचार करना होगा, तो सोचता हूँ कि क्या उन्होंने सिर्फ flink चलाने वाले nodes बनाए हैं (flink पर load बढ़ने पर slave node down होने की समस्या हो सकती है)।
उस नज़रिए से Kubernetes इस्तेमाल करने का फ़ायदा क्या होगा?

साथ ही, flink में window function इस्तेमाल करने पर उस दौरान data memory में बना रहता है और उसी से SQL join statement काम करता है। trade-off के नज़रिए से देखें तो क्या flink वाकई अच्छा विकल्प है, यह सोचने वाली बात है। समय के साथ बहुत बड़ा होता जाने वाला SQL + job अगर मर जाए तो उससे पैदा होने वाली भारी समस्या...

मैं भी सोच रहा हूँ कि जब सबसे ऊपर वाले data source पर join की ज़रूरत हो, तब flink का इस्तेमाल किए बिना किस तरह इसे application level पर नीचे लाकर process किया जा सकता है।