Деректер монолитін бұзу туралы толық нұсқаулық.

Бағдарламалық жасақтама әлеміндегі жаңа үлкен мақсатпен қалай күресуге болады.

Деректер монолитін бұзыңыз!

Мотивация

Деректер монолиті

Адам - ​​бір жартаста екі рет саяхаттайтын жалғыз жануар. Қызметтердегі монолитті бұзу туралы бірнеше жыл сөйлескеннен кейін, біз тағы бір нәрсені жасадық: деректер монолиттері (деректердің көлдері және деректер қоймасы).

Мен соңғы жылдары көптеген жобалармен жұмыс істедім (әр түрлі компанияларда) және мен монолитті мәліметтердің проблемалары ұқсас екенін көрдім:

  • Өзгерістерге байланысты деректердегі қателер кодтар мен деректер құбырлары арасында келісілмейді.
  • Әдетте, монолит ақпараттық силостарды жасайды, өйткені бізге мәліметтер мен машиналарды оқытуда код мамандары мен мамандандырылған топтар қажет.
  • Компаниялар өскен сайын бізде көбірек деректер көзі болады және бұл тек өсетін нәрсе, бұл бір жерде деректерге ие болу қиынға соғады.
  • Әдетте деректер құбырларында жұмыс істейтін адамдарға деректердің мағынасын дұрыс түсіну қиын (өйткені оны жасаушылардан кем болмауы керек), өйткені олардың контексттері аз.
  • Кейде ETL процестеріндегі түсінбеушіліктер мен сәйкессіз деректерді жою үшін деректер қоймаларында жаппай жаңартулар жасау қажет.
  • Жаңа идея мен бұл идея өндірісте болған кезде алшақтықты азайту қиын. Сондықтан біз инновация жасай алмаймыз. Егер сіз баяу болсаңыз, сізде жылдам тестілеу және оқу циклы болмайды, онсыз сіз инновация жасай алмайсыз.

Сонымен қатар, деректер монолиті, шын мәнінде, монолит болып табылады, және біз көптеген жаман нәрселерді түсінеміз (және кейбір жақсы); сондықтан біз бұл жұмыстың (біріккен қызметтер, үздіксіз орналастыруға кедергі келтіретін жаңа мүмкіндіктерді шығарудағы проблемалар, тестілеу стратегиясы және т.с.с.) қандай проблема тудыруы мүмкін екенін түсіндірудің қажеті жоқ.

Мұны жасаудың әдеттегі әдісі

Нақты тәсілі - бұл біздің қызметтерімізге назар аудару, содан кейін ETL арқылы қызметтерді / көздерді шығаратын деректерді алу және кейбір өзгертулерден кейін деректерді кейінірек ол / қызмет көрсетілетін жерге реттелген қою (деректер марты, API, BigQuery, типтік құбырлар және т.б.). Бұл процестер деректер құбырларының ішінде жасалады және жоғарыда айтқанымыздай үш нақты бөлікті (ETL) айыра аламыз:

  • Біріншіден, әртүрлі дереккөздерден мәліметтерді қабылдайтын процесс.
  • Деректерді тазартатын және деректер құбырлары бойымен біраз өзгеріс жасайтын өңдеу бөлігі.
  • Деректердің қызмет көрсету сатысы бұрмаланды. Біздің жағдайда BigQuery бұл қызметке қызмет етеді.
Монолиттік мәліметтер

Монолитті қалай бұзуға болады

Бұл ажырату идеясы - бұл құбырды кейбір құбырларда, домендерде немесе ұңғымаларда, кодтар қызметімен бірдей етіп, қызметтер арқылы бұзу.

Сонымен, әр қызмет тек бір ғана құбыр өткізудің орнына, өз деректерін өңдейтін өзіндік (немесе одан да көп) болса ше? Сонымен, әрбір қызмет тазартуға, өзгеруге және өнім ретінде өзгермейтін деректер жиынтығында өз деректерімен бөлісуге жауапты болуы керек.

Осы өзгерістен біз не ұта аламыз? Біріншіден, әр түрлі қызметтерде көптеген өзгерістер бар екенін ұмытпауымыз керек. Міне, проблемалар басталған кезде, немесе біз адамдар туралы өзгерістермен үйлестіруді ұмытып кетеміз немесе қазір бұл үйлестіру мүмкін емес. Шынында да, аналитиканы бұзбау немесе деректердің басқа қызметтері команда қызметтерді өзгертіп жатқан тәрізді, иә? Сонымен қатар, мәліметтердің қалай және қандай форматта екендігі туралы осы топтан артық кім біледі?

