🥇 के हामीलाई डाटा लेक चाहिन्छ? डाटा गोदाम संग के गर्ने?

यो लेख माध्यममा मेरो लेखको अनुवाद हो - डाटा लेकको साथ सुरू गर्दै, जुन धेरै लोकप्रिय हुन थाल्यो, सायद यसको सादगी को कारण। तसर्थ, मैले यसलाई रूसीमा लेख्ने निर्णय गरें र डाटा वेयरहाउस (DW) के हो, र डाटा लेक के हो (डेटा लेक), र तिनीहरू कसरी डेटा विशेषज्ञ नभएका एक साधारण व्यक्तिलाई यो स्पष्ट पार्नको लागि थोरै थप्ने निर्णय गरें। सँगै जानुहोस्।

डाटा लेकको बारेमा किन लेख्न मन लाग्यो? म 10 वर्ष भन्दा बढीको लागि डाटा र एनालिटिक्स संग काम गरिरहेको छु, र अब म निश्चित रूप देखि क्याम्ब्रिज मा Amazon Alexa AI मा ठूलो डाटा संग काम गर्दैछु, जो बोस्टन मा छ, यद्यपि म भ्यानकुभर आइल्याण्ड मा भिक्टोरिया मा बस्छु र अक्सर बोस्टन, सिएटल मा जान्छु। , र भ्यानकुभरमा, र कहिलेकाहीँ मस्कोमा पनि, म सम्मेलनहरूमा बोल्छु। म पनि समय समयमा लेख्छु, तर म मुख्यतया अंग्रेजीमा लेख्छु, र मैले पहिले नै लेखेको छु केही किताबहरू, मलाई उत्तरी अमेरिकाबाट विश्लेषणात्मक प्रवृतिहरू पनि साझा गर्न आवश्यक छ, र म कहिलेकाहीं लेख्छु टेलिग्रामहरू.

मैले सधैं डाटा गोदामहरूसँग काम गरेको छु, र 2015 देखि मैले Amazon वेब सेवाहरूसँग नजिकबाट काम गर्न थालें, र सामान्यतया क्लाउड एनालिटिक्स (AWS, Azure, GCP) मा स्विच गरें। मैले 2007 देखि एनालिटिक्स समाधानहरूको विकास अवलोकन गरेको छु र डाटा वेयरहाउस विक्रेता टेराडाटाका लागि पनि काम गरेको छु र यसलाई Sberbank मा कार्यान्वयन गरेको छु, र त्यही बेला Hadoop सँग बिग डाटा देखा पर्‍यो। सबैले भन्न थाले कि भण्डारणको युग बितिसकेको छ र अब सबै कुरा हडूपमा छ, र त्यसपछि उनीहरूले फेरि डाटा लेकको बारेमा कुरा गर्न थाले, कि अब डाटा गोदामको अन्त्य अवश्य आयो। तर सौभाग्यवश (हुनसक्छ दुर्भाग्यवश हडूप सेटअप गर्न धेरै पैसा कमाउनेहरूका लागि), डाटा गोदाम गएन।

यस लेखमा हामी डाटा लेक के हो हेर्नेछौं। यो लेख डाटा गोदामहरूसँग थोरै वा कुनै अनुभव नभएका व्यक्तिहरूको लागि हो।

तस्बिरमा लेक ब्लेड छ, यो मेरो मनपर्ने तालहरू मध्ये एक हो, यद्यपि म त्यहाँ एक पटक मात्र थिएँ, मैले यसलाई मेरो बाँकी जीवनको लागि सम्झें। तर हामी अर्को प्रकारको तालको बारेमा कुरा गर्नेछौं - डेटा ताल। सायद तपाईं मध्ये धेरैले पहिले नै यो शब्दको बारेमा एक पटक भन्दा बढी सुनेका छन्, तर अर्को परिभाषाले कसैलाई हानि गर्दैन।

सबैभन्दा पहिले, यहाँ डाटा लेकको सबैभन्दा लोकप्रिय परिभाषाहरू छन्:

"सबै प्रकारका कच्चा डाटाको फाइल भण्डारण जुन संगठनमा जो कोहीद्वारा विश्लेषणको लागि उपलब्ध छ" - मार्टिन फाउलर।

