मार्गदर्शिका

निरंतर, उच्च-मात्रा वाले डेटा को आने के कुछ ही मिनटों के भीतर विश्लेषण की आवश्यकता होती है।

→इन्जेस्ट करने के लिए Pub/Sub -> ट्रांसफॉर्मेशन के लिए Dataflow (स्ट्रीमिंग) -> विश्लेषण के लिए स्ट्रीमिंग इन्सर्ट या Storage Write API के साथ BigQuery।

क्यों: यह कैननिकल सर्वरलेस, ऑटोस्केलिंग स्ट्रीमिंग पैटर्न है। बैच प्रोसेसिंग (जैसे, Dataproc) कम-विलंबता आवश्यकताओं को पूरा नहीं कर पाएगा।

डेटा पाइपलाइन को अप्रत्याशित ट्रैफिक स्पाइक्स (जैसे, 10 गुना मौसमी वॉल्यूम) को कम विलंबता बनाए रखते हुए संभालना चाहिए।

→पूरी तरह से प्रबंधित, ऑटोस्केलिंग सेवाओं का उपयोग करें: इन्जेस्ट करने के लिए Pub/Sub, ऑटोस्केलिंग सक्षम के साथ Dataflow, और स्टोरेज के लिए BigQuery।

क्यों: प्रबंधित सेवाएं लोड से मेल खाने के लिए संसाधनों को स्वचालित रूप से स्केल करती हैं, जिससे ओवर-प्रोविजनिंग लागत से बचा जा सकता है और पीक ट्रैफिक के तहत प्रदर्शन सुनिश्चित होता है।

एक बड़े ऑन-प्रिमाइसेस Hadoop/Hive डेटा वेयरहाउस को Google Cloud में माइग्रेट करें।

→डेटा को Cloud Storage में माइग्रेट करें, फिर BigQuery में लोड करें। सर्वरलेस एनालिटिक्स के लिए Hive/Spark SQL को BigQuery से बदलें। उन Spark नौकरियों के लिए Dataproc का उपयोग करें जिन्हें SQL में आसानी से ट्रांसलेट नहीं किया जा सकता है।

क्यों: BigQuery Hadoop डेटा वेयरहाउस के लिए एक सर्वरलेस, उच्च-प्रदर्शन प्रतिस्थापन प्रदान करता है, जिससे परिचालन ओवरहेड कम होता है।

एक स्ट्रीमिंग पाइपलाइन को प्रत्येक इकाई (जैसे, प्रति स्टॉक सिंबल) के लिए संदेशों को ठीक एक बार और क्रम में संसाधित करने की आवश्यकता होती है।

→ऑर्डरिंग कुंजी के साथ Pub/Sub पर संदेश प्रकाशित करें। Dataflow स्ट्रीमिंग पाइपलाइन के साथ प्रोसेस करें, जो दी गई कुंजी के लिए इन-ऑर्डर प्रोसेसिंग की गारंटी देता है।

क्यों: Dataflow के साथ संयुक्त Pub/Sub ऑर्डरिंग कुंजियाँ मैन्युअल स्थिति प्रबंधन के बिना प्रबंधित, स्केलेबल, ऑर्डर की गई और ठीक एक बार की प्रोसेसिंग प्रदान करती हैं।

संदर्भ↗

डेटा गवर्नेंस के साथ बैच और स्ट्रीमिंग दोनों वर्कलोड का समर्थन करने के लिए एक लचीला, स्केलेबल डेटा लेक बनाएं।

→स्टोरेज लेयर के रूप में Cloud Storage का उपयोग करें। बैच और स्ट्रीम प्रोसेसिंग दोनों के लिए Dataflow का उपयोग करें। मेटाडेटा प्रबंधन, खोज और गवर्नेंस के लिए Data Catalog के साथ Dataplex का उपयोग करें।

क्यों: यह आर्किटेक्चर स्टोरेज और कंप्यूट को डीकपल करता है, जिससे एक एकीकृत गवर्नेंस के साथ एक केंद्रीय डेटा स्टोर पर कई प्रोसेसिंग इंजनों (Dataflow, Dataproc) का उपयोग किया जा सकता है।

संवेदनशील डेटा (जैसे, PHI, PII) को संसाधित करने वाली पाइपलाइन को HIPAA या GDPR जैसे विनियमों का पालन करना चाहिए।

→सभी डेटा एक्सेस के लिए Cloud Audit Logs सक्षम करें। डेटा एक्सफ़िल्ट्रेशन को रोकने के लिए एक सुरक्षा परिधि बनाने के लिए VPC Service Controls लागू करें।

