Dekabrın əvvəlində ölümcül bir səhv etdim və bir developer kimi həyatımda dönüş nöqtəsi etdim və şirkət daxilində Data Engineering (DE) komandasına keçdim. Bu yazıda DE komandasında iki ay işlədiyim müddətdə etdiyim bəzi müşahidələri bölüşəcəyəm.
Niyə Data Engineering?
DE-yə səyahətim 2019-cu ilin yayında başladı gəlin gedək , və orada maariflənməyə nail oldum. Mövzu ilə maraqlanmağa, alqoritmləri və hətta onlar haqqında öyrənməyə başladım , və sonra tətbiq dairəsi haqqında düşündük və tez bir zamanda şirkətimizdə praktik tətbiqin paylanmış verilənlər bazası olduğunu öyrəndik.
Komandamız tam olaraq nə edir? Biz, bütün dəbli oğlan və qızlar kimi, Data Driven Company olmaq istəyirik. Və bunun mümkün olması üçün ən azı şirkətin ehtiyac duyduğu hesabatları hazırlamaq üçün istifadə edilə bilən etibarlı saxlama qurğusu qurmalıyıq. Ancaq ən vacibi odur ki, bu yaddaşdakı məlumatlara etibar edilməlidir. Üstəlik, bu məlumatlardan istifadə edərək, t vaxtında sistemin vəziyyətini bərpa edə bilməlisiniz. Bütün bunlar, mikroservislərin cəsarətli yeni dünyasında yaşamağımızla çətinləşir və bu ideologiya hər bir xidmətin öz kiçik funksionallığını həyata keçirdiyini, verilənlər bazası öz işi olduğunu və onu ən azı hər gün silə biləcəyini nəzərdə tutur, lakin eyni zamanda xidmətin vəziyyətini qəbul edib emal etməyi bacarmalıyıq.
Məlumata əsaslanan olmaq istəyirsinizsə, əvvəlcə Hadisələrə əsaslanan olun
O qədər də sadə deyil. Hadisələr fərqlidir və tərtibatçı və məlumat mühəndisi onlara fərqli baxırlar. Hadisələr haqqında danışmaq ayrıca məqalənin mövzusudur, ona görə də burada daxil olmayacağam. Bundan əlavə, belə bir məqalə artıq var müəyyən bir Martin Fowler, mən onun uğurlarını götürməyəcəyəm, qoy o da məşhur olsun.
Ümumiyyətlə, düşünməli çox şey var və ona görə də bu sahə cəlbedicidir. Elə olur ki, şirkətimizdə Məlumat Mühəndisi ETL/ELT boru kəmərlərini yazan şəxsdən daha geniş məsuliyyət sahəsidir (əgər siz bu ixtisarların nə demək olduğunu bilmirsinizsə, gəlin . Kontekstli reklam kimi).
Biz saxlama arxitekturası, verilənlərin modelləşdirilməsi, məlumat təhlükəsizliyi ilə bağlı məsələlər və əlbəttə ki, boru kəmərlərinin özləri ilə məşğul oluruq. Biz həmçinin əmin olmalıyıq ki, bir tərəfdən, bizim mövcudluğumuz məhsul tərtibatçıları üçün çox da ağır deyil və sistemə yeni funksiyalar kəsərkən onlar bizim tələblərimizlə mümkün qədər az diqqəti yayındırmalıdırlar, digər tərəfdən isə biz onları analitiklər və BI komandası üçün saxlama məlumatlarında rahat şəkildə təqdim etməlidir. Biz belə yaşayırıq.
İnkişafdan keçid zamanı çətinliklər
İlk iş günümdə bir sıra çətinliklərlə qarşılaşdım və onları sizinlə bölüşmək istəyirəm.
1. İlk gördüyüm tülinq və bəzi təcrübələrin olmaması oldu. Məsələn, testlərlə kod əhatəsini götürün. İnkişafda olan yüzlərlə sınaq çərçivəmiz var. Məlumatlarla işləyərkən hər şey daha mürəkkəbdir. Bəli, biz ETL boru kəmərlərini test məlumatlarında sınaqdan keçirə bilərik, lakin biz bütün bunları əl ilə etməli və hər bir konkret hal üçün həll yolları axtarmalıyıq. Nəticədə, test əhatə dairəsi daha pisdir. Xoşbəxtlikdən, monitorinq və qeydlər şəklində başqa bir rəy təbəqəsi var, lakin bu, artıq bizdən fəal şəkildə deyil, reaktiv reaksiya verməyi tələb edir ki, bu da qəzəbləndirici və əsəbidir.
2. DE nöqteyi-nəzərindən dünya heç də adi bir məhsul tərtibatçısı üçün göründüyü kimi deyil (yaxşı, əlbəttə ki, oxucu belə deyil və o, artıq hər şeyi bilir, amma mən bilmirdim və indi vida edirəm. yuxarı). Tərtibatçı kimi mən öz mikroservisimi yaradıram, məlumatları [seçdiyiniz verilənlər bazasına] qoyuram, vəziyyətimi orada saxlayıram, şəxsiyyət vəsiqəsi ilə nəsə alıram və yaxşıdır. Xidmət ləngdir, sifarişlər qarışıqdır, hamısı budur. Məndən vəziyyətimi başqa bir xidmətdə axtarmağımı xahiş edirlər, buna görə də bəzi RabbitMQ-da bir hadisə atacağam və bu qədər. Və burada yenidən yuxarıda təsvir edilən hadisələr məsələsinə qayıtdıq.
Xidmətin əməliyyat işi üçün ehtiyac duyduğu şey tarixi məlumatlar üçün bizə uyğun gəlmir, buna görə də xidmət müqavilələrinin yenidən işlənməsi və inkişaf qrupları ilə sıx iş məsələsi başlayır. Razılaşmağımız üçün neçə saat çəkdiyimizi təsəvvür belə edə bilməzsiniz: o, şirkətimizdə hansı hadisəyə əsaslanan bir insandır.
3. Başınızla düşünmək lazımdır. Xeyr, mən bunu nəzərdə tutmuram ki, tərtibatçılar düşünmürlər (baxmayaraq ki, mən kiməm ki, hamı üçün danışım), sadəcə olaraq, məhsul inkişafında çox vaxt bir növ arxitekturanız var və siz geridə qalan işlərdən fərqli qarışıqlıqları kəsirsiniz. Əlbəttə ki, bu, planlaşdırma və düşünməyi tələb edir, lakin bu, axın işidir, burada əsas problem sadəcə bunu yaxşı və səmərəli etməkdir.
Bizim üçün bu o qədər də sadə deyil, çünki müxtəlif sistem komponentlərinin isti və rahat monolitdən vəhşi mikroservis cəngəlliyi dünyasına köçürülməsi o qədər də sadə deyil. Xidmət hadisələri yaymağa başlayanda yaddaşın doldurulması məntiqini yenidən nəzərdən keçirməlisiniz, çünki məlumatlar indi fərqli görünür. Artıq bir tərtibatçı kimi deyil, məlumat mühəndisi kimi çox və hərtərəfli düşünməli olduğunuz yer budur. Günlərinizi dəftər və qələmlə və ya lövhədə markerlə keçirdiyiniz zaman bu normal bir hekayədir. Çox çətindir, düşünməyi sevmirəm, mən də istehsalı sevirəm.
4. Bəlkə də ən vacib şey məlumatdır. Bilik çatışmazlığı olanda nə edirik? Stackoverflow'u kim dedi? Bu adamı otaqdan çıxarın. Mövzu ilə bağlı sənədləri, kitabları oxumağa gedirik və forumlar, görüşlər və konfranslar təşkil edən bir cəmiyyət də var. Sənədləşmə əladır, lakin təəssüf ki, natamam ola bilər. Biz bir sıra layihələrdə Cosmos DB-dən istifadə edirik. Bu məhsulun sənədlərini oxumaqda uğurlar. Kitablar yeganə qurtuluşdur, xoşbəxtlikdən onlar mövcuddur və tapıla bilər, onlar çoxlu fundamental bilikləri ehtiva edir və çox və daim oxumaq lazımdır. Amma problem cəmiyyətdədir.
İndi bizim ərazidə ən azı bir adekvat konfrans və ya görüş tapmaq çətindir. Xeyr, əlbəttə ki, Data sözü ilə çoxlu görüşlər var, lakin bu sözün yanında adətən ML və ya AI kimi qəribə abbreviaturalar olur. Deməli, bu bizim üçün deyil, biz özümüzü neyronlarla necə ləkələməkdən deyil, saxlama anbarlarının necə qurulacağından danışırıq. Bu hipsterlər hər şeyi ələ keçirdilər. Nəticədə biz icmasız qalırıq. Yeri gəlmişkən, əgər siz Data Engineersinizsə və yaxşı icmaları bilirsinizsə, şərhlərdə yazın.
Yığıncağın yekunları və elanı
Axırımız nə ilə bitəcək? İlk təcrübəm mənə deyir ki, məlumat mühəndisi kimi hiss etmək hər bir tərtibatçı üçün faydalı olacaq. Bu, sadəcə olaraq bizə hər şeyə fərqli baxmağa imkan verir və tərtibatçıların məlumatlarına necə münasibət bəslədiyini görəndə gözlərimiz qan töküləndə təəccüblənməyək. Beləliklə, şirkətinizdə bir DE varsa, sadəcə bu uşaqlarla danışın, bir çox yeni şeylər öyrənəcəksiniz (özünüz haqqında).
Və nəhayət, elan. Gün ərzində mövzumuzla bağlı görüşlər tapmaq çətin olduğundan, özümüzünkü görüşlər etməyə qərar verdik. Niyə biz daha pisik? Xoşbəxtlikdən bizdə heyrətamiz var və bizim dostlarımız , bizim kimi məlumat mühəndislərinin ədalətsiz olaraq diqqətdən məhrum olduğunu hiss edən.
Fürsətdən istifadə edərək, maraqlanan hər kəsi 27.02.2020 fevral XNUMX-ci il tarixində Dodo Pizza ofisində keçiriləcək “DE or DIE” adlı perspektivli başlıqlı ilk icma görüşümüzə gəlməyə dəvət edirəm. Ətraflı burada .
Bir şey olarsa, orada olacağam, tərtibatçılar haqqında nə qədər səhv etdiyimi şəxsən mənim üzümə deyə bilərsiniz.
Mənbə: www.habr.com