"यदि तपाईलाई डेटा मार्ट भनेको पानीको बोतल हो भन्ने लाग्छ - शुद्ध, प्याकेज गरिएको र सुविधाजनक उपभोगको लागि प्याकेज गरिएको छ भने, तब डाटा लेक यसको प्राकृतिक रूपमा पानीको ठूलो भण्डार हो। प्रयोगकर्ताहरू, म आफ्नै लागि पानी सङ्कलन गर्न सक्छु, गहिरो डुब्न, अन्वेषण गर्न सक्छु" - जेम्स डिक्सन।

अब हामी निश्चित रूपमा जान्दछौं कि डाटा लेक एनालिटिक्सको बारेमा हो, यसले हामीलाई यसको मूल फारममा ठूलो मात्रामा डाटा भण्डारण गर्न अनुमति दिन्छ र हामीसँग डाटामा आवश्यक र सुविधाजनक पहुँच छ।

म प्राय: चीजहरू सरल बनाउन चाहन्छु, यदि मैले सरल शब्दहरूमा जटिल शब्दलाई व्याख्या गर्न सक्छु, तब म आफैंले बुझ्छु कि यसले कसरी काम गर्छ र यसको लागि के आवश्यक छ। एक दिन, म आईफोन फोटो ग्यालेरीमा घुमिरहेको थिएँ, र यो मलाई थाहा भयो, यो एक वास्तविक डाटा ताल हो, मैले सम्मेलनहरूको लागि स्लाइड पनि बनाएको छु:

सबै कुरा धेरै सरल छ। हामी फोनमा फोटो लिन्छौं, फोटो फोनमा सुरक्षित हुन्छ र iCloud (क्लाउड फाइल भण्डारण) मा बचत गर्न सकिन्छ। फोनले फोटो मेटाडेटा पनि सङ्कलन गर्छ: के देखाइएको छ, जियो ट्याग, समय। नतिजाको रूपमा, हामी हाम्रो फोटो फेला पार्न आईफोनको प्रयोगकर्ता-अनुकूल इन्टरफेस प्रयोग गर्न सक्छौं र हामी संकेतकहरू पनि देख्छौं, उदाहरणका लागि, जब मैले आगो शब्दको साथ फोटोहरू खोज्छु, मैले आगोको छवि भएको 3 फोटोहरू फेला पार्छु। मेरो लागि, यो एकदम चाँडो र सही काम गर्ने एक व्यापार खुफिया उपकरण जस्तै हो।

र निस्सन्देह, हामीले सुरक्षा (प्राधिकरण र प्रमाणीकरण) को बारेमा बिर्सनु हुँदैन, अन्यथा हाम्रो डाटा सजिलै सार्वजनिक डोमेनमा समाप्त हुन सक्छ। त्यहाँ ठूला निगमहरू र स्टार्टअपहरूको बारेमा धेरै समाचारहरू छन् जसको डाटा विकासकर्ताहरूको लापरवाही र साधारण नियमहरू पालना गर्न असफलताको कारण सार्वजनिक रूपमा उपलब्ध भयो।

यस्तो साधारण तस्विरले पनि हामीलाई डेटा ताल के हो, परम्परागत डाटा गोदाम र यसको मुख्य तत्वहरूबाट यसको भिन्नताहरू कल्पना गर्न मद्दत गर्दछ:

