Бұл мақала менің ортадағы мақаламның аудармасы - , ол өте танымал болды, мүмкін оның қарапайымдылығына байланысты. Сондықтан мен оны орыс тілінде жазуды жөн көрдім және деректер маманы емес қарапайым адамға деректер қоймасы (DW) не екенін және деректер көлі (Data Lake) не екенін және олар қалай жұмыс істейтінін түсіну үшін аздап қосуды шештім. бірге болыңыз.
Неліктен мен деректер көлі туралы жазғым келді? Мен деректермен және аналитикамен 10 жылдан астам жұмыс істеп келемін, қазір мен міндетті түрде Бостондағы Кембридждегі Amazon Alexa AI үлкен деректермен жұмыс істеймін, бірақ мен Ванкувер аралындағы Викторияда тұрамын және Бостонға, Сиэтлге жиі барамын. , мен Ванкуверде, кейде тіпті Мәскеуде конференцияларда сөйлеймін. Мен де анда-санда жазамын, бірақ мен негізінен ағылшын тілінде жазамын, мен қазірдің өзінде жаздым , Сондай-ақ Солтүстік Америкадағы аналитикалық трендтермен бөлісу қажет, мен кейде жазамын .
Мен әрқашан деректер қоймаларымен жұмыс істедім, ал 2015 жылдан бастап мен Amazon Web Services-пен тығыз жұмыс істей бастадым және негізінен бұлттық аналитикаға (AWS, Azure, GCP) ауыстым. Мен 2007 жылдан бері аналитикалық шешімдердің эволюциясын байқадым, тіпті Teradata деректер қоймасының жеткізушісінде жұмыс істедім және оны Сбербанкте енгіздім, дәл сол кезде Hadoop көмегімен үлкен деректер пайда болды. Барлығы сақтау дәуірі өтті және қазір бәрі Hadoop-та болды деп айта бастады, содан кейін олар қайтадан Data Lake туралы айта бастады, енді деректер қоймасының соңы сөзсіз келді. Бақытымызға орай (мүмкін, өкінішке орай, Hadoop-ты орнату арқылы көп ақша тапқандар үшін), деректер қоймасы жойылмады.
Бұл мақалада біз деректер көлінің не екенін қарастырамыз. Бұл мақала деректер қоймаларымен тәжірибесі аз немесе мүлдем жоқ адамдарға арналған.
Суретте Блед көлі, бұл менің сүйікті көлдерімнің бірі, мен онда бір рет болсам да, өмір бойы есімде қалды. Бірақ біз көлдің басқа түрі – деректер көлі туралы айтатын боламыз. Мүмкін сіздердің көпшілігіңіз бұл термин туралы бірнеше рет естіген шығарсыз, бірақ тағы бір анықтама ешкімге зиян тигізбейді.
Ең алдымен, деректер көлінің ең танымал анықтамалары:
«Ұйымдағы кез келген адам талдау үшін қолжетімді бастапқы деректердің барлық түрлерінің файлдық қоймасы» - Мартин Фаулер.
«Егер сіз дата-мартты ыңғайлы тұтыну үшін тазартылған, буып-түйілген және оралған бөтелке су деп ойласаңыз, онда деректер көлі табиғи түрде судың үлкен қоймасы болып табылады. Пайдаланушылар, мен өзім үшін су жинай аламын, терең сүңги аламын, зерттей аламын» - Джеймс Диксон.
Енді біз деректер көлі аналитикаға қатысты екенін анық білеміз, ол бізге деректердің үлкен көлемін бастапқы түрінде сақтауға мүмкіндік береді және бізде деректерге қажетті және ыңғайлы қол жетімділік бар.
Мен жиі заттарды жеңілдетуді ұнатамын, егер мен күрделі терминді қарапайым сөздермен түсіндіре алсам, оның қалай жұмыс істейтінін және не үшін қажет екенін өзім түсінемін. Бір күні мен iPhone фото галереясын аралап жүрдім, ол маған таң қалды, бұл нағыз деректер көлі, мен тіпті конференциялар үшін слайд жасадым:
Барлығы өте қарапайым. Біз телефонда суретке түсіреміз, фото телефонда сақталады және оны iCloud-қа сақтауға болады (бұлтты файлдарды сақтау). Телефон фотосурет метадеректерін де жинайды: не көрсетілген, гео тег, уақыт. Нәтижесінде біз фотосуретімізді табу үшін iPhone-ның ыңғайлы интерфейсін пайдалана аламыз және біз тіпті индикаторларды көреміз, мысалы, мен өрт сөзі бар фотосуреттерді іздегенде, мен өрт бейнесі бар 3 фотосуретті табамын. Мен үшін бұл өте жылдам және анық жұмыс істейтін Business Intelligence құралы сияқты.
Және, әрине, біз қауіпсіздік (авторизация және аутентификация) туралы ұмытпауымыз керек, әйтпесе біздің деректеріміз қоғамдық доменде оңай аяқталуы мүмкін. Әзірлеушілердің салғырттығы және қарапайым ережелерді сақтамау салдарынан деректері көпшілікке қолжетімді болған ірі корпорациялар мен стартаптар туралы жаңалықтар көп.
Тіпті осындай қарапайым сурет бізге деректер көлінің не екенін, оның дәстүрлі деректер қоймасынан айырмашылығын және оның негізгі элементтерін елестетуге көмектеседі:
- Деректер жүктелуде (Жұту) деректер көлінің негізгі құрамдас бөлігі болып табылады. Мәліметтер деректер қоймасына екі жолмен кіруі мүмкін - топтамалық (аралықпен жүктеу) және ағындық (деректер ағыны).
- Файлды сақтау (Сақтау) деректер көлінің негізгі құрамдас бөлігі болып табылады. Бізге жад оңай масштабталатын, өте сенімді және арзан болуы үшін қажет болды. Мысалы, AWS жүйесінде бұл S3.
- Каталог және іздеу (Каталог және іздеу) - деректер батпақтан аулақ болу үшін (бұл біз барлық деректерді бір қадаға төгетін кезде, содан кейін онымен жұмыс істеу мүмкін емес), деректерді жіктеу үшін метадеректер қабатын жасау керек. пайдаланушылар талдауға қажетті деректерді оңай таба алады. Оған қоса, ElasticSearch сияқты қосымша іздеу шешімдерін пайдалануға болады. Іздеу пайдаланушыға ыңғайлы интерфейс арқылы қажетті деректерді табуға көмектеседі.
- Өңдеу (Процесс) - бұл қадам деректерді өңдеуге және түрлендіруге жауапты. Біз деректерді түрлендіруге, құрылымын өзгертуге, тазалауға және т.б.
- Қауіпсіздік (Қауіпсіздік) - Шешімнің қауіпсіздік дизайнына уақыт бөлу маңызды. Мысалы, сақтау, өңдеу және жүктеу кезінде деректерді шифрлау. Аутентификация және авторизация әдістерін қолдану маңызды. Соңында аудит құралы қажет.
Практикалық тұрғыдан біз деректер көлін үш атрибутпен сипаттай аламыз:
- Кез келген нәрсені жинап, сақтаңыз — деректер көлі кез келген уақыт кезеңіндегі өңделмеген өңделмеген деректерді де, өңделген/тазаланған деректерді де барлық деректерді қамтиды.
- Терең сканерлеу — деректер көлі пайдаланушыларға деректерді зерттеуге және талдауға мүмкіндік береді.
- Икемді қол жеткізу — Деректер көлі әртүрлі деректер мен әртүрлі сценарийлерге икемді қол жеткізуді қамтамасыз етеді.
Енді деректер қоймасы мен деректер көлінің айырмашылығы туралы айтуға болады. Әдетте адамдар сұрайды:
- Деректер қоймасы туралы не деуге болады?
- Деректер қоймасын деректер көлімен ауыстырамыз ба әлде оны кеңейтеміз бе?
- Дата көлінсіз әлі де істеу мүмкін бе?
Қысқасы, нақты жауап жоқ. Мұның бәрі нақты жағдайға, команданың шеберлігіне және бюджетке байланысты. Мысалы, деректер қоймасын Oracle жүйесіне AWS жүйесіне көшіру және Amazon еншілес компаниясы - Woot арқылы деректер көлін жасау - .
Екінші жағынан, Snowflake сатушысы енді деректер көлі туралы ойлаудың қажеті жоқ дейді, өйткені олардың деректер платформасы (2020 жылға дейін ол деректер қоймасы болған) деректер көлін де, деректер қоймасын да біріктіруге мүмкіндік береді. Мен Snowflake-пен көп жұмыс істеген жоқпын және бұл шынымен де мұны істей алатын бірегей өнім. Шығарылымның бағасы басқа мәселе.
Қорытындылай келе, менің жеке пікірім бойынша, бізге есеп беру үшін деректердің негізгі көзі ретінде әлі де деректер қоймасы қажет, ал сәйкес келмейтін нәрселерді біз деректер көлінде сақтаймыз. Аналитиканың барлық рөлі бизнеске шешім қабылдауға оңай қол жеткізуді қамтамасыз ету болып табылады. Қалай десек те, бизнес пайдаланушылар деректер көліне қарағанда деректер қоймасымен тиімдірек жұмыс істейді, мысалы Amazon-да – Redshift (аналитикалық деректер қоймасы) және Redshift Spectrum/Athena (S3 жүйесіндегі деректер көлі үшін SQL интерфейсі негізінде) бар. Hive/Presto). Бұл басқа заманауи аналитикалық деректер қоймаларына да қатысты.
Деректер қоймасының типтік архитектурасын қарастырайық:
Бұл классикалық шешім. Бізде бастапқы жүйелер бар, ETL/ELT көмегімен деректерді аналитикалық деректер қоймасына көшіреміз және оны Business Intelligence шешіміне қосамыз (менің сүйікті Tableau, сіздікі ше?).
Бұл шешімнің келесі кемшіліктері бар:
- ETL/ELT операциялары уақыт пен ресурстарды қажет етеді.
- Әдетте, аналитикалық деректер қоймасында деректерді сақтауға арналған жад арзан емес (мысалы, Redshift, BigQuery, Teradata), өйткені бізге тұтас кластерді сатып алу керек.
- Іскерлік пайдаланушылар тазартылған және жиі біріктірілген деректерге қол жеткізе алады және өңделмеген деректерге қол жеткізе алмайды.
Әрине, бәрі сіздің жағдайыңызға байланысты. Деректер қоймасында проблемалар болмаса, сізге деректер көлі мүлдем қажет емес. Бірақ орын, қуат немесе бағаның жетіспеушілігіне байланысты проблемалар туындаған кезде негізгі рөл атқарса, деректер көлінің нұсқасын қарастыруға болады. Сондықтан дата көлі өте танымал. Мұнда деректер көлінің архитектурасының мысалы келтірілген:
Деректер көлі тәсілін пайдалана отырып, біз бастапқы деректерді деректер көлімізге жүктейміз (пакет немесе ағындық), содан кейін деректерді қажетінше өңдейміз. Деректер көлі бизнес пайдаланушыларға өздерінің деректер түрлендірулерін (ETL/ELT) жасауға немесе Business Intelligence шешімдеріндегі деректерді талдауға мүмкіндік береді (қажетті драйвер бар болса).
Кез келген аналитикалық шешімнің мақсаты бизнес пайдаланушыларға қызмет көрсету болып табылады. Сондықтан біз әрқашан бизнес талаптарына сай жұмыс істеуіміз керек. (Amazon-да бұл принциптердің бірі - кері жұмыс).
Деректер қоймасымен және деректер көлімен жұмыс істей отырып, біз екі шешімді де салыстыра аламыз:
Шығаруға болатын негізгі қорытынды: деректер қоймасы деректер көлімен бәсекелеспейді, керісінше оны толықтырады. Бірақ сіздің ісіңізге не сәйкес келетінін өзіңіз шешесіз. Оны өзіңіз сынап көру және дұрыс қорытынды жасау әрқашан қызықты.
Сондай-ақ, мен data lake әдісін қолдана бастаған жағдайлардың бірін айтқым келеді. Барлығы өте тривиальды, мен ELT құралын (бізде Matillion ETL болды) және Amazon Redshift қолдануға тырыстым, менің шешімім жұмыс істеді, бірақ талаптарға сәйкес келмеді.
Маған веб-журналдарды алу, оларды түрлендіру және 2 жағдай бойынша деректерді беру үшін біріктіру керек болды:
- Маркетинг тобы SEO үшін бот белсенділігін талдағысы келді
- АТ веб-сайт өнімділігі көрсеткіштерін қарастырғысы келді
Өте қарапайым, өте қарапайым журналдар. Міне, мысал:
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" "-" "-"Бір файлдың салмағы 1-4 мегабайт болды.
Бірақ бір қиындық болды. Бізде бүкіл әлем бойынша 7 домен болды және бір күнде 7000 50 мың файл жасалды. Бұл әлдеқайда көп көлем емес, бар болғаны 4 гигабайт. Бірақ біздің Redshift кластерінің көлемі де шағын болды (XNUMX түйін). Бір файлды дәстүрлі жолмен жүктеу шамамен бір минутты алды. Яғни, мәселе бетпе-бет шешілген жоқ. Бұл мен data lake әдісін қолдануды шешкен кезде болды. Шешім келесідей көрінді:
Бұл өте қарапайым (бұлтта жұмыс істеудің артықшылығы қарапайымдылығын атап өткім келеді). Мен пайдаландым:
- Есептеу қуатына арналған AWS Elastic Map Reduce (Hadoop).
- AWS S3 деректерді шифрлау және қол жеткізуді шектеу мүмкіндігі бар файлдарды сақтау ретінде
- Spark InMemory есептеу қуаты ретінде және логика мен деректерді түрлендіру үшін PySpark
- Spark нәтижесіндегі паркет
- AWS Glue Crawler жаңа деректер мен бөлімдер туралы метадеректер жинаушы ретінде
- Redshift Spectrum бар Redshift пайдаланушылары үшін деректер көліне SQL интерфейсі ретінде
Ең кішкентай EMR+Spark кластері файлдардың бүкіл сағын 30 минут ішінде өңдеді. AWS үшін басқа жағдайлар бар, әсіресе көптеген деректер бар Alexa-ға қатысты.
Жақында мен деректер көлінің кемшіліктерінің бірі GDPR екенін білдім. Мәселе мынада, клиент оны жоюды сұрағанда және деректер файлдардың бірінде болса, біз дерекқордағы сияқты Деректерді өңдеу тілі мен ЖОЮ әрекетін пайдалана алмаймыз.
Бұл мақала деректер қоймасы мен деректер көлі арасындағы айырмашылықты түсіндірді деп үміттенемін. Егер сізді қызықтырса, мен өзімнің мақалаларымды немесе оқыған мамандардың мақалаларын аудара аламын. Сондай-ақ мен жұмыс істейтін шешімдер мен олардың архитектурасы туралы айтыңыз.
Ақпарат көзі: www.habr.com