क्यों: ऑडिट लॉगिंग अनुपालन के लिए डेटा एक्सेस को ट्रैक करने के लिए महत्वपूर्ण है। VPC Service Controls डेटा एक्सफ़िल्ट्रेशन के खिलाफ एक मजबूत बचाव प्रदान करते हैं, जो संवेदनशील डेटा के लिए एक प्रमुख आवश्यकता है।

अलग-अलग बैच और स्पीड लेयर के साथ एक लैम्ब्डा आर्किटेक्चर को डेटा का एक एकीकृत दृश्य प्रस्तुत करने की आवश्यकता है।

→सर्विंग लेयर के लिए BigQuery का उपयोग करें। एक मास्टर टेबल में बैच-प्रोसेस्ड डेटा को अपडेट/इन्सर्ट करने के लिए `MERGE` स्टेटमेंट का उपयोग करें, उसी अवधि के लिए स्ट्रीमिंग डेटा को ओवरराइट करें। एक व्यू को उजागर करें जो वर्तमान अवधि के लिए ऐतिहासिक बैच डेटा को रियल-टाइम स्ट्रीमिंग डेटा के साथ `UNION` करता है।

क्यों: यह पैटर्न क्लाइंट-साइड सामंजस्य लॉजिक की आवश्यकता के बिना कम-विलंबता वाले रियल-टाइम दृश्य और बैच-सुधारित ऐतिहासिक सटीकता दोनों प्रदान करता है।

एक विकेन्द्रीकृत डेटा मेश आर्किटेक्चर लागू करें जहां डोमेन अपने डेटा उत्पादों के मालिक हों।

→डोमेन-विशिष्ट "लेक्स" और "ज़ोन" पर फेडरेटेड गवर्नेंस के लिए Dataplex का उपयोग करें। प्रति डोमेन BigQuery डेटासेट का उपयोग करें। डोमेन के बीच डेटा उत्पादों को साझा करने के लिए Analytics Hub का उपयोग करें।

क्यों: Dataplex केंद्रीय गवर्नेंस प्लेन प्रदान करता है जबकि डोमेन स्वायत्तता की अनुमति देता है, जो डेटा मेश का एक मुख्य सिद्धांत है।

एक डेटा लेक और डेटा वेयरहाउस को मिलाएं, जिससे कच्चे डेटा पर Spark जॉब्स और क्यूरेटेड डेटा पर तेज़ SQL की अनुमति मिलती है।

→Cloud Storage पर खुले फॉर्मेट (Iceberg, Delta Lake) में डेटा स्टोर करें। एक एकीकृत गवर्नेंस और एक्सेस लेयर प्रदान करने के लिए BigLake का उपयोग करें। Dataproc (Spark) और BigQuery दोनों से डेटा क्वेरी करें।

क्यों: BigLake BigQuery प्रदर्शन और बारीक सुरक्षा के साथ Cloud Storage पर डेटा को इन-प्लेस क्वेरी करने की अनुमति देता है, जिससे लेक और वेयरहाउस एकीकृत होते हैं।

कम RPO (जैसे, 1 घंटा) वाले एक महत्वपूर्ण BigQuery डेटा वेयरहाउस के लिए आपदा रिकवरी रणनीति डिज़ाइन करें।

→महत्वपूर्ण डेटासेट के लिए BigQuery क्रॉस-रीजन डेटासेट रेप्लिकेशन कॉन्फ़िगर करें। स्कीमा और व्यू परिभाषाओं को प्रबंधित करने के लिए Terraform या Dataform का उपयोग करें। Cloud Monitoring अलर्ट द्वारा ट्रिगर किए गए Cloud Functions के साथ फ़ेलओवर ऑर्केस्ट्रेट करें।

क्यों: क्रॉस-रीजन रेप्लिकेशन DR क्षेत्र में लगातार अपडेट की गई, क्वेरी करने योग्य कॉपी प्रदान करता है, जो महत्वपूर्ण डेटा के लिए कम RPO/RTO आवश्यकताओं को पूरा करता है।

कम विलंबता के साथ एक OLTP डेटाबेस (जैसे, Oracle, PostgreSQL, MySQL) से BigQuery में परिवर्तनों को लगातार दोहराएं (replicate)।

→Change Data Capture (CDC) करने के लिए Datastream का उपयोग करें। इसे सीधे BigQuery पर परिवर्तनों को स्ट्रीम करने के लिए कॉन्फ़िगर करें, जो अपनी `MERGE` क्षमता का उपयोग करके उन्हें लागू करता है।

क्यों: Datastream एक प्रबंधित, सर्वरलेस CDC सेवा है जो कस्टम पाइपलाइन या महत्वपूर्ण स्रोत डेटाबेस लोड की आवश्यकता के बिना रियल-टाइम डेटाबेस रेप्लिकेशन को सरल बनाती है।