डाटा लोड गर्दै (इन्जेसन) डाटा लेकको मुख्य भाग हो। डाटा दुई तरिकामा डाटा गोदाममा प्रवेश गर्न सक्छ - ब्याच (अन्तरमा लोड) र स्ट्रिमिङ (डेटा प्रवाह)।
फाइल भण्डारण (भण्डारण) डाटा ताल को मुख्य भाग हो। हामीलाई सजिलै मापनयोग्य, अत्यन्त भरपर्दो, र कम लागतको भण्डारण चाहिन्छ। उदाहरण को लागी, AWS मा यो S3 हो।
सूची र खोज (क्याटलग र खोज) - डेटा दलदलबाट बच्नको लागि हामीलाई (यो जब हामी सबै डाटालाई एउटै थुप्रोमा डम्प गर्छौं, र त्यसपछि योसँग काम गर्न असम्भव हुन्छ), हामीले डाटा वर्गीकरण गर्न मेटाडेटा तह सिर्जना गर्न आवश्यक छ। ताकि प्रयोगकर्ताहरूले सजिलैसँग डाटा फेला पार्न सक्छन्, जुन उनीहरूलाई विश्लेषणको लागि चाहिन्छ। थप रूपमा, तपाईले थप खोज समाधानहरू प्रयोग गर्न सक्नुहुन्छ जस्तै ElasticSearch। खोजले प्रयोगकर्तालाई प्रयोगकर्ता-अनुकूल इन्टरफेस मार्फत आवश्यक डाटा फेला पार्न मद्दत गर्दछ।
प्रशोधन गर्दै (प्रक्रिया) - यो चरण डाटा प्रोसेसिंग र रूपान्तरणको लागि जिम्मेवार छ। हामी डेटा रूपान्तरण गर्न सक्छौं, यसको संरचना परिवर्तन गर्न सक्छौं, यसलाई सफा गर्न सक्छौं, र अधिक।
सुरक्षा (सुरक्षा) - समाधानको सुरक्षा डिजाइनमा समय खर्च गर्न महत्त्वपूर्ण छ। उदाहरण को लागी, भण्डारण, प्रशोधन र लोड को समयमा डाटा ईन्क्रिप्शन। प्रमाणीकरण र प्राधिकरण विधिहरू प्रयोग गर्न महत्त्वपूर्ण छ। अन्तमा, एक अडिट उपकरण आवश्यक छ।

व्यावहारिक दृष्टिकोणबाट, हामी डेटा ताललाई तीन विशेषताहरूद्वारा विशेषता गर्न सक्छौं:

जम्मा गर्नुहोस् र केहि भण्डार गर्नुहोस् — डाटा लेकले सबै डाटा समावेश गर्दछ, कुनै पनि अवधिको लागि कच्चा अप्रशोधित डाटा र प्रशोधन गरिएको / सफा डाटा।
गहिरो स्क्यान - डाटा लेकले प्रयोगकर्ताहरूलाई डाटा अन्वेषण र विश्लेषण गर्न अनुमति दिन्छ।
लचिलो पहुँच - डाटा लेकले विभिन्न डाटा र विभिन्न परिदृश्यहरूको लागि लचिलो पहुँच प्रदान गर्दछ।

अब हामी डाटा गोदाम र डाटा लेक बीचको भिन्नताको बारेमा कुरा गर्न सक्छौं। सामान्यतया मानिसहरू सोध्छन्:

डाटा गोदामको बारेमा के हो?
के हामी डाटा गोदामलाई डाटा लेकले प्रतिस्थापन गर्दैछौं वा यसलाई विस्तार गर्दैछौं?
के यो अझै पनि डाटा लेक बिना गर्न सम्भव छ?

छोटकरीमा, त्यहाँ कुनै स्पष्ट जवाफ छैन। यो सबै विशिष्ट स्थिति, टोली को कौशल र बजेट मा निर्भर गर्दछ। उदाहरणका लागि, Oracle मा AWS मा डाटा गोदाम माइग्रेट गर्ने र Amazon को सहायक कम्पनी - Woot - द्वारा डाटा लेक सिर्जना गर्ने। हाम्रो डाटा लेक कहानी: कसरी Woot.com ले AWS मा सर्भरलेस डाटा लेक बनायो.

अर्कोतर्फ, विक्रेता स्नोफ्लेक भन्छन् कि तपाईंले अब डाटा लेकको बारेमा सोच्न आवश्यक छैन, किनकि तिनीहरूको डाटा प्लेटफर्म (२०२० सम्म यो डाटा गोदाम थियो) तपाईंलाई डाटा लेक र डाटा गोदाम दुबै संयोजन गर्न अनुमति दिन्छ। मैले स्नोफ्लेकसँग धेरै काम गरेको छैन, र यो वास्तवमै एक अद्वितीय उत्पादन हो जसले यो गर्न सक्छ। मुद्दाको मूल्य अर्को कुरा हो।

