Məlumatların monolitini necə sındırmaq barədə tam bir bələdçi.

Proqram dünyasında yeni böyük hədəflə necə mübarizə aparmaq olar.

Məlumat monolitini qırın!

Motivasiya

Məlumat monolit

İnsan eyni qayada iki dəfə gəzən yeganə heyvandır. Xidmətlərdə monolitin qırılması haqqında illərlə danışdıqdan sonra yenə eyni şeyi etdik: məlumat monolitləri (aka məlumat gölləri və məlumat anbarları).

Son illər bir çox layihə üzərində çalışmışam (müxtəlif şirkətlərdə) və məlumatların monolit səbəb olduğu problemlərin oxşar olduğunu gördüm:

  • Dəyişikliklər səbəbindən məlumatların səhvləri kod və məlumat boru kəmərləri arasında əlaqələndirilmir.
  • Adətən, monolit məlumat silosları yaradır, çünki məlumat və maşın öyrənməsində kod mütəxəssislərinə və xüsusi qruplara ehtiyacımız var.
  • Şirkətlər böyüdükcə, daha çox məlumat mənbəyimiz var və bu yalnız böyüyən bir şeydir ki, bu da məlumatların bir yerdə qalmasını çətinləşdirir.
  • Məlumat boru kəmərlərində işləyən insanlar üçün məlumatların mənasını düzgün başa düşmək çətindir (ən azı onu istehsal edən insanlardan yaxşı deyil), çünki daha az kontekstə sahibdirlər.
  • Bəzən ETL proseslərindəki anlaşılmazlıqları və uyğun olmayan məlumatları düzəltmək üçün məlumat anbarlarında toplu yeniləmələr aparmaq lazımdır.
  • Yeni bir fikir və bu ideyanın istehsalda olduğu vaxt arasındakı boşluğu azaltmaq çətindir. Buna görə yenilik edə bilmərik. Yavaş olsanız, sürətli bir test edə və dövrü öyrənə bilməzsiniz və bunsuz yenilik edə bilməzsiniz.

Bundan əlavə, məlumat monolit, əslində, monolitdir və buna aid bir çox pis şeyləri (və bəzi yaxşılarını) başa düşürük; buna görə bu işin (birləşdirilmiş xidmətlər, fasiləsiz yerləşdirməyə mane olan yeni xüsusiyyətlər buraxma problemləri, qarışıq test strategiyası və s.) Problem ola biləcəyini izah etməyə ehtiyac duymuruq.

Bunun adi yolu

Həqiqi yol, diqqətimizi xidmətlərimizə yönəltmək və sonra bir ETL tərəfindən xidmətlərin / mənbələrin istehsal etdiyi məlumatları əldə etmək və bəzi dəyişikliklərdən sonra məlumatları daha sonra istifadə / xidmət ediləcəyi yerə (data marts, API, BigQuery, model boru kəmərləri və s.) Bu proseslər məlumat boru kəmərləri içərisində edilir və əvvəllər dediyimiz kimi üç aydın hissəni (ETL) fərqləndirə bilərik:

  • Birincisi, müxtəlif mənbələrdən məlumatları daxil edən bir proses.
  • Verilənləri təmizlədiyimiz və məlumat boru kəmərləri boyunca bəzi dəyişikliklər etdiyimiz bir emal hissəsi.
  • Verilənlərin xidmət etmə addımı mübahisələndirildi. Bizim vəziyyətimizdə BigQuery bu məlumat xidmətini edir.
Məlumat monolit nümunəsi

Monoliti necə qırmaq olar

Bu parçalama ideyası, bu boru xəttini bəzi boru kəmərlərində, domenlər və ya quyularda, xidmətlərimizlə kod xidmətləri ilə eyni şəkildə qırmaqdır.

Beləliklə, hər bir xidmətin yalnız bir boru kəməri əvəzinə, öz məlumatlarını emal edən öz (və ya daha çox) olması nə olar? Beləliklə, hər bir xidmət təmiz olmağa, dəyişdirməyə və öz məlumatlarını məhsul kimi dəyişməz verilənlər bazalarında paylamağa cavabdeh olmalıdır.

Bu dəyişikliklə nə qazana bilərik? Əvvəla, fərqli xidmətlərdə bir çox dəyişiklik olduğunu unutmamalıyıq. Problemlər başladığında, ya da dəyişikliklər haqqında məlumatları insanlarla əlaqələndirməyi unutduğumuz zaman ya da bu koordinasiya bu anda mümkün deyil. Həqiqətən, analitikləri pozmamağın məsuliyyəti və ya məlumatdakı digər xidmətlərin komandanın xidmətləri dəyişdirməsi kimi görünür, elə deyilmi? Bundan əlavə, məlumatların necə olması və hansı formatın olması barədə bu komandadan daha yaxşı kim bilir?