संदर्भ↗

एक Dataflow स्ट्रीमिंग पाइपलाइन को सटीक इवेंट-टाइम विंडो वाले परिणाम उत्पन्न करने चाहिए, भले ही कुछ इवेंट घंटों देर से आएं।

→विलंब को समायोजित करने के लिए `allowedLateness` के साथ इवेंट-टाइम विंडोज़ कॉन्फ़िगर करें। प्रारंभिक परिणामों के लिए शुरुआती फ़ायरिंग और देर से आए डेटा को शामिल करने के लिए संचित फ़ायर्ड पेन्स के साथ ट्रिगर्स का उपयोग करें।

क्यों: Dataflow का वॉटरमार्क, ट्रिगर्स और अनुमत विलंब का मॉडल आउट-ऑफ-ऑर्डर डेटा से निपटने के दौरान पूर्णता और विलंबता को संतुलित करने के लिए एक मजबूत ढांचा प्रदान करता है।

BigQuery में लिखने वाली एक Dataflow पाइपलाइन को रीस्टार्ट या क्षणिक विफलताओं के बाद डुप्लिकेट का अनुभव होता है।

→BigQuery Storage Write API सिंक (`STORAGE_WRITE_API`) का उपयोग करें जिसमें विधि को `at-least-once` (डिफ़ॉल्ट, पहले `STREAMING_INSERTS`) या `exactly-once` (`COMMITTED` मोड) पर सेट किया गया हो।

क्यों: `COMMITTED` मोड में Storage Write API स्ट्रीमिंग के लिए बिल्ट-इन `exactly-once` सिमेंटिक्स प्रदान करता है, जिससे कस्टम deduplication लॉजिक की आवश्यकता समाप्त हो जाती है।

Dataflow का उपयोग करके एक पेजिनटेड, रेट-लिमिटेड REST API से डेटा इन्जेस्ट करें।

→पेजिनटेड स्रोत को समानांतर में प्रोसेस करने के लिए `SplittableDoFn` का उपयोग करें। DoFn के भीतर रिट्री के लिए रेट-लिमिटिंग लॉजिक (जैसे, Guava RateLimiter का उपयोग करके) और एक्सपोनेंशियल बैकऑफ़ लागू करें।

क्यों: एक `SplittableDoFn` गतिशील कार्य पुनर्संतुलन की अनुमति देता है। इसे रेट-लिमिटिंग और रिट्री लॉजिक के साथ संयोजित करने से बाहरी API को संभालने के लिए एक लचीला और कुशल पैटर्न बनता है।

एक सिंगल डेटा स्ट्रीम को कई गंतव्यों (जैसे, BigQuery, Bigtable, Cloud Storage) पर लिखने की आवश्यकता है।

→एक सिंगल Dataflow पाइपलाइन में, प्रारंभिक प्रोसेसिंग के बाद, उसी अंतिम `PCollection` पर कई `PTransform` राइटर लागू करें।

क्यों: फैन-आउट पैटर्न अत्यधिक कुशल है क्योंकि डेटा को केवल एक बार प्रोसेस किया जाता है। यह एक ही स्रोत से पढ़ने वाली कई अलग-अलग पाइपलाइनों को चलाने की लागत और जटिलता से बचाता है।

एक उच्च-मात्रा वाली स्ट्रीम को धीरे-धीरे बदलने वाले आयाम तालिका (जैसे, उपयोगकर्ता प्रोफाइल) के साथ जुड़कर समृद्ध किया जाना चाहिए जो समय-समय पर अपडेट होती है।

→Dataflow में साइड इनपुट पैटर्न का उपयोग करें। आयाम तालिका को `PCollectionView` के रूप में लोड करें। पाइपलाइन रीस्टार्ट को रोकने के लिए, एक शेड्यूल पर साइड इनपुट को रीफ़्रेश करने के लिए एक आवधिक ट्रिगर कॉन्फ़िगर करें।

क्यों: साइड इनपुट तेज़ इन-मेमोरी लुकअप के लिए सभी वर्करों को आयाम डेटा प्रसारित करते हैं, प्रति-एलिमेंट API/DB कॉल से बचते हैं। आवधिक रीफ़्रेश अपडेट को कुशलता से संभालता है।

Dataproc क्लस्टर वर्कलोड्स में काफी भिन्नता होती है, जिससे या तो अत्यधिक प्रावधान (over-provisioning) या कम प्रदर्शन होता है।

→एक ऑटोस्केलिंग नीति के साथ एक Dataproc क्लस्टर बनाएं। न्यूनतम/अधिकतम प्राथमिक और माध्यमिक वर्कर गणना परिभाषित करें। नीति YARN मेट्रिक्स के आधार पर क्लस्टर को स्केल करेगी।