निष्कर्षमा, मेरो व्यक्तिगत विचार यो हो कि हामीलाई अझै पनि हाम्रो रिपोर्टिङको लागि डेटाको मुख्य स्रोतको रूपमा डेटा गोदाम चाहिन्छ, र जे पनि उपयुक्त छैन हामी डेटा तालमा भण्डार गर्छौं। एनालिटिक्सको सम्पूर्ण भूमिका भनेको व्यापारलाई निर्णय गर्न सजिलो पहुँच प्रदान गर्नु हो। जे होस्, व्यापार प्रयोगकर्ताहरूले डाटा लेक भन्दा डाटा गोदामसँग बढी कुशलतापूर्वक काम गर्छन्, उदाहरणका लागि अमेजनमा - त्यहाँ रेडशिफ्ट (विश्लेषणात्मक डाटा गोदाम) छ र त्यहाँ रेडशिफ्ट स्पेक्ट्रम/एथेना (S3 मा डाटा लेकको लागि एसक्यूएल इन्टरफेस) छ। Hive/Presto)। अन्य आधुनिक विश्लेषणात्मक डाटा गोदामहरूमा पनि यही कुरा लागू हुन्छ।

एक विशिष्ट डाटा गोदाम वास्तुकला हेरौं:

यो एक क्लासिक समाधान छ। हामीसँग स्रोत प्रणालीहरू छन्, ETL/ELT प्रयोग गरेर हामी डेटालाई विश्लेषणात्मक डेटा गोदाममा प्रतिलिपि गर्छौं र यसलाई व्यापारिक खुफिया समाधानमा जडान गर्छौं (मेरो मनपर्ने Tableau हो, तपाईंको बारेमा के हो?)।

यो समाधान निम्न बेफाइदा छ:

ETL/ELT सञ्चालन समय र स्रोतहरू चाहिन्छ।
नियमको रूपमा, विश्लेषणात्मक डाटा गोदाममा डाटा भण्डारण गर्नको लागि मेमोरी सस्तो छैन (उदाहरणका लागि, Redshift, BigQuery, Teradata), किनकि हामीले सम्पूर्ण क्लस्टर किन्न आवश्यक छ।
व्यवसायिक प्रयोगकर्ताहरूसँग सफा र प्रायः एकत्रित डाटामा पहुँच छ र कच्चा डाटामा पहुँच छैन।

निस्सन्देह, यो सबै आफ्नो मामला मा निर्भर गर्दछ। यदि तपाइँसँग तपाइँको डाटा गोदाममा समस्या छैन भने, तपाइँलाई डाटा लेकको आवश्यकता पर्दैन। तर जब समस्याहरू ठाउँ, शक्ति, वा मूल्यको कमीको कारणले महत्त्वपूर्ण भूमिका खेल्छ, तब तपाइँ डेटा लेकको विकल्पलाई विचार गर्न सक्नुहुन्छ। यसैले डाटा लेक धेरै लोकप्रिय छ। यहाँ डेटा ताल वास्तुकला को एक उदाहरण छ:

डाटा लेक दृष्टिकोण प्रयोग गरेर, हामी कच्चा डाटा हाम्रो डाटा लेक (ब्याच वा स्ट्रिमिङ) मा लोड गर्छौं, त्यसपछि हामी डाटालाई आवश्यक अनुसार प्रशोधन गर्छौं। डाटा लेकले व्यापार प्रयोगकर्ताहरूलाई आफ्नै डाटा रूपान्तरणहरू (ETL/ELT) सिर्जना गर्न वा व्यापार बुद्धिमत्ता समाधानहरूमा डाटा विश्लेषण गर्न अनुमति दिन्छ (यदि आवश्यक चालक उपलब्ध छ भने)।

कुनै पनि एनालिटिक्स समाधानको लक्ष्य व्यापार प्रयोगकर्ताहरूलाई सेवा दिनु हो। तसर्थ, हामीले सधैं व्यापार आवश्यकताहरू अनुसार काम गर्नुपर्छ। (अमेजनमा यो एक सिद्धान्त हो - पछाडि काम गर्दै)।

डाटा गोदाम र डाटा लेक दुबैसँग काम गर्दै, हामी दुबै समाधानहरू तुलना गर्न सक्छौं:

मुख्य निष्कर्ष निकाल्न सकिन्छ कि डाटा गोदामले डाटा लेकसँग प्रतिस्पर्धा गर्दैन, बरु यसलाई पूरक गर्दछ। तर तपाईको केसको लागि के सही छ भनेर निर्णय गर्न तपाईमा निर्भर छ। यसलाई आफैं प्रयास गर्न र सही निष्कर्षहरू आकर्षित गर्न सधैं रोचक छ।