Сонымен, әр домен өз мәліметтерін дайындайды, оны басқа қызметтер, ағындық құралдар, басқару, аналитика, деректерді зерттеуші құралдар (jupyter ноутбук ретінде), машиналық оқыту құбырлары, ғаламдық қойма және басқалардан хабарлама брокеріне шығарады. көп, оларға қол жеткізуге болады.

Деректерді тарату стратегиясы

Бұған қоса, егер сіз қазір машинамен оқумен ештеңе жасамасаңыз, сіз жасайсыз. Сонымен, ойланыңыз, жақсы деректерсіз жақсы модель жасауға бола ма? Егер сіз ML-де жақсы жұмыс жасағыңыз келсе, сізге домен бойынша модельдік құбыр қажет болуы мүмкін және сізге осы деректер құбыры қажет болады. Егер сіз осы тақырып туралы көбірек ақпарат алғыңыз келсе, мен жазған келесі жазбаны оқи аласыз: машиналарды оқыту жүйелерінде үздіксіз орналастыру.

Деректер инфрақұрылымы платформа ретінде

Сонымен, біз деректердің монолитін бұзатын боламыз және біз оны доменмен аламыз, бірақ командалардың әрқайсысына өз деректер инфрақұрылымын құруға уақыты жоқ. Бұл мәселені шешу үшін компаниялар жалпы мәліметтер инфрақұрылымын құруға назар аударуы керек.

Мартин Фоулер блогындағы (Mesh-тің экс-әріптесі Жамак Деггани жазған) деректер торабындағы мақалада олар осы инфрақұрылымның кейбір мүмкіндіктерін жазады, олардың кейбіреулері: масштабталатын полиглотты қазу деректерін сақтау, деректерді өңдеу, мәліметтер схемасы, деректер желісі, деректерді бақылау / ескерту / тіркеу, деректер өнімінің сапа көрсеткіштері, деректерді басқару, қауіпсіздік және есептеу және деректердің орналасуы.

Осы деректер платформасында командалар (әзірлеушілер мен деректерді зерттеуші) тек олар өздері жасаған деректермен не істегілері келетіндігі және басқа топтарға қалай қызмет көрсететіні туралы ойлануы керек, мысалы, қазір біз CircleCi немесе Дженкинс (командалар тек инфрақұрылымды емес, CI-ны қалай жасауды ойластыруы керек). Мысалы, бұл суретте Метафлоу инфрақұрылымды ғалымдардың көзқарасы бойынша түсіндіреді:

Метафлоудан алынған сурет

Келесі сурет (Мартин Фоулер блогындағы мәліметтер торынан) соңғы мәртебе болуы мүмкін. Бұл схемада әр түрлі домендерді өз құбырларымен және көлденең деректер платформасымен көруге болады.

Мартин Фоулер блогынан алынған мәліметтер жиынтығы

Жарайды, жарайды ... мен тұжырымдаманы және бәрін түсінемін, бірақ ... оған жету стратегиясы туралы не айтуға болады?

Алдымен, біз кодты жақсы көреміз және көптеген жылдар бойы код пен ең жақсы әдістемелер мен XP құрамындағы барлық әдістерді жетілдіріп келеміз. Сонымен, кодты деректерде және біз білетін барлық озық тәжірибелерде қолданайық.

Деректер құбырын кодпен жасау үшін біз көптеген құралдар мен құрылымдарды пайдалана аламыз. Packlink Инженерлік тобында біз GCP-ді жақсы көреміз, сондықтан мен бұл хабарламада Airflow-мен түсіндіремін, өйткені Google платформасында шертпе және ойнату бар және Airflow-да жұмыс істейтін толық басқарылатын жұмыс процесі оркестрі бар: Cloud Composer.

Есіңізде болсын, маңызды сәттер (қызметтерде бірдей, егер сіз CircleCI, Jenkins және т.б. қолдансаңыз), идеялар - бұл құрал біздің мақсатымызға жетудің жолы. Басқа жақсы құралдар / жақтаулар - Метафлоу, Луиджи, Префект, Пинбол. Қазіргі уақытта әр компания өз шеңберін құруда және олардың барлығы басқаша, бірақ, идеяның мәні - олардың әрқайсысы - код. Келесі бөлімдерде мен:

  • Стронглер үлгісі: оған жету стратегиясы ретінде.
  • Деректер құбыры: бұл құбыр қалай болуы керек?
  • Код: құбырды жазу үшін тексерілген код.

