- उपभोक्ता डेटा की मांग हाल के समय में बढ़ने के साथ, Yelp ने Redshift में डेटा को अधिक कुशलता से लोड करने के तरीकों की फिर से समीक्षा की
- इस लेख में देखा गया है कि DBT, Redshift Spectrum के साथ सहज रूप से मिलकर Data Lake से Redshift में डेटा पढ़कर runtime को काफी कम कैसे करता है, data quality समस्याओं को कैसे हल करता है, और developer productivity को कैसे बेहतर बनाता है
शुरुआत
- बैच डेटा को Redshift में लोड करने का तरीका कई वर्षों तक प्रभावी रहा, लेकिन सुधार की संभावनाएँ लगातार खोजी जाती रहीं
- मुख्य रूप से Spark jobs का उपयोग करके S3 डेटा पढ़ा जाता था और in-house Kafka-आधारित डेटा पाइपलाइन में publish किया जाता था, ताकि Data Lake और Redshift दोनों में डेटा पहुँच सके
- लेकिन कुछ समस्याएँ सामने आने लगीं:
- प्रदर्शन: बड़े डेटा सेट (प्रतिदिन 10 लाख से अधिक rows) में देरी होने लगी। इसका मुख्य कारण upsert के दौरान primary key duplication से बचने के लिए table scans का होना था
- स्कीमा परिवर्तन: अधिकांश tables Avro schema से बने थे। schema changes कभी-कभी जटिल हो जाते थे, क्योंकि इसके लिए नया Avro schema बनाना और register करना एक multi-step process था
- बैकफिल: डेटा सुधार के लिए backfill support कमजोर था, क्योंकि rows को in-place modify करने का आसान तरीका नहीं था। अक्सर पूरे partition के लिए संशोधित डेटा लिखने से पहले डेटा को manually delete करना पड़ता था
- डेटा गुणवत्ता: Data Lake और Redshift में समानांतर रूप से लिखने से दोनों data stores के बीच data type differences जैसी data discrepancies का जोखिम था
DBT के साथ Redshift लोडिंग में सुधार
- डेटा को अधिक कुशलता से स्थानांतरित करने के विकल्पों पर विचार करते समय, AWS Redshift Spectrum का उपयोग करने का निर्णय लिया गया, जो विशेष रूप से Redshift में Data Lake डेटा को query करने के लिए बनाया गया टूल है
- Data Lake tables में आम तौर पर सबसे अद्यतन schema होता था, इसलिए Redshift batch के लिए data source के रूप में S3 के बजाय Data Lake का उपयोग करने का निर्णय लिया गया। इससे data discrepancies कम करने में मदद मिली, और यह Data Lake को single source of truth मानने की हमारी best practice के भी अनुरूप था
- implementation के लिए Spectrum को defined schema की आवश्यकता होती है, जो हमारी Data Lake tables के लिए पहले से ही Glue में मौजूद था। अतिरिक्त रूप से केवल इतना setup चाहिए था कि Data Lake tables को external tables के रूप में जोड़ा जाए, ताकि Redshift में simple SQL queries से उन तक पहुँचा जा सके
- अन्य data sets के लिए DBT को पहले ही अपनाना शुरू कर दिया गया था, और यह pipeline में Redshift Spectrum queries को capture करने के लिए भी एकदम उपयुक्त लगा। DBT data transformation में बहुत सक्षम है और modular, version-controlled SQL लिखने को लागू करने में मदद करता है
- Spark jobs द्वारा S3 से Redshift पढ़ने के बजाय, DBT का उपयोग करके Data Lake से सीधे Redshift में डेटा copy किया गया। DBT न केवल reproducibility, flexibility, और data lineage जैसे अपने विशिष्ट लाभ देता है, बल्कि ऊपर बताई गई कई समस्याओं को हल करने में भी मदद करता है
सरल schema changes
- schema changes को सरल बनाने के लिए DBT के
on_schema_change configuration argument का उपयोग किया गया। इसे append_new_columns पर सेट किया गया, ताकि आने वाले डेटा में columns न होने पर वे हटाए न जाएँ
- साथ ही, DBT contracts को दूसरे सुरक्षा स्तर के रूप में उपयोग किया गया, ताकि यह सुनिश्चित हो सके कि लिखा जा रहा डेटा model configuration से मेल खाता है
कम manual backfill
- DBT के जरिए backfill भी काफी आसान हो गया।
pre_hook configuration argument का उपयोग करके model से ठीक पहले चलने वाली query निर्धारित की जा सकती है
- इससे उन partitions के लिए डेटा को अधिक स्वचालित तरीके से delete किया जा सकता है जिनमें लिखा जाना है
- अब idempotency सुनिश्चित की जा सकती है, इसलिए backfill करते समय यह चिंता नहीं रहती कि पुराना डेटा हटे बिना रह जाएगा
डेटा deduplication
- duplicate rows से निपटने के लिए SQL में एक deduplication layer जोड़ी गई और DBT tests से उसका validation किया गया
- DBT में built-in unique column test है, लेकिन इसके लिए पूरे table scan की आवश्यकता होती है, इसलिए बड़े tables पर यह व्यावहारिक नहीं है
- इसके बजाय
dbt_expectations package के expect_column_values_to_be_unique function का उपयोग किया गया। इससे ऐसी row condition निर्धारित की जा सकती है जो केवल हाल में लिखी गई rows को scan करे
प्रदर्शन में सुधार
- सबसे स्पष्ट उपलब्धि प्रदर्शन में सुधार थी, खासकर उस Redshift data set में जहाँ समस्या सबसे अधिक थी:
- writes में पहले लगभग 2 घंटे लगते थे, लेकिन अब वे आमतौर पर सिर्फ 10 मिनट में पूरे हो जाते हैं
- पहले महीने में अधिकतम 6 घंटे तक की देरी होती थी, लेकिन अब कोई देरी नहीं है। इससे on-call incident response के प्रयासों का बोझ काफी कम हुआ
- schema upgrades पहले लंबी multi-step process थे। अब यह कुछ ही घंटों में पूरी होने वाली 3-step process बन गई है
बेहतर data consistency
- डेटा प्रवाह में branching को हटाने से यह भरोसा बढ़ा कि अलग-अलग data stores के बीच डेटा अलग नहीं होगा
- Redshift में आने वाला सारा डेटा पहले Data Lake से होकर गुजरता है, इसलिए यह बेहतर तरीके से सुनिश्चित किया जा सकता है कि Data Lake single source of truth बना रहे
निष्कर्ष
- migration की सफलता के बाद, लगभग 12 अन्य data sets पर भी ये बदलाव लागू किए गए और कुल मिलाकर समान लाभ देखे गए
- AWS Redshift Spectrum और DBT जैसे tools का उपयोग करके, इंफ्रास्ट्रक्चर को बदलती data requirements के अनुरूप ढाला गया, जिससे users और stakeholders को अधिक मूल्य दिया जा सका
अभी कोई टिप्पणी नहीं है.