मैले डाटा लेक अप्रोच प्रयोग गर्न थालेपछि म तपाईंलाई एउटा घटना पनि बताउन चाहन्छु। सबै कुरा एकदम मामूली छ, मैले एक ELT उपकरण प्रयोग गर्ने प्रयास गरें (हामीसँग Matillion ETL थियो) र Amazon Redshift, मेरो समाधानले काम गर्यो, तर आवश्यकताहरू फिट भएन।

मैले वेब लगहरू लिन, तिनीहरूलाई रूपान्तरण गर्न र 2 केसहरूको लागि डेटा प्रदान गर्न तिनीहरूलाई जम्मा गर्न आवश्यक छ:

मार्केटिङ टोली SEO को लागि बोट गतिविधि विश्लेषण गर्न चाहन्थे
IT वेबसाइट प्रदर्शन मेट्रिक्स हेर्न चाहन्थे

धेरै सरल, धेरै सरल लगहरू। यहाँ एउटा उदाहरण छ:

https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188 
192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57 
"GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-"

एउटा फाइलको तौल १-४ मेगाबाइट थियो।

तर त्यहाँ एउटा कठिनाई थियो। हामीसँग संसारभर 7 डोमेनहरू थिए, र एक दिनमा 7000 हजार फाइलहरू सिर्जना गरियो। यो धेरै भोल्युम होइन, केवल 50 गीगाबाइट्स। तर हाम्रो Redshift क्लस्टरको साइज पनि सानो थियो (4 नोडहरू)। परम्परागत तरिकामा एउटा फाइल लोड गर्न करिब एक मिनेट लाग्यो। अर्थात्, समस्या टाउकोमा समाधान भएको छैन। र यो मामला थियो जब मैले डाटा ताल दृष्टिकोण प्रयोग गर्ने निर्णय गरे। समाधान यो जस्तै केहि देखिन्थ्यो:

यो एकदम सरल छ (म नोट गर्न चाहन्छु कि क्लाउडमा काम गर्ने फाइदा सादगी हो)। मैले प्रयोग गरे:

कम्प्युट पावरको लागि AWS लोचदार नक्सा घटाउनुहोस् (हडूप)
AWS S3 डाटा इन्क्रिप्ट र पहुँच सीमित गर्ने क्षमताको साथ फाइल भण्डारणको रूपमा
तर्क र डेटा रूपान्तरणको लागि InMemory कम्प्युटिङ पावर र PySpark को रूपमा स्पार्क
स्पार्कको परिणामको रूपमा पार्केट
नयाँ डाटा र विभाजन बारे मेटाडाटा कलेक्टर रूपमा AWS ग्लु क्रलर
Redshift स्पेक्ट्रम अवस्थित Redshift प्रयोगकर्ताहरूको लागि डाटा तालमा SQL इन्टरफेसको रूपमा

सबैभन्दा सानो EMR+Spark क्लस्टरले फाइलहरूको सम्पूर्ण स्ट्याक 30 मिनेटमा प्रशोधन गर्यो। त्यहाँ AWS का लागि अन्य केसहरू छन्, विशेष गरी धेरै Alexa सम्बन्धित, जहाँ धेरै डाटा छ।

भर्खरै मैले डाटा लेकको एक बेफाइदा जीडीपीआर हो भनेर सिकें। समस्या तब हुन्छ जब क्लाइन्टले यसलाई मेटाउन सोध्छ र डाटा फाइलहरू मध्ये एकमा छ, हामी डाटाबेसमा जस्तै डाटा हेरफेर भाषा र DELETE सञ्चालन प्रयोग गर्न सक्दैनौं।

मलाई आशा छ कि यस लेखले डाटा गोदाम र डाटा ताल बीचको भिन्नता स्पष्ट गरेको छ। यदि तपाइँ इच्छुक हुनुहुन्छ भने, म मेरा लेखहरू वा मैले पढेका पेशेवरहरूको लेखहरू अनुवाद गर्न सक्छु। र मैले काम गर्ने समाधानहरू र तिनीहरूको वास्तुकलाको बारेमा पनि बताउनुहोस्।

स्रोत: www.habr.com

के हामीलाई डाटा लेक चाहिन्छ? डाटा गोदाम संग के गर्ने?

एक टिप्पणी थप्न Отменить ответ