क्यों: ऑटोस्केलिंग क्लस्टर संसाधनों को नौकरी की मांग से मिलाकर लागतों को अनुकूलित करता है, भारी लोड के लिए स्केल अप करता है और निष्क्रिय अवधि के दौरान स्केल डाउन करता है।

एक Dataflow पाइपलाइन को कस्टम बाइनरीज़, प्रोप्राइटरी लाइब्रेरीज़, या मानक वर्कर इमेज में नहीं होने वाले विशिष्ट संस्करणों की आवश्यकता होती है, और इसे बिना इंटरनेट के VPC में चलना चाहिए।

→सभी डिपेंडेंसी प्री-इंस्टॉल के साथ एक कस्टम कंटेनर इमेज बनाएं। इमेज को Artifact Registry पर पुश करें। कस्टम कंटेनर को संदर्भित करने वाले Flex Template का उपयोग करके पाइपलाइन को डिप्लॉय करें।

क्यों: कस्टम कंटेनरों वाले Flex Templates रनटाइम वातावरण और डिपेंडेंसी पर पूर्ण नियंत्रण प्रदान करते हैं, जो ऑफ़लाइन या विशेष वातावरण के लिए महत्वपूर्ण है।

एक Dataflow या Spark जॉब जो `GroupByKey` कर रहा है वह धीमा है क्योंकि कुछ कुंजियों में असंगत रूप से कई मान होते हैं ("हॉट कुंजी")।

→दो-चरण एकत्रीकरण (कुंजी सॉल्टिंग) लागू करें। सबसे पहले, हॉट कुंजी को कई वर्करों में विभाजित करने के लिए कुंजी में एक रैंडम सफ़िक्स जोड़ें। आंशिक रूप से एकत्रित करें। दूसरा, सफ़िक्स हटा दें और आंशिक परिणामों को एकत्रित करें।

क्यों: यह फैनआउट तकनीक मैन्युअल रूप से हॉट कुंजी के लिए काम को तोड़ती है, जिससे इसे समानांतर में संसाधित किया जा सकता है और बॉटलनेक को दूर किया जा सकता है।

एक स्ट्रीमिंग पाइपलाइन को गलत फॉर्मेट वाले रिकॉर्ड के कारण विफल नहीं होना चाहिए। अमान्य रिकॉर्ड को प्रोसेसिंग को रोके बिना विश्लेषण के लिए अलग किया जाना चाहिए।

→एक `DoFn` में, पार्सिंग के लिए एक try-catch ब्लॉक का उपयोग करें। मुख्य आउटपुट पर वैध रिकॉर्ड और अलग त्रुटि आउटपुट पर अमान्य रिकॉर्ड (त्रुटि संदर्भ के साथ) को रूट करने के लिए `TupleTag` के साथ एक मल्टी-आउटपुट DoFn का उपयोग करें। त्रुटि PCollection को एक dead-letter गंतव्य जैसे Pub/Sub टॉपिक या BigQuery टेबल पर सिंक करें।

क्यों: यह पैटर्न खराब डेटा को अलग करके, पाइपलाइन विफलताओं को रोककर, और डिबगिंग और रीप्रोसेसिंग के लिए विफल रिकॉर्ड कैप्चर किए जाने को सुनिश्चित करके लचीलापन प्रदान करता है।

BigQuery क्वेरी धीमी और महंगी हैं, आमतौर पर एक दिनांक/समय कॉलम और अन्य उच्च-कार्डिनैलिटी कॉलम (जैसे, `customer_id`) पर फ़िल्टरिंग होती है।

→दिनांक/समय कॉलम (जैसे, दैनिक विभाजन) द्वारा तालिका को विभाजित करें। तालिका को चार तक बार-बार फ़िल्टर किए गए कॉलम (जैसे, `customer_id`, `product_category`) द्वारा क्लस्टर करें।

क्यों: पार्टीशनिंग केवल प्रासंगिक समय अवधियों के लिए स्कैन किए गए डेटा को छाँटता है। क्लस्टरिंग आगे विभाजन के भीतर डेटा को सॉर्ट करता है, जिससे क्लस्टर किए गए कॉलम पर फ़िल्टर के लिए स्कैन किए गए डेटा को कम किया जा सकता है। यह प्राथमिक BQ प्रदर्शन ट्यूनिंग पैटर्न है।

संदर्भ↗

एप्लिकेशन को बड़े डेटासेट (अरबों पंक्तियों) के लिए कम-विलंबता (उप-10ms) रीड और राइट्स की आवश्यकता होती है, जैसे रियल-टाइम वैयक्तिकरण या IoT फ़ीचर स्टोर के लिए।