Стронглер үлгісі

Дәл қазір сізде деректер монолиті бар деп болжаймын. Егер жоқ болса, сізде жасыл алаң бар болса, бәлкім бұл тарау сізге қызықты емес, бірақ кешіріңіз, біз монолитті бұзу туралы айтып отырмыз.

Бізде деректердің монолиті бар, ол қай стратегия? Сарқырама жасап, бүкіл инфрақұрылымды бірден салу жақсы идея емес сияқты, сондықтан мақсатымызға жету үшін біз Strangler үлгісін қолданамыз. Бұл бұрынғы жүйелердегі монолитті бұзудың әдеттегі әдісі, мен жоғарыда айтқанымдай, біз көп нәрсені үйрендік және біз бұл білімді қайта пайдаланғымыз келеді.

Бұл үлгіні қолдану жақсы, өйткені; бізде көп жұмыс істеп жатыр және біз осы үш қадамда пайдалы және ептілікпен жұмыс істегіміз келеді:

  • Монолитті доменнен жаңа құбырға салыңыз.
  • Өндіріске қойыңыз және екі жол бірігіп тұрған кезде бәрі жақсы жұмыс істейтінін тексеріңіз.
  • Монолитке осы қарапайым бөлікті жойыңыз.
Іс-әрекеттегі бейтаныс адам

Сонымен, біз ең қарапайым доменді таңдай аламыз және жаңа деректер құбырын жасай аламыз, содан кейін жалған көші-қонды екі жүйемен бірге жасай аламыз, және бәрі дұрыс жұмыс істеп жатқандығына сенімді болған кезде, бұрынғы бөлікті өшіруге болады.

Деректер құбыры

Бұл құбырдың негізгі нүктелері:

  • Деректермен күрес. Қызметтер өндірген барлық мәліметтер ортақ бола бермейді және өндірілген мәліметтердің бәрі де шикі емес. Кейде кейбір өзгерістер жасау керек. Біз кодты жасаймыз, мен әрқашан айтқанымдай, код - бұл код, сондықтан біз әрқашан ең жақсы тәжірибелерді қолдануымыз керек.
  • Схеманы тексеру. Егер біз өзіміздің деректеріміздің сапасын қамтамасыз еткіміз келсе, оны компанияның басқа бөліктерімен (қызметтер, аналитика және т.б.) бөлісу кезінде схеманы пайдалану қажет. Мысалы, бізде бұл мән бүтін сан екенін және ең үлкен мәні ... 150 болатындығын қамтамасыз еткіміз келетін адамдардың жасы бар. Achieve Оған қол жеткізу үшін сіз деректерді сериялаудың әртүрлі жүйелерін қолдана аласыз, мен Protocol Buffers немесе Avro ұсынамын. Бұл ретте, өндіруші де, тұтынушы да әр нүктенің нені білдіретінін біледі.
  • Өнім ретінде өзгермейтін мәліметтер жиынтығын экспорттау. Әрбір қызмет ұйыммен ақпаратты бөлісуге жауап береді. Кафка немесе pub / sub сияқты хабар алмасу брокері арқылы жасалған өзгермейтін деректер жиынтығын бөлісу оңтайлы болып табылады. Таратылған жүйелердегі бөлісетін деректер туралы жақсы жазбаны мына жерден оқи аласыз. Мұнда назар аударыңыз: біз функционалды бағдарламалауда білетініміздей, мәліметтер өзгермейтін болуы керек және бұл бізге бүкіл тарихты сақтауға және кейінірек оларды жинақтамай-ақ қажетті агрегаттарды жасауға мүмкіндік береді.
  • Деректерді редакциялау / кодтар. Біз код түрінде жасағаннан кейін біз деректер жиынтығын нақтылауды қажет етеміз, тіпті көбірек, деректерді код ретінде алғымыз келеді. Мұның бірнеше пайдасы бар: біз қателерді оңай көбейте аламыз, тесттерде және құбырлардағы мәліметтер жиынтығын қолдана аламыз, машинаны үйренудегі көптеген артықшылықтар (осында қосымша ақпарат) және кодтың барлық жақсы жақтары бар. DVC, деректер мен модельдерді басқаруға негізделген git жүйесі, шешім, бұл менің ойымша, деректер әлеміндегі ең жақсы құралдардың бірі.