Beləliklə, hər bir domen öz məlumatlarını hazırlayır, onu digər xidmətlər, axın vasitələri, idarəetmə, analitik, məlumat alimləri alətləri (jupyter notebook kimi), maşın öyrənmə boru kəmərləri, qlobal bir anbar və sairdən bir mesajlaşma brokerinə məhsul kimi qoyur. daha çox, onlara nail ola bilər.

Məlumatların paylanması strategiyası

Bunun xaricində əminəm ki, indi maşın öyrənməklə heç nə etmirsinizsə, edəcəksiniz. Beləliklə, bu barədə düşünün, yaxşı məlumat almadan yaxşı bir model etmək mümkündürmü? ML-də yaxşı bir iş görmək istəyirsinizsə, çox güman ki, domen ilə bir model boru kəmərinə ehtiyacınız olacaq və bu məlumat boru kəmərinə ehtiyacınız olacaq. Bu mövzuda daha çox məlumat istəyirsinizsə, yazdığım başqa bir yazını oxuya bilərsiniz: maşın öyrənmə sistemlərində davamlı yerləşdirmə.

Məlumat platforması platforma kimi

Beləliklə, məlumatların monolitini qıracağıq və bunu domenlə davam etdirəcəyik, amma əslində komandaların hər birinin öz məlumat infrastrukturunu yaratmağa vaxtları yoxdur. Bu problemi həll etmək üçün şirkətlər ümumi məlumat infrastrukturunun yaradılmasına diqqət ayırmalıdırlar.

Martin Fowlerin bloqundakı məlumat mesh məqaləsində (Düşüncələrdəki keçmiş yoldaşım Jamak Dehghani tərəfindən yazılmış) bu infrastrukturun bəzi imkanlarına sahib olduqlarını yazırlar: genişlənən poliqlot qazma məlumatlarının saxlanması, məlumatların formatlaşdırılması, məlumatların sxemi, məlumatların ötürülməsi, məlumatların monitorinqi. / xəbərdarlıq / qeyd, məlumat məhsulunun keyfiyyət göstəriciləri, məlumatların idarə edilməsi, təhlükəsizlik və hesablama və məlumatların yerləşməsi.

Bu məlumat platforması ilə qruplar (inkişaf etdiricilər və məlumat alimi) yalnız istehsal etdikləri məlumatlarla nə etmək istədikləri və bu məlumatları digər komandalara necə təqdim edəcəkləri barədə qayğı göstərməlidirlər, indi CircleCi ya da etdiyimiz kimi Jenkins (komandalar yalnız infrastrukturu deyil, CI-ni necə etmək istədikləri barədə düşünməlidirlər). Məsələn, bu görüntüdə Metaflow infrastrukturu məlumatların elm adamları baxımından izah edir:

Metaflow-dan görüntü