→Bigtable का उपयोग करें। एक row key डिज़ाइन करें जो प्राथमिक एक्सेस पैटर्न का समर्थन करता हो। टाइम-सीरीज़ के लिए, `entity_id#reverse_timestamp` का उपयोग करें।

क्यों: Bigtable एक NoSQL वाइड-कॉलम स्टोर है जो बड़े पैमाने पर उच्च-थ्रूपुट, कम-विलंबता वर्कलोड के लिए अनुकूलित है। BigQuery एनालिटिक्स के लिए है और इसमें उच्च पॉइंट-लुकअप विलंबता है।

एक ट्रांजैक्शनल एप्लिकेशन को SQL इंटरफ़ेस के साथ वैश्विक वितरण, क्षैतिज स्केलेबिलिटी और मजबूत स्थिरता की आवश्यकता होती है।

→मल्टी-रीजन कॉन्फ़िगरेशन के साथ Cloud Spanner का उपयोग करें।

क्यों: Spanner एकमात्र सेवा है जो ये सभी क्षमताएं प्रदान करती है: वैश्विक रूप से वितरित, ACID लेनदेन, और एक रिलेशनल स्कीमा। Cloud SQL क्षेत्रीय है; Bigtable रिलेशनल नहीं है और क्लस्टर के बीच अंततः स्थिरता (eventual consistency) है।

एक BigQuery डेटा वेयरहाउस में बड़ी मात्रा में ऐतिहासिक डेटा होता है जिसे शायद ही कभी क्वेरी किया जाता है लेकिन इसे बनाए रखना आवश्यक है, जिससे उच्च स्टोरेज लागत आती है।

→90 लगातार दिनों तक अपरिवर्तित रहे विभाजन/तालिकाओं के लिए किसी कार्रवाई की आवश्यकता नहीं है। BigQuery स्वचालित रूप से long-term storage pricing लागू करता है, जिससे लगभग 50% लागत कम होती है।

क्यों: यह एक स्वचालित, बिल्ट-इन ऑप्टिमाइजेशन है। मैन्युअल रूप से डेटा को GCS में ले जाना (जब तक कि Archive टियर के लिए न हो) अक्सर अनावश्यक होता है और जटिलता बढ़ाता है।

Cloud Storage बकेट में डेटा का एक अनुमानित एक्सेस पैटर्न होता है: 30 दिनों के लिए बार-बार, 90 दिनों के लिए कभी-कभी, फिर दुर्लभ।

→ऑब्जेक्ट्स को ट्रांजिशन करने के लिए एक बकेट लाइफसाइकिल पॉलिसी कॉन्फ़िगर करें: Standard -> Nearline (30 दिनों में) -> Coldline (90 दिनों में)।

क्यों: लाइफसाइकिल पॉलिसी डेटा को सस्ता स्टोरेज क्लासेस में स्थानांतरित करके लागत ऑप्टिमाइजेशन को स्वचालित करती है क्योंकि इसे कम बार एक्सेस किया जाता है।

एक BigQuery तालिका को एक unique key constraint लागू करना चाहिए।

→लोडिंग पाइपलाइन में विशिष्टता लागू करें। ऐसे लॉजिक के साथ एक `MERGE` स्टेटमेंट का उपयोग करें जो केवल तभी इन्सर्ट करता है जब कुंजी पहले से मौजूद न हो। वैकल्पिक रूप से, डुप्लिकेशन हटाने के लिए Dataflow में एक स्टेटफुल DoFn का उपयोग करें।

क्यों: BigQuery `PRIMARY KEY` या `UNIQUE` कंस्ट्रेंट लागू नहीं करता है। विशिष्टता को डेटा लोडिंग प्रक्रिया द्वारा प्रबंधित किया जाना चाहिए।

BigQuery में एक आयाम तालिका को पॉइंट-इन-टाइम विश्लेषण (SCD Type 2) के लिए परिवर्तनों का पूरा इतिहास बनाए रखने की आवश्यकता है।

→`valid_from` और `valid_to` टाइमस्टैम्प कॉलम जोड़ें। जब कोई परिवर्तन होता है, तो पुराने रिकॉर्ड पर `valid_to` को अपडेट करने और एक नया रिकॉर्ड इन्सर्ट करने के लिए `MERGE` स्टेटमेंट का उपयोग करें।

क्यों: यह डेटा वेयरहाउस में SCD Type 2 को लागू करने का मानक पैटर्न है। `MERGE` आवश्यक अपडेट और इन्सर्ट ऑपरेशंस करने का एक कुशल, परमाणु तरीका प्रदान करता है।