Деректер мен модельдер туралы DVC диаграммалары, код және деректерді бөлісу
  • Деректерді басқару және сандық. Егер мен деректердің монолитін бұзғымыз келсе, бұл мен үшін деректер құбырындағы ең маңызды сәттердің бірі. Біріншіден, бізге мәлімет платформасында оны сақтау құралы қажет. Жақсы баламалар бар, бірақ мен тек екеуін ұсынамын: Lyft Ammundsen және егер сіз GCP, Деректер каталогын қолдансаңыз. Екеуі де деректерді автоматты түрде ашады. Маңыздысы - құрал емес, сонымен қатар тұжырымдама. Біз өзіміздің құбырларымызда біз бөлісетін мәліметтердің сипаттамасын және API арқылы метадеректерді біздің құралға сақтауымыз керек, мысалы, бұл кітапхана Деректер каталогында жасайтындай және деректердің дұрыс құрамына ие болу үшін қажет. Осының арқасында барлығы деректердің қайда екенін, иесі кім екенін, оның мәні мен мәні қандай екенін білетін болады.
Lyft Ammundsen көмегімен деректерді басқару
  • Бақылау. Біз жүйенің қалай жұмыс істейтінін түсінуіміз керек, және біз оны үш деңгейден: инфрақұрылым деңгейінен, жұмыс деңгейіндегі оқиғалардан және деректер деңгейінен жоғары жұмыс істейтін боламыз. Анық және пайдалы ақпараты бар бақылау тақтасын жасаңыз. Бұл басты мәселе. Біз күрделі жүйелермен айналысудамыз, сондықтан біздің жүйелеріміз дұрыс жұмыс істеп жатқанын оңай түсіну үшін бақылау тақтасы болуы керек. Осыған байланысты, кеме пайда болған кезде, сіз бірінші болып оны ашасыз. Деректердегі әдеттегі қате - бұл тыныштықты жою. Егер ақпарат жаңа деректерді шығаруды тоқтатса, біз бұл туралы ертерек хабардар болуымыз керек, өйткені біздің модельдеріміз, басқа қызметтеріміз немесе бизнесіміз бұл деректерге жоғары пайызда тәуелді болуы мүмкін. Сонымен қатар, жақсы деректер құбырының арқасында сәтсіздіктерді автоматтандырылған түрде анықтауға қол жеткізуге болады, мысалы, уақыт кезеңі аз болған жағдайда.
  • Деректердің сапасы. Тесттер, тесттер және тағы басқалар. Біз сынаймыз. Кодтағы тесттерден басқа, бізге бірнеше мәліметтер қажет. Мысалы, сіз бұл құбырдағы сынақ туралы не ойлайсыз, егер біз өнімнен гөрі тапсырыс берсек, бізге кеңес береді? Бұл қисынды және пайдалы болып көрінеді, иә?
  • Мәліметтерге үйрету. Егер сіз сондай-ақ машинамен жұмыс жасайтын болсаңыз және біз өзіміздің ғалымдарымыздың өмірін құрғымыз келсе, сізге оқу туралы мәліметтер алу керек. Мұнда көптеген маңызды тұстар бар: маңыздылығы бойынша іріктеліп алынды, мәліметтерді кішігірім тілімдерге бөліңіз, барлық құпия деректерді анонимдей аласыз ... осында қосымша ақпарат.
  • Біз өз клиенттерімізге қамқорлық жасаймыз, сондықтан біз олардың деректері туралы қамқорлық жасауымыз керек, сондықтан біз бұл деректер бөлігінде көптеген қауіпсіздікті қажет етеміз. Егер біз олармен жұмыс жасағымыз келсе, барлық құпия деректерді анонимдеу маңызды.

Иә, Хуан өте әдемі, бірақ ...

Құтқарушыға арналған экстремалды бағдарламалау

Біріншіден, біз бәрін код ретінде қарастыруды жалғастырамыз, сондықтан да деректер құбыры.

Бейтаныс тәсілмен, және бірінші итерация кезінде, логика - біз бұрын жасаған логиканың қайтадан қолданылуы, және біз оны XP және біздің ойымызша айтқандай TDD көмегімен жасаймыз.

Егер сіз маған тез әдіспен жетудің қарапайым әдісін қалай түсіндіретінімді ойласаңыз. Сонымен қатар, сіз ұзақ мерзімді перспективада өз стратегияңызды шешуіңіз керек.