Növbəti görüntü (Martin Fowler'in bloqunun məlumat mesh postundan) mümkün son vəziyyət ola bilər. Bu sxemdə, fərqli sahələri öz boru kəmərləri və transversal məlumat platforması ilə görə bilərsiniz.

Martin Fowler-in bloqundan Data Mesh sxemi

OK, OK OK ... Mən konsepsiyanı və hər şeyi başa düşürəm, amma ... Buna nail olmaq üçün strategiya haqqında nə demək olar?

Yaxşı, hər şeydən əvvəl, kodu sevirik və illərdir kodun ən yaxşı təcrübələrini və ən yaxşı metodologiyaları və XP-nin daxil olduğu bütün texnikaları inkişaf etdiririk. Beləliklə, məlumatları və bildiyimiz ən yaxşı təcrübələri də koddan istifadə edək.

Verilən boru kəmərlərimizi kodla düzəltmək üçün çox sayda vasitə və çərçivə istifadə edə bilərik. Packlink mühəndislik komandasında biz GCP-ni çox sevirik, bu yazıda bu işi hava axını ilə izah edəcəyəm, çünki Google platforması bir klik və oynaq və Airflow-da qurulmuş tam idarəetmə iş orkestrasiyasına malikdir: Cloud Composer.

Unutmayın ki, vacib məqamlar (xidmətlərdə olduğu kimi eynidir, əgər CircleCI, Jenkins və s. İstifadə edirsinizsə) fikirlərdir, vasitə məqsədlərimizə çatmaq üçün yalnız bir yoldur. Digər yaxşı alətlər / çərçivələr Metaflow, Luigi, Prefect, Pinball. Bu anda hər bir şirkət öz çərçivəsini qurur və hamısı bir-birindən fərqlidir, lakin israrla, fikrin ideyası və hər birinin kod olmasıdır. Növbəti hissələrdə keçəcəyəm:

  • Strangler nümunəsi: buna nail olmaq üçün bir strategiya olaraq.
  • Məlumat kəməri: bu boru kəməri necə olmalıdır?
  • Kod: boru kəmərini yazmaq üçün sınanmış kod.

Qərib naxış

Güman edirəm ki, hazırda məlumat monolitiniz var. Yoxdursa, bir yaşıllıq sahəniz varsa, bəlkə bu fəsil sizin üçün maraqlı deyil, amma bağışlayın, monolitin qırılması haqqında danışırıq.

Bizdə məlumat monoliti var, ən yaxşı strategiya hansıdır? Bir şəlalə düzəltmək və bütün infrastrukturu bir anda qoymaq yaxşı bir fikir deyil ki, hədəfimizə çatmaq üçün Strangler modelindən istifadə edəcəyik. Bu köhnə sistemlərdə monolitin qırılması üçün tipik bir üsuldur və əvvəllər dediyim kimi, çox şey öyrəndik və bu bilikdən yenidən istifadə etmək istəyirik.

Bu nümunəni istifadə etmək yaxşıdır, çünki; çox işimiz var və bu üç addımda bu işi faydalı və çevik bir düşüncə tərzində etmək istəyirik:

  • Yeni bir boru kəmərində monolit bir domen çıxarın.
  • İstehsal qoyun və hər iki yolun birlikdə olduğu müddətdə hər şeyin yaxşı olduğunu yoxlayın.
  • Monolitin bu köhnə hissəsini aradan qaldırın.
Fəaliyyətdə qəriblik nümunəsi

Beləliklə, başlamaq üçün ən sadə domeni seçib yeni bir məlumat boru kəməri qura bilərik, sonra hər iki sistemi tənbəl bir miqrasiya ilə birlikdə qura bilərik və hər şeyin yaxşı olduğuna əmin olduğumuz zaman, köhnə hissəni silə bilərik.

Məlumat kəməri

Bu boru kəmərinin əsas məqamları bunlardır:

  • Məlumat mübahisəsi. Xidmətlər tərəfindən istehsal olunan bütün məlumatlar paylaşılmır və istehsal olunan bütün məlumatlar xam deyil. Bəzən bəzi dəyişikliklər etməliyik. Kodla edəcəyik və həmişə dediyim kimi, kod koddur, buna görə də həmişə ən yaxşı təcrübələri tətbiq etməliyik.
  • Şemanın yoxlanılması. Məlumatlarımızın keyfiyyətini təmin etmək istəyiriksə, şirkətin digər hissələri (xidmətlər, analitiklər və s.) İlə bölüşərkən bir sxemdən istifadə etməliyik. Məsələn, bu dəyərin tam olduğunu və maksimum dəyərin olmasını təmin etmək istədiyimiz insanların yaşı var. 150 Buna nail olmaq üçün müxtəlif məlumat seriya sistemlərindən istifadə edə bilərsiniz, Protokol Buferləri və ya Avro tövsiyə edirəm. Bununla həm istehsalçı, həm də istehlakçı hər məlumat nöqtəsinin nə demək olduğunu bilirlər.
  • Məhsul olaraq dəyişməz verilənlər məcmuəsinin ixracı. Hər bir xidmət məlumatı təşkilatla bölüşmək üçün məsuliyyət daşıyır. Ən optimal biri Kafka və ya pub / sub kimi bir mesajlaşma brokeri vasitəsi ilə hazırlanmış dəyişilməz məlumat toplusunu paylaşmaqdır. Paylanmış sistemlərdə paylaşma məlumatlarından bəhs edən yaxşı bir yazını burada oxuya bilərsiniz. Zəhmət olmasa, məlumat verin: funksional proqramlaşdırmada da öyrəndiyimiz kimi, dəyişməz olmalı və bu da bizə bütün tarixə sahib olmağa və sonradan onları yığmadan lazım olan yığımları etməyə imkan verir.
  • Verilənlərin kodlaşdırılması / məlumatların kodlaşdırılması. Kod hazırladığımız üçün məlumat bazalarımıza yenidən baxmağa ehtiyac duyuruq, daha da çox, məlumatları kod kimi istəyirik. Bunun bir sıra faydaları var: səhvləri asanlıqla təkrarlaya bilərik, testlərimizdə və boru kəmərlərimizdə məlumat toplamalarından istifadə edə bilərik, maşın öyrənmənin çox faydaları (burada daha çox məlumat) və mütləq kodun bütün yaxşı şeyləri. DVC, məlumat və modellərin versiyasına nəzarət sistemidir, həll yolu, mənə, məlumat dünyasının ən yaxşı vasitələrindən biridir.
Məlumat və paylaşma məlumatları kimi məlumat və modellər haqqında DVC diaqramları
  • Məlumatların idarə olunması və nəsil. Məlumatların monolitini pozmaq istəyiriksə, məlumat boru kəmərindəki mənim üçün ən vacib məqamlardan biridir. Əvvəlcə məlumat platformasında onu saxlamaq üçün bir vasitəyə ehtiyacımız var. Bəzi yaxşı alternativlər var, amma yalnız ikisini tövsiyə etmək niyyətindəyəm: Lyft Ammundsen və GCP istifadə etsəniz, Məlumat Kataloqu. Onların ikisinin də məlumatların avtomatik kəşfi var. Burada vacib olan vasitə deyil, həm də konsepsiya. Boru kəmərlərimizdə paylaşdığımız məlumatların təsvirini və API vasitəsi ilə metaməlumatları alətimizə saxlamalıyıq, bu kitabxana Məlumat Kataloqunda olduğu kimi və məlumatların düzgün bir xəttinə sahib olmalıyıq. Bunun sayəsində hər kəs məlumatların harada olduğunu, sahibi kim olduğunu, necə olduğunu və hər bir dəyərin nə demək olduğunu biləcək.
Lyft Ammundsen ilə məlumatların idarə edilməsi
  • Müşahidə. Sistemimizin necə işlədiyini başa düşməliyik və bunu üç növ səviyyədən yuxarıda davam etdirəcəyik: İnfrastruktur səviyyəsi, İş səviyyəsində hadisələr və Məlumat səviyyəsi. Aydın və faydalı məlumatları olan bir tablo yaradın. Əsas məqam budur. Biz mürəkkəb sistemləri edirik, buna görə sistemlərimizin düzgün işləməsini asanlıqla başa düşmək üçün yalnız ən vacib məlumatlara tabe olmalıyıq. Bununla, gəmi baş verdikdə və olacaq, siz onu kəşf edən ilk olacaqsınız. Məlumatlarda tipik bir səhv səssiz uğursuzluqları unutmaqdır. Bir mənbə yeni məlumatlar istehsalını dayandırırsa, bu barədə əvvəlcədən xəbərdar olmalıyıq, çünki bəlkə də modellərimiz, digər xidmətlərimiz və ya biznesimiz bu məlumatlardan yüksək faizlə asılıdır. Bundan əlavə, yaxşı bir məlumat kəməri sayəsində, məsələn, bir müddətdə daha az hadisələr olduqda, nasazlıqların avtomatik anomal aşkarlanmasına nail ola bilərik.
  • Məlumat keyfiyyəti. Testlər, testlər və daha çox testlər. sınayırıq. Kodda olan testlərdən əlavə, bəzi məlumatlara ehtiyacımız var. Məsələn, bu boru kəmərindəki məhsullardan daha çox sifariş verdiyimiz təqdirdə bizə məsləhət verən bir sınaq haqqında nə düşünürsünüz? Məntiqli və faydalı görünür, elə deyilmi?
  • Məlumat təhsili alın. Maşın öyrənməsi ilə də işləyirsinizsə və məlumat alimlərimizin həyatını təmin etmək istədiyimiz üçün təlim məlumatlarını almalısınız. Burada kritik məqamlar çoxdur: əhəmiyyət kəsb edən nümunələr, məlumatları kiçik dilimlərə kəsin, bütün həssas məlumatları anonimləşdirin ... daha çox məlumat.
  • Müştərilərimizə qayğı göstəririk, onların məlumatlarına diqqət yetirməliyik, buna görə də bu məlumat hissəsində çoxlu təhlükəsizlik tələb olunur. Əgər onlarla işləmək istəsək bütün həssas məlumatların anonimləşdirilməsi vacibdir.

Bəli Juan çox gözəl, amma ...

Xilasetmə üçün həddindən artıq proqramlaşdırma

Əvvəlcə hər şeyi kod kimi davam etdirməyə davam edəcəyik, buna görə də məlumat boru kəməri.

Qəribən yanaşma ilə və ilk iterasyonda məntiq əvvəllər etdiyimiz məntiqin bir hissəsini təkrar istifadə etməkdir və XP və ümumi düşüncəmizin dediyi kimi bunu TDD ilə edəcəyik.

Sürətli bir şəkildə buna nail olmaq üçün sadə bir üsulu necə izah edəcəyimi düşünürəmsə. Bundan əlavə, uzunmüddətli perspektivdə strategiyanızı qərar verməlisiniz.

Hava axını bilirsinizsə, hər DAG-da qoymaq istədiyiniz kod növündən asılı olaraq bir çox operatorun (python_operator, http_operator, bash_operator, mysql_operator və uzun bir eteter.) Olduğunu bilirsiniz. Bu operatorlarda bəzi problemlər var. Məni daha pis olanı bunları sınamağın mürəkkəb və çirkin bir üsuludur, bundan əlavə, əgər Python'dan istifadə edirsinizsə, qarışıqlıq mövzusunda bir şeyə qulaq asacaqsınız. Bu operatorlar ilə bütün layihələrdə bütün bağlantıları quraşdırmalısınız, onlardan fərqli bir versiyaya ehtiyacınız yoxdur və Python-un eyni versiyasından istifadə etməlisiniz. Üstəlik, biz müasir bir şirkətik və poliqlot sisteminə sahib olmaq və yeni dilləri sınamaq istəyirik!

Mənim həll yolum, qəribəlik nümunəsi, docker operatoru, kubernetes_pod_operator edərkən istifadə etməkdir. Google Bəstəkardan istifadə edirsinizsə, Kubernetes-dən birini istifadə etməlisiniz və GKEContainerOperator-u heç vaxt istifadə etməməlisiniz, çünki bu resurs rəqabətinə səbəb ola bilər. Bu operatorlarla hər DAG-da icra ediləcək kod bir konteynerə daxil olacaq (python kodu, skala, java, şüa prosesləri, qığılcım prosesləri, Kafka axınları ola bilər, ümumiləşdirə bilərsiniz, təsəvvür edə biləcəyiniz hər şey var ...). TDD-ni istədiyiniz dildə istifadə edin və bəzi köhnə kodlarınızdan yenidən istifadə edə bilərsiniz. Vahid test və inteqrasiya testi aparılır ... demək olar ki!

Hələ də öz hava axınının kodunu yazmalıyıq ki, bunu da TDD edək. Hava axını hissəsinin vahid testinə daxil edilmiş tərif test hissəsi olacaqdır. Kodu göstərməzdən əvvəl Chandu Kavar və Sarang Shinde'e hava axınında test strategiyaları haqqında necə yazdığına görə təşəkkür edirəm.

Beləliklə, TDD etdiyimiz kimi, əvvəlcə bölmənin testləri:

Bu TDD ilə yaratdığımız boru kəmərinin istehsal kodudur:

Lakin vahid testi kifayət deyil, Packlink Engineering-də testlərin kodun ən vacib hissəsi olduğunu bilirik. Beləliklə, daha çox sınaqdan keçək.

İndi hava axını hissəsində inteqrasiya testlərinin vaxtı gəldi (qabların öz bölməsi və inteqrasiya testləri var). Bu yanaşma ilə buradakı inteqrasiya testləri hava axınının konfiqurasiyası və XComs ilə əlaqədardır ki, bu da hava axınının bir DAG-dakı vəzifələr arasında məlumat paylaşmağımızdır. Nümunəmizdə, packlink_hello_task-da saxlanan məlumatın stream_data_task tərəfindən götürüldüyünü sınamalıyıq:

Piramida sınağının son hissəsi e2e testləridir. Piramida içərisində e2e testləri həmişə kiçik tərəfdən olur, çünki onlar çox bahalıdır. Hava axınında bəlkə də daha çoxdur. Burada yaxşı bir nümunə görə bilərsiniz: https://github.com/chandulal/airflow-testing. Daha yaxşısını edə bilməzdim.

Nəticələr

Bu məni yazının sonuna aparır. Sadəcə yazını ümumiləşdirmək üçün burada bir nəticə çıxarmaq istədim:

  • Kod koddur. XP təcrübələrindən istifadə edin.
  • Kod monolitləri kimi məlumat monolitləri oxşar problemlərə malikdir.
  • Məhsul olaraq dəyişməz məlumat toplusunu paylaşın.
  • Tarixinizi bilin, məlumat idarəçiliyinə sevgi qoyun. Şirkətdəki hər kəs məlumatları başa düşə bilməlidir.
  • Bok olur. Müşahidəyə diqqət yetirin.
  • Onların məlumatları haqqında domenlərdən daha yaxşı heç kim bilmir. Məlumatlara bir DDD görmə tətbiq edin.
  • Packlink qaydaları !.

Resurslar və bağlantılar