एक एप्लिकेशन को ट्रांजैक्शनल सपोर्ट और जटिल क्वेरी आवश्यकताओं के साथ लचीले-स्कीमा JSON डॉक्यूमेंट्स के लिए एक प्रबंधित, स्केलेबल डेटाबेस की आवश्यकता होती है।

→नेटिव मोड में Firestore का उपयोग करें। डेटा को मॉडल करने के लिए कलेक्शन, डॉक्यूमेंट्स और सबकलेक्शन का उपयोग करें। जटिल क्वेरी के लिए कंपोजिट इंडेक्स बनाएं।

क्यों: Firestore एक सर्वरलेस NoSQL डॉक्यूमेंट डेटाबेस है जो रिच क्वेरी क्षमताओं के साथ ट्रांजैक्शनल वर्कलोड के लिए अनुकूलित है, Bigtable (की-वैल्यू) या BigQuery (विश्लेषणात्मक) के विपरीत।

बारीक-दानेदार (रो/कॉलम) सुरक्षा लागू करते हुए BigQuery के माध्यम से Cloud Storage (Parquet, Avro, आदि) में डेटा को क्वेरी करने की आवश्यकता है।

→Cloud Storage डेटा पर BigLake टेबल बनाएं। BigLake तालिकाओं पर BigQuery रो-लेवल और कॉलम-लेवल सुरक्षा नीतियां लागू करें।

क्यों: BigLake BigQuery गवर्नेंस को Cloud Storage में खुले-फॉर्मेट डेटा तक विस्तारित करता है, जिससे एक सुरक्षित, एकीकृत डेटा लेकहाउस आर्किटेक्चर सक्षम होता है।

एक डेटा साइंस टीम को डेटा को स्थानांतरित या निर्यात किए बिना बड़े BigQuery डेटासेट पर ML मॉडल को प्रशिक्षित करने की आवश्यकता है।

→BigQuery ML का उपयोग करें। BigQuery के भीतर सीधे प्रशिक्षित करने, मूल्यांकन करने और भविष्यवाणी करने के लिए SQL में `CREATE MODEL` स्टेटमेंट लिखें।

क्यों: BQML डेटा आंदोलन को समाप्त करता है, ML वर्कफ़्लो को सरल बनाता है, और BigQuery की प्रोसेसिंग शक्ति का लाभ उठाता है, जिससे पुनरावृति में तेजी आती है।

संदर्भ↗

ML मॉडल को बैच प्रशिक्षण और कम-विलंबता ऑनलाइन इन्फरेंस दोनों के लिए सुविधाओं की आवश्यकता होती है, उनके बीच स्थिरता के साथ ताकि तिरछापन से बचा जा सके।

→Vertex AI Feature Store का उपयोग करें। बैच या स्ट्रीमिंग के माध्यम से सुविधाओं को इन्जेस्ट करें। यह प्रशिक्षण के लिए एक ऑफ़लाइन स्टोर (BigQuery) और कम-विलंबता सर्विंग के लिए एक ऑनलाइन स्टोर (Bigtable) प्रदान करता है।

क्यों: यह एक उद्देश्य-निर्मित, प्रबंधित सेवा है जो फ़ीचर स्थिरता, पॉइंट-इन-टाइम शुद्धता, और दोहरी-सर्विंग आवश्यकताओं की जटिल समस्या को हल करती है।

व्यवसाय उपयोगकर्ताओं को सेल्फ-सर्विस BI की आवश्यकता होती है, लेकिन डेटा वेयरहाउस को सीधे क्वेरी करते समय असंगत मेट्रिक्स और रिपोर्ट बनाते हैं।

→LookML का उपयोग करके एक Looker सिमेंटिक लेयर लागू करें। आयाम, उपाय और जॉइन एक बार परिभाषित करें। उपयोगकर्ता कच्चे तालिकाओं के बजाय शासित मॉडल का अन्वेषण करते हैं।

क्यों: LookML व्यावसायिक लॉजिक के लिए एक "सिंगल सोर्स ऑफ़ ट्रुथ" प्रदान करता है, जो सेल्फ-सर्विस अन्वेषण की अनुमति देते हुए सुसंगत और सटीक रिपोर्टिंग सुनिश्चित करता है।

BigQuery और Cloud Storage में डेटा के लिए स्वचालित डेटा गुणवत्ता जांच (नल्स, विशिष्टता, मान रेंज) और निगरानी लागू करने की आवश्यकता है।

→Dataplex Data Quality का उपयोग करें। YAML में नियम परिभाषित करें या प्रोफाइलिंग से स्वतः-जनरेटेड नियमों का उपयोग करें। समय के साथ गुणवत्ता की निगरानी के लिए स्कैन शेड्यूल करें।