Егер сіз ауа ағындарын білсеңіз, онда сіз әр DAG-ге қандай код қою керектігіне байланысты бірнеше оператордың (python_operator, http_operator, bash_operator, mysql_operator және тағы басқа) бар екенін білесіз. Бұл операторларда кейбір проблемалар бар. Мені одан да жаманы - оларды сынақтан өткізудің күрделі және ұнамсыз әдісі, бұдан басқа, егер сіз Python-ны қолдансаңыз, тәуелділік мәселесі туралы бір нәрсені тыңдайтын боларсыз. Осы операторлардың көмегімен барлық жобада барлық тәуелділіктерді орнату керек, олардың басқа нұсқасын қажет етпейді және Python-дің дәл нұсқасын пайдалану керек. Сонымен қатар, біз қазіргі заманғы компаниямыз және біз полиглот жүйесін пайдаланып, жаңа тілдерді үйренгіміз келеді!

Менің шешімім - біз бейтаныс жандармен, докер операторымен, kubernetes_pod_operatorмен жұмыс жасауда. Егер сіз Google Composer-ді қолдансаңыз, Kubernetes-ті қолданыңыз, бірақ GKEContainerOperator-ны ешқашан пайдаланбаңыз, өйткені бұл ресурстар бәсекелестігіне әкелуі мүмкін. Осы операторлардың көмегімен әр DAG-да орындалатын код контейнерге түседі (питон коды, шкалалар, java, сәулелік процестер, ұшқын процестері, Кафка ағындары, қорытындылай келе, сіз елестете алатын барлық нәрселер болуы мүмкін ...), осылайша сіз TDD-ді өзіңіз қалаған тілде қолданыңыз және сіз бұрынғы кодты қайта пайдалана аласыз. Бөлімшелік тестілеу және интеграциялық тестілеу шамамен ...

Біз әлі де өз ағынды кодты жазуымыз керек, ол үшін біз TDD-ны де орындаймыз. Бұл ауа ағынының бөлігін сынауға кіретін анықтамалық тест бөлігі болады. Кодты көрсетпестен бұрын мен Чанду Кавар мен Саранг Шиндеге ауа ағынындағы тестілеу стратегиялары туралы жазған хабарламалары үшін алғыс айтамын.

Сонымен, біз TDD сияқты, алдымен қондырғы тексереді:

Бұл TDD көмегімен біз жасаған құбырдың өндірістік коды:

Бірақ қондырғыны тестілеу жеткіліксіз, Packlink Engineering-те тесттер кодтың маңызды бөлігі екенін біледі. Сонымен, көп тестілеуге көшейік.

Ауа ағынының бөлігінде интеграциялық сынақтардың уақыты келді (контейнерлерде өз қондырғысы және интеграциялық сынақтар бар). Осы тәсілмен интеграциялық тесттер ауа ағынының конфигурациясы мен XComs-қа қатысты, олар жиынтықта ауа ағынының жолын біз DAG-тегі тапсырмалар арасында бөлісуіміз керек. Біздің мысалда, біз packlink_hello_task-те сақталған ақпаратты stream_data_task қабылдағанын тексеруіміз керек:

Пирамида тестілеудің соңғы бөлігі - e2e тестілері. Пирамидада e2e сынақтары әрқашан кішкентай жақта болады, өйткені олар өте қымбат. Ауа ағынында одан да көп болуы мүмкін. Сіз жақсы мысалды мына жерден көре аласыз: https://github.com/chandulal/airflow-testing. Мен мұны жақсы жасай алмадым.

Қорытындылар

Бұл мені қызметімнің соңына дейін жеткізеді. Мен жай ғана осы постты қорытындылау үшін бірнеше қорытынды жасағым келді:

  • Код - бұл код. XP тәжірибесін қолданыңыз.
  • Кодтық монолиттер сияқты деректер монолиттері ұқсас проблемаларға ие.
  • Өзгермейтін деректер жиынтығын өнім ретінде бөлісіңіз.
  • Өз күніңізді біліңіз, деректерді басқаруға махаббат салыңыз. Компанияның барлығы деректерді түсіне алатындай болуы керек.
  • Жоқ болады. Байқауға назар аударыңыз.
  • Олардың деректері туралы домендерден басқа ешкім жақсы білмейді. DDD көрінісін мәліметтерге қолданыңыз.
  • Пакет ережелері!.

Ресурстар мен сілтемелер