स्ट्रीमिंग अधिग्रहण के लिए Kinesis सेवा चुनें।
→उपभोक्ता-नियंत्रित उप-सेकंड प्रोसेसिंग → Kinesis Data Streams। S3/Redshift/OpenSearch पर वैकल्पिक प्रारूप रूपांतरण के साथ पूर्णतः प्रबंधित डिलीवरी → Kinesis Data Firehose।
क्यों: KDS रिकॉर्ड को बनाए रखता है (24 घंटे-365 दिन) और कई उपभोक्ताओं का समर्थन करता है। Firehose में रीप्ले नहीं होता; रीप्ले को शून्य-ऑप्स डिलीवरी के लिए बदलता है।
संदर्भ↗
पीक के दौरान स्ट्रीम ProvisionedThroughputExceeded त्रुटियों का सामना करती है।
→रिशार्ड करें। प्रत्येक शार्ड 1 MB/s या 1,000 रिकॉर्ड/s अधिग्रहण, 2 MB/s निकास का समर्थन करता है। एकसमान विभाजन कुंजियों का उपयोग करें; प्रति उपभोक्ता >2 MB/s के लिए Enhanced Fan-Out सक्षम करें।
क्यों: हॉट विभाजन कुंजियाँ एक शार्ड पर ट्रैफिक केंद्रित करती हैं। यादृच्छिक या हैश-आधारित कुंजियाँ लोड को फैलाती हैं।
संदर्भ↗
स्ट्रीमिंग वर्कलोड स्पाइकी और अप्रत्याशित है; मैन्युअल रिशार्डिंग परिचालन में समस्या है।
→ऑन-डिमांड क्षमता मोड में Kinesis Data Streams। डिफ़ॉल्ट रूप से 200 MB/s तक स्वतः-स्केल करता है; डेटा वॉल्यूम के अनुसार भुगतान करें।
संदर्भ↗
एक ही स्ट्रीम को पढ़ने वाले कई उपभोक्ता 2 MB/s/shard पढ़ने की सीमा को पार कर जाते हैं।
→Enhanced Fan-Out। प्रत्येक उपभोक्ता को पुश-आधारित HTTP/2 SubscribeToShard के माध्यम से समर्पित 2 MB/s/shard प्राप्त होता है।
संदर्भ↗
प्रोड्यूसर-साइड एप्लिकेशन से अधिग्रहण थ्रूपुट को अधिकतम करें।
→Kinesis Producer Library (KPL) एकत्रीकरण + संग्रह के साथ। कई उपयोगकर्ता रिकॉर्ड को एक Kinesis रिकॉर्ड में 1 MB तक बैच करता है; PUT लागत कम करता है।
क्यों: सिंगल-रिकॉर्ड PutRecord 50k इवेंट/s पर दर-सीमित और महंगा है। KPL क्लाइंट-साइड पर एकत्रित करता है।
संदर्भ↗
JSON क्लिकस्ट्रीम को S3 में Parquet के रूप में उतारें, इवेंट समय के अनुसार विभाजित करें।
→Glue Data Catalog तालिका + इवेंट टाइमस्टैम्प पर डायनेमिक पार्टिशनिंग का उपयोग करके रिकॉर्ड प्रारूप रूपांतरण (JSON → Parquet) के साथ Firehose।
क्यों: Parquet + पार्टिशनिंग Athena स्कैन लागत को नाटकीय रूप से कम करता है। डायनेमिक पार्टिशनिंग एक अलग ETL चरण से बचाती है।
संदर्भ↗
कुछ रिकॉर्ड Firehose परिवर्तन या वितरण में विफल होते हैं; उन्हें रीप्ले के लिए कैप्चर करने की आवश्यकता है।
→S3 बैकअप को `AllData` या `FailedDataOnly` के साथ कॉन्फ़िगर करें। विफल रिकॉर्ड त्रुटि मेटाडेटा के साथ कॉन्फ़िगर किए गए उपसर्ग पर आते हैं।
संदर्भ↗
यदि एक ब्रोकर AZ विफल हो जाता है तो MSK में कोई डेटा हानि सुनिश्चित न करें।
→3 AZs और `min.insync.replicas=2` के साथ उत्पादक `acks=all` पर प्रतिकृति कारक ≥ 3। ZooKeeper-less KRaft या 3-AZ ब्रोकर प्लेसमेंट के माध्यम से Multi-AZ सक्षम करें।
संदर्भ↗
Kafka Connect क्लस्टर को प्रबंधित किए बिना MSK से S3, OpenSearch या RDS में स्ट्रीम करें।
→प्रबंधित कनेक्टर (Confluent S3 Sink, CDC के लिए Debezium) के साथ MSK Connect। WCU के अनुसार ऑटो-स्केल वर्कर्स।
संदर्भ↗
विषय प्रति कुंजी एक रिकॉर्ड का नवीनतम संस्करण संग्रहीत करता है; पुराने संस्करणों को छोड़ा जा सकता है।
→विषय `cleanup.policy=compact` सेट करें। Kafka प्रत्येक कुंजी के लिए सबसे हाल का मान रखता है; पुराने समान-कुंजी रिकॉर्ड संपीड़न के लिए योग्य हैं।
संदर्भ↗
Direct Connect पर ऑन-प्रेम NFS से S3 में 10 TB का साप्ताहिक आवर्ती स्थानांतरण।
→ऑन-प्रेम एजेंट + अनुसूचित कार्य के साथ AWS DataSync। डेटा अखंडता को सत्यापित करता है, वृद्धिशील स्थानांतरण, समानांतर का समर्थन करता है।
क्यों: DataSync aws-cli सिंक से तेज़ है और मूल रूप से बैंडविड्थ थ्रॉटलिंग, रिट्राइज़ और सत्यापन को संभालता है।
संदर्भ↗
SaaS APIs (Salesforce, ServiceNow, Zendesk) से डेटा को S3 में एक शेड्यूल पर खींचें।
→AWS AppFlow। प्रबंधित कनेक्टर, OAuth संभाला गया, अनुसूचित या इवेंट-ट्रिगर, S3 में Parquet लिखता है।
संदर्भ↗
न्यूनतम डाउनटाइम के साथ ऑन-प्रेम SQL Server से Aurora MySQL में चल रहे परिवर्तनों को रेप्लिकेट करें।
→फुल-लोड + CDC कार्य के साथ AWS DMS। DMS से पहले विषम स्कीमा/कोड रूपांतरण के लिए Schema Conversion Tool (SCT) का उपयोग करें।
संदर्भ↗
DMS प्रतिकृति इंस्टेंस विफल हो जाता है — प्रतिकृति बाधित होती है।
→प्रतिकृति इंस्टेंस पर Multi-AZ सक्षम करें। दूसरे AZ में सिंक्रोनस स्टैंडबाय; स्वचालित फेलओवर।
संदर्भ↗
ETL पाइपलाइन के बिना OLTP Aurora डेटा पर लगभग-वास्तविक-समय के विश्लेषण की आवश्यकता है।
→Redshift में Aurora शून्य-ETL एकीकरण। Aurora डेटा का Redshift में सतत प्रतिकृति; क्वेरीज़ सेकंडों के भीतर नया डेटा देखती हैं।
क्यों: OLTP-से-वेयरहाउस उपयोग के मामले के लिए DMS / Glue / कस्टम CDC पाइपलाइनों को समाप्त करता है।
संदर्भ↗
ऑन-प्रेम से S3 में 100 TB ऐतिहासिक संग्रह को ले जाएं; बैंडविड्थ सीमित है।
→AWS Snowball Edge Storage Optimized। भौतिक डिवाइस साइट पर भेज दिया जाता है; डेटा कॉपी करें; वापस भेजें।
संदर्भ↗
स्रोत JSON में नेस्टेड एरेज़ हैं; डाउनस्ट्रीम रिलेशन एनालिसिस को फ्लैट किए गए पंक्तियों की आवश्यकता है।
→Glue PySpark `Relationalize` ट्रांसफॉर्म (या DataFrame में `explode()`) नेस्टेड एरेज़ को अलग-अलग पंक्तियों/तालिकाओं में फ्लैट करता है।
संदर्भ↗
Glue Crawler अव्यवस्थित CSV डेटा से अस्पष्ट प्रकारों (`choice<int,string>`) को अनुमानित करता है।
→`ResolveChoice` ट्रांसफॉर्म लागू करें — विशिष्ट प्रकार पर कास्ट करें या struct पर प्रोजेक्ट करें। या स्कीमा को लागू करके स्रोत पर ठीक करें।
संदर्भ↗
Glue ETL जॉब बढ़ते S3 डेटा पर प्रति घंटा चलता है; केवल नई फाइलों को संसाधित करने की आवश्यकता है।
→Glue जॉब बुकमार्क्स सक्षम करें। Glue संसाधित फाइलों/विभाजनों को ट्रैक करता है और उन्हें पुनः चलाने पर छोड़ देता है।
क्यों: पूरे डेटासेट को पुनः संसाधित करने से बचाता है। वृद्धिशील ETL पाइपलाइनों के लिए आवश्यक है।
संदर्भ↗
बड़ी एकत्रीकरण के दौरान ड्राइवर पर आउट ऑफ मेमोरी त्रुटि के साथ Glue Spark जॉब विफल हो जाता है।
→G.2X या G.4X वर्कर्स पर स्विच करें (अधिक ड्राइवर मेमोरी) या शफल्ड डेटा को कम करने के लिए `--enable-glue-datacatalog` पुश-डाउन प्रेडिकेट्स सक्षम करें।
संदर्भ↗
प्रबंधित इन्फ्रा के साथ Kinesis स्रोत के विरुद्ध सतत स्पार्क स्ट्रक्चर्ड स्ट्रीमिंग चलाएँ।
→AWS Glue स्ट्रीमिंग ETL जॉब। अंतर्निहित Spark Structured Streaming; S3 पर चेकपॉइंटिंग।
संदर्भ↗
व्यावसायिक विश्लेषक को कोड लिखे बिना डेटा को साफ और परिवर्तित करने की आवश्यकता है।
→AWS Glue DataBrew। विज़ुअल रेसिपी-आधारित ट्रांसफॉर्म (250+), प्रोफाइलिंग, लीनेज। S3, Redshift, RDS पर आउटपुट।
संदर्भ↗
Crawler द्वारा डेटा कैटलॉग को सफलतापूर्वक अपडेट करने के बाद ही Glue ETL जॉब चलाएँ।
→शर्तों के साथ Glue Workflow। Crawler सफलता → ETL जॉब ट्रिगर करें। विफलता → छोड़ें / अलार्म।
संदर्भ↗
Crawler सभी CSV कॉलम को `string` के रूप में अनुमानित करता है — तारीख और संख्या प्रकारों की आवश्यकता है।
→क्रॉलिंग से पहले एक कस्टम Glue क्लासिफायर (Grok पैटर्न या कॉलम संकेत) जोड़ें। वैकल्पिक रूप से स्पष्ट प्रकारों के साथ एक हेडर पंक्ति पहले से लिखें।
संदर्भ↗
Kafka पर कई उत्पादकों/उपभोक्ताओं को एक-दूसरे को तोड़े बिना स्कीमा विकास की आवश्यकता है।
→संगतता नियमों (BACKWARD/FORWARD/FULL) के साथ AWS Glue Schema Registry। उत्पादक स्कीमा पंजीकृत करते हैं; उपभोक्ता लाते + मान्य करते हैं।
संदर्भ↗
Spark ETL के लिए EMR और Glue के बीच चयन करें।
→गहरे ट्यूनिंग, कई फ्रेमवर्क (Hive, Presto, Flink) के साथ लंबे समय तक चलने वाला कस्टम Spark → EMR। Glue Data Catalog एकीकरण के साथ सर्वरलेस पे-पर-जॉब ETL → Glue। स्पाइकी/अप्रत्याशित Spark → EMR Serverless।
संदर्भ↗
अंतराल पर चलने वाले Spark/Hive जॉब्स; शून्य क्लस्टर ऑप्स और कोई निष्क्रिय कंप्यूट नहीं चाहते।
→EMR Serverless। कम-विलंबता शुरू करने के लिए पूर्व-आरंभिक क्षमता पूल; प्रति-जॉब स्केल करता है; प्रति vCPU-घंटे भुगतान करें।
संदर्भ↗
लागत-अनुकूलित EMR के लिए ऑन-डिमांड कोर + स्पॉट टास्क नोड्स को मिलाएं।
→प्रकार के अनुसार लक्ष्य क्षमता के साथ Instance Fleets। HDFS स्थिरता के लिए ऑन-डिमांड कोर फ्लीट; विविध इंस्टेंस प्रकारों के साथ स्पॉट टास्क फ्लीट।
संदर्भ↗
Kubernetes पर मानकीकरण करें; EMR Spark जॉब्स को अन्य वर्कलोड के साथ क्लस्टर साझा करना चाहते हैं।
→EKS पर EMR। Spark मौजूदा EKS क्लस्टर पर पॉड्स के रूप में चलता है; IRSA के माध्यम से इन्फ्रा और IAM भूमिकाएँ साझा करें।
संदर्भ↗
विंडो वाली एकत्रीकरण और ठीक-एक बार सिमेंटिक्स के साथ स्टेटफुल स्ट्रीमिंग।
→Apache Flink के लिए Kinesis Data Analytics। प्रबंधित Flink रनटाइम; S3 पर चेकपॉइंट; ऑटो-स्केल।
संदर्भ↗
एक Kinesis स्ट्रीम पर हल्का प्रति-रिकॉर्ड परिवर्तन (<1 ms प्रत्येक)।
→KDS पर इवेंट स्रोत मैपिंग के साथ Lambda। `BatchSize`, `MaximumBatchingWindowInSeconds`, और `ParallelizationFactor` को ट्यून करें।
क्यों: छोटे प्रति-रिकॉर्ड कार्य के लिए Lambda KCL/Glue स्ट्रीमिंग से सस्ता है।
संदर्भ↗
Step Functions चरण कभी-कभी क्षणिक थ्रॉटलिंग पर विफल हो जाता है; फिर से प्रयास करें और फिर अलर्ट करें।
→`ErrorEquals: ["Lambda.ThrottlingException", "States.TaskFailed"]`, `IntervalSeconds`, `MaxAttempts`, `BackoffRate=2` के साथ `Retry` ब्लॉक जोड़ें। साथ ही एक अधिसूचना स्थिति के लिए `Catch`।
संदर्भ↗
Lambda ट्रांसफॉर्म के माध्यम से 500,000 JSON फाइलों को समानांतर में संसाधित करें।
→S3 से `MaxConcurrency` और ItemReader के साथ Step Functions वितरित Map स्टेट। हजारों समानांतर Lambda invocations में फैन-आउट।
संदर्भ↗
क्रॉस-सर्विस निर्भरताओं (Glue + Redshift COPY + Lambda + ईमेल) और लीनेज आवश्यकताओं के साथ जटिल DAG।
→Amazon MWAA (Managed Workflows for Apache Airflow)। AWS सेवाओं के लिए नेटिव Airflow ऑपरेटर; Git-ड्रिवन DAG सिंक।
संदर्भ↗
यदि कोई परिनियोजन विफलताओं का कारण बनता है तो DAG परिवर्तनों को वापस रोल करने की आवश्यकता है।
→DAGs को S3 संस्करण वाले बकेट में संग्रहीत करें + S3 संस्करण के माध्यम से सिंक करें। या CI के माध्यम से वातावरण-प्रति-शाखा + S3 सिंक के साथ Git में DAG रेपो बनाए रखें।
संदर्भ↗