क्यों: Dataplex एक प्रबंधित, एकीकृत डेटा गुणवत्ता समाधान प्रदान करता है जो कस्टम SQL जांचों या स्क्रिप्ट की तुलना में अधिक स्केलेबल और रखरखाव योग्य है।

पूर्वनिर्धारित लेबल के बिना ग्राहक डेटासेट के भीतर प्राकृतिक समूहीकरण या सेगमेंट खोजें।

→ग्राहक डेटा पर सीधे `KMEANS` क्लस्टरिंग मॉडल को प्रशिक्षित करने के लिए BigQuery ML का उपयोग करें।

क्यों: K-means सेगमेंटेशन के लिए एक आदर्श अनसुपरवाइज्ड लर्निंग एल्गोरिथम है। BQML डेटा निर्यात के बिना SQL के माध्यम से इसे सुलभ बनाता है।

BigQuery में संग्रहीत टेक्स्ट डेटा पर सिमेंटिक खोज (अर्थ पर आधारित, कीवर्ड पर नहीं) सक्षम करें।

→वेक्टर एम्बेडिंग बनाने के लिए Vertex AI foundation model के साथ `ML.GENERATE_EMBEDDING` फ़ंक्शन का उपयोग करें। उन्हें स्टोर करें और समानता खोज के लिए `VECTOR_SEARCH` फ़ंक्शन का उपयोग करें।

क्यों: यह पैटर्न शक्तिशाली सिमेंटिक खोज क्षमताओं को सीधे BigQuery में लाता है, जिससे Elasticsearch जैसे बाहरी खोज इंडेक्स की आवश्यकता समाप्त हो जाती है।

BigQuery एनालिटिक्स वर्कफ़्लो में सीधे टेक्स्ट संक्षेपण या वर्गीकरण जैसी Large Language Model (LLM) क्षमताओं को एकीकृत करें।

→एक BigQuery ML रिमोट मॉडल बनाएं जो Vertex AI LLM एंडपॉइंट को इंगित करता हो। टेक्स्ट डेटा को प्रोसेस करने के लिए SQL क्वेरी के भीतर `ML.GENERATE_TEXT` फ़ंक्शन का उपयोग करें।

क्यों: यह जनरेटिव AI को SQL में कसकर एकीकृत करता है, जिससे विश्लेषकों को BigQuery वातावरण छोड़े बिना या जटिल एप्लिकेशन कोड लिखे बिना अपने डेटा पर LLM का लाभ उठाने की अनुमति मिलती है।

एक बहु-चरणीय डेटा पाइपलाइन में विभिन्न GCP सेवाओं (जैसे, Dataflow, BigQuery, Dataproc) में जटिल डिपेंडेंसी, रिट्री और टास्क शामिल होते हैं।

→Cloud Composer (प्रबंधित Apache Airflow) का उपयोग करें। Python का उपयोग करके वर्कफ़्लो को एक Directed Acyclic Graph (DAG) के रूप में परिभाषित करें।

क्यों: Composer जटिल वर्कफ़्लो ऑर्केस्ट्रेशन के लिए डिज़ाइन किया गया GCP टूल है, जो मजबूत डिपेंडेंसी प्रबंधन, शेड्यूलिंग, रिट्री लॉजिक और निगरानी प्रदान करता है जो Cloud Scheduler जैसे सरल टूल में कमी है।

एक Airflow DAG टास्क जो एक बाहरी API को कॉल करता है वह क्षणिक नेटवर्क समस्याओं के कारण अक्सर विफल हो जाता है।

→`retry_exponential_backoff=True` के साथ DAG में टास्क-लेवल रिट्री कॉन्फ़िगर करें। यह रिट्री के बीच के विलंब को बढ़ाता है, जिससे बाहरी सिस्टम को ठीक होने का समय मिलता है।

क्यों: एक्सपोनेंशियल बैकऑफ़ क्षणिक विफलताओं को फिर से प्रयास करने के लिए एक सर्वोत्तम अभ्यास है, क्योंकि यह तेजी से, बार-बार अनुरोधों के साथ संघर्षरत डाउनस्ट्रीम सिस्टम को अभिभूत करने से बचाता है।

BigQuery में इंटरडिपेंडेंट SQL ट्रांसफॉर्मेशन के एक जटिल सेट को प्रबंधित करें, वर्ज़न करें, परीक्षण करें और शेड्यूल करें।

→Dataform का उपयोग करें। SQLX फ़ाइलों में टेबल और डिपेंडेंसी परिभाषित करें, वर्ज़न कंट्रोल के लिए Git का उपयोग करें, डेटा गुणवत्ता अभिकथन लिखें, और निष्पादन वर्कफ़्लो शेड्यूल करें।

क्यों: Dataform ELT के लिए Google Cloud का नेटिव सॉल्यूशन है, जो BigQuery ट्रांसफॉर्मेशन के लिए डिपेंडेंसी प्रबंधन, परीक्षण और वर्ज़न कंट्रोल प्रदान करता है, जिससे DataOps सर्वोत्तम प्रथाओं को बढ़ावा मिलता है।

यह समझने और विज़ुअलाइज़ करने की आवश्यकता है कि BigQuery और Dataflow जैसी कई सेवाओं में डेटा स्रोत से अंतिम रिपोर्ट तक कैसे प्रवाहित होता है।

→Dataplex का उपयोग करें, जो Data Catalog UI में समर्थित Google Cloud सेवाओं से डेटा लीनिएज को स्वचालित रूप से कैप्चर और प्रदर्शित करता है।

क्यों: प्रभाव विश्लेषण, डीबगिंग और गवर्नेंस के लिए स्वचालित लीनिएज ट्रैकिंग महत्वपूर्ण है। Dataplex एकीकृत सेवाओं के लिए यह आउट-ऑफ-द-बॉक्स प्रदान करता है।

एक चल रहे Dataflow स्ट्रीमिंग जॉब को डेटा या स्थिति खोए बिना नए लॉजिक के साथ अपडेट करने की आवश्यकता है।

→चल रहे पाइपलाइन के जॉब ID को निर्दिष्ट करते हुए `--update` कमांड-लाइन विकल्प का उपयोग करके नया पाइपलाइन संस्करण लॉन्च करें। पुराने जॉब को इन-फ़्लाइट डेटा को प्रोसेस करना समाप्त करने की अनुमति देने के लिए `drain` मोड का उपयोग करें।

क्यों: Dataflow का इन-प्लेस अपडेट मैकेनिज्म स्ट्रीमिंग पाइपलाइनों में परिवर्तनों को डिप्लॉय करने का एक शून्य-डाउनटाइम तरीका प्रदान करता है, जबकि स्थिति को संरक्षित करता है और `exactly-once` प्रोसेसिंग की गारंटी देता है।

अनुपालन के लिए, BigQuery और Cloud Storage में संवेदनशील डेटा तक सभी रीड और राइट एक्सेस को लॉग और ऑडिट करने योग्य होना चाहिए।

→प्रासंगिक सेवाओं के लिए Cloud Audit Logs, विशेष रूप से Data Access logs सक्षम करें। दीर्घकालिक प्रतिधारण और विश्लेषण के लिए इन लॉग को BigQuery में निर्यात करने के लिए एक लॉग सिंक बनाएं।

क्यों: Cloud Audit Logs डेटा एक्सेस का एक छेड़छाड़-प्रूफ, व्यापक रिकॉर्ड प्रदान करते हैं। BigQuery में लॉग को सिंक करने से शक्तिशाली SQL-आधारित ऑडिटिंग और रिपोर्टिंग की अनुमति मिलती है।

पुनरावृत्ति और वर्ज़निंग (Infrastructure as Code) के लिए BigQuery डेटासेट, टेबल और एक्सेस कंट्रोल को कोड के रूप में प्रबंधित करने की आवश्यकता है।

→सभी BigQuery संसाधनों (डेटासेट, टेबल, IAM नीतियां) को Terraform कॉन्फ़िगरेशन फ़ाइलों (`.tf`) में परिभाषित करें। CI/CD पाइपलाइन के माध्यम से डिप्लॉयमेंट प्रबंधित करें।

क्यों: Terraform GCP पर IaC के लिए मानक है, जो डेटा इन्फ्रास्ट्रक्चर के ऑडिटेड, वर्ज़न-नियंत्रित और सुसंगत प्रबंधन को सक्षम बनाता है, जिससे मैन्युअल कॉन्फ़िगरेशन ड्रिफ्ट को रोका जा सकता है।

उत्पादन में एक ML मॉडल समय के साथ खराब प्रदर्शन दिखा रहा है।

→Vertex AI Model Monitoring लागू करें। बेसलाइन के खिलाफ उत्पादन ट्रैफिक की तुलना करके प्रशिक्षण-सर्विंग तिरछापन और भविष्यवाणी ड्रिफ्ट का पता लगाने के लिए एक निगरानी जॉब कॉन्फ़िगर करें। जांच या स्वचालित पुन:प्रशिक्षण को ट्रिगर करने के लिए अलर्ट सेट करें।

क्यों: डेटा ड्रिफ्ट के कारण मॉडल का प्रदर्शन खराब होता है। इसका पता लगाने और मॉडल की सटीकता बनाए रखने के लिए सक्रिय निगरानी आवश्यक है, जिससे पुन:प्रशिक्षण उचित हो जाता है।