Twoje testy danych nie powiodły się! Co teraz?

Gratulacje - pomyślnie wdrożyłeś testowanie danych w swoim potoku! Niezależnie od tego, czy korzystasz z gotowego narzędzia, czy z domowego kodu weryfikacyjnego, podjąłeś kluczowe kroki w celu zapewnienia wysokiej jakości wglądu w dane. Ale czy masz też plan na to, co się stanie, gdy twoje testy faktycznie zakończą się niepowodzeniem? W tym rozdziale omówimy kilka kluczowych etapów reagowania na niepowodzenia testów danych i krytyczne pytania, które należy zadać podczas opracowywania strategii jakości danych dla Twojego zespołu.

Odpowiedź systemu

Pierwszą linią odpowiedzi na nieudany test danych są automatyczne odpowiedzi systemu. Może to być albo nic nie robienie, izolowanie "złych" danych i kontynuowanie potoku, albo zatrzymanie potoku.

Rejestrowanie i alarmowanie

Które błędy wymagają alertów, a które można po prostu rejestrować do późniejszego wykorzystania? Jakie medium (e-mail, Slack, PagerDuty itp.) wybierzesz dla alertu, aby upewnić się, że zostanie zauważony? Jaka jest terminowość alertów (natychmiastowych, pod koniec przebiegu potoku lub w ustalonym czasie)? I wreszcie, czy alerty są wystarczająco jasne, aby respondenci zrozumieli, co się stało i powagę incydentu?

Odpowiedź na alert

Kto zobaczy te powiadomienia i na nie odpowie? Czy istnieje rotacja dyżurów? Jaki jest uzgodniony czas odpowiedzi? Czy wszyscy interesariusze wiedzą, kto jest właścicielem odpowiedzi?

Komunikacja z interesariuszami

Będziesz chciał, aby konsumenci danych wiedzieli, że "coś jest nie tak z danymi", zanim zauważą. Podczas badania problemu pomocne jest również utrzymywanie otwartej linii komunikacji z interesariuszami w celu przekazywania aktualnych informacji na temat procesu rozwiązywania problemów.

Identyfikacja pierwotnej przyczyny

Kluczem do zidentyfikowania pierwotnej przyczyny problemów z danymi jest metodyczne podejście do następujących kwestii:

•  Identyfikacja dokładnego problemu, który faktycznie się dzieje
•  Identyfikacja przyczyny problemu

Polecam nie brać niepowodzeń testowych za dobrą monetę. Na przykład test na wartości NULL w kolumnie może zakończyć się niepowodzeniem, ponieważ niektóre wiersze mają rzeczywiste wartości NULL lub ponieważ ta kolumna już nie istnieje. Zagłębienie się w przyczynę problemu ma sens dopiero wtedy, gdy jest jasne, na czym właściwie polega ten problem!

Rozwiązanie problemu

Myślimy o problemach powodujących niepowodzenia testów danych w następujących kategoriach:

•  Dane są w rzeczywistości prawidłowe, ale testy wymagają korekty. Może się tak zdarzyć, gdy istnieją nietypowe, ale poprawne wartości odstające.
•  Dane są "uszkodzone", ale można je naprawić; na przykład niepoprawnie sformatowane numery telefonów. W takim przypadku możemy wprowadzić odpowiednie zmiany w danych nadrzędnych, jeśli mamy dostęp, lub dodać logikę w kodzie potoku, aby obsłużyć te problemy.
•  Dane są "uszkodzone" i nie można ich naprawić. Może się to zdarzyć w przypadku brakujących wartości lub gdy po prostu nie mamy dostępu do danych źródłowych. W takim przypadku możemy zdecydować się na odizolowanie "uszkodzonych" rekordów i kontynuowanie działania potoku bez nich lub możemy być zmuszeni do dostosowania dalszego korzystania z danych, aby uwzględnić te problemy.

Z doskonałymi danymi wiąże się wielka odpowiedzialność

W ciągu ostatniej dekady nastąpiła eksplozja danych, w tym sposobu ich gromadzenia, przetwarzania i analizowania w różnych organizacjach, aby lepiej służyć swoim klientom. Wiele osób przyjęło tę zmianę, aby stać się firmami zorientowanymi na dane. Zarówno sprzęt, jak i oprogramowanie ewoluowały w celu obsługi systemów Big Data, ułatwiając inżynierom danych uzyskiwanie cennych informacji, które nigdy wcześniej nie były możliwe. Chociaż aplikacje oparte na danych poprawiły środowisko użytkownika, informacje o użytkowniku mogą być udostępniane aplikacjom i użytkownikom będącym poza ich kontrolą. Inżynierowie danych powinni teraz traktować te informacje z większą odpowiedzialnością.

Postaw się na miejscu użytkownika

Wiele systemów gromadzi różnego rodzaju dane osobowe o użytkownikach. Zawsze postępuj z informacjami użytkowników tak, jak z własnymi. Inżynierowie danych powinni czasami działać jako strażnicy danych podczas projektowania aplikacji danych. Zawsze powinniśmy przestrzegać standardów firmy lub branży dotyczących bezpieczeństwa i prywatności. Organizacja powinna mieć dedykowane osoby lub zespoły, które pomagają egzekwować zasady bezpieczeństwa, jednocześnie upewniając się, że są na bieżąco z nowszymi zagrożeniami.

Zapewnij etyczne wykorzystanie informacji o użytkowniku

Nawet przy narzuconych wszystkich zasadach bezpieczeństwa inżynierowie danych odpowiadają zawodowo za upewnienie się, że dane użytkowników są wykorzystywane w sposób etyczny. Zaawansowane algorytmy uczenia maszynowego i sztucznej inteligencji mogą łatwo przewidywać zachowanie i zamiary użytkownika. Musimy poświęcić trochę czasu na zastanowienie się nad implikacjami tych algorytmów oraz ich wpływem na doświadczenia i emocje użytkowników.

Obserwuj swój ślad danych

Podczas tworzenia aplikacji, które zużywają dane, należy również obserwować, w jaki sposób wykorzystywane są dane wyjściowe aplikacji. Naszym obowiązkiem jest zrozumienie, gdzie i w jaki sposób wykorzystywane są wygenerowane dane, kto ma do nich dostęp i jakie aplikacje są budowane przy użyciu tych danych. Odnosi się to również do korzystania z danych pochodnych z innych aplikacji. Postaraj się zrozumieć zamierzone użycie i postaraj się ujawnić jego użycie oryginalnemu twórcy. Obecnie ważniejsze niż kiedykolwiek wcześniej dla organizacji jest posiadanie całościowego obrazu tego, w jaki sposób wykorzystywane są informacje o użytkownikach, co z nich wynika, oraz kto ma dostęp do tych informacji.

Dlaczego zespoły zajmujące się badaniem danych potrzebują ogólnych, a nie specjalistów

W Bogactwie narodów Adam Smith pokazuje, jak podział pracy jest głównym źródłem wzrostu wydajności, na żywym przykładzie linii montażowej fabryki szpilek: Jedna osoba wyciąga drut, inna go prostuje, trzecia go przecina, czwarta wskazuje, piąta szlifuje. Dzięki specjalizacji zorientowanej na funkcję, każdy pracownik staje się wysoko wykwalifikowany w wąskim zadaniu, co prowadzi do wydajności procesu. Urok takiej wydajności skłonił nas do zorganizowania nawet naszych zespołów zajmujących się analizą danych według funkcji specjalistycznych, takich jak inżynierowie danych, inżynierowie uczenia maszynowego, naukowcy zajmujący się badaniami naukowymi, naukowcy zajmujący się wnioskowaniem przyczynowym i tak dalej. Usługi specjalistów jest koordynowana przez kierownika produktu, z przekazywaniem między funkcjami w sposób przypominający fabrykę szpilek: "jedna osoba pozyskuje dane, inna je modeluje, trzecia wdraża, czwarta mierzy" i tak dalej. Wyzwaniem związanym z tym podejściem jest to, że produkty i usługi związane z analizą danych rzadko można projektować z góry. Muszą się uczyć i rozwijać za pomocą iteracji. Jednak gdy rozwój jest rozłożony na wielu specjalistów, kilka sił może utrudnić cykle iteracji. Koszty koordynacji - czas poświęcony na komunikację, dyskusję i uzasadnianie każdej zmiany - skalują się proporcjonalnie do liczby zaangażowanych osób. Nawet przy zaledwie kilku specjalistach koszt koordynowania ich pracy może szybko przekroczyć wszelkie korzyści wynikające z podziału pracy. Jeszcze bardziej nikczemne są czasy oczekiwania między jednostkami pracy wykonywanymi przez specjalistów. Harmonogramy specjalistów są trudne do uzgodnienia, więc projekty często stoją bezczynnie, czekając na udostępnienie zasobów specjalistów. Te dwie siły mogą zakłócić iterację, co ma kluczowe znaczenie dla rozwoju produktów do nauki o danych. Aktualizacje statusu, takie jak "oczekiwanie na zmiany ETL" lub "oczekiwanie na wdrożenie ML Eng" to typowe symptomy nadmiernej specjalizacji. Zamiast organizować analityków danych według funkcji specjalistycznych, nadaj każdemu kompleksowy dostęp do różnych możliwości biznesowych. Na przykład jeden specjalista ds. danych może zbudować funkcję rekomendowania produktu, drugi może zbudować zdolność do poszukiwania klientów i tak dalej. Każdy analityk danych by wtedy wykonywał wszystkie funkcje wymagane do rozwoju każdej zdolności, od szkolenia modeli, przez ETL, po wdrożenie i pomiary. Oczywiście ci generaliści zajmujący się danymi naukowymi muszą wykonywać swoją pracę sekwencyjnie, a nie równolegle. Jednak wykonanie tej pracy zwykle zajmuje tylko ułamek czasu oczekiwania wymaganego na udostępnienie oddzielnych zasobów specjalistycznych. Tak więc czas iteracji i rozwoju ulega skróceniu. Nauka i rozwój są szybsze. Wielu uważa, że ten pomysł ogólnych specjalistów w dziedzinie nauki o danych jest zniechęcający. W szczególności umiejętności techniczne są tak trudne do zdobycia, ponieważ wielu naukowców zajmujących się danymi nie zostało przeszkolonych jako inżynierowie oprogramowania. Jednak większość złożoności technicznej można wyabstrahować dzięki solidnej platformie danych. Analitycy danych mogą być chronieni przed wewnętrznymi działaniami konteneryzacji, przetwarzania rozproszonego i automatycznego przełączania awaryjnego. Dzięki temu naukowcy zajmujący się danymi mogą bardziej skoncentrować się na naukowej stronie rzeczy, ucząc się i opracowując rozwiązania poprzez iterację.

Kiedy mówić, a kiedy słuchać

Kiedy zbliżamy się do pierwszej rocznicy mojego obecnego projektu digitalizacji w pracy, spoglądam wstecz, aby zobaczyć, czego można się nauczyć z tego doświadczenia. Projekt SWIFT miał na celu dostarczanie informacji o globalnych zakładach produkcyjnych mojego pracodawcy twórcom produktów na wcześniejszym etapie rozwoju. Wynikiem byłoby narzędzie do gromadzenia danych i raport analizy biznesowej w Tableau. Cel był dość prosty, ale napotykaliśmy ciągłe przeszkody na poziomie mikro i makro. Na poziomie makro w naszej organizacji następowały ogromne zmiany. Nasz dział przechodził strategiczną zmianę w kierunku chmury i coraz bardziej opierał się na danych. Nastąpiły znaczące restrukturyzacje organizacyjne, w tym nowy zespół analityki danych, który wchłonął moje stanowisko. W przypadku nowych projektów, takich jak SWIFT, mój zespół objął prowadzenie po stronie technicznej, a nie IT w poprzednich latach. Zmiany organizacyjne pozostawiły lukę w przywództwie dla krytycznych decyzji projektowych. Wierzę, że ta zmiana na poziomie makro była podstawą wielu wyzwań związanych z tym projektem. Na poziomie mikro byłem w centrum wszystkich dyskusji o wymaganiach. Dane wymagane do raportu końcowego nie istniały, więc wczesne rozmowy dotyczyły tego, jakie dane należy przechwycić, oraz relacji między modelowanymi podmiotami. Wstępne żądanie zostało przetłumaczone na 35 pól danych. Natychmiast odrzuciłem tę prośbę. Zastosowaliśmy metodykę Agile, aby jak najszybciej uruchomić ten projekt. Gdy tylko uzgodniliśmy mniej pól, natrafiliśmy na poważną przeszkodę. Projekt dodał nowych ekspertów merytorycznych z bardziej specjalistyczną wiedzą. Spowodowało to zakwestionowanie wcześniejszych wymagań. W każdym kolejnym spotkaniu uczestniczyło 10 lub więcej osób. Trzeba było wybiórczo podchodzić do tego, jakie pytania zadać i jak jasno przedstawić prośbę. Pamiętam, że ciągle poprawiałem swoje podejście, aby odkryć, które pary pól danych mają relację wiele do wielu. Czasami moje prośby były interpretowane nieprawidłowo, ale nigdy nie było do końca jasne, kiedy powinienem rozpocząć rozmowę. Najlepsze, co mogłem zrobić, to słuchać i czekać na właściwy początek, aby poprawić kurs. Na dzień dzisiejszy nadal pracujemy nad projektem, ale z radością mogę powiedzieć, że jesteśmy na żywo. Chociaż nadal istnieją pewne bieżące wyzwania, poczyniliśmy znaczne postępy. Zakres projektu ograniczono do dziewięciu pól, a model danych zaprojektowaliśmy w trzeciej normalnej formie, aby zmaksymalizować elastyczność dla biznesu. Bez ciągłego nacisku ze strony naszego zespołu na zmniejszenie złożoności projektu nie bylibyśmy nawet w pobliżu "uruchomienia". Ten projekt dostarczył wielu cennych lekcji. Dążenie do prostoty jest niezbędne we wszystkich dyskusjach; jednak zrozumienie, kiedy nadszedł czas na rozmowę, a nie na słuchanie, jest niezwykle subiektywne. Steve Jobs ujął to najlepiej: "Naszym zadaniem jest ustalenie, czego będą chcieć, zanim to zrobią". Jako inżynier danych czasami musisz myśleć jak Steve Jobs, aby poprowadzić różnych interesariuszy właściwą ścieżką prostoty technicznej, jednocześnie spełniając ich wymagania.

Kiedy należy uważać na udostępnianie danych

Kiedy byłem świeżo po szkole biznesowej, uczono mnie, że silosy są złe, a nawet toksyczne dla organizacji. Kiedy ludzie i działy stają się zbyt odosobnieni i skoncentrowani na sobie, mogą wystąpić wszelkiego rodzaju dysfunkcje korporacyjne. Zbędna praca staje się powszechna, sprzeczne i konkurencyjne cele podważają skuteczność organizacji, a cenne dane, z których każdy może skorzystać, pozostają zamknięte przed ich właścicielami. Chociaż te obawy są uzasadnione i się zdarzają, dowiedziałem się, że biurokracja i silosy czasami istnieją z uzasadnionych powodów. Dane mogą stać się politycznym i organizacyjnym bólem głowy, jeśli zostaną udostępnione zbyt wielu stronom. "Dlaczego?" pytasz zdziwionym tonem. "Czy nie powinno być przejrzystości oraz analizy i innowacje napędzające otwarte dane?" Oczywiście, ale udostępnianie danych jest czynnością balansującą i zależy od sytuacji. Znajdźmy oczywiste powody, dla których nie należy w pierwszej kolejności udostępniać danych. Jeśli dane są wrażliwe, najlepiej jest udzielić dostępu tylko na zasadzie potrzeby wiedzy. Jeśli baza danych jest podatna na duży ruch i kosztowne zapytania analityczne SQL, jest to kolejny oczywisty powód, dla którego nie należy zapewniać dostępu. Zazwyczaj w takiej sytuacji należy podać replikowaną bazę danych używaną do analizy, więc nie ma to wpływu na produkcyjną bazę danych. Teraz chcę przejść do mniej oczywistego powodu: czasami eksperci domenowi powinni mieć wyłączny dostęp do bazy danych i być jej strażnikami. Wiem, brzmi to biurokratycznie i okropnie, i ja również nienawidzę wyrażenia "zostaw to ekspertom". Ale wytrzymaj ze mną. Czasami poprawne nawigowanie i interpretacja specjalistycznych danych może być trudne, ponieważ wymaga to ogromnej wiedzy dziedzinowej. Jeśli nie wiesz nic o prognozowaniu przychodów, czy naprawdę masz jakaś firma przechodząca przez bazę danych prognozowania przychodów? Może powinieneś zapytać ludzi zajmujących się prognozowaniem przychodów bezpośrednio o to, czego potrzebujesz! Wiedzą, jakie dane, biznes, który odzwierciedla i które pola wymagają warunku WHERE dla Twojego zapytania. Powiedzmy, że Joe pracuje dla firmy z listy Fortune 500 i przechodzi z jednego działu do drugiego. Jego nowy dział pyta, czy mógłby pociągnąć za sznurki, aby uzyskać dostęp do danych prognostycznych z poprzedniego działu. Joe słusznie mówi im o konsekwencjach tego, o co proszą: dane są skomplikowane i ich interpretacja wymaga wiedzy specjalistycznej w pełnym wymiarze godzin. Nie jest to typ bazy danych do swobodnego przeglądania i łatwo jest wykonać nieprawidłowe zapytanie. Nie wspominając o tym, że jeśli nowy dział Joe zacznie dobrze wykonywać pracę swojego starego działu, skomplikuje to ich organizację, a to być może nadepnie na niektóre palce. Jeśli chodzi o prognozowanie pracy, gdzie teraz należy umieścić budżet i talenty? Oba działy? W najlepszym razie może to być konieczna zmiana organizacyjna, ale w najgorszym może to być zaciekła i niepotrzebna walka polityczna. Delegowanie odpowiedzialności (i danych z nią związanych) w organizacji nie jest łatwym zadaniem. Centralizacja danych i udostępnianie ich jak największej liczbie interesariuszy to szczytny cel, ale nie zawsze praktyczny. Niektóre dane powinny być udostępniane w bardziej otwarty sposób, podczas gdy inne dane powinny być przechowywane wyłącznie przez pełnoetatowych ekspertów, którzy znają je wystarczająco dokładnie, aby prawidłowo z nich korzystać.

Kiedy unikać naiwnego podejścia?

Zawsze mówią, że należy unikać nadmiernej inżynierii. Właśnie rozpocząłeś projekt i nie wiesz, co przyniesie przyszłość, więc powinieneś uczynić rozwiązanie tak prostym, jak to tylko możliwe. Nie próbuj rozwiązywać problemów, które jeszcze nie istnieją. Ale czasami koszt odkładania problemów na później może być zbyt wysoki. Kiedy masz do czynienia z dużymi ilościami danych, okazuje się, że migracje danych to skomplikowane i kosztowne procesy. Musisz napisać kod, który przekształca dane ze starego do nowego formatu, następnie musisz go uruchomić na wszystkich istniejących danych, a ostatecznie musisz idealnie zsynchronizować stary i nowy zestaw danych w czasie rzeczywistym, aby konsumenci zwyciężyli. nie zauważam żadnej zmiany. Proces ten jest kosztowny pod względem mocy pracowników i mocy komputera i zawsze niesie ryzyko wprowadzenia błędów do systemu produkcyjnego. Projektując nasz magazyn danych, powinniśmy pomyśleć o tym, jak uniknąć migracji danych w przyszłości. Powinniśmy wziąć pod uwagę dwa główne czynniki. Pierwszy to format przechowywania danych. Może to być baza danych lub format pliku, którego używamy w naszym jeziorze danych. Gdy zdecydujesz się na jeden, zmiana go będzie wymagała albo posiadania skomplikowanego systemu, który obsługuje zarówno stary, jak i nowy format, albo przeprowadzenia migracji danych. Oba są niechciane. Drugim aspektem do rozważenia jest schemat partycji. Większość dzisiejszych magazynów danych obsługuje pewnego rodzaju ewolucję schematu. Będziesz mógł dość łatwo dodawać lub usuwać pola. Ale kiedy zmienisz pola dzielące dane, musisz przenieść dane do nowych partycji. Można by pomyśleć, że na początek wystarczy użyć domyślnej technologii baz danych firmy bez partycjonowania. To może być prawda, ale jeśli wcześniej zatrzymamy się i rozważymy te dwa punkty, możemy zauważyć optymalizacje, o których już wiemy, że będziemy musieli wykonać je w przyszłości. Dlaczego więc nie pozbyć się ich od razu? Jak w przypadku większości rzeczy, nie ma jednej uniwersalnej prawdy. Warto zacząć od niezoptymalizowanego magazynu danych. Może nadal jest możliwe, że projekt nigdy nie trafi do produkcji. Może nie mamy żadnych informacji o oczekiwanych wzorcach zapytań, ale musimy szybko stworzyć prototyp. Decydując się na naiwne podejście, powinniśmy wiedzieć, że jeśli pozwolimy na zgromadzenie zbyt dużej ilości danych przed optymalizacją, później będzie to kosztowne. W takim przypadku najlepiej jest oznaczyć kamienie milowe (według ilości danych lub statusu biznesowego) ponownego przyjrzenia się projektowi, zanim będzie za późno.

Kiedy nasz zespół ds. analizy danych nie przyniósł wartości: ważna lekcja na kierowanie zespołem ds. danych

Jestem w biurze mojego szefa i informuję go o nowym pulpicie nawigacyjnym, który znacznie zwiększy dostęp do danych dla wszystkich w organizacji. Jak uderzenie w twarz, mówi: "Twój zespół danych nie może uzyskać żadnych znaczących danych". Powiedzieć, że to mnie zaskoczyło, to mało powiedziane. Wiedziałem, że zespół ciężko pracuje. Na przestrzeni lat zaprojektowaliśmy i uruchomiliśmy kilka złożonych projektów. Jednak nie miał zaufania do naszych danych ani naszej zdolności do dostarczania wartości. Szczerze zdezorientowany, próbowałem dowiedzieć się więcej o jego doświadczeniu i perspektywie. Potrzebował pilnych, reaktywnych odpowiedzi na swoje prośby o dane. Ciągle słyszał, że nie możemy dostarczyć danych. Priorytety zespołu ds. danych koncentrowały się na BI, ML i prognozowaniu. To były miejsca, w których organizacja musiała być i uzasadniała zwiększenie zasobów. Cholera, postępowaliśmy zgodnie z pięcioletnim planem! Patrząc wstecz, zbytnio skupiłem się na postępach naszych "seksownych" długoterminowych inicjatyw. A żądania danych ad hoc nie były priorytetem. Tylko te żądania z łatwym dostępem do danych zostały spełnione. Kiedy jesteś w reaktywnej organizacji, musisz poświęcić zasoby na tę misję. Byłem zdeterminowany, aby zmienić postrzeganie naszej użyteczności. Pracowaliśmy nad tym, aby zespół ustanowił nową kulturę "dochodzenia do tak" bez względu na wysiłek. Zmieniliśmy priorytety projektów i pociągnęliśmy się do odpowiedzialności. Przed tym doświadczeniem nie mieliśmy nastawienia na eksplorację. To była moja wina. Zlecałem konkretne zadania i prośby, nie tracąc czasu na ustalanie oczekiwań. Ufałem wiedzy członków mojego zespołu (poprawnie), ale nie zbadałem przyczyny odrzuconych żądań (niepoprawnie). Jako lider nie wystarczy zbudować odpowiedni zespół. Musisz także stworzyć odpowiednią postawę i kulturę. Musisz pozwolić potrzebom organizacji ustalić priorytety. Jak możesz to odwrócić? Jeśli w organizacji, w której pracujesz, brzmi to znajomo, polecam:

Pięć powodów: To moje ulubione narzędzie. Pozwala ci nakłonić zespół do zrozumienia prawdziwych ograniczeń.
Zaangażowanie interesariuszy: Spędź dużo czasu z wnioskodawcami, aby zrozumieć potrzeby. Zaangażuj większą grupę interesariuszy, aby uzyskać niewygodne dane.
Wiedza dziedzinowa: Pomóż zespołowi oprzeć się na ekspertach merytorycznych (MŚP) i spraw, aby dyskusje były dwukierunkowe. Pokaż im swoje dane i poproś, aby przeprowadzili Cię przez ich procesy.
Świadomość zewnętrzna: Wyjdź z biura. Porozmawiaj z ludźmi w innych biurach. Zrozum ich potrzeby i pragnienia.
W organizacjach, które nie opierają się na data science, musisz zrozumieć, w jaki sposób twoja praca przyczynia się do ogólnej misji. Pełniąc rolę wsparcia, miej autentyczną troskę o potrzeby i problemy organizacji. Dowiedz się, w jaki sposób Twoje narzędzia mogą zapewnić rozwiązania. Zrównoważ długoterminowe rozwiązania z krótkoterminowymi potrzebami. Zwykle dzisiejszy problem ma większe znaczenie niż problem przyszłoroczny.

Co zrobić, gdy nie otrzymasz żadnego kredytu

Spójrzmy prawdzie w oczy. Inżynierowie danych często nie otrzymują żadnego kredytu. Pochwały spadają na naukowców zajmujących się danymi, ale żaden kredyt nie spada na pustynię inżynierii danych. To niesprawiedliwe i konsekwentnie słyszę to od inżynierów danych. Niektórzy są zirytowani i zniechęceni brakiem kredytu. Niektórzy są gotowi odejść, ponieważ widzą, że ich kariery zmierzają donikąd lub nie dostaną awansu. Zacznijmy od kilku trudnych realiów. Dyrektorzy generalni, wiceprezesi i inni ludzie biznesu nie dbają o to, że korzystasz z najnowszych technologii, masz testy jednostkowe lub masz skalowalny system. Dbają o wartość biznesową stworzoną przez dane. (Oni troszczą się o te szczegóły tylko wtedy, gdy coś pójdzie nie tak.) Prawdopodobnie słyszałeś, że "dane to nowe złoto". Zgadzam się z tym stwierdzeniem. Problem polega na tym, że dane same w sobie są stosunkowo bezwartościowe. Dane stają się złotem dopiero wtedy, gdy przekształcą się w coś, co przynosi biznesowi pieniądze lub pozwala na podjęcie decyzji. Jeśli myślisz o łańcuchu wartości danych, to część związana z inżynierią danych zazwyczaj nie tworzy wartości biznesowej - ułatwia tworzenie wartości biznesowej. Analitycy danych i analitycy danych są najczęściej kreowanymi wartościami biznesowymi. To oni są w centrum uwagi, gdy pokazuje się jakiś rodzaj analizy lub wglądu. Jak więc zacząć zdobywać uznanie w swojej organizacji za to, co robisz? Jako inżynierowie danych uważamy, że kierownictwo powinno być zainteresowane technologiami, z których korzysta organizacja; nie są. To się po prostu nie zmieni. Zamiast tego, my, inżynierowie danych, musimy zacząć koncentrować się na tym, co interesuje ludzi biznesu. Musimy wyrobić sobie nawyk mówienia w języku, który rozumieją i na którym im zależy. Musimy wyjaśnić, że analizy są możliwe tylko dzięki bezpośrednim rezultatom utworzonych przez nas potoków danych. Musimy zacząć grać własnymi rogami. Może naukowcy zajmujący się danymi zaczną nawet dla nas trąbić. Zacznij lepiej mówić językiem biznesowym - a kredyty, podwyżki i promocje spadną na Ciebie.

Co to są duże zbiory danych?

Wielokrotnie słyszałeś pojęcie big data. Napisano na ten temat artykuły i książki. Być może używasz produktu, który twierdzi, że taki jest. Być może masz to nawet w swoim CV. Czy kiedykolwiek zastanawiałeś się, co to naprawdę oznacza? Big data nie ma standardowej, jasnej i uzgodnionej definicji. Niektórzy używają go do opisywania ilości danych, inni jako wskaźnik szybkości przesyłania danych, a jeszcze inni jako dane o dużej różnorodności. Żaden z nich nie ma żadnych wskaźników ilościowych, które mogą sklasyfikować zbiór danych jako duży lub mały. Wielu używa go w odniesieniu do konkretnych technologii, takich jak Hadoop, podczas gdy inni używają go do opisywania danych z określonych źródeł, takich jak media społecznościowe lub IoT, lub tak zwanych danych nieustrukturyzowanych. Istnieje wiele sprzecznych, niejasnych i niejednoznacznych definicji dużych zbiorów danych, ale żadna nie opisuje danych ani ich wykorzystania. Każdy może twierdzić, że jego produkty, usługi, technologie lub zbiory danych są big data i nie można temu zaprzeczyć. Prawda jest taka, że nie ma czegoś takiego jak big data. Duża objętość, wysoka prędkość, dane pochodzące z różnych źródeł zawsze kwestionowały naszą zdolność do czerpania z nich wartości. Nic fundamentalnego nie zmieniło się w ciągu ostatniej dekady, aby uzasadnić nową kadencję. Zarządzanie danymi zawsze polegało na stosowaniu metod analitycznych w celu uzyskania informacji, które poprawiają jakość decyzji. Nic dodać nic ująć. Do tej pory możesz zadać sobie pytanie, dlaczego tak wielu mądrych, uczciwych i pełnych dobrych intencji specjalistów od danych wierzy, że duże zbiory danych to rzeczywistość. Big data to nic innego jak rebranding istniejących ofert wymyślonych przez marketingowców, aby ożywić zainteresowanie i zwiększyć sprzedaż, i nie jest to pierwszy (i prawdopodobnie nie ostatni) taki przypadek. W Big Data at Work (Harvard Business Review Press) Thomas Davenport mówi: "To dobrze ugruntowane zjawisko, że dostawcy i konsultanci przyjmą każdy nowy gorący termin i zastosują go do swojej istniejącej oferty - i to już się stało duże zbiory danych". Aby znaleźć pierwotną przyczynę, wystarczy podążać ścieżką pieniędzy. Zwolennicy Big Data opowiadają się za tym, że musisz wszystko przechowywać i przechowywać na zawsze. Przekonuje organizacje, że muszą korzystać z najnowszych technologii, inaczej zostaną w tyle. Jestem pewien, że widzisz, do czego to zmierza. Pogoń za big data to szalona pogoń za gęsią gębą. Odwraca uwagę organizacji od tego, co jest naprawdę potrzebne do odkrycia wartości danych, inwestując w pamięć masową i najnowsze technologie zamiast poprawiać jakość danych i podejmowanie decyzji, co można osiągnąć tylko dzięki wiedzy specjalistycznej w danej dziedzinie, umiejętnościom modelowania, krytycznemu myśleniu i komunikacji. Wymagają one wykształcenia, praktyki i czasu. Niestety nie są one tak łatwe, seksowne ani tak atrakcyjne, jak fałszywa obietnica, że big data jest srebrną kulą, która rozwiąże wszystkie Twoje wyzwania związane z danymi. Musimy ponownie skoncentrować nasze wysiłki i przestać gonić za najnowszą modą, co robimy w kółko od dziesięcioleci. Poleganie na jakiejkolwiek nowej technologii lub rebranding starej skazane jest na niepowodzenie. W ciągu moich 25 lat w zarządzaniu danymi nie widziałem jeszcze technologii, która mogłaby pokonać zły projekt.

Co to jest siatka danych i jak jej nie tworzyć: przewodnik dla początkujących dotyczący wdrażania najnowszych trendów w branży

W podobny sposób, w jaki zespoły inżynierów oprogramowania przeszły z aplikacji monolitycznych do architektur mikrousług, siatka danych jest pod wieloma względami platformą danych w wersji mikrousług.

Jak po raz pierwszy zdefiniował Zhamak Dehghani, pierwotny architekt tego terminu, siatka danych to rodzaj architektury platformy danych, która obejmuje wszechobecność danych w przedsiębiorstwie, wykorzystując zorientowany na domenę, samoobsługowy projekt. Pomysł ten zapożycza z teorii projektowania opartego na domenach Erica Evansa, elastycznego, skalowalnego paradygmatu tworzenia oprogramowania, który dopasowuje strukturę i język kodu do odpowiadającej mu domeny biznesowej. W przeciwieństwie do tradycyjnych monolitycznych infrastruktur danych, które obsługują zużycie, przechowywanie, transformację i wyprowadzanie danych w jednym centralnym jeziorze danych, siatka danych obsługuje rozproszone, specyficzne dla domeny odbiorców danych i wyświetla dane jako produkt, przy czym każda domena obsługuje własne potoki danych . Jeśli jeszcze tego nie zrobiłeś, gorąco polecam przeczytanie przełomowego artykułu Dehghaniego "Jak przejść poza monolityczne jezioro danych do rozproszonej siatki danych" lub obejrzenie wykładu technicznego Maxa Schulte na temat tego, dlaczego Zalando przeszło na siatkę danych. Nie będziesz żałować.

Dlaczego warto korzystać z siatki danych?

W 2021 r. architektura du jour stanie się jeziorem danych z dostępnością danych w czasie rzeczywistym i przetwarzaniem strumieniowym, którego celem jest pozyskiwanie, wzbogacanie, przekształcanie i udostępnianie danych ze scentralizowanej platformy danych. . W przypadku wielu organizacji ten typ architektury nie spełnia kilku kryteriów:

•  Centralny potok ETL daje zespołom mniejszą kontrolę nad rosnącą ilością danych.
•  Ponieważ każda firma staje się firmą zajmującą się danymi, różne przypadki użycia danych wymagają różnego rodzaju transformacji, co bardzo obciąża centralną platformę.

Takie jeziora danych prowadzą do odłączonych producentów danych, niecierpliwych konsumentów danych, a co gorsza, zespołu danych z zaległościami, który stara się nadążyć za wymaganiami firmy. Zamiast tego architektury danych zorientowane na domenę, takie jak siatki danych, dają zespołom najlepsze z obu światów: scentralizowana baza danych (lub rozproszone jezioro danych) z domenami (lub obszarami biznesowymi) odpowiedzialnymi za obsługę własnych potoków.

Ostateczne ogniwo: obserwowalność

Ogromny potencjał wykorzystania architektury siatki danych jest jednocześnie ekscytujący i onieśmielający dla wielu przedstawicieli branży danych. W rzeczywistości niektórzy z naszych klientów obawiają się, że nieprzewidziana autonomia i demokratyzacja siatki danych wprowadza nowe zagrożenia związane z odkrywaniem i kondycją danych, a także zarządzaniem danymi. Biorąc pod uwagę względną nowość wokół siatek danych, jest to poważny problem, ale zachęcam dociekliwe umysły do przeczytania drobnym drukiem. Zamiast wprowadzać te zagrożenia, siatka danych w rzeczywistości nakazuje skalowalną, samoobsługową obserwowalność danych. W rzeczywistości domeny nie mogą naprawdę posiadać swoich danych, jeśli nie mają możliwości obserwacji. Według Zhamaka takie samoobsługowe możliwości nieodłącznie związane z każdą dobrą siatką danych obejmują:

•  Szyfrowanie danych w spoczynku i w ruchu
•  Wersjonowanie produktu danych
•  Schemat produktu danych
•  Odkrywanie produktów danych, rejestracja katalogów i publikowanie
•  Zarządzanie danymi i standaryzacja
•  Linia produkcji danych
•  Monitorowanie, ostrzeganie i rejestrowanie produktów danych
•  Mierniki jakości produktu danych

Po połączeniu te funkcje i standaryzacja zapewniają solidną warstwę wglądu w Twoje potoki.

Kim jest inżynier danych? Wskazówka: jesteśmy aktywistami Data Science

Usługi inżyniera danych nie zawsze ma tę samą seksowną konotację jako coś w rodzaju naukowca danych. Zrozumiałe jest, że tematy takie jak uczenie maszynowe i sztuczna inteligencja zawsze wygrywają w konkursie popularności. Jednak duża część pracy, która kryje się za tymi koncepcjami, wynika z inżynierii danych. Widziałem ostatnio mnóstwo artykułów mówiących o tym dokładnie: że 80% pracy data scientist to przygotowanie i czyszczenie danych.

Modele sztucznej inteligencji i uczenia maszynowego wymagają danych

Porozmawiaj z dowolnym naukowcem zajmującym się danymi, a powie Ci, że pozyskiwanie danych, zwłaszcza ze źródła, które ma absolutnie wszystko, czego potrzebują do swojego modelu, to odległe marzenie. W tym właśnie rozwijają się inżynierowie danych. Zaletą inżyniera danych jest właśnie to: inżynieria. Inżynier danych może nie tylko dostarczać dane z różnych źródeł, ale także robić to w sposób powtarzalny, aktualny, a nawet w czasie rzeczywistym.

Czyste dane == lepszy model

Ankieta z 2016 r. wykazała, że 80% prac związanych z analizą danych to przygotowywanie danych, a 75% naukowców zajmujących się danymi uważa, że jest to najnudniejszy aspekt pracy. Zgadnij, co - tutaj również rozwija się inżynier danych: czy to łączenie, czyszczenie, manipulowanie czy agregowanie danych. Wszystko to zostanie zbudowane w powtarzalny sposób, zapewniając spójne źródło świeżych, czystych danych. Analitycy danych mogą teraz poświęcać więcej czasu na ulepszanie modelu, a ich morale będzie wyższe, ponieważ nudna część ich pracy zniknie.

Wreszcie budowanie modelu

Usługi inżyniera danych nie kończy się na tym, ponieważ podczas kompilacji wielokrotne iteracje poprzednich kroków zostaną przetworzone. Jednak ta część cyklu to miejsce, w którym naukowcy zajmujący się danymi naprawdę błyszczą i nie mogę wystarczająco podkreślić, jak ważne jest, aby pozwolić im robić swoje tutaj. Wszystko, o czym do tej pory mówiłem, nie polega na tym, że chcę powiedzieć, że inżynierowie danych są lepsi lub warci więcej. Ma pokazać, że mogą umożliwić bardziej wydajne przepływy pracy dla analityków danych, aby przejść do sedna sprawy.

Model jest przydatny tylko wtedy, gdy ktoś go użyje

Model będzie musiał zostać zaimplementowany w rzeczywistej aplikacji, a jeśli martwisz się, że model stanie się przestarzały za kilka miesięcy, nie martw się. Dobry inżynier danych będzie w stanie współpracować z analitykami danych i przełożyć ich pracę na coś, co może być zasilane nowymi danymi, odbudowywać model i automatycznie go wdrażać.

Więc do czego zmierzam?

Inżynieria danych jest oczywiście ważną dziedziną do rozważenia. Możesz zobaczyć, jak wiele pracy związanej z tworzeniem i wdrażaniem modelu danych może wykonać inżynier danych. Uzyskane wydajności oznaczają, że dotarcie do punktu budowy modelu będzie szybsze, a modele będą bez wątpienia lepsze, ponieważ analitycy danych będą mieli więcej czasu na ich poprawianie i ulepszanie.

Zrozumienie, w jaki sposób różne domeny danych rozwiązują problemy

Organizacje technologiczne zwykle opracowują równoległe ścieżki dla wielu problemów dotyczących danych, które muszą działać w tandemie. Często otrzymujesz mieszankę zespołów, które obejmują inżynierię danych, uczenie maszynowe i infrastrukturę danych. Jednak te grupy często mają różne podejścia do projektowania i mają trudności ze zrozumieniem decyzji i kompromisów podejmowanych przez sąsiednich odpowiedników. Z tego powodu ważne jest, aby zespoły wczuły się w siebie i rozumiały motywy i naciski na siebie nawzajem, aby odnieść sukces w firmie opartej na danych. Odkryłem, że kilka trybów myślenia determinuje wiele początkowych założeń w szczególności w tych trzech grupach i że znajomość tych motywów pomaga wspierać lub odrzucać podejmowane decyzje. Na przykład zespoły zajmujące się analizą danych i uczeniem maszynowym często wprowadzają złożoność do narzędzi, które opracowują, aby rozwiązać swoje problemy. W większości przypadków uzyskanie dokładniejszej, bardziej precyzyjnej lub konkretnej odpowiedzi wymaga dodania większej ilości danych lub większej złożoności istniejącego procesu. Dla tych zespołów dodanie złożoności jest zatem często rozsądnym kompromisem w stosunku do wartości. Analitycy danych mają tendencję do bycia w trybie eksploracji wyników końcowych, a skupianie się na optymalizacji kroków, aby je osiągnąć, spowalnia tylko tę eksplorację, gdy większość wypróbowanych rzeczy i tak nie jest zachowywana. W przypadku infrastruktury danych często pożądana droga do sukcesu jest odwrotna. Złożone systemy mają niższą niezawodność i wymagają większych nakładów na konserwację, aby utrzymać działanie. Wybór bloków konstrukcyjnych, które są zoptymalizowane pod kątem celu końcowego, jest zwykle niezbędny do niezawodnego osiągnięcia celów skalowania po kosztach. Ponadto zespoły zajmujące się infrastrukturą danych często mają za zadanie skalowanie personelu podrzędnie do wielkości danych i potrzeb biznesowych. Wynikiem tej kombinacji jest to, że zespoły zajmujące się infrastrukturą zawsze walczą z kosztami bezpośredniej uwagi na istniejących systemach i znajdują czas na przeprojektowanie systemów o najwyższej krytyczności z wzorcami, które mogą nadal rosnąć przed pobieraniem danych. Wyraźny kontrast między modus operandi tych dwóch pierwszych grup może prowadzić do gorących rozmów na temat najlepszych sposobów rozwiązywania wspólnych problemów. Wreszcie inżynierom danych zwykle powierza się precyzyjne i dyskretne zadania polegające na tworzeniu tabel danych. Zwykle mają one bardziej dobrze zdefiniowane wyniki i wymagania organizacyjne niż problemy zespołów ich odpowiedników. Tabele muszą być dokładne, czyste i schematyczne. Sukces zależy od dobrego zdefiniowania tych umów dla dalszych konsumentów. Co więcej, zwykle mają ogromne ograniczenia czasowe, aby sprostać wymaganiom zespołów niższego szczebla. Dlatego ich rozwiązania są zwykle skoncentrowane na pilnych potrzebach zadania i wykonaniu go jak najlepiej przed przejściem do następnego. Projekty przepływów pracy związanych z inżynierią danych mają zwykle na celu rozwiązanie powtarzającej się struktury w sposób precyzyjny i wydajny. Dokładność i umowy są często ważniejsze niż długoterminowe planowanie tych problemów. Jednak świadomość długoterminowych problemów jest nadal istotnym i koniecznym problemem, który czasami dyktuje zaprojektowanie nowego wzorca dla konkretnego problemu z danymi przed powrotem do zwykłego cyklu iteracji. Ważne jest, aby z tego wyciągnąć wniosek, że nie to, że jedna grupa skupia się lepiej niż inna, ale raczej, że jeśli należysz do jednej z tych grup, bądź świadomy własnego błędu projektowego. Kryteria sukcesu naszych codziennych wysiłków w zakresie danych będą miały wpływ na to, jak patrzymy na sąsiednie problemy. Czasami opieranie się na innym sposobie myślenia w poszukiwaniu rozwiązań może prowadzić do projektu, który lepiej radzi sobie z nadchodzącymi problemami, ale warto również rozpoznać, kiedy do problemu zostanie zastosowany niedopasowany punkt skupienia.

Całkowity koszt alternatywny posiadania

Wybór odpowiedniej technologii często sprowadza się do kosztów - wymaganego czasu i pieniędzy. Całkowity koszt posiadania (TCO) jest tak stary, jak samo oprogramowanie dla przedsiębiorstw. Chociaż całkowity koszt posiadania jest podstawą od dziesięcioleci, inny koszt jest prawdopodobnie bardziej uciążliwy i znacznie mniej dyskutowany: całkowity koszt alternatywny posiadania. Ponieważ nowe technologie i paradygmaty pojawiają się i znikają w wykładniczym tempie, firmy muszą mieć otwarte możliwości i korzystać z nowych i lepszych sposobów działania. TCO składa się z dwóch dużych obszarów: ceny zakupu zasobu i ciągłego kosztu operacyjnego przez cały okres użytkowania tego zasobu. Firmy mogą zdecydować się na zakup rozwiązań zarządzanych, wdrożenie i zarządzanie rozwiązaniem open source lub wprowadzenie własnych. Każda z tych decyzji ma swoje własne kompromisy zarówno w perspektywie długoterminowej, jak i krótkoterminowej. Poza całkowitym kosztem posiadania, istnieją dwa aspekty wyboru technologii: sama technologia i paradygmat, który reprezentuje. Możesz zainwestować w technologię X, która jest częścią paradygmatu Y. Na przykład lokalny Hadoop (technologia X) na początku 2010 roku był częścią nowego ruchu big data (paradygmat Y). Jeśli w 2010 r. zainwestowałeś dużo w lokalną platformę Hadoop, prawdopodobnie uważałeś, że to sprytne posunięcie. Szybko do 2020 roku, a terminy "on-premises" i "Hadoop" wydają się przestarzałe. Od 2010 roku świat przeniósł się do chmury i istnieje wiele doskonałych alternatyw dla Hadoopa. Tymczasem Twój zespół danych poświęca znaczną ilość czasu i przepustowości na obsługę istniejącego systemu. Prawdopodobnie masz mało czasu lub energii, aby rozważyć zmianę platformy na nowoczesne rozwiązanie. Całkowity koszt alternatywny posiadania (TOCO) to koszt pozostawania w niewoli technologii X i paradygmatu Y bez korzystania z nowych technologii i platform. Jest to cena, jaką płacisz, wchodząc na całość w technologię X i paradygmat Y i nie będąc w stanie przejść na nowe paradygmaty. Założyciel Amazon, Jeff Bezos, zachęca ludzi do podejmowania decyzji z "drzwiami dwukierunkowymi", co oznacza, że można zmienić kurs lub obrać inny kierunek. Obniżenie TOCO umożliwia szybkie poruszanie się, eksperymentowanie i wprowadzanie nowych technologii i paradygmatów, które mogą znacznie usprawnić Twój biznes. Oto kilka sugestii dotyczących obniżenia TOCO:

•  Unikaj religijnych przywiązań do określonej technologii lub paradygmatu. Rzeczy szybko się zmieniają. Tak pewne, jak słońce zachodzi i wschodzi, tak samo twoja ulubiona technologia lub paradygmat w końcu stanie się przestarzały.
•  Oddzielne przetwarzanie i przechowywanie. Przechowuj swoje dane w obiektowej pamięci masowej, takiej jak Amazon S3, Azure Blob Storage lub Google Cloud Storage.
•  Używaj pojemników. Umożliwia to przenoszenie kodu między platformami i chmurami.
•  Skoncentruj się na kluczowych kompetencjach i unikaj niezróżnicowanego podnoszenia ciężkich przedmiotów. Inwestuj w usługi zarządzane, gdy tylko jest to możliwe. Uwolnij swój czas na zainwestowanie w rzeczy, które poruszają igłę dla Twojej organizacji.
•  Ucz się. Zawsze szukaj lepszych sposobów robienia rzeczy.

Technologia i paradygmaty zmieniają się z prędkością światła. Zachowaj otwarte opcje.

Narzędzia nie mają znaczenia, wzorce i praktyki mają znaczenie

Jeśli zanurzasz się w świecie inżynierii danych, łatwo jest być przytłoczonym terminami technicznymi i ramami. Większość artykułów i książek o big data zaczyna się od obszernych wyjaśnień na temat Apache Hadoop, Spark i Kafka. Zanurzając się nieco dalej w siostrzane królestwa tworzenia oprogramowania i nauki o danych, lista języków programowania i narzędzi staje się niekończącą się stertą dziwnie brzmiących terminów, o których mówisz sobie: "Powinienem to zbadać!" Znam wielu inżynierów, którzy śledzą listy frameworków i narzędzi, w które muszą się zanurzyć. Jednak to nie jest droga, jeśli dopiero zaczynasz. Zamiast uczyć się narzędzi (frameworków, produktów, języków, silników), powinieneś skupić się na koncepcjach (wspólnych wzorcach, najlepszych praktykach, technikach). Jeśli po nauce natkniesz się na nową sztuczkę, szybkie rozeznanie powinno wystarczyć, aby wiedzieć, gdzie umieścić ją w krajobrazie. Ale wszystkie te abstrakcyjne koncepcje mogą również wydawać się akademickie i na wysokim poziomie. Kluczem do sukcesu jest znalezienie zasobów edukacyjnych z dobrymi przykładami. Szukaj książek, blogów i artykułów, które nie przeskakują bezpośrednio do kodu źródłowego, ale wyjaśniają ogólne koncepcje i architekturę. Kiedy natkniesz się na interesujący fragment technologii lub termin, którego nie znasz, sztuczka polega na tym, aby zawsze zadać sobie pytanie "dlaczego": dlaczego systemy muszą być dystrybuowane? Dlaczego potrzebne jest zarządzanie danymi? Dlaczego całe zespoły i produkty po prostu wykonują ETL? Wystarczy wpisać te pytania w wyszukiwarce Google lub na Quorze, aby uzyskać doskonałe odpowiedzi bez bałaganu ze szczegółami dotyczącymi dostawcy/struktury. Następnie możesz przejść do tego, jak i co: Jak działa ten framework? Jakie przypadki użycia obsługuje? Jak współdziała z innymi technologiami? Jakie są koszty prowadzenia tego? Oto kilka praktycznych porad, które pomogą Ci we wspaniałej praktyce inżynierii danych. Wybierz koncepcję, taką jak gotowanie na parze danych, NoSQL lub programowanie funkcjonalne, które Cię interesują, i szybko przeszukaj Internet, aby poznać podstawy z dokumentacji. Wikipedia to świetny punkt wyjścia. Następnie wybierz dowolne narzędzie, które przyciągnie twoją uwagę i jest przykładem koncepcji, którą badasz (na przykład Flink, Cassandra lub Scala). Zablokuj popołudnie na dobry samouczek, uruchom swój terminal i ulubiony edytor i postępuj zgodnie z zestawem samouczków. Pamiętaj jednak, gdy podążasz dalej, że uczysz się koncepcji, a nie samego narzędzia. Nie skupiaj się zbytnio na szczegółach, takich jak składnia i konfiguracja, ale raczej zadawaj sobie pytania, dlaczego. Powodzenia!

Czas (semantyka) nie będzie czekać

Potoki danych ewoluują od przechowywania stale przychodzących danych i przetwarzania ich jako ograniczonych partii do podejść do przesyłania strumieniowego, które w sposób ciągły pozyskują i przetwarzają nieograniczone strumienie danych. Zwykle celem jest zmniejszenie opóźnień między momentem otrzymania danych a ich przetwarzaniem. Ważną różnicą między przetwarzaniem wsadowym a strumieniowym jest pojęcie kompletności. W przetwarzaniu wsadowym dane są zawsze uważane za kompletne (zgodnie z definicją danych wejściowych), ale aplikacje przetwarzające strumienie muszą uzasadnić kompletność danych wejściowych podczas pozyskiwania niepowiązanych strumieni danych. Na przykład typowym zadaniem jest obliczanie agregatów w regularnych odstępach czasu, takich jak liczenie liczby kliknięć na godzinę. Podczas implementacji takiej aplikacji do przetwarzania strumieniowego musisz zdecydować, kiedy rozpocząć, a kiedy zatrzymać zliczanie (tj. które zliczanie zwiększa się w przypadku zdarzenia). Najprostszym podejściem jest liczenie zdarzeń na podstawie czasu systemowego maszyny, na której odbywa się obliczenie. Takie podejście jest powszechnie nazywane czasem przetwarzania. Chociaż jest łatwy do wdrożenia, ma szereg niepożądanych właściwości, w tym:

•  Wyniki są niedeterministyczne i zależą od kilku czynników zewnętrznych, takich jak obciążenie maszyny przetwarzającej, prędkość podawania i przeciwciśnienie.
•  Czas przetwarzania nie uwzględnia zdarzeń, które pojawiają się poza kolejnością, co zawsze ma miejsce w środowiskach rozproszonych.

Alternatywą dla czasu przetwarzania jest czas zdarzenia. Z czasem wydarzenia każde wydarzenie ma dołączoną sygnaturę czasową. W naszym przykładzie liczenia kliknięć na godzinę każde zdarzenie kliknięcia będzie miało sygnaturę czasową określającą czas, w którym nastąpiło kliknięcie, a aplikacja do przesyłania strumieniowego użyje sygnatury czasowej zdarzenia, aby zdecydować, którą liczbę zwiększyć. Czas zdarzenia daje deterministyczne wyniki i prawidłowo obsługuje dane poza kolejnością. Dobrą ilustracją różnicy między czasem przetwarzania a czasem zdarzenia jest sekwencja filmów Gwiezdnych Wojen: rok, w którym każdy film został wydany, odpowiada czasowi przetwarzania, a rzeczywista kolejność chronologiczna działań w fabule do czasu zdarzenia



Jednak wyzwanie związane z wnioskowaniem o kompletności danych wejściowych nie jest magicznie rozwiązywane przez zdarzenia z dołączonymi znacznikami czasu. Aplikacja czasu zdarzenia potrzebuje mechanizmu do śledzenia jego postępu w czasie. Wiele procesorów strumieniowych, w tym Google Cloud Dataflow, Apache Beam i Apache Flink, wykorzystuje do tego znaki wodne. Znak wodny to komunikat metadanych, który przyspiesza czas działania aplikacji. Operatorzy używają znaków wodnych, aby zdecydować, do jakiego czasu można wykonać obliczenia. Fajną właściwością znaków wodnych jest to, że można ich użyć do dostosowania kompromisu między latencją a kompletnością. Bardziej konserwatywne znaki wodne prowadzą do pełniejszych wyników z większym opóźnieniem, podczas gdy ciaśniejsze znaki wodne dają szybsze, ale prawdopodobnie niekompletne wyniki. W końcu nie ma nic złego ani słusznego w tych semantycznych kompromisach dla aplikacji przetwarzających strumienie. Pamiętaj tylko, że czas naprawdę nie będzie czekać na Twoje dane. Chyba że mu każesz.

Wątki i współbieżność: zrozumienie awarii Amazon Kinesis 2020

W typowym nowoczesnym środowisku dane przepływają przez złożone systemy rozproszone na każdym etapie potoku danych, a serwery muszą niezawodnie utrzymywać liczne połączenia z równorzędnymi użytkownikami. Awaria Amazon Kinesis pod koniec 2020 roku ilustruje konsekwencje ignorowania problemów ze współbieżnością. Awaria, która miała miejsce 25 listopada, spowodowała utratę dużej części Internetu. W tej dyskusji założę, że przeczytałeś oficjalny raport Amazona. Raport ujawnia kilka błędów inżynieryjnych, ale skupimy się przede wszystkim na ograniczeniach współbieżności opartej na wątkach.

Wątek systemu operacyjnego

" … każdy serwer frontendowy tworzy wątki systemu operacyjnego dla każdego z pozostałych serwerów we flocie frontendowej."

W Linuksie i większości innych nowoczesnych systemów operacyjnych wątki jest mechanizm umożliwiający procesorowi wykonywanie wielu jednoczesnych zadań znacznie przekraczających liczbę dostępnych rdzeni procesora. Wątek uzyskuje dostęp do rdzenia procesora w wyznaczonym czasie; gdy skończy się czas, stan wątku jest zrzucany do pamięci systemowej, a następny wątek jest ładowany do rdzenia. Szybkie cykle pozwalają systemowi operacyjnemu zachować iluzję, że wszystkie wątki działają jednocześnie. Wątki zapewniają łatwy mechanizm zarządzania wieloma połączeniami sieciowymi.

Narzut na wątki

" … nowa pojemność spowodowała, że wszystkie serwery we flocie przekroczyły maksymalną liczbę wątków dozwoloną przez konfigurację systemu operacyjnego".

Wątki są drogie. Każdy wątek utrzymuje swój własny stos, więc tysiące połączeń zużywają znaczną ilość pamięci systemowej. Przełączanie wątków jest powolne, pochłania kilka mikrosekund czasu rdzenia, a duża liczba wątków może prowadzić do szybkiego przełączania kontekstu. Linux narzuca limit wątków, aby zapobiec zatrzymaniu systemów z powodu narzutu wątków.

Rozwiązywanie problemu C10K

Na szczęście społeczność inżynierów przezwyciężyła ograniczenia współbieżności wątków ponad dekadę temu. Nginx, wydany po raz pierwszy w 2004 roku, został zaprojektowany od podstaw do obsługi ponad 10 tysięcy jednoczesnych klientów (C10K) poprzez zadanie każdego wątku do zarządzania wieloma połączeniami. Język programowania Go buduje oprogramowanie na prymitywach współbieżności - gorutynach - które są automatycznie multipleksowane przez niewielką liczbę wątków zoptymalizowanych pod kątem dostępnych rdzeni.

Skalowanie nie jest magicznym pociskiem

Inżynierowie natywni w chmurze przyswoili sobie ideę, że skalowanie i współbieżność mogą rozwiązać każdy problem; Firmy technologiczne rutynowo uruchamiają obecnie klastry składające się z tysięcy instancji, a pojedyncze serwery mogą zarządzać ponad 10 milionami połączeń. Jednak awaria Kinesis przypomina nam, że skalowanie jest opłacalne tylko wtedy, gdy opiera się na dźwięku leżącym u podstaw inżynierii współbieżności.

Nie ma czegoś takiego jak jakość danych

Ostatnio pojawiła się coraz większa liczba narzędzi z obietnicą ochrony jakości danych w potoku poprzez rygorystyczne testy. Oczywiście testowanie ma kluczowe znaczenie dla zrównoważonej infrastruktury, więc narzędzia te są z pewnością cenne. Jednak nie powinieneś być zaskoczony, gdy usłyszysz, jak użytkownicy biznesowi Twoich danych spędzają tyle samo czasu na narzekaniu na czyszczenie danych. Często to, co konsumenci danych zgłaszają jako błędy danych lub problemy z jakością danych, nie są w rzeczywistości podstawowymi lub powszechnymi wadami danych, takimi jak brakujące lub zduplikowane rekordy. To, czy dane są odpowiednie do celu lub odpowiednie i dobrze skonstruowane dla konkretnego przypadku użycia, jest zazwyczaj największą przeszkodą dla konsumentów - w przeciwieństwie do globalnych i bezkontekstowych definicji jakości danych. Dopasowanie danych może obejmować wiele rzeczy dla analityków. Na przykład, czy dane są modelowane we właściwym podmiocie gospodarczym? Mogą tu pojawić się problemy, jeśli te same słowa reprezentują różne rzeczy w różnych kontekstach. Na przykład w danych kart kredytowych analitycy mogą szukać danych transakcyjnych w potocznym znaczeniu klientów dokonujących zakupów. Jednak inżynier danych może pomyśleć o transakcji z bardziej techniczną definicją "dowolnej modułowej jednostki pracy, która wpływa na saldo klienta" (w tym zakupy, ale także płatności, opłaty itp.). Dopasowanie danych może również odnosić się do odpowiedniego poziomu przetwarzania zastosowanego do danych w kontekście, w którym mają być używane. Na przykład otwarte dane dotyczące wejść do nowojorskiego systemu metra podają całkowitą liczbę obrotów dla każdego kołowrotu co cztery godziny, skumulowane w dowolnym czasie rozpoczęcia określonym przez czujnik i wyzerowane "losowo" (zwykle ze względu na konserwację kołowrotu). . Dane te charakteryzują się niezwykle wysoką precyzją i jakością w tym sensie, że najdokładniej przechwytują mechanizm generowania danych tego, co raportują czujniki. Jednak dla analityka, który chce badać trendy dotyczące liczby pasażerów na przestrzeni czasu, taki format jest kłopotliwy i podatny na błędy. Dopasowanie danych może być nawet funkcją interakcji wielu źródeł danych podczas procesu rozwiązywania problemów. Czy wszystkie istotne dane są przechowywane we wzajemnie dostępnej lokalizacji? Czy wspólne klucze łączenia są sformatowane w ten sam sposób? Czy źródła, które muszą być połączone, mają ten sam wymiar i strukturę? Chociaż są to drobne funkcje, które można łatwo naprawić po stronie użytkownika końcowego, mogą one wybić analityka z ich przepływu pracy i prawdopodobnie nie zostaną przechwycone przez metody walidacji z jednego źródła. Co możesz zrobić jako inżynier danych, aby pomóc swoim produktom osiągnąć dopasowanie do celu? Rozważ następujące:

•  Wyjaśnij, co mogą, a czego nie mogą obiecać Twoje surowe dane. Jasno udokumentuj, jakie kontrole danych są już prowadzone.
•  Współpracuj z analitykami danych, aby skonfigurować testy specyficzne dla użytkowania. Zastanów się, czy istnieją sposoby, aby użytkownicy mogli dodawać własne testy do istniejących wcześniej frameworków lub interaktywnie uruchamiać własne testy.
•  Zapoznaj się z typowymi wzorcami użytkowania i językiem firmy, aby pomóc w przewidywaniu optymalnych wyborów projektowych.
•  Utrzymuj niezmienione dane, ale pomóż użytkownikom szybko uzyskać dostęp do instrumentów pochodnych dopasowanych do celu.

Dwa typy inżynierii danych i inżynierów

Istnieją dwa rodzaje inżynierii danych. Istnieją dwa rodzaje zadań z tytułowym inżynierem danych. Jest to szczególnie mylące dla organizacji i osób, które zaczynają uczyć się inżynierii danych. To zamieszanie prowadzi do niepowodzenia projektów big data wielu zespołów.

Rodzaje inżynierii danych : Pierwszy rodzaj inżynierii danych koncentruje się na SQL. Usługi i podstawowe przechowywanie danych odbywa się w relacyjnych bazach danych. Całe przetwarzanie danych odbywa się za pomocą SQL lub języka opartego na SQL. Czasami przetwarzanie danych odbywa się za pomocą narzędzia ETL. Drugi rodzaj inżynierii danych skupia się na big data. Usługi i podstawowe przechowywanie danych odbywa się w technologiach Big Data, takich jak Apache Hadoop, Cassandra i HBase. Całe przetwarzanie danych odbywa się w big data frameworki, takie jak MapReduce, Spark i Flink. Podczas gdy używany jest SQL, podstawowe przetwarzanie odbywa się za pomocą języków programowania, takich jak Java, Scala i Python.

Rodzaje inżynierów danych : Te dwa typy inżynierów danych ściśle odpowiadają typom zespołów inżynierii danych. Pierwszy typ inżynierów danych przetwarza dane za pomocą SQL. Mogą korzystać z narzędzia ETL. Czasami ich tytuły to administrator bazy danych (DBA), programista SQL lub programista ETL. Inżynierowie ci mają niewielkie lub żadne doświadczenie w programowaniu. Drugi typ inżyniera danych to inżynier oprogramowania, który specjalizuje się w dużych zbiorach danych. Mają rozległe umiejętności programistyczne i potrafią pisać zapytania SQL. Główną różnicą jest to, że inżynierowie danych mają umiejętności programowania i SQL, aby wybierać między nimi.

Dlaczego te różnice są dla Ciebie ważne

Ważne jest, aby menedżerowie znali różnice między tymi dwoma typami zespołów. Czasami organizacje mają swój zespół inżynierów danych skupiony na SQL, który podejmuje próbę realizacji projektu big data. Tego rodzaju wysiłki rzadko kończą się sukcesem. W przypadku projektów Big Data potrzebny jest drugi typ inżyniera danych i zespół inżynierów danych, który koncentruje się na big data. W przypadku osób fizycznych ważne jest zrozumienie wymaganych umiejętności początkowych w przypadku dużych zbiorów danych. Chociaż istnieją interfejsy SQL do obsługi dużych zbiorów danych, potrzebujesz umiejętności programistycznych, aby wprowadzić dane do stanu, który można przeszukiwać. Dla osób, które nigdy wcześniej nie programowały, jest to trudniejsza krzywa uczenia się. Zdecydowanie zalecam, aby osoby skupione na SQL zrozumieli, ile czasu zajmuje nauka programowania i związane z tym trudności. Tylko znając i rozumiejąc te dwie definicje, możesz odnieść sukces w projektach Big Data. Koniecznie musisz mieć odpowiednich ludzi do tego zadania.

Trzy R inżynierii danych

Kiedy dorośniesz i zdobędziesz pracę jako inżynier danych, dowiesz się, że tak naprawdę są trzy zasady, które musisz znać, a w tym przypadku faktycznie zaczynają się od tej litery!

Reliability [Niezawodność] : W ostatecznym rozrachunku najważniejszą cechą Twoich danych jest to, że muszą być wiarygodne. Całe wymyślne uczenie maszynowe i wyrafinowane algorytmy na świecie nic ci nie pomogą, jeśli dostarczysz im niechlujne i niespójne dane. Zamiast zdrowych, pięknych i wartościowych systemów, o których wiesz, że mogą być, wyrosną na ohydne potwory, które pochłoną twój czas i ambicję. Rzetelność może oznaczać wiele rzeczy, ale w tym kontekście mówimy o cechach Twoich danych, które przyczyniają się do wysokiego stopnia pewności, że analizy, które przeprowadzasz, można uznać za prawidłowe. Niektóre z elementów niezawodnej platformy danych to:

•  Spójne i sprawdzone schematy. Wszystkie zapisy przebiegają według tego samego schematu i mogą być traktowane w ten sam sposób przez Twoje procesy analityczne.
•  Wysoka dostępność Twoich systemów, aby zapewnić powodzenie operacji odczytu i zapisu. Wymaga to systemów zapewniających nadmiarowość (jest jeszcze jedno słowo na R) w obliczu nieuniknionych awarii serwerów i sieci.
•  Dobrze zdefiniowane i dobrze zarządzane repozytorium metadanych, które zapewni niezbędny kontekst wokół tego, czym są dane, skąd pochodzą i jak zostały utworzone. Te pytania zostaną zadane w pewnym momencie, więc najlepiej jest mieć odpowiedzi z wyprzedzeniem.
•  Kontrola dostępu i audytowalność, aby upewnić się, że tylko osoby i procesy, które powinny mieć możliwość modyfikowania danych, faktycznie to robią.

Reproducibility [Odtwarzalność] : Odtwarzalność to kluczowa kompetencja podczas pracy z systemami o znaczeniu krytycznym dla firmy. Jeśli inny członek zespołu lub jednostka biznesowa nie ma możliwości niezależnej weryfikacji i ponownego tworzenia zestawów danych i analiz, nie ma możliwości upewnienia się, że oryginalne wyniki były prawidłowe. Ma to również wpływ na koncepcję niezawodności, ponieważ jeśli jesteś w stanie konsekwentnie odtworzyć dany zestaw danych, możesz być całkiem pewien, że jest on niezawodny i można mu zaufać, że będzie dostępny.

Repeatability [Powtarzalność] : Jeśli wszystkie Twoje serwery umrą lub centrum danych, w którym działają Twoje systemy, zostanie zniszczone lub unieruchomione w wyniku klęski żywiołowej, potrzebujesz planu naprawczego. W tym miejscu w grę wchodzi trzecie R, powtarzalność. Dobrze jest móc zbudować klaster Spark lub zainstalować bazę danych PostgreSQL, ale czy można to robić szybko i wielokrotnie? Posiadanie konfiguracji i procedur powtarzania instalacji lub wdrażania infrastruktury danych wpływa na odtwarzalność danych i wiarygodność analiz.

Wniosek

Teraz, gdy nauczyłeś się trzech R inżynierii danych, możesz mieć pewność, że zespoły i systemy zależne od wyników Twojej pracy będą szczęśliwe i skuteczne. Po prostu powiedz im, ile pracy w to włożono, aby mogli w pełni docenić twoje poświęcenie i wytrwałość.

Trzy nieocenione zalety Open Source w testowaniu jakości danych

Jako inżynier oprogramowania, który został inżynierem danych, mogę potwierdzić znaczenie danych w dzisiejszych organizacjach. Mogę również zaświadczyć, że zasady inżynierii oprogramowania dotyczące pisania testów jednostkowych i aplikacji monitorujących powinny być stosowane do danych. Jednak nawet jeśli ludzie wiedzą, że powinni testować dane, nie mają dobrych praktyk ani wiedzy, aby do tego podejść. Wpisz open source. Zgłębiam trzy obszary, w których oprogramowanie open source przedstawia korzyści z testowania danych: dla inżyniera danych, dla przedsiębiorstwa jako całości oraz dla narzędzi, które tworzą i używają programiści. Narzędzia open source są opracowywane przez inżynierów dla inżynierów; jeśli chcesz rozpocząć pracę z narzędziem do testowania danych, które naturalnie wpasuje się w Twoje przepływy pracy, musisz zacząć od open source. Oprogramowanie open source można również z łatwością osadzać w potokach inżynierii danych, bez ograniczeń licencyjnych lub ukrytych kosztów, inżynierowie danych mogą być pewni, że narzędzia open source będą działać szybko i łatwo. Dla przedsiębiorstwa opcje open source stały się świetnym sposobem na rozpoczęcie działań związanych z jakością danych. Wdrożenie podstawowych testów danych i osiągnięcie lepszej jakości danych w zaledwie kilka dni pomaga zbudować uzasadnienie biznesowe i zaczyna odkrywać problemy z danymi, pomagając uniknąć bólu związanego z ich zbyt późnym znalezieniem. Projekty open source pozwalają na bezproblemowe podejście do rozpoczęcia i szybkiego osiągania wyników. Umożliwia to znacznie większą adopcję przez organizacje i osoby prywatne. W rezultacie każdy może zbliżyć się do danych, a zespoły danych mogą szybko dostarczać wysokiej jakości, wiarygodne informacje. Połączenie oprogramowania open source z platformą opartą na chmurze zapewnia każdemu potrzebne narzędzia do pracy w sposób, w jaki lubi. Jakość danych to sport zespołowy, a łączenie open source z chmurą zapewnia zintegrowane i oparte na współpracy podejście, które zapewnia nowoczesnym zespołom danych to, czego potrzebują, aby zapewnić przejrzystość i zaufanie do danych. Dla mnie najlepszą praktyką open source jest umożliwienie wspólnej biblioteki, która obsługuje wszystko, od tworzenia narzędzi po wspólne rozwiązania dla przedsiębiorstw, a wszystko to jest łatwo dostępne dla całej organizacji. I tak naprawdę to właśnie ta zdolność do angażowania się i wprowadzania innowacji trafia w sedno największej szansy, jaką oprogramowanie open source zapewnia testowaniu danych. Mówią, że wychowanie dziecka wymaga wioski, ale to samo można powiedzieć o tworzeniu dobrej jakości danych. Rozwój oprogramowania open source jest zwiększany zarówno pod względem szybkości, jak i kreatywności dzięki zaangażowaniu społeczności, kodowaniu i testowaniu. Podczas gdy komercyjny produkt do testowania danych może mieć mały zespół zajmujący się nim, projekty open source czerpią korzyści z całych społeczności oddanych analityków danych i inżynierów. Oprogramowanie typu open source umożliwia lepsze testowanie danych zarówno osobom z profesjonalnej społeczności programistów, jak i spoza niej. Jest bezpłatny, integracyjny, stworzony specjalnie i otwarty na innowacje kierowane przez społeczność - to trzy nieocenione korzyści, które poprawiają jakość danych we wszystkich sektorach.

Sześć słów, które zniszczą twoją karierę

Sześć słów może zniszczyć twoją wiarygodność i zagrozić twojej karierze: "Ta liczba nie wygląda na prawidłową". Kiedy słyszysz te słowa, jest już za późno. Ludzie ci już nie ufają. Są podejrzliwi w stosunku do wszystkiego, co zrobiłeś do tej pory. Nagle stajesz się osobą, która popełnia błędy - osobą, która prawdopodobnie przez lata karmiła nas fałszywymi danymi. Czy jest się czym martwić? Co by było, gdyby czas był fatalny, a ktoś ostatnio podjął złą decyzję, która spowodowała, że firma straciła mnóstwo pieniędzy? Nagle każda decyzja staje się oparta na danych. Nawet ludzie, którzy przez lata ignorowali dane, twierdzą, że robili oparte na danych decyzje. Problem polega na tym, że dane są nieprawidłowe. Dane są błędne, ponieważ popełniłeś błąd! Gratulacje! Zostałeś awansowany na kozła ofiarnego! Wszyscy w firmie będą znali twoje imię. Właśnie zostałeś Wymówką Roku. Chcesz tego? Nie? Co robisz, aby uniknąć takiej sytuacji? Jak często "nadzieja" i "szczęście" są istotną częścią potoku danych? Mamy nadzieję, że format danych się nie zmieni. Jeśli nam się poszczęści, pliki zostaną przesłane, zanim wygenerujemy raport dla prezesa. Oczywiście w przypadku niepowodzenia mamy osobę, która uruchamia go ręcznie i nikt nie zauważa problemu. Inżynieria danych nie różni się od innych gałęzi wytwarzania oprogramowania. Możemy zastosować zasady programowania funkcjonalnego i przekształcić nasze potoki w coś, co przypomina funkcję. Oczywiście, dane wejściowe są ogromne, a funkcja działa przez kilka godzin, ale dla każdego danego wejścia istnieje tylko jeden poprawny wynik i możemy napisać testy, aby upewnić się, że otrzymamy to, czego oczekujemy. Czy to wydaje się banalne i oczywiste? Dlaczego więc istnieje tak wiele potoków danych bez jednej linii kodu testowego? Inne najlepsze praktyki, które możemy skopiować, pochodzą od zespołów inżynierii niezawodności witryny (SRE). Należą do nich bezwzględna automatyzacja i monitorowanie. Konfiguracja ręczna prowadzi do systemów, które są kruche, nieprzewidywalne i nie można ich naprawić. Nigdy nie wiesz, co się stanie, gdy coś zmienisz. Nie możesz stworzyć środowiska testowego, ponieważ nie znasz nawet aktualnego stanu systemu produkcyjnego. To koszmar. Podobnie brak monitorowania sprawi, że w nocy obudzisz się z krzykiem. Czy wiesz, czy Twój potok przetwarza wszystkie dane? Co jeśli spadnie o 3% i nikt o tym nie wie? Powinniśmy zbierać metryki oprzyrządowania dotyczące uruchamianego kodu i przetwarzanych danych. Byłbyś zaskoczony liczbą problemów, które można wykryć, porównując histogramy wartości wejściowych i dane wyjściowe potoku. Oczywiście wszystko to musi być zautomatyzowane jako część potoku, a cały proces musi zakończyć się niepowodzeniem, jeśli jakakolwiek walidacja wykryje nieprawidłowe wartości. W przeciwnym razie staje się ekspansywną zabawką, której nikt nie używa i nikt się nią nie przejmuje.

Wiele znaczeń braków

Brakujące dane są prawdopodobnie jednym z najlepiej zbadanych tematów w tradycyjnym zarządzaniu danymi; zapobieganie wartościom null jest podręcznikowym przykładem ograniczenia bazy danych, a wykrywanie wartości null jest takie samo w przypadku sprawdzania poprawności danych. Jednak brakujące dane nie powinny być po prostu unikane. Rozważając wiele znaczeń braków, inżynierowie danych mogą podejmować bardziej przemyślane decyzje dotyczące sposobu kodowania i komunikowania tego braku użytkownikom końcowym. Kuszące jest myślenie o braku w sposób binarny: dane istnieją lub nie. Jednak ten pogląd ignoruje potencjalnie informacyjny charakter wartości null. Braki mogą powstawać na wiele sposobów, z których każdy wiąże się z własnymi wyzwaniami analitycznymi. Na przykład może się wydawać, że brakuje zmiennej dla obserwacji z następujących powodów:

•  Prawdziwa wartość tej zmiennej istnieje, ale została załadowana nieprawidłowo.
•  Prawdziwa wartość tej zmiennej istnieje, ale celowo nie została zebrana.
•  Prawdziwa wartość tej zmiennej istnieje, ale jest nieznana.
•  Brak odpowiedniej wartości dla tej zmiennej.
•  Odpowiednia wartość tej zmiennej to null.

Aby to zilustrować, rozważ zbiór danych użytkowników rejestrujących się na internetowej platformie e-commerce:

•  Niezgodność formatów identyfikatorów kont w tabelach lub operacje arytmetyczne wykonywane przy użyciu pól o wartości null i innych niż null mogą wprowadzić wartości null.
•  Losowa próbka użytkowników jest proszona o wypełnienie ankiety, a odpowiedzi są rejestrowane tylko dla tej próby.
•  Użytkownicy mogą zostać opcjonalnie poproszeni o podanie daty urodzenia. Każdy użytkownik ma datę urodzenia, ale tylko niektóre są rejestrowane.
•  Możemy rejestrować, czy użytkownicy mobilni zarejestrowali się z urządzenia z systemem Android lub iPhone′a, ale nie ma istotnej wartości dla użytkowników, którzy zarejestrowali się z telefonu z systemem Windows
•  Sprzedawcy często chcą przypisywać ruch użytkowników do źródła odesłań adresu URL, z którego pochodzi użytkownik. Jednak w przypadku użytkowników, którzy naprawdę wpisują adres URL bezpośrednio, prawdziwa wartość witryny odsyłającej to NULL.

Dla analityków danych i naukowców korzystających z Twoich danych to rozróżnienie to coś więcej niż semantyka. Wartości null reprezentujące problem z ładowaniem danych budzą obawy dotyczące ogólnej jakości danych; wartości zerowe z losowego próbkowania mogą być bezpiecznie zignorowane; wartości null, które reprezentują aspekty informacji zwrotnych od użytkowników, mogą same stać się cechami w modelu lub analizie. . (Kontynuując poprzedni przykład, być może niechęć użytkownika do dzielenia się swoją datą urodzenia może być predyktorem rezygnacji.) Jako inżynier jesteś bliżej systemu generowania i możesz mieć więcej możliwości i wglądu w identyfikowanie pierwotnej przyczyny braków i przejście to wzdłuż. Możesz zachować znacznie więcej informacji z procesu generowania danych, identyfikując przyczynę braków i myśląc krytycznie o tym, jak przedstawić to w danych. Czy braki powinny być niejawne (na przykład brak wiersza w tabeli lub polu w JSON) czy jawne? Jeśli wartość ma wartość null, wartość wartowniczy (np. data urodzenia 1900-01-01 lub dochód 999999999) lub pole cienia (np. null w polu głównym z innym polem kategoryzującym brak). Nie ma jednego uniwersalnego rozwiązania, ale rozpoznawanie i specjalne projektowanie pod kątem takich niuansów osadza wartość w pustej informacji.

Znaczenie pochodzenia danych

Jako inżynier danych stajesz się swego rodzaju kolekcjonerem zbiorów danych pochodzących z różnych źródeł. Wyzwanie polega na tym, że zestawy danych nie są po prostu przypięte do tablicy za szkłem. Muszą być utrzymywane i aktualizowane w odpowiednim czasie. Muszą zostać przekształcone i dostosowane do różnych przypadków użycia. Z czasem zmieniają formę; wszystkie warstwy na nich zbudowane muszą zostać zaktualizowane. W miarę nawarstwiania się potoków danych złożoność dramatycznie wzrasta i staje się trudniejsze aktualizować rzeczy na czas. Obserwacja pochodzenia danych we wszystkich warstwach transformacji - od pozyskiwania po uczenie maszynowe, inteligencję biznesową i ogólnie przetwarzanie danych - zapewnia krytyczne źródło widoczności. Dzięki tym informacjom inżynier dyżurny może zrozumieć, co się dzieje i szybko rozwiązać problemy, gdy wystąpi kryzys. Lineage zapewnia zrozumienie, w jaki sposób zbiór danych został wyprowadzony z innego. Linia operacyjna idzie o krok dalej, śledząc, jak i kiedy nastąpiła ta transformacja. Przechwytuje informacje, takie jak:

•  Wersja danych wejściowych, która została zużyta
•  Podzbiór odczytanych danych
•  Wersja kodu wykonującego transformację
•  Definicja wyjścia i sposób, w jaki każda kolumna została wyprowadzona z danych wejściowych
•  Czas potrzebny na ukończenie i czy zakończyło się sukcesem
•  Wersja wyjścia, która została wyprodukowana
•  Kształt danych wyjściowych (schemat, liczba wierszy, rozkład, …)

Śledzenie zmian w pochodzeniu operacyjnym w czasie zapewnia kluczowe informacje potrzebne do szybkiego udzielenia odpowiedzi na wiele pytań pojawiających się w przypadku wystąpienia problemów związanych z danymi:

Moja transformacja zawodzi : Czy coś się zmieniło na górze? Czy zmienił się kształt moich danych wejściowych? Skąd ta zmiana się wzięła? Czy ktoś zmienił logikę transformacji, która to spowodowała?

Mój zbiór danych jest spóźniony : Gdzie jest wąskie gardło w górnym biegu? Jak wyjaśnić to wąskie gardło? Czy ostatnio stało się wolniej? Jeśli tak, co się zmieniło w jego definicji i wkładzie?

Mój zbiór danych jest nieprawidłowy : Co zmieniło się w kształcie danych? Gdzie w górę rzeki zaczął dryfować rozkład tej kolumny? Jaka zmiana logiki transformacji jest skorelowana ze zmianą kształtu danych? OpenLineage to projekt open source, który standaryzuje pochodzenie i zbieranie metadanych w całym ekosystemie danych. Dzięki platformie do gromadzenia danych inżynier danych może działać szybko i szybko naprawiać. Mogą szybko przeprowadzić analizę wpływu, aby zapobiec zepsuciu nowych zmian, odpowiadając na takie pytania, jak: Czy ta zmiana schematu zepsuje dalszych konsumentów? Kogo należy poinformować o tej zmianie semantycznej? Czy możemy wycofać ten zbiór danych?

Pochodzenie jest również podstawą wielu innych potrzeb związanych z danymi:

Prywatność : Gdzie są wykorzystywane prywatne dane moich użytkowników? Czy jest używany zgodnie z zgodą użytkownika?

Odkrycie : Jakie zbiory danych istnieją i jak są wykorzystywane? W jaki sposób ten zbiór danych pochodzi od innych? Kto jest właścicielem?

Spełnienie : Czy mogę udowodnić, że moje raportowanie jest prawidłowo wyprowadzone z moich danych wejściowych?

Zarządzanie : Czy prawidłowo wykorzystuję dane? W miarę wzrostu liczby zbiorów danych i miejsc pracy w organizacji, odpowiedzi na te pytania szybko stają się niemożliwe bez gromadzenia metadanych linii danych. Ta wiedza jest mocnym fundamentem, który umożliwia zarządzanie danymi na dużą skalę.

Implikacje twierdzenia CAP

Twierdzenie CAP zmusza nas do kompromisu między spójnością, dostępnością i tolerancją partycji w rozproszonych systemach danych: Spójność oznacza, że wszyscy klienci widzą tę samą odpowiedź na zapytanie. Dostępność oznacza, że każde zapytanie od klienta otrzymuje odpowiedź. Tolerancja partycji oznacza, że system działa, jeśli system utraci wiadomości. Jako inżynierowie danych musimy zaakceptować rozproszone dane systemu będą miały partycje, więc musimy zrozumieć kompromis między spójnością a dostępnością. Konstruowanie solidnych potoków danych wymaga od nas zrozumienia, co może pójść nie tak. Z definicji potok danych musi przenosić dane z jednego miejsca do drugiego. Oto trzy rzeczy, na które należy zwrócić uwagę, jeśli chodzi o wpływ twierdzenia na projekt systemu:

•  Próba sklasyfikowania systemów danych jako CP lub AP jest daremna. Klasyfikacja może zależeć od operacji lub konfiguracji. System może nie spełniać definicji twierdzenia o spójności i dostępności.
•  Chociaż twierdzenie CAP wydaje się w praktyce ograniczające, odcina tylko niewielką część przestrzeni projektowej. Nie zezwala na te systemy, które mają doskonałą dostępność i spójność w obecności partycji sieciowych.
•  Jedyna brana pod uwagę usterka to partycja sieciowa. Z praktyki wiemy, że musimy pomyśleć o wielu innych trybach awarii w rzeczywistych systemach.

Powiedziawszy to, twierdzenie CAP zmusza nas do zastanowienia się nad projektowaniem systemu danych. Zmusza nas do zadawania pytań o systemy, które budujemy i używamy. Wymusza na nas pewność, że spełniamy potrzebne wymagania i oczekiwania. Ale twierdzenie CAP nie mówi nic o tym, co robić, gdy wszystko działa normalnie. Twierdzenie PACELC opiera się na CAP i mówi nam, że w przypadku braku partycji kompromis jest między opóźnieniem a spójnością. Jeśli zamierzamy budować i wykorzystywać systemy danych o wysokiej dostępności, systemy te będą musiały replikować dane między węzłami. Pojedynczy węzeł to pojedynczy punkt awarii. Ta replikacja danych jest sercem kompromisu; jak długo jesteśmy gotowi czekać na replikację danych? Możemy poczekać, aż zreplikuje się do wszystkich węzłów, zanim udostępnimy je, aby zapewnić spójność, lub możemy zachować dostępność danych i zaakceptować, że niektórzy użytkownicy mogą zobaczyć nieaktualne dane. Tworzone przez nas potoki danych muszą zrozumieć te wybory. Jest to ważny krok w kierunku budowania solidnych potoków danych. Wyodrębnianie danych z bazy danych może wymagać innych opcji niż korzystanie z danych z kolejki komunikatów. Twierdzenie CAP jest ważnym wynikiem, ale to tylko niewielka część obrazu. Pozwala nam to ukształtować nasze myślenie i zrozumienie technologii, których używamy, ale nie pozwala nam przestać myśleć o tym, kim są nasi klienci i czego potrzebują.

Święta wojna między prawem autorskim a otwartym oprogramowaniem to kłamstwo

Nie musisz wybierać stron w jakiejś wyimaginowanej świętej wojnie. Oprogramowanie open source może być świetne, podobnie jak oprogramowanie własnościowe. Jedyną miarą, która nimi rządzi, jest: użyj tego, co działa najlepiej. -Paige Roberts

Wielu inżynierów i architektów danych czuje, że muszą wybrać stronę między oprogramowaniem open source a oprogramowaniem własnościowym. Ty nie. Poważnie, nie ma stron. Ci sami inżynierowie, którzy piszą zastrzeżony kod, często również piszą kod open source. A po której stronie linii znajduje się oprogramowanie z otwartym rdzeniem? A co z oprogramowaniem własnościowym z komponentami open source lub oprogramowaniem własnościowym, które pozwala na osadzenie lub zintegrowanie komponentów open source? Dlaczego do cholery się tym martwisz? Jedyną rzeczą, o którą powinien się martwić inżynier danych, jest to, jak najefektywniej wprowadzić projekt do produkcji. Główna różnica między ofertami open source a ofertami własnościowymi polega na tym, że jedna została stworzona przez programistów dla programistów, a druga przez programistów dla klientów. Klienci chcą większej łatwości użytkowania i niezawodności. Zadowoli się mniejszą kontrolą, jeśli oznacza to, że mogą szybciej wprowadzać zadania do produkcji, nie muszą zatrudniać specjalisty i mogą polegać na rozwiązaniu. Deweloperzy chcą więcej pokręteł mocy i kontroli. Zadowoli się mniejszą łatwością obsługi i niezawodnością, jeśli oznacza to większą elastyczność. Moc, elastyczność, łatwość obsługi, szybkość produkcji i niezawodność są ważne. Dokonując wyboru, pomyśl o dostępnych umiejętnościach teraz i w przewidywalnej przyszłości. Rozważ zalety szybkości produkcji w porównaniu z elastycznością na etapie rozwoju. Pomyśl o ciężarze bieżącej konserwacji i tolerancji projektu na sporadyczne przestoje. Zastanów się, czy któreś z tych pokręteł regulacyjnych jest niezbędne dla Twojego projektu. Czasami najlepiej sprawdza się oprogramowanie typu open source; innym razem będzie zastrzeżony. Czasami konieczne jest zbudowanie czegoś od podstaw, chociaż prawdopodobnie jest to najdroższe pod względem czasu i wiedzy. Niezależnie od tego, co wybierzesz tym razem, nic nie stoi na przeszkodzie, aby dokonać zupełnie innego wyboru w następnej pracy. Rozważ również integrację. Najlepsze z rasy ma wiele sensu, ale jeśli spędzasz połowę czasu, próbując uzyskać różne oprogramowanie, aby ze sobą rozmawiać, to nie jest wygrana. Możliwości integracji nie są również rozwiązaniem typu open source w przeciwieństwie do własności. Uzyskanie oprogramowania zbudowanego przez jeden zespół w celu porozumiewania się z oprogramowaniem zbudowanym przez inny jest zawsze wyzwaniem. Nawet oprogramowanie własnościowe od jednego dostawcy było czasami tworzone przez wiele zespołów i łączone bez większego zastanowienia nad integracją. Wybierz oprogramowanie, które działa i dobrze współpracuje z innymi, zwłaszcza innym oprogramowaniem, które już znasz, wymaga Twojego projektu. I spójrz, ile pracy może wykonać jedna aplikacja. Jeśli jedna rzecz może wykonać wiele części twojego zadania, zmniejszy to obciążenie związane z integracją. Oceń na podstawie swoich potrzeb, dostępnych zasobów i tego, co zapewni Twojemu projektowi największy zwrot z inwestycji.

Podejście Haiku do pisania oprogramowania

Haiku to tradycyjna forma poezji japońskiej, która kieruje się określonymi zasadami. Mają na celu wywołanie głębokich emocji lub zrozumienia za pomocą tylko trzech linijek i stałej liczby sylab. Na przykład:

Pierwszy jesienny poranek
lustro, w które wpatruję się
pokazuje twarz mojego ojca.
_Murakami Kijo

W miarę jak moje doświadczenie jako inżyniera oprogramowania rośnie, odkryłem, że piszę lepsze oprogramowanie, podchodząc do niego jak do haiku. Oto kilka lekcji, których nauczyłem się po drodze.

Zrozum ograniczenia z przodu

Kiedy tworzymy oprogramowanie, często musimy działać w ramach wąskiego zestawu ograniczeń. Ograniczenia mogą obejmować wymagania, technologie, którymi dysponujemy, zestaw umiejętności lub przepustowość zespołu oraz czas, jaki mamy na faktyczne stworzenie oprogramowania. Niezależnie od tego, czy piszesz haiku, czy oprogramowanie, jeśli zignorujesz lub nie zrozumiesz ograniczeń projektu, będziesz mieć problemy z wytworzeniem tego, co zamierzasz stworzyć. Zamiast ignorować ograniczenia, staraj się stworzyć w nich coś potężnego lub pięknego.

Zacznij mocno, ponieważ wczesne decyzje mogą mieć wpływ na produkt końcowy

Na początkowych etapach projektu jest dużo swobody. Wielu inżynierów podchodzi do nowego projektu tak, jak malarz może podchodzić do czystego płótna. Umieszczają kilka początkowych, dzikich pociągnięć pędzla w bazie kodu z zamiarem powrotu później i dodania większej struktury lub szczegółów. To malarskie podejście nie zawsze przekłada się dobrze, ponieważ początkowe pociągnięcia pędzla często nie są w ogóle nakładane na siebie, ale zamiast tego są opisywane komentarzami w stylu TODO i stają się stałymi elementami w kodzie. Podejście haiku polega na ostrożnym i celowym podejmowaniu wczesnych decyzji, więc by stały się mocnym fundamentem wszystkiego, co nastąpi później. Inymi słowy, nie pisz odpowiednika następującego haiku w swoim oprogramowaniu:

Coś coś // DO ZROBIENIA
lustro, w które wpatruję się
pokazuje twarz mojego ojca
Utrzymuj to tak proste, jak to możliwe

Niepotrzebna złożoność może zrujnować projekt. Haiku reprezentuje całość pracy z odciętym tłuszczem. Do bazy kodu należy podchodzić z taką samą ostrożnością, ponieważ złożoność zagraża długoterminowej konserwacji projektu i ułatwia ukrycie błędów. Prostota nie zawsze jest łatwa do osiągnięcia. W rzeczywistości często łatwiej jest napisać zbyt dużo kodu niż znaleźć prostsze, wydajniejsze implementacje. Z powodów, o których wspomniałem, warto włożyć dodatkowy wysiłek, aby usunąć ten dodatkowy tłuszcz z bazy kodu i zachować go tak zwięzły i prosty, jak to tylko możliwe.

Zaangażuj twórczą stronę swojego mózgu

Pisanie oprogramowania to forma sztuki. Wymaga kreatywności, dobrego podejmowania decyzji i dużo ciężkiej pracy. Jeśli nie jesteś zainteresowany projektem lub medium, znajdzie to odzwierciedlenie w produkcie końcowym. Jeśli pozwolisz sobie na kreatywne wyzwania, tak jak zrobiłby to pisarz haiku, dasz sobie możliwość stworzenia czegoś, co będzie miało wpływ na swoich klientów lub firmę, jednocześnie dobrze się przy tym bawiąc.

Koniec ETL, jaki znamy

Jeśli masz dość tego trzyliterowego terminu, tak jak ja, z przyjemnością dowiesz się, że jest inny sposób. Jeśli pracujesz z danymi w 2021 r., akronim ETL jest wszędzie. Zapytaj określone osoby, co robią, a całą ich odpowiedzią będzie "ETL". Na LinkedIn tysiące osób ma tytuł "Programista ETL". Może to być rzeczownik, czasownik, przymiotnik, a nawet przyimek. (Tak, mysz może ETL w domu.) Skrót od wyodrębniania, przekształcania i ładowania, ETL odnosi się do ogólnego procesu pobierania partii danych z jednej bazy danych lub aplikacji i ładowania ich do innej. Zespoły danych są mistrzami ETL, ponieważ często muszą wtykać brudne palce w narzędzia i bazy danych innych zespołów - inżynierów oprogramowania, marketerów i pracowników operacyjnych - aby przygotować dane firmy do głębszych, niestandardowych analiz. Dobrą wiadomością jest to, że przy odrobinie przewidywania zespoły danych mogą całkowicie usunąć większość obciążeń ETL z ich talerza. Jak to jest możliwe?

Zastąpienie ETL zamierzonym transferem danych

Ścieżką do przodu jest celowy transfer danych, czyli ITD. Potrzeba ETL pojawia się, ponieważ nikt nie buduje swojej bazy danych użytkowników ani systemu zarządzania treścią (CMS) z myślą o dalszych analizach. Zamiast zmuszać zespół ds. danych do wybierania * z tabeli_zakupów, gdzie data_zdarzenia > now() - 1 godz. co godzinę, można dodać logikę w kodzie aplikacji, która najpierw przetwarza zdarzenia i emituje je w modelu pub/sub. Bez marnowania wysiłku zespół danych może skonfigurować proces subskrybowania, aby otrzymywać te zdarzenia i przetwarzać je w czasie rzeczywistym (lub przechowywać je trwale w S3 do późniejszego wykorzystania). Wystarczy jedna odważna dusza w zespole ds. danych, aby zebrać pewność siebie i poprosić o to główny zespół inżynierów. Dziesięć lat temu zespoły danych zaczęły ustalać swoje możliwości ipotrzeby, a takie prośby mogą spotkać się ze zdrową dawką oporu. Jednak dekadę później ta wymówka już nie leci. A jeśli pracujesz w zespole zajmującym się danymi wykonującym wyłącznie tradycyjne ETL na wewnętrznych zbiorach danych, nadszedł czas, abyś ulepszył swoją grę. Istnieje kilka innych zalet IDT, na które warto zwrócić uwagę.

Uzgadnianie umowy dotyczącej modelu danych

Ile razy jeden zespół zmieniał schemat tabeli bazy danych, aby później dowiedzieć się, że zmiana spowodowała uszkodzenie raportu analitycznego? Trudno jest nawiązać komunikację między zespołami niezbędną do uniknięcia tych problemów, gdy skrypty ETL działają bezpośrednio w nieprzetworzonych tabelach bazy danych. Zamiast tego, w przypadku IDT, gdy wystąpi zdarzenie, zostanie ono opublikowane z zawsze obecnymi określonymi polami, które zostały wcześniej uzgodnione i udokumentowane. I wszyscy wiedzą, że wszelkie zmiany w tej umowie JSON muszą być najpierw komunikowane.

Usuwanie opóźnień w przetwarzaniu danych

Najczęściej zadania ETL są uruchamiane raz dziennie, w nocy. Ale pracowałem też nad projektami, w których są uruchamiane przyrostowo co 5 minut. Wszystko zależy od wymagań odbiorców danych. Zawsze będzie pewne opóźnienie między zaistniałym zdarzeniem a otrzymanym przez zespół danych, co wprowadza trudne przypadki brzegowe do aplikacji danych. Jednak w przypadku IDT wydarzenia są publikowane natychmiast po ich wystąpieniu. Korzystając z usług czasu rzeczywistego, takich jak Amazon Simple Notification Service (SNS), Amazon Simple Queue Service (SQS) i AWS Lambda, można na nie natychmiast odpowiedzieć.

Robienie pierwszych kroków

Przejście z ETL na IDT nie jest transformacją, która nastąpi z dnia na dzień dla wszystkich Twoich zestawów danych. Jednak pobranie jednego zestawu danych na początek i skonfigurowanie dla niego wzorca komunikatów pub/sub jest niezwykle wykonalne. Radzę znaleźć przypadek użycia, który najbardziej skorzystałby na przetwarzaniu danych w czasie rzeczywistym - niezależnie od tego, czy jest to kanał zawierający bieżące lokalizacje użytkowników, czy zdarzenia anulowania - a następnie przenieść go z ETL do wzorca IDT.

Nakazy i zakazy inżynierii danych

Oto rzeczy, o których żałuję, że nie wiedziałem, kiedy zaczynałem lata temu w branży danych.

Nie bądź bohaterem

Zespoły zajmujące się analizą danych pracują długie godziny, aby zrekompensować różnicę między wydajnością a oczekiwaniami. Gdy osiągnięto rezultat, zespół ds. analizy danych jest uważany za bohaterów. Każdy uwielbia zdobywać nagrody na spotkaniu firmowym; jednak heroizm jest pułapką. Bohaterowie rezygnują z równowagi między życiem zawodowym a prywatnym. Wczorajsi bohaterowie szybko zostają zapomniani gdy pojawi się nowy kryzys lub coś do spełnienia. Długie godziny w końcu prowadzą do wypalenia, niepokoju, a nawet depresji. Heroizm jest trudny do utrzymania przez długi czas i ostatecznie tylko wzmacnia fałszywe przekonanie, że istniejące zasoby i metodologie są odpowiednie.

Nie polegaj na nadziei

Kiedy trzeba dotrzymać terminu, kuszące jest szybkie stworzenie rozwiązania z minimalnymi testami, wypchnięcie go do użytkowników z nadzieją, że się nie zepsuje. Takie podejście niesie ze sobą nieodłączne ryzyko. Ostatecznie wynik będzie zawierał błędy, denerwując użytkowników i szkodząc z trudem wywalczonej wiarygodności zespołu analityki danych. Wielu specjalistów od danych rozpozna tę sytuację. Pracujesz do późna w piątek wieczorem, aby zakończyć zmiany o wysokim priorytecie. Po heroicznym wysiłku robisz to i idziesz do domu. W sobotę rano budzisz się zaskoczony. "Zapomniałem sprawdzić X. Czy właśnie złamałem analitykę?" Możesz albo spieszyć się z powrotem do pracy i spędzić weekend na testowaniu, albo odpuścić i mieć nadzieję, że wszystko jest w porządku. W tym kontekście nadzieja nie jest strategią, na której można oprzeć swoją reputację. Kilka razy ujdzie ci to na sucho, aż ci się to nie uda.

Nie licz na ostrożność

Kiedy zespół w końcu kupuje testy, częstym błędem jest spowolnienie wszystkiego. Kierownik projektu daje każdemu projektowi analizy danych dłuższy harmonogram rozwoju i testowania. W rzeczywistości jest to decyzja o zapewnieniu użytkownikom wyższej jakości, ale mniejszej liczby funkcji. Zrób to, a zespół analityki danych ryzykuje, że zostanie uznany za biurokratyczny i nieefektywny. Wkrótce każdy z wiceprezesów będzie miał swojego własnego analityka danych wśród pracowników i będą się zastanawiać, co dokładnie robisz.

Wykonaj operacje danych

Przez wiele lat przyjmowałem te rzeczy tylko jako część pracy specjalisty ds. danych. Wtedy zdałem sobie sprawę, że nie, nie musi tak być. Odkryłem, że branża oprogramowania i produkcja zmagały się z tymi samymi problemami od dziesięcioleci. Kiedy zastosowałem ich metodologie do inżynierii danych, odkryłem, że mój zespół może skrócić czas cyklu analitycznego i praktycznie wyeliminować błędy. To nowe podejście nazywa się DataOps i można je wdrożyć wraz z istniejącym łańcuchem narzędzi:

•  Zautomatyzuj tworzenie piaskownic programistycznych z danymi dla analityków danych.
•  Używaj kontenerów i innych narzędzi, które upraszczają ponowne wykorzystanie.
•  Zarządzaj rozwojem równoległym i dopasuj łańcuchy narzędzi do środowisk i kontroli źródła.
•  Wprowadzaj nowe analizy do operacji, korzystając z ciągłego wdrażania DevOps.
•  Twórz automatyczny przegląd wpływu i testuj, testuj, testuj.
•  Zorganizuj wdrażanie kodu i potoki operacji na danych- w tym testy.
•  Architekt do szybkich zmian i szybkiego odzyskiwania po przestojach.

Projektuj na taki czas, jaki sobie życzysz.

Gdy testy weryfikują dane przepływające przez potok, a także zapewniają jakość wszystkich nowych i zaktualizowanych analiz, wskaźnik błędów spada, aż do całkowitego wyeliminowania błędów. Nie ma już potrzeby heroizmu, ponieważ potoki danych są znacznie bardziej niezawodne. Nie musisz mieć nadziei, ponieważ Twoje testy dowodzą, że dane i analityka działają. Co najważniejsze, zaufanie jest utrzymywane, ponieważ analityka działa zgodnie z oczekiwaniami, a gdy tak nie jest, zespół danych jest aktywowany za pomocą automatycznych alertów. Dowiesz się przed użytkownikami, a oni podziękują Ci, gdy zadzwonisz, aby poinformować ich o tym. Najważniejsze jest to, że metodologia i narzędzia liczą się bardziej niż heroizm. Zautomatyzuj wszystko, co można zautomatyzować i skup swoją uwagę na kreatywności, która wymaga ludzkiego dotyku.

Dziesięć pytań, które trzeba zadać w projekcie inżynierii danych

Pomyśl o tym jako o liście kontrolnej pytań, które musisz zadać, zanim oszacujesz, kiedy będziesz dostarczać lub kiedy zaczniesz projektować. I zdecydowanie musisz zadać te pytania przed kodowaniem.

Pytanie 1: Jakie są punkty dotykowe?

Zidentyfikuj wszystkie źródła danych, z których będzie korzystał potok danych. Zidentyfikuj również wszystkie lokalizacje/systemy wyjściowe, które będą korzystać z produktu danych tworzonego przez potok, wraz z systemami zawierającymi konfiguracje, wyszukiwania itp.

Pytanie 2: Jakie są szczegóły?

W przypadku danego źródła danych nie zakładaj (na podstawie przykładowego zestawu danych) szczegółowości, jaką reprezentuje. Dany zbiór danych może reprezentować transakcję, firmę, kombinację obu lub agregację opartą na pewnym poziomie szczegółowości. Zapytaj o poziom szczegółowości zarówno wejściowego źródła danych, jak i wyjściowego źródła danych. Na przykład zapytaj:

•  Czy obiekt danych reprezentuje dane na poziomie transakcji; poziom transakcji podniesiony do miesięcznego, kwartalnego, rocznego; czy w ruchomym oknie?
•  Czy obiekt danych reprezentuje dane na poziomie klienta (indywidualnego lub grupy klientów)?

Pytanie 3: Jakie są schematy wejścia i wyjścia?

Przed rozpoczęciem kodowania zapytaj o schemat źródeł danych wejściowych i źródeł danych wyjściowych. Podaj przykładowe dane wyjściowe na podstawie schematu wejściowego i podanych wymagań.

Pytanie 4: Co to jest algorytm?

Większość zbioru danych tworzonych przez zespół inżynierów danych zostanie wprowadzonych do algorytmu, który wygeneruje obliczenia lub prognozę. Upewnij się, że rozumiesz dane wejściowe dla takiego algorytmu i porównaj je z wyjściowym zestawem danych, który masz utworzyć. Pod koniec dnia dane wyjściowe generowane przez potok danych muszą zawierać wszystkie elementy wejściowe algorytmu na wszystkich etapach.

Pytanie 5: Czy potrzebujesz danych uzupełniających?

Wiele algorytmów wykorzystuje heurystykę do tworzenia lepszej predykcji. Jednak podczas opracowywania naukowcy zajmujący się danymi mogą koncentrować się na mniejszym zestawie danych, ale nadal oczekują pełnej kopii zapasowej historii podczas produkcji. Takie wymagania mają wpływ na wysiłki programistyczne, termin dostawy, zasoby i koszt.

Pytanie 6: Kiedy upływa termin realizacji projektu?

W wielu przypadkach projekt może być uzależniony od innych projektów. Wyjaśnij termin płatności w odniesieniu do innych zależności.

Pytanie 7: Dlaczego ustawiono ten termin?

Teraz, gdy wyjaśniłeś termin realizacji projektu, wyjaśnij uzasadnienie, ponieważ może to prowadzić do większej liczby projektów. Zgoda na termin realizacji projektu bez zrozumienia jego wpływu na kolejny projekt może dawać fałszywe wrażenie, że będziesz realizować wiele projektów.

Pytanie 8: Jakie środowisko hostingowe?

Poproś o wyjaśnienie, gdzie będzie działać potok danych. Czy będzie hostowany wewnętrznie czy w chmurze? Z jakich kont w chmurze, uprawnień do zbiorów danych i zasobów będziesz korzystać?

Pytanie 9: Co to jest umowa SLA?

Czy zbiory danych są tworzone w czasie rzeczywistym? Partia? Kiedy ma trafić do klienta?

Pytanie 10: Kto przejmie ten projekt?

Wiele projektów będzie utrzymywanych przez inne osoby. Zapytaj o ich poziom umiejętności i rodzaj dokumentacji, której potrzebują do obsługi potoku danych.

Tech powinien zająć tylne miejsce, aby odnieść sukces w projekcie danych

Dane zawsze były stałym elementem mojej kariery. Od początku jako programista C++, aż do przejścia na inżynierię danych, moje doświadczenie w zarządzaniu rosnącą prędkością i objętością danych - w przypadkach użycia, takich jak handel o wysokiej częstotliwości - zmusiło mnie do oparcia się na najnowocześniejszych technologiach open source. Byłem jednym z tych szczęśliwców. Pracowałem z elitarną grupą dobrze opłacanych programistów u szczytu rewolucji big data. Choć byliśmy nowatorstwem, zarządzanie technologią nie było naszym największym wyzwaniem. Naszym największym wyzwaniem było zrozumienie kontekstu biznesowego i tego, co zrobić z technologią. Jako programista nie powinienem oczekiwać ode mnie konfigurowania złożonej infrastruktury, budowania i obsługi rurociągów, a także bycia ekspertem w zakresie ryzyka rynku kredytowego. Wielokrotnie byłem świadkiem, jak analitycy biznesowi odsuwali się na bok na rzecz inżynierów danych, którzy spędzali cały dzień na walce z technologiami open source z niewielkim lub żadnym kontekstem danych lub zamierzonym rezultatem. Skupienie się na technologii na pierwszym miejscu często prowadziło do Resume++, gdzie technolodzy byli wzmocnieni i zakochani w technologii, zamiast skupiać się na celach biznesowych. Rezultatem były powolne postępy, niepowodzenia projektów i przekroczenia budżetu. To szczególnie zaszkodził firmom podczas krachu w 2008 r., a widzimy ten wpływ ponownie, począwszy od 2020 r. wraz z COVID. Największy sukces i innowacyjność, jakich byłem świadkiem, ma miejsce, gdy użytkownicy końcowi (użytkownicy biznesowi, analitycy danych, analitycy danych) otrzymują odpowiednie narzędzia i dostęp do samodzielnego eksplorowania, przetwarzania i obsługi danych. Nowoczesne platformy danych są rozproszone, generalnie open source, a ich oprzyrządowanie, jeśli istnieje, nie jest gotowe do pracy w przedsiębiorstwie. Dlatego organizacje muszą zwrócić się do trudnych do znalezienia i wysoko wykwalifikowanych inżynierów. Niestety inżynierowie ci mają ograniczone zrozumienie danych i kontekstu biznesowego. Niektóre organizacje z "elitarnymi" badaniami i rozwojem opracują narzędzia samoobsługowe ogromnym kosztem. Dla osób bez elitarnych zasobów technologie te są znacznie mniej dostępne. To pogłębia przepaść między firmami działającymi w Internecie (takimi jak Google, Spotify, Uber i Amazon) a resztą branży. Technologia powinna umożliwiać dostarczanie produktów danych. Aby to osiągnąć, najlepsze w swojej klasie technologie powinny być dostępne w architekturze typu siatka danych z oddzieloną warstwą samoobsługi i zarządzania. Dzięki temu użytkownicy końcowi mogą stosować praktyki DataOps do obsługi danych i aplikacji bez wiedzy o infrastrukturze. Obciążenia powinny obejmować katalogowanie danych, opcje kontroli dostępu opartej na rolach (RBAC), maskowanie danych i możliwość tworzenia wirtualnych obszarów roboczych, które umożliwiają zespołom eksplorowanie, przetwarzanie i przenoszenie danych za pomocą aplikacji o niskim kodzie. Dostawcy chmury stworzyli "intensywność technologii", oferując rozwiązania zarządzane dla Apache Kafka, takie jak Amazon MSK, Azure HDInsight i Kubernetes. Dlatego rola inżynierów danych powinna odejść od budowania potoków i obsługi infrastruktury danych, aby skupić się na dostarczaniu narzędzia samoobsługowego, które umożliwiają użytkownikom końcowym samodzielne operowanie danymi i budowanie "intensywności danych".

Spóźnione dane

Podczas zbierania danych opartych na czasie, niektóre dane są spóźnione, niektóre osiągają spóźnienie, a niektóre są spóźnione. To sprawia, że przetwarzanie "najnowszych" danych jest trudne. Na przykład:

•  Dane śledzenia są zwykle indeksowane według czasu rozpoczęcia. Dane dla trwającego interwału są spóźnione i nie można ich jeszcze wygenerować.
•  Systemy gromadzenia danych mogą działać wolniej w przypadku awarii lub wybuchów, osiągając opóźnienia w generowanych danych.
•  Rozproszone systemy gromadzenia danych mogą opóźniać niektóre dane, narzucając im opóźnienia.

Opóźnienia występują na wszystkich poziomach potoku zbierania. Większość potoków gromadzenia jest rozproszona, a spóźnione dane docierają znacznie poza kolejnością. Spóźnienia są nieuniknione; solidna obsługa jest niezbędna. Jednocześnie dla niektórych pożądane jest zapewnienie powtarzalnych zapytań celów, a dodawanie spóźnionych danych może bezpośrednio z tym kolidować. Na przykład agregacja musi uwzględniać późne dane. Popularne strategie są do siebie dopasowane pod względem sposobu przechowywania późnych danych i zapytań o nie. Który wybór zależy w takim samym stopniu od logiki biznesowej, jak i od zalet technicznych. Koncepcyjnie najprostszą strategią jest aktualizacja istniejących danych o późniejsze dane. Każdy element danych, bez względu na to, jak późno, jest wstawiany zgodnie ze swoim znacznikiem czasu. Można to zrobić w prosty sposób z wieloma bazami danych. Można to wykonać za pomocą prostego przechowywania danych. Ale skalowanie jest trudne; na przykład nowe pliki danych lub partycje muszą zostać wygenerowane dla opóźnionych danych. Nie ma powtarzalności (bardzo późne dane mogły dotrzeć między powtórzeniami tego samego zapytania), a wszelkie przechowywane agregacje muszą zostać rozszerzone, ponownie przetworzone lub usunięte. Ta metoda jest najbardziej odpowiednia dla mniejszych skal. Modelowanie dwuczasowe pozwala nam dodać powtarzalność: dodać drugie pole serializowanego czasu przybycia magazynu do wszystkich danych. Każde zapytanie dotyczące analizy lub agregacji może filtrować czasy według sygnatury czasowej, a następnie według czasu przybycia magazynu, o którym wiadomo (poprzez serializację) w przeszłości. Agregaty uwzględniają w swoich metadanych czas nadejścia górnego magazynu, dzięki czemu zapytania mogą z nich korzystać przez filtrowanie danych, które dotarły później. Inną opcją jest zignorowanie spóźnionych danych. Ustaw stały termin ostateczny. Wszelkie dane przychodzące później niż ten termin są usuwane (najlepiej z pewną obserwowalnością). Po upływie terminu udostępnij dane do wglądu. Jest to prosta opcja do zrozumienia, wdrożenia i skalowania. Ale dla powtarzalności to się opóźnia wszystkie dane w określonym terminie, nawet jeśli wszystkie dane dotrą na czas. Jest więc bezpośrednio przydatne, jeśli istnieje odpowiednia wartość terminu. Połącz ignorowanie spóźnionych danych z efektywnym czasem przybycia, nakładając na siebie wiele wystąpień tej strategii. Ustaw sekwencję przedziałów terminów. Dane trafiają do pierwszej warstwy nie po terminie, dając skwantowany czas przybycia. Równoważnie zbieranie danych utrzymuje sekwencję wiader z coraz dłuższymi terminami. Po upływie terminu jego wiadro zostaje zapieczętowane i otwiera się nowy z tym samym terminem. Zapytania dotyczą określonego czasu i używają tylko zasobników, które w tym czasie były zapieczętowane; czas jest częścią zapytania, zapewniając powtarzalność.

Streaming różni się od Batch

Wiele organizacji dysponuje szeregiem zaawansowanych analiz przy użyciu narzędzi takich jak Hadoop, SAS i hurtownie danych. Wadą tych procesów wsadowych jest potencjalnie duże opóźnienie między przybyciem nowych danych a wydobyciem z nich użytecznych informacji, co może być niekorzystne dla konkurencji. Dlaczego więc nie przenieść tych analiz do usług przesyłania strumieniowego? Dlaczego nie przetworzyć nowych danych natychmiast i nie zminimalizować opóźnień? Kilka wyzwań utrudnia to przejście. Po pierwsze, mogą być wymagane różne narzędzia. Bazy danych mogą mieć nieoptymalną wydajność odczytu i zapisu dla ciągłych strumieni. Użyj systemu zorientowanego na dzienniki jako płyty bazowej danych, takiego jak Apache Kafka lub Apache Pulsar, aby połączyć usługi przesyłania strumieniowego, źródła i ujścia. Znane koncepcje analizy wymagają ponownego przemyślenia. Na przykład, co oznacza zapytanie SQL GROUP BY w kontekście przesyłania strumieniowego, gdy dane wciąż przychodzą i nigdy się nie zatrzymują? Chociaż SQL może wydawać się słabo przystosowany do przesyłania strumieniowego, po dodaniu okienkowania stał się popularnym narzędziem do logiki przesyłania strumieniowego; na przykład w czasie wydarzenia. GROUP BY nad oknami ma sens, ponieważ okno jest skończone. Umożliwia również dekompozycję dużych zadań wsadowych na małe, szybkie przyrosty niezbędne do przesyłania strumieniowego. Teraz jesteś gotowy do wdrożenia, ale usługi przesyłania strumieniowego są trudniejsze do utrzymania w dobrym stanie w porównaniu z zadaniami wsadowymi. Dla porównania, gdy uruchomisz zadanie wsadowe w celu przeanalizowania wszystkiego, co wydarzyło się wczoraj, może ono działać przez kilka godzin. Jeśli się nie powiedzie, naprawisz go i uruchomisz ponownie, zanim zadanie wsadowe następnego dnia będzie musiało zostać uruchomione. Podczas swojego uruchomienia może napotkać awarie sprzętu i sieci, może zauważyć skoki danych, ale szanse są niewielkie. Natomiast usługa przesyłania strumieniowego może działać przez tygodnie lub miesiące. O wiele bardziej prawdopodobne jest napotkanie znacznego wzrostu ruchu i skoków, a także awarie sprzętu i sieci. Niezawodne, skalowalne działanie jest zarówno trudniejsze, jak i ważniejsze, ponieważ teraz oczekujesz, że ta usługa będzie zawsze dostępna, ponieważ nowe dane nigdy nie przestaną napływać. Rozwiązaniem jest zaadaptowanie narzędzi zapoczątkowanych przez społeczność mikrousług, aby utrzymać długo działające systemy w dobrym stanie, bardziej odporne na awarie i łatwiejsze do dynamicznego skalowania. W rzeczywistości, teraz, gdy przetwarzamy dane w małych przyrostach, wiele usług przesyłania strumieniowego powinno zostać zaimplementowanych jako mikrousługi korzystające z bibliotek zorientowanych strumieniowo, takich jak Akka Streams i Kafka Streams, zamiast zawsze sięgać po "duże" narzędzia do przesyłania strumieniowego, takie jak Apache Spark i Apache Flink. Podsumowując:

•  Zapoznaj się z objętością na jednostkę czasu strumieni danych.
•  Zrozum swój budżet na opóźnienia.
•  Jako płyty bazowej danych użyj Apache Kafka, Apache Pulsar lub podobnych.
•  Używaj Apache Spark lub Apache Flink, gdy masz duże wolumeny lub złożone analizy (np. SQL) lub jedno i drugie.
•  Używaj mikrousług z bibliotekami przetwarzania strumieniowego, Akka Streams lub Kafka Streams, aby spełnić wymagania dotyczące niższych opóźnień i sytuacji o mniejszej objętości.

Małe pliki w świecie Big Data: największy koszmar inżyniera danych

Bez względu na to, czy potoki danych obsługują strumienie oparte na zdarzeniach w czasie rzeczywistym, w czasie zbliżonym do rzeczywistego, czy zadania przetwarzania wsadowego, pracując z ogromną ilością danych utworzonych z małych plików, napotkasz koszmar małych plików.

Co to są małe pliki i dlaczego stanowią problem?

Mały plik jest znacznie mniejszy niż rozmiar bloku pamięci. Tak, nawet w przypadku magazynów obiektów, takich jak Amazon S3 i Azure Blob, istnieje minimalny rozmiar bloku. Znacznie mniejszy plik może spowodować zmarnowanie miejsca na dysku, ponieważ pamięć masowa jest optymalizowana na podstawie rozmiaru bloku. Aby zrozumieć dlaczego, najpierw zbadajmy, jak działa odczyt i zapis. Dla operacji odczytu i zapisu, istnieje dedykowane wywołanie API. Przy pisaniu żądań magazyn zapisuje trzy składniki:

•  Same dane
•  Metadane z opisowymi właściwościami do indeksowania i zarządzania danymi
•  Globalnie unikalny identyfikator do identyfikacji w systemie rozproszonym

Więcej przechowywanych obiektów oznacza dodatkowe unikalne identyfikatory i dodatkowe wywołania we/wy do tworzenia, zapisywania i zamykania metadanych i plików danych. Aby odczytać zapisane dane, używamy wywołania API w celu pobrania określonego obiektu. Serwer sprawdza unikalny identyfikator obiektu po stronie serwera pamięci masowej i znajduje rzeczywisty adres i dysk, z którego ma odczytać. Hierarchia unikalnych identyfikatorów pomaga nam poruszać się po możliwościach przechowywania obiektów w eksabajtach. Im więcej unikalnych identyfikatorów (obiektów), tym dłużej potrwa wyszukiwanie. Spowoduje to niższą przepustowość ze względu na czas wyszukiwania i wymagane wyszukiwanie dysków. Co więcej, przekłada się to na narzut milisekund dla każdej operacji składnicy obiektów, ponieważ serwer tłumaczy każdy interfejs API na zdalne wywołania procedur (RPC). Gdy serwer osiągnie limity lub pobranie danych zajmie zbyt dużo czasu, wywołanie interfejsu API do odczytu lub zapisu otrzyma kod błędu, taki jak 503 (serwer zajęty) lub 500 (przekroczenie limitu czasu operacji). Radzenie sobie z tymi błędami jest straszne dzięki narzędziom Amazon Athena, Azure Synapse i Apache Spark, ponieważ abstrahują one dla nas od potrzeb związanych z pamięcią masową.

Dlaczego tak się dzieje?

Przyjrzyjmy się trzem ogólnym przypadkom skutkującym małymi plikami. Po pierwsze, podczas procedury pozyskiwania strumienie zdarzeń pochodzące z urządzeń, serwerów lub aplikacji Internetu rzeczy (IoT) są tłumaczone na pliki JSON w skali kilobajtów. Zapisywanie ich w pamięci obiektowej bez łączenia/pakowania i kompresowania wielu plików razem spowoduje powstanie wielu małych plików. Po drugie, małe pliki mogą wynikać z nadmiernie równoległych zadań Apache Spark. W przypadku zadań przetwarzania wsadowego lub strumieniowego nowy plik jest zapisywany na każde zadanie zapisu; więcej zadań pisania Spark oznacza więcej plików. Posiadanie nadmiernie równoległych zadań dotyczących rozmiaru danych może skutkować wieloma małymi plikami. Przekrzywienie danych może mieć podobny efekt, w którym większość danych jest kierowana do jednego lub kilku autorów, co oznacza, że wielu autorów pozostaje z małymi porcjami danych do przetworzenia i zapisania; każdy zapisuje mały, przetworzony fragment danych do małego pliku. Po trzecie, nadmiernie partycjonowane tabele Hive mogą wynikać z gromadzenia danych w tabelach codziennie lub co godzinę. Zgodnie z ogólnym podejściem, jeśli partycja Hive jest mniejsza niż ~ 256 MB, rozważ przejrzenie projektu partycji i dostosuj konfiguracje plików scalania Hive przy użyciu hive.merge.smallfiles.avgsize i hive.merge.size.per.task.

Wykryj i łagodź

Aby rozwiązać problem małych plików, najpierw zidentyfikuj główną przyczynę. Czy jest to procedura przetwarzania, czy przetwarzanie wsadowe offline? Sprawdź rozmiary plików partycji Hive, programy zapisujące zadania Spark w interfejsie użytkownika History Server oraz rzeczywisty rozmiar plików podczas pozyskiwania. Po drugie, napraw to. Jeśli optymalizacja procedury przetwarzania w celu wygenerowania większych plików nie rozwiąże problemu, spójrz na funkcję podziału na partycje Spark (repartition_by_range) i funkcję łączenia, aby zestawić małe pliki razem. Spark 3.0 udostępnia wskazówki dotyczące partycjonowania, aby zasugerować konkretną strategię składania do aparatu Spark SQL.

Wniosek

Uważaj na małe pliki podczas projektowania potoków danych. Staraj się ich unikać, ale wiedz, że też możesz je naprawić!

Sześć wymiarów do pobrania analitycznej hurtowni danych.

Hurtownia danych (DWH) odgrywa kluczową rolę w ekosystemie danych. Często jest to również najdroższy element infrastruktury danych do wymiany, dlatego ważne jest, aby wybrać odpowiednie rozwiązanie, które będzie działać dobrze przez co najmniej siedem lat. Ponieważ analizy są wykorzystywane do podejmowania ważnych decyzji biznesowych, wybór niewłaściwego DWH jest pewnym sposobem na stworzenie kosztownego wąskiego gardła dla Twojej firmy. W tym artykule proponuję sześć wymiarów oceny rozwiązania hurtowni danych dla następujących przypadków użycia:

•  Pozyskiwanie i przechowywanie wszystkich danych analitycznych
•  Wykonywanie transformacji danych (T of ELT)
•  Udostępnianie danych konsumentom (zasilanie pulpitów nawigacyjnych i ad hoc analiza)
Skalowalność: firmy, które wybierają słabo skalowalne hurtownie danych, płacą ogromny podatek od swojej produktywności, gdy ich DWH nie może już rosnąć: zapytania są zaległe, użytkownicy są blokowani, a firma jest zmuszona do migracji do lepiej skalowanej DWH. Jednak w momencie odczuwania bólu jest już za późno: migracje są powolne (lata), bolesne i prawie nigdy nie zakończone. Skalowalność hurtowni danych oznacza trzy rzeczy:

- Możesz łatwo zwiększyć ilość miejsca do magazynowania, kiedy tylko jest to potrzebne i przy stałej (jeśli nie malejącej) cenie jednostkowej.
-Można skalować zasoby obliczeniowe, aby mieć jak najwięcej zadań przetwarzania danych działających jednocześnie bez spowalniania siebie nawzajem i skrócić czas wykonywania każdego zadania.
-Można skalować zasoby pamięci masowej i obliczeniowe niezależnie od siebie, w zależności od tego, gdzie znajduje się wąskie gardło.

Elastyczność cenowa: Ceny DWH można podzielić na dwie główne kategorie:

- Oparte na zasobach (np. płatność za węzeł o określonej konfiguracji)
-W oparciu o wykorzystanie (np. płatność za gigabajt zeskanowanych danych lub czas procesora)

Biorąc pod uwagę naturalną zmienność wielkości obciążenia analitycznego ze względu na godziny pracy i harmonogramy ETL/ELT, ustalanie cen na podstawie użytkowania jest zwykle bardziej ekonomiczne z następujących powodów:

-Dostosowuje zachęty dla dostawców do Twojego najlepszego interesu, zmuszając ich do zwiększenia wydajności (szybkości) ich oprogramowania. W przeciwieństwie do tego, dostawcy pobierający opłaty za węzeł są zachęcani do sprzedawania większej ilości zasobów obliczeniowych zamiast zwiększania ich wydajności.
- Ceny oparte na użytkowaniu zapewniają jasną ścieżkę do optymalizacji kosztów aby mniej zapłacić . Proste taktyki, takie jak eliminacja zbędnych podzapytań w ETL lub dodawanie filtrów do dashboardów, są natychmiastowe skuteczne w obniżaniu kosztów.

Interoperacyjność : Mówiąc najprościej, potrzebujesz DWH, z którego można łatwo pobierać i wyprowadzać dane. Wybierając rozwiązanie, które jest obsługiwane przez głównych dostawców kolekcji, integracji i BI, zaoszczędzisz sobie wielu problemów.

Funkcje zapytań i transformacji : chociaż wymagania dotyczące funkcji zależą w dużej mierze od charakteru firmy, należy pamiętać o tych dwóch kwestiach dotyczących funkcjonalności DWH:

- Optymalizacja dla przeciętnego użytkownika: biorąc pod uwagę, że zdecydowana większość dzisiejszych użytkowników DWH nie jest inżynierami z wykształcenia, przedkładaj ich doświadczenie nad funkcje zasilania.
- Twoja główna DWH nie musi zajmować się każdym specjalistycznym przypadkiem użycia, w tym uczeniem maszynowym lub analizą geoprzestrzenną i szeregów czasowych. Jeśli DWH jest interoperacyjne, zawsze możesz podłączyć specjalistyczne oprogramowanie do odpowiedniego zadania.

Szybkość : jednym z typowych scenariuszy awarii w planowaniu infrastruktury danych jest nadmierna optymalizacja pod kątem szybkości. W skali tera/petabajtów w hurtowni danych chodzi o kompromisy. Nie możesz jednocześnie uzyskać nieskończonej skalowalności i szybkości zapytań poniżej sekundy. Szybkość ma znaczenie w dwóch podstawowych aspektach:

- Podczas opracowywania obciążenia/zapytania, które odbywa się na mniejszych ilościach danych, zadania powinny być wykonywane szybko i szybko kończyć się niepowodzeniem, aby uniknąć blokowania przepływów pracy przez ludzi.
-W produkcji "wystarczająco dobry" czas wykonania jest wystarczająco dobry, o ile jest spójny i można go utrzymać w miarę wzrostu danych (do punktu skalowalności).

Test porównawczy TPC-DS przeprowadzony przez Fivetran pokazuje, że większość silników głównego nurtu (stan na 2021 r.) jest mniej więcej na tym samym polu pod względem osiągów.

Zerowa konserwacja: nowoczesne hurtownie danych to złożone i rozproszone oprogramowanie, którego wdrażanie i uruchamianie nie jest proste, nie mówiąc już o programowaniu. Jeśli masz ochotę na nowy, obiecujący silnik open source, pamiętaj, aby uwzględnić pełny koszt posiadania i dokładnie ocenić przypadek użycia i kompromisy. Wybór rozwiązania DWH, które nie wymaga od Ciebie żadnych zasobów do zarządzania, pozwala skupić się na budowaniu produktu skierowanego do klienta.

Skalowanie jest łatwe / skalowanie jest trudne: skalowanie dużych zbiorów danych Yin i Yang

Nowoczesne technologie big data, takie jak Apache Cassandra i Apache Kafka, osiągają ogromną skalowalność dzięki wykorzystaniu klastrów wielu węzłów (serwerów) w celu zapewnienia skalowalności poziomej. Skalowanie poziome polega na (1) współdzieleniu obciążeń na wszystkie węzły w klastrze poprzez partycjonowanie danych, tak aby każdy węzeł zawierał podzbiór danych, (2) umożliwianie zwiększenia przepustowości poprzez proste dodanie większej liczby węzłów oraz (3) replikację kopie danych w więcej niż jednym węźle pod kątem niezawodności, dostępności i trwałości. Będąc wewnętrznie skalowalnymi, Cassandra i Kafka są popularnymi rozwiązaniami typu open source do uruchamiania aplikacji o małych opóźnieniach, wysokiej przepustowości i dużej ilości danych, które można łatwo skalować. Niedawno zaprojektowaliśmy, przetestowaliśmy i skalowaliśmy demonstracyjną aplikację do wykrywania anomalii z Cassandrą w warstwie pamięci masowej, Kafką w warstwie strumieniowej i Kubernetes w przypadku skalowania aplikacji. Pokrętła dostrajające kontrolują sprzęt (rozmiary klastrów) i zasoby oprogramowania. Zwiększając zasoby sprzętowe (liczba węzłów w klastrach Cassandra i Kafka oraz liczba podów w klastrze Kubernetes), byliśmy w stanie (ostatecznie) skalować do 19 miliardów sprawdzania anomalii dziennie. To była arbitralna liczba, na której można się zatrzymać; nie ma teoretycznej górnej granicy. Osiągnięto to przy 574 rdzeniach CPU (72 rdzenie Kafki/9 węzłów, 118 rdzeni Kubernetes/100+ podów, 384 rdzenie Cassandra/48 węzłów). Tak więc skalowanie jest łatwe dzięki dodaniu zasobów sprzętowych, ale to nie jest cała historia. Skalowanie też jest trudne! Aby zbliżyć się do liniowej skalowalności wraz ze wzrostem liczby węzłów, musieliśmy dostroić wiele zasobów oprogramowania, aby umożliwić efektywne wykorzystanie zasobów sprzętowych. Niedostrojony system osiągał 7 miliardów sprawdzeń dziennie, ale dostrojenie przyniosło 2,5-krotną poprawę o 19 miliardów sprawdzeń dziennie. Najbardziej krytycznym parametrem była liczba partycji Kafki. W Kafce partycje umożliwiają wyższą współbieżność konsumencką Kafki, więc założyliśmy, że im więcej, tym lepiej. Odkryliśmy jednak, że zwiększenie liczby partycji powyżej liczby krytycznej znacznie zmniejszyło przepustowość klastra Kafka. Późniejsze testy porównawcze wykazały, że przepustowość klastra Kafka jest maksymalizowana przy "sweet spot" liczbie partycji, a przepustowość znacznie spada - z powodu narzutu replikacji - przy zbyt wielu partycjach. Tak więc, wbrew intuicji, krytyczną częścią procesu skalowania była optymalizacja potoku aplikacji w celu zminimalizowania liczby konsumentów i partycji Kafka w celu osiągnięcia maksymalnej przepustowości. Ważne jest również, aby upewnić się, że masz dobre modele danych zarówno dla Cassandry, jak i Kafki. W przypadku Cassandry użyj kluczy o wysokiej kardynalności i partycji ograniczonych. W przypadku Kafki upewnij się, że liczność klucza jest znacznie wyższa niż liczba partycji (aby zapobiec problemowi z parkowaniem kluczy przez Knutha) i nie uruchamiaj zbyt wielu konsumentów naraz (w przeciwnym razie możesz uzyskać burze równoważące).

Skalowanie ETL: jak potoki danych ewoluują wraz z rozwojem firmy

W dzisiejszym świecie generowanych jest tak wiele danych i tyle wartości biznesowej, które czekają na odkrycie. W jaki sposób inżynier danych może skutecznie przekazać te dane w ręce analityków i naukowców zajmujących się danymi? Wprowadź potok danych. Historycznie standardową praktyką biznesową było utworzenie potoku ETL:

Wyodrębnij : Pobiera dane z systemu źródłowego, zwykle jakiegoś rodzaju programu planującego wykonanie kodu, zwanego zadaniami.
Przekształć : zmodyfikuj dane w jakiś sposób, na przykład zapewnij spójność nazewnictwa, podaj dokładne sygnatury czasowe, wykonaj podstawowe czyszczenie danych lub oblicz metryki bazowe.
Load : Zapisz dane w systemie docelowym, zwykle hurtowni danych.

Wzorzec ETL działał dobrze przez wiele lat i nadal działa dla tysięcy firm. Jeśli nie jest zepsuty, nie naprawiaj go. Jednak tradycyjne ETL może być również onieśmielające na początku i istnieją alternatywy. W przypadku firm na wczesnym etapie rozwoju, które nadal poruszają się po dopasowaniu produktu do rynku, zrezygnuj z wyrafinowanego potoku. Pytania będą zbyt zróżnicowane, a odpowiedzi będą potrzebne zbyt szybko. Wszystko, co jest wymagane, to zestaw skryptów SQL, które działają jako zadanie cron na danych produkcyjnych w okresie małego ruchu, oraz arkusz kalkulacyjny. Dla firmy znajdującej się w środku fazy wzrostu odpowiednie jest utworzenie rurociągu wydobycia, obciążenia, transformacji (ELT). Będziesz mieć mnóstwo niewiadomych i będziesz chciał zachować jak największą elastyczność zarówno w zakresie produktu, jak i analizy. Potok ELT jest wystarczająco elastyczny, aby się dostosować. Pobierz dane źródłowe za pomocą dostawcy oprogramowania jako usługi (SaaS) i/lub kilku prostych skryptów SQL i umieszczania ich w hurtowni danych bez przekształceń jako "surowe" dane. Przekształcenia są wykonywane na zapytanie lub wbudowane w różne widoki. W miarę jak firma się krystalizuje, dane zaczynają rosnąć wykładniczo, a pomiary dojrzewają, hurtownia będzie musiała skodyfikować kluczowe metryki i punkty danych w standardowy sposób, aby zachować niezawodność w całej rozwijającej się organizacji. Skonfiguruj ten potok, modyfikując przepływ ELT za pomocą harmonogramu, gdy nieprzetworzone dane znajdują się już w magazynie danych. Widziałem to dobrze podczas mojego pobytu w Grubhub. Dzięki temu masz do dyspozycji dwa magazyny danych, magazyn "surowych" danych jeziora danych oraz hurtownię danych "przekształconych". Ten rodzaj architektury ma następujące zalety:

•  Zarządzanie danymi staje się łatwiejsze, ponieważ kontrola dostępu może być różna dla danych surowych i przekształconych.
•  Przekształcenia pozwalają na aktywny rozwój i wstępne obliczanie ważnych wskaźników biznesowych.
•  Każdy element w rurociągu jest znacznie łatwiejszy do skalowania.

Z tą architekturą wiąże się złożoność i koszt, więc ma to sens tylko wtedy, gdy biznes osiągnął pewien stopień skali. Potoki są konstruowane w celu uzyskania szybszego wglądu w dane biznesowe. Dzieje się tak bez względu na skalę. Architektura rurociągu będzie zależeć od skali działalności, a także od tego, jak dobrze firma osiągnęła dopasowanie produktu do rynku. Znajomość wszystkich rodzajów architektury jest cenna, ponieważ wczesne decyzje wpływają na to, jak łatwe lub trudne będzie wdrożenie innych architektur w miarę rozwoju firmy.

Kontrola jakości i cała jej seksowność

Przed przeprowadzką do nowego domu potencjalni właściciele domów zatrudnią inspektora, który oceni wszelkie szkody w domu. Podobnie jak inspektor domowy, jako inżynier danych, musimy wykryć wszelkie rażące i niezbyt rażące problemy z naszymi danymi przed wysłaniem ich do produkcji. Stworzenie programu zapewniania jakości (QA) jest proste, a korzyści są tego warte! Przy tworzeniu programu zapewniania jakości testy można podzielić na dwa główne segmenty: praktyczny i logiczny. Testy praktyczne mają na celu sprawdzenie kompletności danych i dokładnych typów danych. Należą do nich:

•  Sprawdzanie pokrycia danych poprzez sprawdzenie dat lub oczekiwanego wiersza
•  Standaryzacja danych wejściowych walut (np. usuwanie przecinków z metryk)
•  Zapewnienie, że wymagane pola nie zawierają wartości null
•  Sprawdzanie zgodności formatów daty, strefy czasowej i wielkości liter
•  Potwierdzenie, że nagłówki są stosowane do danych, a nie w samych danych
•  Deduplikacja zbioru danych

Testy logiczne mają znaczenie biznesowe i domenowe. To fajna część! Integralną częścią tego kroku jest uzyskanie kontekstu makrobiznesowego i zrozumienie głównych pytań, na które należy odpowiedzieć. Pomocne jest również zrozumienie, jak ważna jest dokładność dla interesariuszy. Czy dokładność kierunkowa jest wystarczająca, czy wymagana jest pełna dokładność? (Często zespoły finansowe mówią, że wymagana jest całkowita dokładność, podczas gdy inne zespoły mogą szukać tylko różnic kierunkowych). Ten krok obejmowałby zastosowanie wiedzy merytorycznej do testów. Na przykład:

•  Każdy użytkownik korzystający z wersji próbnej powinien mieć łącznie 0 USD na zakupy.
•  Zdarzenie atrybucji liczy się tylko wtedy, gdy miało miejsce przed instalacją, a nie po.
•  Dwie wielkości próbek w eksperymencie powinny znajdować się w zakresie 1% od siebie.
•  Bezpłatni użytkownicy nigdy nie będą mieli dostępu do tych części aplikacji, a zatem żadnych danych. •  Jeśli użytkownik otrzyma zwrot pieniędzy, upewnij się, że kwota jest odjęta od daty zwrotu, a nie od daty zakupu.

Oto kilka dodatkowych uwag na temat procesu kontroli jakości:

•  Test jest równaniem. Określ, czego oczekujesz dla pola i porównaj to z rzeczywistą wartością. Voila!
•  Narzędzia mogą pomóc zautomatyzować te testy podczas procesu tworzenia, aby zapewnić spójność, dokładność i stabilność.
•  Użyj lintera!
•  Zasady kodu są w porządku. Na przykład, może chcesz wszystkie kolumny True/False zaczynające się od prefiksu is, np. is_.
•  W miarę jak coraz więcej osób wchodzi do organizacji i mnożą się małe zmiany u wielu osób, dobrze przemyślany program zapewniania jakości pomoże złagodzić awarie.
•  Jeśli masz więcej niż jedno źródło prawdy dla metryki, użyj tej metody jako metody kontroli jakości, aby kontrolować oba metryki.
•  W miarę pojawiania się nowych typów danych potrzebne są nowe testy.

Wiedz, że testy się psują - i to jest całkowicie normalne! Niektóre będziesz w stanie naprawić stosunkowo szybko, a inne mogą wymagać znacznej refaktoryzacji, ponieważ ujawniły dziurę w kodzie, i to też jest OK! Możesz znaleźć błędy, które są poza Twoim zakresem, takie jak pola wpisów użytkownika, i w takich przypadkach najlepiej jest tworzyć raporty o błędnych wpisach i udostępniać je zespołowi odpowiedzialnemu za pomoc w naprawie. Chociaż wdrożenie rygorystycznych standardów zapewniania jakości nie uodparnia Cię na błędy, pomaga zmniejszyć ich częstotliwość i poprawić ogólny sentyment do danych. Kiedy ludzie mogą skoncentrować się na informacjach, które przekazują nam dane, organizacje mogą spodziewać się wyższej znajomości danych i innowacji.

Prywatność to Twój problem

Dane zostały nazwane "nowym złotem" ze względu na ich zdolność do przekształcania i automatyzacji procesów biznesowych; zostały również nazwany "nowym uranem" ze względu na ich zdolność do naruszania prawa człowieka do prywatności na masową skalę. I tak jak inżynierowie nuklearni mogli bez wysiłku wyliczyć fundamentalne różnice w złocie i uranie, tak inżynierowie danych muszą nauczyć się instynktownie identyfikować i oddzielać dane niebezpieczne od łagodnych. Weźmy na przykład słynny atak na łącze, który ponownie zidentyfikował dokumentację medyczną kilku głośnych pacjentów szpitala Massachusetts General Hospital. W 1997 roku MGH opublikowało około 15 000 rekordów, w których nazwiska i identyfikatory pacjentów zostały usunięte z bazy danych. Pomimo środków ostrożności, badaczka z Harvardu Latanya Sweeney była w stanie połączyć publicznie dostępne informacje o wyborcach z tymi zanonimizowanymi dokumentami medycznymi, łącząc je na trzech pośrednich identyfikatorach: kodach pocztowych, urodzinach i płci. To pozostawiło Sweeneyowi tylko garść akt do przejrzenia, aby ponownie zidentyfikować wiele osób - w szczególności akta pacjentów gubernatora Massachusetts. Dwadzieścia lat później każda firma to MGH, a każda osoba mająca dostęp do internetu to potencjalna Latanya Sweeney. Jednak wszyscy chcemy świata, w którym dane są przetwarzane odpowiedzialnie, udostępniane z ostrożnością i wykorzystywane tylko do właściwych celów. Naszym największym ograniczeniem w uświadomieniu sobie tego świata nie jest możliwość, ale odpowiedzialność; to nie jest pytanie "Jak?" ale "kto?" Uważam, że inżynierowie danych muszą być tymi, którzy przejmują odpowiedzialność za problem i przewodzą. Kontrolowanie możliwości ponownej identyfikacji rekordów na jednym pulpicie nawigacyjnym to dobra higiena analityczna, ale zachowanie prywatności na platformie dostarczającej dane ma kluczowe znaczenie. Zarządzanie utratą prywatności to problem systemowy wymagający rozwiązań systemowych - a inżynierowie danych budują systemy. Mandat do ochrony prywatności nie oznacza nudnego ćwiczenia we wdrażaniu logiki biznesowej; stawia nowe, ekscytujące wyzwania techniczne. Jak możemy określić ilościowo stopień zapewnianej przez nas ochrony prywatności? Jak możemy odbudować produkty danych - i zagwarantować, że nadal będą działać - po tym, jak osoba zażąda usunięcia jej danych? Jak możemy przełożyć rozległe regulacje prawne na zrozumiałe zasady dotyczące danych, jednocześnie zaspokajając głodnych danych konsumentów? Będziemy musieli sformułować nowy zestaw najlepszych praktyk inżynierskich, który wykracza poza znane dziedziny bezpieczeństwa i projektowania systemów. Ustalenie, co jest najlepszą praktyką, wymaga jednak dużo praktyki. Niezwykle ważne jest, aby liderzy inżynierii zachęcali swoje zespoły do zrozumienia i rozwiązania istotnych problemów: mocnych i słabych stron maskowania danych, technik anonimizacji, takich jak k-anonimizacja i prywatność różnicowa, oraz nowych technologii, takich jak sfederowane uczenie się. Ostatecznie inżynierowie danych powinni znać praktykę ochrony prywatności w fazie projektowania tak intuicyjnie, jak znają zasadę najmniejszych uprawnień. Alternatywą, jeśli historia jest jakimkolwiek przewodnikiem, jest świat, w którym instytucje publikują "zanonimizowane" dane światu, a sprytni ludzie i organizacje rekonstruują prywatne dane i wykorzystują je do własnych celów. Zarządzanie prywatnością, dalekie od bycia abstrakcyjną koncepcją tylko dla filozofów i prawników, stało się konkretnym problemem doskonale odpowiadającym inżynierom danych. Nadszedł czas, aby zrobili to po swojemu.

Zapobieganie otchłani Data Lake: jak zapewnić, że Twoje dane pozostaną ważne przez lata

Każdy pracował przy niewłaściwych założeniach w tym czy innym momencie swojej kariery i nigdzie nie uważam tego za bardziej widoczne niż w przypadku starszych danych i wielu tego, co ląduje w jeziorach danych większości firm. Koncepcja jeziora danych wyewoluowała z bardziej tradycyjnej hurtowni danych, która pierwotnie była przewidziana jako sposób na złagodzenie problemu silosów i fragmentacji danych w organizacji. Hurtownia danych osiągnęła to, zapewniając centralny magazyn, w którym można uzyskać dostęp do wszystkich danych, zwykle za pośrednictwem tradycyjnego interfejsu SQL lub innych narzędzi analizy biznesowej. Data Lake idzie o krok dalej w tej koncepcji i umożliwia zrzucanie wszystkich danych w ich nieprzetworzonym formacie (nieustrukturyzowanym lub ustrukturyzowanym) do skalowalnego poziomo ogromnego magazynu danych (HDFS/S3), w którym można je przechowywać prawie w nieskończoność. Z biegiem lat to, co zwykle zaczyna się od najlepszych intencji, może łatwo przekształcić się w czarną dziurę dla najcenniejszego zasobu Twojej firmy, ponieważ podstawowe formaty danych zmieniają się i sprawiają, że starsze dane stają się bezużyteczne. Wydaje się, że problem ten wynika z trzech głównych kwestii:

•  Podstawowy brak własności zespołu tworzącego dany zbiór danych
•  Ogólny brak dobrej etykiety lub higieny danych, jeśli chodzi o zachowanie wstecznej kompatybilności w odniesieniu do starszych struktur danych
•  Zaczynając od złego kroku podczas tworzenia nowego zestawu danych, bez wsparcia innych ekspertów od modelowania danych lub inżynierii danych

Odkryłem, że proste podejście do rozwiązania tych problemów ze spójnością danych wynika z ustalenia tego, co nazywam kontraktami danych.

Ustanawianie kontraktów danych

Stale rosnące zapotrzebowanie na dane wysokiej jakości w organizacji prawie wymaga wcześniejszego zawarcia umów dotyczących danych. Oznacza to pójście dalej niż tylko trzymanie się i dostarczanie schematu danych, ale także generowanie planu lub historii dla tego, jakie pola istnieją, kiedy, gdzie i dlaczego. Ta umowa jest interfejsem API Twoich danych i powinna być aktualizowana i wersjonowana po każdej zmianie w kodzie produkcyjnym. Wiedza o tym, kiedy pole będzie istniało (lub nie) oszczędza czas i zmniejsza frustrację.

Od Generic Data Lake do Data Structure Store

Przeniesienie tego pomysłu na wyższy poziom wymaga, aby zespół produkcyjny skompilował biblioteki zarówno do tworzenia, jak i wykorzystywania danych. Biblioteki te powinny również zapewniać testy jednostkowe, aby zapewnić pełną zgodność z poprzednimi wersjami zmian w podstawowych strukturach danych. Dwie powszechnie używane struktury struktury danych to Apache Avro i Google Protocol Buffers. Oba umożliwiają definiowanie schematów danych w sposób niezależny od platformy i ostatecznie zapewniają bezpieczeństwo typów, których nigdy nie będziesz mieć w przypadku tradycyjnego JSON. Te wersjonowane i skompilowane biblioteki pomagają zapewnić, że każdy bajt danych przechowywany podlega ścisłej walidacji i jest rozliczane z wersji umowy dotyczącej danych. Ustanawia to prostą zasadę, że każdy rekord będzie zachowywany w formacie wersjonowanym, który będzie co najmniej zgodny wstecznie oraz w formacie, który będzie można łatwo wyodrębnić i używać przez wiele lat. Ten wstępny wysiłek doprowadzi do zwiększenia produktywności we wszystkich jednostkach zużywających dane w Twojej firmie. Zamiast wykolejać mapy drogowe z długimi okresami zabawy, aby znaleźć brakujące dane (lub dosłownie wyrzucić lub osuszyć jezioro, aby zacząć od nowa z powodu ogólnego braku zaufania do integralności danych), możesz wrócić do posiadania jeziora danych, które to nieoceniony wspólny zasób wykorzystywany do wszelkich potrzeb związanych z danymi: od analityki do nauki o danych i do głębokich horyzontów uczenia się.

Potokowe sny

Jednym z subtelnych i nowatorskich paradygmatów architektury systemów komputerowych jest koncepcja przekazywania wiadomości. Ta prosta, aczkolwiek użyteczna konstrukcja pozwoliła uzyskać rząd wielkości korzyści w przetwarzaniu równoległym, pozwalając procesom (aplikacjom, zadaniom jądra itp.) w ramach jednego systemu operacyjnego na udział w rozmowie. Piękno tego polegało na tym, że procesy mogły teraz uczestniczyć w rozmowach w sposób synchroniczny lub asynchroniczny i rozdzielać pracę między wiele aplikacji bez koniecznego narzutu związanego z blokowaniem i synchronizacją. To nowatorskie podejście do rozwiązywania zadań przetwarzania równoległego w ramach jednego systemu zostało dodatkowo rozszerzone na przetwarzanie w systemach rozproszonych wraz z pojawieniem się kolejki komunikatów jako usługi. Podstawowa kolejka wiadomości pozwalała na utworzenie jednego lub wielu kanałów (lub tematów) w rozproszonym stylu kolejki FIFO (pierwsze weszło, pierwsze wyszło), która może być uruchamiana jako usługa nad lokalizacją adresowalną w sieci (np. , adres ip:port). Teraz wiele systemów na wielu serwerach może komunikować się w rozproszonym, współdzielonym stylu pracy, w rozkładzie zadań. Nietrudno wyobrazić sobie, jak architektura potoku wyrosła z koncepcji systemów rozproszonych komunikujących się za pośrednictwem kolejek wiadomości adresowalnych przez sieć. To ma sens na poziomie makro. Zasadniczo wszystkie komponenty nowoczesnej architektury rurociągów znajdowały się na linii montażowej, czekając na montaż. Ale najpierw musieliśmy rozwiązać drobny problem: niepowodzenie w obliczu częściowo przetworzonych wiadomości. Jak możesz sobie wyobrazić, jeśli mamy kolejkę rozproszoną i pobieramy wiadomość z tej kolejki, możemy założyć, że kolejka usunie tę wiadomość i życie będzie toczyć się dalej. Jednak w obliczu niepowodzenia-nieważne gdzie wskaeż winę - jeśli wiadomość zostanie usunięta przed zakończeniem pracy, spowoduje to utratę danych bez możliwości odzyskania. Teraz to jest miejsce, w którym rzeczy ewoluowały. Biorąc pod uwagę, że chcieliśmy mieć pewność, że nasze aplikacje wykonają całą pracę, którą wykonały z kolejki, sensowne było przechowywanie dziennika wiadomości w kanale (lub temacie) i umożliwienie naszym systemom śledzenia tego, co wykorzystały i zasadniczo gdzie ich przetwarzanie zostało przerwane. Ten prosty pomysł potwierdzania, gdzie aplikacja znajdowała się w kolejce, doprowadził do koncepcji śledzenia przesunięcia i wyznaczania punktów kontrolnych dla grupy konsumentów w kolejce. Apache Kafka był pierwszym projektem, który traktował kolejkę wiadomości jako niezawodną i co ważniejsze, odtwarzalną kolejkę, którą można łatwo podzielić i udostępnić między wieloma aplikacjami w ramach wspólnej grupy konsumentów. Teraz istniał niezawodny, wysoce dostępny i wysoce skalowalny system, który może być używany nie tylko do przekazywania wiadomości, a to zasadniczo stworzyło podstawę architektury potoku strumieniowego.

Idealne jest wrogiem dobrego

"Le mieux est l'ennemi du bien", luźno tłumaczone jako "Doskonałość jest wrogiem dobrego", to powiedzenie, które najbardziej przypisuje się Wolterowi. To ostrzeżenie dotyczące postrzeganej wartości dążenia do perfekcji w porównaniu z rzeczywistością. To zdanie może dotyczyć wielu dziedzin, w tym inżynierii danych. Sugerowanie, że doskonałość nie jest celem, często wywołuje sceptycyzm ze strony inżynierów danych. W końcu opracowywanie produktów danych wymaga precyzji i podejścia zorientowanego na szczegóły. Co więcej, większość inżynierów danych brała udział w pośpiesznych implementacjach tylko po to, by wracały, by ich prześladować. Posyp naturalną awersję do ryzyka, a istnieje wiele powodów, dla których ludzie kwestionują pogląd, że powstrzymanie się od perfekcji to dobry pomysł. Nie jest to jednak zarzut na skróty. Zamiast tego opowiadam się za szybszym dostarczaniem i wdrażaniem tylko wartościowych funkcji. Ta koncepcja szybszego dostarczania jest podobna do zasady Agile, która polega na dostarczaniu produktu o minimalnej opłacalności (MVP). Wartość szybkiego oddania produktu w ręce użytkownika jest nie do przecenienia. Na przykład, jeśli Twoi liderzy potrzebują trzech wskaźników do prowadzenia działalności, a Ty masz ukończony tylko jeden, wyślij go. Prowadzenie organizacji z pewnym wglądem jest zawsze lepsze niż prowadzenie bez żadnego. Jedyną rzeczą, która może być gorsza niż czekanie na dostarczenie opłacalnego produktu, jest rozwijanie pozostałych funkcji w dążeniu do perfekcji. Te pozostałe funkcje mogą często trwać dłużej niż inne lub zapewniają zmniejszoną wartość lub jedno i drugie. Na przykład, jeśli dodanie wizualizacji pulpitu nawigacyjnego dla pojedynczego użytkownika wymaga przerwania zmian modelu i potoku, to prawdopodobnie nie wymaga to wysiłku. Wszystkie proponowane funkcje rozwiązania powinny zostać przeanalizowane pod kątem przewidywanego zwrotu z inwestycji, ale należy zachować szczególną ostrożność w odniesieniu do tych znajdujących się na dole listy priorytetów. Inżynieria danych to trudne przedsięwzięcie, które często jest skomplikowane. Dostarczając szybciej i wdrażając tylko wartościowe funkcje, możesz zmniejszyć ryzyko i zwiększyć swoje szanse na sukces.

Przejście od inżynierii oprogramowania do inżynierii danych

Przejście od inżynierii oprogramowania do inżynierii danych jest satysfakcjonujące i ekscytujące. Inżynieria danych jest wszystkim, czym jest inżynieria oprogramowania: pasją i zasadami skutecznego i eleganckiego rozwiązywania problemów technicznych. Ale poszerzasz swoje rzemiosło o problemy analityczne i związane z danymi. Obejmuje to rozwiązywanie problemów na jeszcze większą skalę, ale także pomaganie ludziom w znajdowaniu wglądu w problemy, które rozwiązujesz. Kiedy po raz pierwszy zacząłem pracować w inżynierii danych, czułem się zagubiony, ponieważ było tak wiele do nauczenia. Ale tak jak ty uwielbiam się uczyć. Byłem zachwycony wyzwaniem poznania nowych technologii i nowych wzorów. Pocieszające jest uświadomienie sobie, że wszystkie te same zasady nadal mają zastosowanie - takie rzeczy jak używanie abstrakcji, utrzymywanie prostoty i budowanie aplikacji tak, aby były skalowalne i łatwe w utrzymaniu. Ponadto całe moje doświadczenie jest nadal aktualne, a nawet ważniejsze, podobnie jak umiejętności, takie jak rozwiązywanie problemów, skalowanie aplikacji korporacyjnych, tworzenie interfejsów API, tworzenie sieci, programowanie i pisanie skryptów. Dzięki inżynierii danych rozwiązujesz problemy podobne do tych w inżynierii oprogramowania, ale na większą skalę. Pracowałem nad kodem przetwarzającym miliardy zdarzeń. Nosiłem go jako odznakę honoru, że tradycyjne technologie i platformy zerwałyby z ilością informacji, które próbowaliśmy przetworzyć. Na początku złamaliśmy naszą relacyjną bazę danych; kiedy próbowaliśmy zreplikować dane do innej bazy danych, proces replikacji nie mógł nadążyć. Ponadto raz w naszym środowisku Hadoop straciliśmy ponad 170 TB danych. Nie martw się; byliśmy w stanie go odzyskać, ale byłem w szoku, ile danych przetwarzał nasz projekt. I to nie tylko technologia, którą psujesz; Ty też zepsujesz sposób myślenia. Jako programista dobrze znasz się na tablicach, strukturach, obiektach, wyliczeniach i formacie JSON, ale kiedy przedstawisz te koncepcje analitykom zaznajomionym tylko z danymi tabelarycznymi i prymitywnymi typami danych, daje to możliwość nauczenia ich o tych nowych rzeczach. Przy wszystkich tych wyzwaniach musisz przemyśleć tradycyjne podejście i wykazać się kreatywnością podczas rozwiązywania problemów. Twoje codzienne wyzwania rosną od operacyjnych przypadków użycia do analitycznych przypadków użycia. Tworzona infrastruktura musi obsługiwać ruch produkcyjny w czasie rzeczywistym, który może być skierowany do klientów, ale także zapewniać wgląd analitykom poszukującym wzorców w ogromnych ilościach danych w Twojej aplikacji. Wspieranie obu jednocześnie jest wyzwaniem inżynieryjnym. Przejście na inżynierię danych zapewnia wiele ekscytujących korzyści. Pozwala uczyć się nowych rzeczy. Pozwala ci mentorować ludzi z twojego doświadczenia. I pozwala rozwiązywać wyjątkowe i duże problemy.

Większość problemów z danymi nie dotyczy dużych ilości danych Big

Pamiętam, że gdy w 2015 r. szczyt popularności osiągął big data, pamiętam, że NoSQL, Hadoop, MongoDB i inne technologie danych niestrukturalnych były reklamowane jako przyszłość analityki. Wiele organizacji zaczęło zbierać dane szybciej, niż były w stanie je zorganizować i przechowywać, więc po prostu zrzucały je do klastra i skalowały w poziomie w razie potrzeby. Wiele firm przeznacza ogromne koszty na migrację z relacyjnych baz danych, takich jak MySQL, na platformy Big Data, takie jak Apache Hadoop. Wśród tego ruchu prowadziłem szkolenie online ′Reilly na temat SQL. Jeden z uczestników zasugerował, że relacyjne bazy danych i SQL mogą być przestarzałą technologią. Jeśli brak skalowania w poziomie nie był wystarczającym powodem, relacyjne bazy danych mają cały ten nieznośny narzut, aby uporządkować dane w znormalizowany sposób, a także wymuszać walidację danych i klucze podstawowe/obce. Internet i łączność urządzeń spowodowały eksplozję danych, więc skalowalność stała się punktem sprzedaży NoSQL i big data. Ironia polega na tym, że do platform Big Data dodano interfejsy SQL i stało się to z jakiegoś powodu. Analitycy uznali języki NoSQL za trudne i chcieli analizować dane w sposób relacyjny. Zdecydowaną większość problemów z danymi najlepiej modelować jako struktury relacyjnych baz danych. ZAMÓWIENIE ma KLIENTA i powiązany z nim PRODUKT. To po prostu ma sens, aby te informacje były znormalizowane w osobnych tabelach, a nie jako blob JSON. Co więcej, możesz mieć spokój, wiedząc, że oprogramowanie bazy danych zweryfikuje ZAMÓWIENIE i sprawdzi, czy KLIENT i PRODUKT rzeczywiście istnieją, zamiast pozwolić, aby uszkodzenie danych po cichu wkradło się z powodu błędów w interfejsie. Prawda jest taka, że większość problemów z danymi nie dotyczy dużych zbiorów danych. Anegdotycznie 99,9% problemów, które napotkałem, najlepiej rozwiązać za pomocą tradycyjnej relacyjnej bazy danych. Z pewnością istnieją uzasadnione przypadki korzystania z platform NoSQL, zwłaszcza gdy trzeba przechowywać ogromną ilość nieustrukturyzowanych danych (pomyśl o postach w mediach społecznościowych, artykułach z wiadomościami i notkach internetowych). Jednak w przypadku danych operacyjnych relacyjne bazy danych zmuszają do uważnego zastanowienia się nad tym, jak działa model danych i do prawidłowego wykonania go za pierwszym razem. Tego rodzaju dane operacyjne rzadko stają się tak duże, że nie można skalować relacyjnej bazy danych.

Nowoczesne metadane dla nowoczesnego stosu danych

Świat danych skupił się ostatnio wokół najlepszego zestawu narzędzi do radzenia sobie z ogromnymi ilościami danych, czyli współczesnego stosu danych. Dobry? Jest super szybki, łatwy do skalowania w kilka sekund i wymaga niewielkich nakładów. Źli? Wciąż nie jest w stanie wprowadzać zarządzania, zaufania i kontekstu do danych. W tym momencie wkraczają metadane. W zeszłym roku rozmawiałem z ponad 350 liderami danych, aby zrozumieć ich wyzwania związane z tradycyjnymi rozwiązaniami i stworzyć wizję nowoczesnych metadanych w nowoczesnym stosie danych. Przedstawiamy tutaj cztery cechy nowoczesnych rozwiązań metadanych.

Zasoby danych > Tabele
Tradycyjne katalogi danych zostały zbudowane na założeniu, że tabele są jedynym zasobem, którym należy zarządzać. Teraz jest zupełnie inaczej. Pulpity nawigacyjne BI, fragmenty kodu, zapytania SQL, modele, funkcje i notatniki Jupyter to dzisiaj zasoby danych. Nowa generacja zarządzania metadanymi musi być wystarczająco elastyczna, aby inteligentnie przechowywać i łączyć różne typy zasobów danych w jednym miejscu.

Pełna widoczność danych, a nie fragmentaryczne rozwiązania

Wcześniejsze katalogi danych poczyniły znaczne postępy w ulepszaniu odkrywania danych. Jednak nie dali organizacjom jednego źródła prawdy. Informacje o zasobach danych są zwykle rozproszone w różnych miejscach - narzędziach do określania pochodzenia danych, narzędziach do jakości danych, narzędziach do przygotowywania danych i nie tylko. Nowoczesne rozwiązania metadanych powinny pomóc zespołom w osiągnięciu wreszcie świętego Graala - jednego źródła informacji dla każdego zasobu danych.

Stworzony dla metadanych, które same w sobie są Big Data
Szybko zbliżamy się do świata, w którym same metadane to big data. Przetwarzanie metadanych pomoże zespołom lepiej zrozumieć i zaufać swoim danym. Fundamentalna elastyczność chmury sprawia, że jest to możliwe jak nigdy dotąd. Na przykład, analizując dzienniki zapytań SQL, można automatycznie utworzyć rodowód na poziomie kolumny, przypisać wynik popularności do każdego zasobu danych i wydedukować potencjalnych właścicieli i ekspertów dla każdego zasobu.

Wbudowana współpraca w jej sercu
Jeszcze kilka lat temu dane były konsumowane głównie przez zespół IT. Obecnie zespoły danych są bardziej zróżnicowane niż kiedykolwiek naukowcy i inżynierowie danych, analitycy biznesowi, menedżerowie produktów i nie tylko. Każda z tych osób ma swoje ulubione i różnorodne narzędzia danych, od Jupytera po SQL. Ze względu na fundamentalną różnorodność nowoczesnych zespołów danych, nowoczesne rozwiązania metadanych muszą bezproblemowo integrować się z codziennymi przepływami pracy zespołów. W tym miejscu ożywa idea wbudowanej współpracy. Współpraca wbudowana polega na pracy w miejscu, w którym się znajdujesz, przy jak najmniejszej liczbie problemów związanych z żądaniem dostępu do danych po otrzymaniu linku, na przykład w Dokumentach Google, które właściciel może zatwierdzić ze Slacka. Może to ujednolicić dziesiątki mikroprzepływów pracy, które marnują czas, frustrują i męczą zespoły danych. Znajdujemy się w punkcie zwrotnym w zarządzaniu metadanymi - przejście od powolnych rozwiązań lokalnych do nowej ery, opartej na zasadach współpracy osadzonej, które są powszechne w nowoczesnych narzędziach. Chociaż nie wiemy wszystkiego o przyszłości katalogów danych, jasne jest, że wkrótce zobaczymy, jak nowoczesne metadane zajmują należne im miejsce w nowoczesnym stosie danych.

Uwaga na lukę: Twoje jezioro danych nie zapewnia żadnych gwarancji na ACID

Nowoczesna architektura jeziora danych opiera się na obiektowej pamięci masowej jako jeziora, wykorzystując technologie przesyłania strumieniowego i replikacji do przesyłania danych do jeziora oraz bogaty ekosystem aplikacji, które pobierają dane bezpośrednio z jeziora lub używają jeziora jako głębokiego przechowywania. Ta architektura jest opłacalna i zapewnia wysoką przepustowość podczas pozyskiwania lub używania danych. Dlaczego więc praca z danymi jest nadal niezwykle trudna? Oto kilka powodów: * Brakuje nam izolacji. Jedynym sposobem na zapewnienie izolacji jest użycie uprawnień lub skopiowanie danych. Korzystanie z uprawnień zmniejsza naszą zdolność do maksymalizacji wartości naszych danych, umożliwiając dostęp każdemu, kto może skorzystać z danych. Kopiowanie jest niewykonalne, ponieważ możesz stracić orientację, co znajduje się w twoim jeziorze.

•  Nie mamy atomowości, czyli innymi słowy, nie możemy polegać na bezpiecznym wykonywaniu transakcji. Na przykład nie ma natywnego sposobu na zagwarantowanie, że nikt nie zacznie czytać kolekcji przed zakończeniem jej pisania.
•  Nie możemy zapewnić spójności między kolekcjami (a w niektórych przypadkach nawet dla jednej kolekcji). Denormalizacja danych w Data Lake jest powszechna; na przykład ze względów wydajnościowych. W takich przypadkach możemy zapisać te same dane w dwóch formatach lub zindeksować je w inny sposób, aby zoptymalizować dla dwóch różnych aplikacji lub dwóch różnych przypadków użycia. (Zauważ, że jest to wymagane, ponieważ obiektowa pamięć masowa słabo obsługuje indeksy drugorzędne). Jeśli jeden z tych procesów zawiedzie, a drugi się powiedzie, otrzymasz niespójne jezioro i ryzykujesz dostarczenie konsumentom danych niespójnego obrazu świata.
•  Nie mamy powtarzalności. Nie ma gwarancji, że operacje na danych + kod będą powtarzalne, ponieważ dane zidentyfikowane w określony sposób mogą ulec zmianie bez zmiany ich tożsamości: możemy zastąpić obiekt obiektem o tej samej nazwie, ale zawierającym inną treść. Mamy niską zarządzalność. Pochodzenie między zestawami danych i powiązanie z kodem, który je utworzył, jest zarządzane ręcznie lub za pomocą zdefiniowanych przez człowieka i skonfigurowanych przez niego standardów nazewnictwa.

Jak obejść te ograniczenia? Przede wszystkim musimy wiedzieć, że nie możemy oczekiwać tych gwarancji. Gdy już wiesz, na co cię czeka, upewnisz się, że wdrożysz potrzebne gwarancje, w zależności od wymagań i umów, które masz z klientami, którzy korzystają z danych z jeziora danych. Ponadto scentralizowane magazyny meta, takie jak Hive Metastore, mogą złagodzić ból związany z brakiem atomowości i spójności w kolekcjach, a wersjonowane formaty danych, takie jak Hudi, mogą ułatwić izolację i oddzielenie czytelników od pisarzy. Struktury, takie jak lakeFS, mogą zapewnić bezpieczne środowisko zarządzania jeziorem danych z gwarancjami atomowości, spójności, izolacji i trwałości (ACID), jednocześnie wspierając korzystanie z Hive i Hudi

Metadane ≥ Dane

Moim pierwszym prawdziwym doświadczeniem w świecie Big Data była pomoc we wdrożeniu klastrów Apache Hadoop w Orbitz Worldwide, często odwiedzanej internetowej witrynie turystycznej. Jedną z pierwszych rzeczy, które zrobiliśmy, było wdrożenie Apache Hive w naszych klastrach i udostępnienie naszym programistom dostępu do tworzenia aplikacji i analiz w oparciu o tę infrastrukturę. To wszystko było wspaniałe, ponieważ pozwoliło nam uwolnić mnóstwo wartości ze wszystkich zebranych danych. Po pewnym czasie zauważyliśmy jednak, że otrzymaliśmy liczne stoły Hive, które zasadniczo przedstawiały te same byty. Z punktu widzenia zasobów nie było to takie okropne, ponieważ nawet w mrocznych czasach przechowywanie było dość tanie. Jednak czas naszych użytkowników nie był tani, więc cały czas, który spędzali na tworzeniu nowych tabel Hive lub przeszukiwaniu naszych istniejących tabel w celu znalezienia potrzebnych danych, był czasem, który nie spędzali na uzyskiwaniu wglądu w dane. Lekcja, której nauczyliśmy się w Orbitz, była taka, że błędem jest pozostawienie planowania zarządzania danymi na później. Zamiast tego najlepiej zacząć planować strategię zarządzania danymi wcześnie, najlepiej równolegle z każdą nową inicjatywą lub projektem dotyczącym danych. Posiadanie infrastruktury zarządzania danymi, która obejmuje takie elementy, jak zarządzanie metadanymi, ma kluczowe znaczenie nie tylko dla umożliwienia użytkownikom odkrywania danych i optymalnego ich wykorzystania. Ma to również kluczowe znaczenie dla takich rzeczy, jak zgodność z istniejącymi i nowymi przepisami rządowymi dotyczącymi danych. Trudno na przykład spełnić prośbę klienta o usunięcie jego danych, jeśli nie wiesz, jakie dane faktycznie posiadasz i gdzie one się znajdują. Chociaż prawdopodobnie stosunkowo łatwo jest zidentyfikować zestawy danych do przechwytywania metadanych i zdefiniować, co te metadane powinny zawierać, większym wyzwaniem może być wdrożenie procesów i narzędzi do przechwytywania tych metadanych i udostępniania ich. Faktem jest, że nie musisz szukać idealnego narzędzia do zarządzania wszystkimi danymi i możliwe, że żadne pojedyncze narzędzie nie pozwoli Ci skutecznie zarządzać danymi we wszystkich systemach. Jest to z pewnością przypadek, w którym nawet nieoptymalne rozwiązanie sprawi, że będziesz daleko przed brakiem rozwiązania. Niezależnie od tego, czy korzystasz z narzędzi dostarczonych przez dostawcę, narzędzi innych firm, czy nawet decydujesz się na wprowadzenie własnych, ważne jest, aby mieć proces i plan na wczesnym etapie oraz zapewnić, że proces ten zostanie utrzymany w ramach projektów dotyczących danych

Usługi metadanych jako podstawowy składnik platformy danych

Eksplozja danych nieustrukturyzowanych wprowadziła nowe wyzwania związane z wykrywaniem danych, zarządzaniem danymi i bezpieczeństwem dla organizacji. Wraz ze wzrostem ilości danych i złożoności ich użycia, uwzględnienie ujednoliconych usług metadanych jako części platformy danych stało się jeszcze ważniejsze. Obecnie zarówno ustrukturyzowane, jak i nieustrukturyzowane dane razem dostarczają kluczowych informacji umożliwiających uzyskanie istotnych informacji biznesowych. Inżynierowie danych powinni szukać następujących funkcji w każdej usłudze metadanych, którą rozważają dla swojej organizacji: wykrywalność, kontrola bezpieczeństwa, zarządzanie schematem oraz interfejs aplikacji i gwarancja usług.

Wykrywalność
Najbardziej oczywistym i powszechnym zastosowaniem usługi metadanych jest udostępnienie użytkownikom interfejsu umożliwiającego odnajdywanie danych i ich partycji. . Jeśli platforma danych ma różne systemy pamięci masowej, posiadanie wspólnego interfejsu do wykrywania dowolnego zestawu danych pomoże użytkownikom w tworzeniu ogólnych rozwiązań. Użytkownicy powinni mieć dobrze zdefiniowany interfejs do wysyłania zapytań do zestawu danych i jego partycji, który może zostać przetłumaczony na rzeczywistą lokalizację fizyczną przez usługę metadanych. Aplikacje użytkownika nie potrzebują już lokalizacji danych na stałe; zamiast tego mogą mieć dostęp do interfejsów, które mogą pomóc im odkryć istniejące i zaktualizowane dane w różnych systemach pamięci masowej.

Kontrola bezpieczeństwa
Dzięki ujednoliconemu zarządzaniu lokalizacją można wymusić w całej organizacji bogaty zestaw kontroli bezpieczeństwa. Usługa metadanych powinna być w stanie obsłużyć reguły autoryzacji dla tych samych danych w różnych systemach pamięci masowej. Należy ujawnić interfejsy służące do definiowania, aktualizowania i egzekwowania zasad bezpieczeństwa. Usługa metadanych powinna działać jako strażnik danych, aby upewnić się, że zasady nigdy nie zostaną naruszone. Dobra usługa metadanych powinna mieć również silne funkcje audytu.

Zarządzanie schematem
Usługa metadanych powinna zapewniać funkcje definiowania i odpytywania schematu powiązanego z danymi, którymi zarządza. Bogaty schemat umożliwia użytkownikom tworzenie wydajnych aplikacji. Zapewnia również wgląd dla organów egzekwujących bezpieczeństwo w celu dostrojenia kontroli dostępu i reguł autoryzacji w zestawie danych w oparciu o zawartość danych. . Dobra usługa metadanych powinna również zapewniać funkcje sprawdzania poprawności schematu i wersjonowania.

Interfejs aplikacji i gwarancja serwisowa
Będąc kluczowym elementem, usługa powinna być budowana i obsługiwana, aby była wysoce dostępna. Interfejs aplikacji powinien być łatwy w użyciu i dobrze zdefiniowany w celu połączenia z różnymi bibliotekami i systemami. Usługa metadanych powinna być w stanie obsługiwać ewoluujące modele danych i aplikacje. Chociaż żaden pojedynczy system nie może zapewnić wszystkich tych funkcji, inżynierowie danych powinni wziąć pod uwagę te wymagania, wybierając jedną lub więcej usług do zbudowania usługi metadanych. Wiele dużych organizacji albo rozwija swoje istniejące usługi, albo korzysta z oprogramowania open source do obsługi tych funkcji

Zachowaj sympatię mechaniczną

Jako nowy technolog masz nieskończenie wiele lekcji do nauczenia się - od podstaw logiki, poprzez składnię i projektowanie oprogramowania, aż po budowanie i integrowanie dużych systemów rozproszonych. Przez lata praktyki, nieustannego uczenia się i nieodgadnionych błędów, przyswoisz sobie zrozumienie większej liczby errat obliczeniowych, niż mógłbyś przypuszczać. W tym potoku informacji twoja wieczna konsternacja zostanie zmyta wraz z twoim "umysłem początkującym". Jedna rzecz, która będzie Ci dobrze służyć na każdym etapie Twojej podróży, to zdrowa dawka mechanicznej sympatii. Możliwe jest pisanie użytecznego oprogramowania, budowanie platform danych lub tworzenie wartościowych analiz bez zrozumienia całej infrastruktury i obliczeń. Jednak gdy coś się zepsuje lub napotkasz mylące problemy z wydajnością, to zrozumienie okaże się nieocenione. Niezależnie od wybranej specjalizacji, niezależnie od tego, czy jest to inżynieria danych, nauka o danych, tworzenie stron internetowych, czy jakakolwiek inna o nieskończonej gradacji, będziesz poruszać się po nieskończonym morzu abstrakcji. Każda warstwa pośredniości oddala Cię od sprzętu, który pilnie przetwarza Twoje wymagające instrukcje i przerzuca Twoje dane na całym świecie z prędkością światła. Rozważając fizyczne implementacje sposobu, w jaki procesory wykonują instrukcje, sposób wypełniania i uzyskiwania dostępu do rejestrów pamięci oraz złożony taniec połączeń sieciowych, zyskasz większe uznanie dla tego, co jest możliwe, co jest praktyczne i kiedy możesz chcieć przyjąć inne podejście. Nie jest konieczne (ani nie jest możliwe), aby stać się ekspertem w zakresie wszystkich systemów i oprogramowania, które napędzają Twój konkretny projekt. Zamiast tego powinieneś starać się dowiedzieć o nich wystarczająco dużo, aby zrozumieć ich ograniczenia i wiedzieć, czego nie wiesz. Dla inżynierów danych niektóre z podstawowych zasad, które okażą się najbardziej przydatne, to różne prędkości dostępu do usług sieciowych, różnego rodzaju dysków twardych i pamięci systemowej. Wszystko to w dużym stopniu przyczynia się do koncepcji grawitacji danych, która wpłynie na twoje decyzje dotyczące tego, jak i kiedy przenosić informacje między systemami lub kiedy pozostawić je na miejscu i przenieść obliczenia do danych. Pomocne jest również poznanie różnic między architekturami obliczeniowymi, takimi jak procesory ogólnego przeznaczenia, procesory graficzne czy układy ASIC, a także kiedy należy wykorzystać każdą z ich możliwości. Pod koniec dnia zawsze jest nowe, błyszczące narzędzie, język lub problem, ale zawsze dobrze przysłuży się Ci czas, który zainwestujesz w zrozumienie fundamentalnych zasad leżących u podstaw wszystkiego, co robimy jako specjaliści od oprogramowania.

Niskie koszty czujników a jakość danych

W 2016 roku pracowałem nad projektem monitoringu jakości powietrza. Celem projektu było opracowanie tanich produktów do monitorowania jakości powietrza przy użyciu tanich czujników i urządzeń o niskim poborze mocy, takich jak Raspberry Pis i Arduino. Tak więc, aby rozpocząć projekt, zamówiliśmy czujniki i płytki, aby wykonać weryfikację koncepcji. Nasz pierwszy problem dotyczył tanich czujników. Zamówiliśmy tylko wymaganą liczbę czujników: jeden czujnik cząstek stałych, jeden czujnik tlenku azotu i jeden czujnik ozonu na jedną płytkę. Plan zakładał ustawienie kilku czujników monitorujących wokół obiektu i monitorowanie jakości powietrza przez rok. Ustawiliśmy redundancje, aby chronić dane na wypadek, gdyby internet nie działał, przechowując dane na karcie SD. Po pierwszych kilku tygodniach testowania mieliśmy skok napięcia i straciliśmy wszystkie dane na karcie SD. Raspberry Pi zostało uszkodzone, ale czujniki zostały ponownie użyte, ponieważ wydawały się działać. Druga sprawa dotyczyła internetu. Jak powiedziałem, kiedy przestał działać na stronie, wszystkie dane były przechowywane na karcie SD. Zdarzyło się to wiele razy podczas naszej fazy przechwytywania danych. Zmieniliśmy kolejność uszkodzonych czujników i płytek, ale ich dostarczenie zajęło dużo czasu, co z kolei wpłynęło na ilość danych, które byliśmy w stanie przechwycić. Po początkowej fazie zdaliśmy sobie również sprawę, że czujniki użyte podczas przepięcia zostały uszkodzone i dawały błędny sygnał wyjściowy. Z tego projektu wyciągnęliśmy następujące wnioski:

•  Zawsze kupuj zbędne materiały, zwłaszcza te, których nie można pozyskiwać lokalnie.
•  Zapewnij redundancję dla wszystkich istotnych aspektów projektu, takich jak zasilanie i internet.
•  Nigdy nie używaj ponownie czujników, które brały udział w incydencie związanym z zasilaniem.
•  Miej oko na jakość danych od pierwszego dnia.

Projekt był wspaniałym doświadczeniem pouczającym, ale musieliśmy się uczyć na własnej skórze. Z perspektywy czasu, gdybym musiał przerobić ten projekt, uruchomiłbym moduły czujnikowe na bateriach, aby uniknąć problemów związanych z zasilaniem, kupiłbym czujniki lepszej jakości, aby uzyskać lepsze wyniki, i miałby nadmiarowy system do zbierania wszystkich danych z różne czujniki lokalnie, zamiast przechowywać je na każdym czujniku. Innym potencjalnym pomysłem, jako że dane trafiały już do chmury w celu przetworzenia i wdrożenia na desce rozdzielczej, byłoby dodanie mechanizmu wykrywania nieprawidłowości, który informowałby nas o wszelkich potencjalnych usterkach czujników. Ze względu na napotkane problemy dane użyteczne z naszego rocznego zbierania skróciły się do okresu pięciu miesięcy

Słuchaj swoich użytkowników - ale nie za dużo

Wszyscy widzieliśmy fajne infografiki, ale nikt nie musi mówić o inżynierach danych o ogromnej i stale rosnącej ilości danych generowanych każdego dnia. Wszyscy tym żyjemy. Wydobywamy go, przekształcamy, lądujemy (teraz zastanawiamy się, czy powinniśmy zacząć lądować przed transformacją), czyścimy (co, jeśli ty mówisz, że powinniśmy przestać je czyścić?), decydowanie, gdzie i jak długo je przechowywać, tworzenie nowej infrastruktury, aby poradzić sobie z jej ogromną ilością, filtrowanie jej, dołączanie do niej, budowanie z niej KPI i modeli, tworzenie dla niej przepływów pracy, eksponowanie katalogowanie, monitorowanie (dość łatwe, gdy zaczynaliśmy, ale coraz trudniejsze po kilku latach). Mając tak wiele do zrobienia i tak duże zapotrzebowanie ze strony naszych interesariuszy, nie jest wcale zaskakujące, że tak wiele zespołów danych, zwłaszcza obsługujących klientów wewnętrznych, jest tak pochłoniętych technicznymi aspektami inżynierii danych, że zapomina o rozważeniu, kim są ich użytkownicy i czego faktycznie potrzebują. Dane to dane, prawda? Niedługo doprowadzi to do frustracji, zmarnowanego wysiłku i braku zaufania do zespołu danych. Tak, wszystkie wymienione przeze mnie rzeczy są niezwykle ważne, ale równie ważne jest, aby zdać sobie sprawę, że nie wszyscy użytkownicy są tacy sami, i cofnąć się o krok i rozważyć, czego potrzebują na podstawie danych, które produkujesz i czego potrzebuję od ciebie. Ale nie powinieneś zaspokajać każdego ich żądania. Pewien poziom zadowolenia wynika z dostarczania wymagań i zamykania zgłoszeń, ale samo wydawanie rozwiązań stwarza długoterminowe problemy. Należy zachować równowagę między dostarczaniem tego, czego potrzebują użytkownicy, a utrzymaniem zrównoważonej, skalowalnej funkcji danych. Dla mnie zaczyna się to od wizji i strategii dla zespołu inżynierów. Jeśli wydaje się to zbyt ambitne, ustal przynajmniej pewne zasady projektowania lub bariery ochronne. Następnie zacznij traktować żądania otrzymane przez Twój zespół jako nic innego jak początek rozmowy. To po prostu wgląd w to, czego oczekują od Ciebie Twoi klienci, a nie w pełni sformułowane wymagania. Aby przekształcić je w wymagania, musisz sięgnąć nieco głębiej, aby zrozumieć problemy, które Twoi klienci próbują rozwiązać za pomocą Twoich danych. Stwórz persony, aby umożliwić Ci zrozumienie różnych użytkowników danych i przypadków użycia w Twojej organizacji; znajdź podobieństwa i zastosuj swoje zasady projektowania, aby umożliwić tworzenie produktów z danymi, które będą im służyć. Przejmij kontrolę nad swoimi danymi i zostań ekspertem w dostarczaniu ich użytkownikom we właściwy sposób.

Niech roboty egzekwują zasady

Radzenie sobie z niechlujnymi danymi wejściowymi jest częścią naszej pracy jako specjalistów od danych. Nie zawsze musimy być pedantyczni, ale proszenie producentów danych o uporządkowanie ich danych wejściowych w określony sposób zmniejsza nasze obciążenie tą niezbyt efektowną pracą. Wspaniały! Teraz nasze przychodzące dane są czystsze. Ale potem zdajemy sobie sprawę, że nasz ciężar właśnie przesunął się na interpersonalny: "prosić" innych o przestrzeganie określonych zasad, czytanie dokumentów i przestrzeganie procesów. Dla niektórych z nas jest to emocjonalnie wymagające i może sprawić, że nasza praca będzie trudniejsza, niż gdybyśmy sami radzili sobie z niechlujnymi danymi. Co z tym zrobimy? To samo, co robimy z każdym innym nudnym, powtarzalnym, trudnym do zdefiniowania zadaniem: Pinky, zautomatyzuj to! Oto kilka pomysłów na opis pracy robota weryfikującego:

•  Użyj formularza Google do przechwytywania danych lub żądań wizualizacji i jednocześnie zadawaj kluczowe pytania - na przykład, jaki jest problem, dlaczego o to prosisz, jaki jest wynik, priorytet itp.

Kluczowy bonus: Ponieważ robot zadał już Twój standardowy zestaw pytań, możesz rozpocząć rozmowę z osobą zgłaszającą prośbę, mając pewien kontekst, a nawet całkowicie ją pominąć. Jeśli to możliwe, używaj listy rozwijanej (tak, walidacja!) zamiast swobodnego wprowadzania tekstu.

Podwójny bonus: Możesz śledzić rodzaje napływających wniosków, dzięki czemu możesz informować o planowaniu i rozbudowie narzędzi samoobsługowych. Dodatkowe punkty: Wyślij e-mailem nowe prośby do oprogramowania śledzącego projekty (Jira, Asana itp.), aby automatycznie uwzględnić je w zaległościach "przychodzących żądań", które należy przygotować i nadać im priorytety.

•  Dodaj CODEOWNERS do repozytorium, definiując schemat danych lub walidację formularza. Na przykład możesz przechwytywać informacje o profilu użytkownika w witrynie Django, które później zostaną użyte w analizie kohortowej. Dodaj wpis CODEOWNERS, aby upewnić się, że ktoś z zespołu analitycznego sprawdzi wszelkie zmiany w definicjach modeli lub walidacjach formularzy.

Kluczowa premia: chociaż dobrą praktyką jest wczesne zapętlanie członków zespołu analitycznego w przypadku wszelkich proponowanych zmian projektu modelu danych, zapewnia to przynajmniej możliwość przeglądu i przygotowania się do zmiany przed ich wysłaniem.

•  Dodaj fosę wokół potoku analitycznego, dodając weryfikację danych podczas ich przetwarzania. Korzystając z narzędzia takiego jak Great Expectations, możesz zweryfikować przychodzące dane, zanim zostaną załadowane do reszty potoku przetwarzania; na przykład jako etap wstępnego przetwarzania w potoku lub gdy użytkownicy przesyłają pliki za pomocą narzędzia do przesyłania, takiego jak używane w Heineken.

Kluczowy bonus: Nawet dobrze poinformowani ludzie o dobrych intencjach popełniają błędy. Dzięki temu problemy są wykrywane wcześnie i bez rozpraszania innych członków zespołu lub wpływania na dalsze produkty.

Podwójna premia: zespół analityczny może określić, jak powinny wyglądać prawidłowe dane, pisząc Oczekiwania i korzystając z dokumentacji danych, aby udostępnić definicję "poprawności".

Krótko mówiąc, dodawanie walidacji wszędzie, gdzie możesz (w granicach rozsądku!) daje dwie wyraźne korzyści: otrzymujesz czystsze dane, a komputer może być złym facetem. Zachowaj rezerwę emocjonalną na ważniejsze rozmowy.

Naucz się korzystać z bazy danych NoSQL, ale nie jak RDBMS

Ciągle się to dzieje: czytam posty lub rozmawiam z ludźmi, którzy mają problemy z bazami danych NoSQL i tak wiele razy obwiniają narzędzie. Bazy danych NoSQL mogą już nie być nowym dzieckiem w bloku, ale wiele osób nadal wydaje się nie rozumieć, kiedy i dlaczego ich używać. Mam na myśli przede wszystkim modelowanie danych z bazami danych NoSQL, szczególnie jeśli chodzi o dokumenty JSON, szerokie kolumny i typy kluczy/wartości. Niektórzy ludzie nadal próbują ich używać tak, jak robili to z RDBMS, ale może gorzej. Tworzą schemat w bazie danych NoSQL, który jest jak schemat relacyjny, a następnie wykonują coś, co nazwałbym "naiwną migracją" lub "naiwnym schematem bazy danych". Następnie używają go jako wysypiska danych, mając nadzieję, że zrozumie to, używając języka zapytań do pracy z danymi. W tym momencie zastanawiają się, dlaczego baza danych NoSQL nie działa dobrze, nie skaluje się lub staje się zbyt droga. Jeśli wykonujesz te naiwne działania, najprawdopodobniej nie rozumiesz, do czego te bazy danych NoSQL są zoptymalizowane, jakich dokonujesz kompromisów, jaką moc wnoszą na imprezę i jak najlepiej modelować dane w celu ułatwienia dostęp. Bazy danych NoSQL działają i skalują się najlepiej, gdy schemat jest zaprojektowany do modelowania wzorców dostępu aplikacji, częstotliwości wywoływania tych wzorców i szybkości dostępu. Celem powinno być wstępne obliczenie odpowiedzi na te wzorce dostępu i rzadko zadawanie pytań dotyczących danych (zapytania ad hoc). Dzieje się tak niezależnie od tego, czy dane mają dostęp do klucza/wartości, szeroką kolumnę czy dokumenty JSON. Czy możesz zadawać pytania w bazach danych NoSQL? Jasne, ale większość z nich nie tam błyszczy. Uderzasz w wydajność, skalowalność lub koszt lub ich mieszankę. Im bardziej próbujesz używać bazy danych NoSQL jako bazy danych ogólnego przeznaczenia, tym bardziej wkraczasz na arenę "jack of all trades, master of none", na którą niestety RDBMS zostały wbite. Aby uzyskać najlepszą wydajność, skalowalność i koszt, zadawanie pytań dotyczących danych powinno stanowić mniejszość żądań w bazach danych NoSQL typu OLTP. Proponuję z pozoru proste zadanie następnym razem, gdy pomyślisz o stworzeniu nowej aplikacji z bazą danych NoSQL lub migracji z RDBMS do bazy NoSQL. Najpierw udokumentuj wszystkie wzorce dostępu tego obciążenia. Jakie dokładne dane są potrzebne, kiedy iz jaką prędkością? To powinno Cię prowadzić podczas tworzenia schematu. Ten schemat może być bardziej złożony na powierzchni, ale aplikacja może zebrać identyfikator/klucz podstawowy/klucz partycji, dzięki czemu nie zadaje pytań, a jedynie wydajnie pobiera dane. Następnie zastanów się, jakie pytania musisz odpowiedzieć na zapytanie. Musisz mieć odpowiednią równowagę między szybkim i tanim dostępem do danych dla większości rzeczy, a następnie wysyłanie zapytań tylko wtedy, gdy naprawdę ich potrzebujesz. Jeśli nie możesz wykonać tych zadań, w tym wcześniej udokumentować wszystkich wzorców dostępu aplikacji, baza danych NoSQL może nie być odpowiednim rozwiązaniem dla Twojego obciążenia. Być może lepiej będzie z RDBMS, który zapewnia większą elastyczność kosztem skalowalności.

Poznaj wartość na bajt swoich danych

Jako inżynier danych zajmującymh się oprogramowaniem opartym na danych zauważyłem, że nowe technologie, takie jak Hadoop i Amazon S3, umożliwiają zespołom produktowym przechowywanie dużej ilości danych. W porównaniu z wcześniejszymi systemami, te nowe systemy obniżyły koszt w przeliczeniu na bajt danych tak bardzo, że przechowywanie terabajtów danych stało się ekonomicznie opłacalne bez wiercenia dziury w kieszeni. Obliczenie tego wskaźnika było łatwe: podziel całkowity rozmiar zbioru danych przez jego całkowity koszt i uzyskasz wskaźnik kosztu na bajt. Inżynierowie produktu zaczęli rejestrować każde zdarzenie w swojej aplikacji bez namysłu: "Będę rejestrować szczegółowe szczegóły wydarzenia, mimo że tak naprawdę potrzebuję tylko jednego małego fragmentu zdarzenia. Logowanie jest tanie, więc po co zawracać sobie głowę zmniejszaniem rozmiaru mojego rekordu dziennika?" My, inżynierowie danych, byliśmy zachwyceni, mogąc pochwalić się rozmiarem naszych zestawów danych o wielkości terabajtów w porównaniu z tradycyjnymi administratorami baz danych, którzy zwykle zarządzali nawet kilkuset gigabajtami danych. Lokomotywy General Electric generują 1 TB na jednej trasie towarowej. Boeing 787 generuje pół terabajta danych na lot. Inżynierowie danych pomagają zarządzać tymi danymi. Miało to miejsce w połowie 2010 roku, kiedy przedsiębiorstwa wykorzystały szybko spadający koszt na bajt, aby praktycznie nigdy nie usuwać swoich danych dziennika (poza względami zgodności). Przewiń do początku lat dwudziestych. Dziś nie kwestionuje mnie rozmiar danych, które muszę utrzymywać. Ważna jest dla mnie wartość, którą przedsiębiorstwo wydobywa z danych. Jakie spostrzeżenia jesteśmy w stanie wydobyć z naszych zbiorów danych? Czy mogę korzystać z danych, kiedy ich potrzebuję, czy muszę na nie czekać? Najlepiej jest je uchwycić za pomocą nowej metryki, wartości na bajt. W moim przedsiębiorstwie mam własny sposób obliczania wartości na bajt. Jeśli zapytanie dotyka jednego określonego bajtu danych, wartość tego bajtu wynosi 1. Jeśli określony bajt nie jest dotknięty przez żadne zapytanie, wartość tego bajtu wynosi 0. Obliczam swoją wartość na bajt jako procent unikalnych bajtów, które były używane do obsługi dowolnego zapytania. W przypadku mojego wieloterabajtowego zestawu danych stwierdziłem, że moja wartość na bajt wynosi 2,5%. Oznacza to, że na każde 100 bajtów danych, którymi pomagam zarządzać, używam tylko informacji zapisanych w 2,5 bajtach. Jaka jest wartość na bajt Twojego przedsiębiorstwa? Możesz obliczyć to inaczej, ale jeśli możesz zwiększyć wartość na bajt systemu, możesz pozytywnie wpłynąć na decyzje podejmowane w przedsiębiorstwie na podstawie danych.

Poznaj swoje opóźnienia

Każdy system danych ma trzy cechy, które jednoznacznie go identyfikują: rozmiar danych, czas ostatnich danych i opóźnienie zapytań dotyczących tych danych. Prawdopodobnie znasz pierwszy, ale pozostałe dwa są czasem refleksją. Jako inżynier danych często wdrażałem system Big Data dla jednego przypadku użycia. Następnie nowy użytkownik używa tego samego systemu danych do innego przypadku użycia i narzeka: "Och, moje opóźnienia w zapytaniach są wolniejsze niż mój akceptowalny limit 500 milisekund" lub "Moje zapytanie nie znajduje rekordów danych, które zostały utworzone w ciągu ostatnich 10 sekund". Na samym początku projektowania systemu danych zadaję sobie następujące trzy pytania:

Jakie jest opóźnienie danych?

Wymagania aplikacji dotyczące opóźnienia danych mogą się znacznie różnić. System budżetowania rocznego byłby usatysfakcjonowany, gdyby miał dostęp do wszystkich danych z ostatniego miesiąca i wcześniejszych. Podobnie system codziennego raportowania byłby prawdopodobnie zadowolony, gdyby mógł uzyskać dostęp do danych z ostatnich 24 godzin. Aplikacja do tworzenia rankingów gier online byłaby zadowolona z analizowania danych, które zostały wygenerowane w ciągu ostatniej sekundy lub wcześniej.

Jakie jest opóźnienie mojego zapytania?

Jeśli buduję system codziennego raportowania, stać mnie na zbudowanie systemu zoptymalizowanego pod kątem ogólnej przepustowości. Opóźnienie zapytania może zająć kilka minut lub kilka godzin, ponieważ zestaw raportów muszę generować tylko raz dziennie. Z drugiej strony aplikacja zaplecza, która obsługuje spersonalizowane wiadomości dla czytelnika, zwykle wymagałaby opóźnień rzędu kilku milisekund, a ten system danych został zaprojektowany w celu optymalizacji opóźnień zapytań.

Jakie są moje zapytania na sekundę?

Jeśli mój system danych zasila aplikację na urządzeniu mobilnym, moje zapytania na sekundę (QPS) prawdopodobnie będą dziesiątkami lub setkami równoczesnych zapytań. Jeśli mój system danych jest używany do budowania codziennego systemu raportowania, muszę obsługiwać maksymalnie od 5 do 10 jednoczesnych zapytań. Odpowiedzi na te trzy pytania określają rodzaj systemu danych, którego musisz użyć. Opóźnienie danych jest zdominowane przez potoki danych, zwane również wyodrębnianiem, przekształcaniem, ładowaniem (ETL). Możesz użyć procesu ETL, aby usunąć rekordy ze złymi danymi lub wstępnie wygenerować agregaty w przedziałach czasowych. Proces ETL dodaje opóźnienia do danych, a krótszy potok oznacza, że możesz wysyłać zapytania do najnowszych danych. Opóźnienia zapytań i QPS są zdominowane przez bazę danych, która obsługuje Twoje zapytania. Jeśli używasz magazynu klucz/wartość, uzyskasz bardzo małe opóźnienia zapytań, ale będziesz musiał zaimplementować większą część logiki biznesowej w kodzie aplikacji. Alternatywnie, jeśli używasz hurtowni danych, która udostępnia interfejs API SQL, możesz delegować większy udział logiki aplikacji za pośrednictwem SQL do hurtowni danych, ale opóźnienie zapytań byłoby większe niż w przypadku magazynu klucz/wartość, być ograniczone do 5 lub 10 jednoczesnych zapytań.

Jak zapobiegać buntom danych?

Zespoły danych są na kursie kolizyjnym. Widzieliśmy wzrost ilości, szybkości i różnorodności danych, które prowadzą do bardziej złożonych systemów, ale najważniejszym elementem wyrafinowania danych firmy jest zdecydowanie liczba ludzi-architektów, inżynierów, analityków i naukowców- w stanie budować nowe produkty danych i ich efektywność w tym zakresie. W miarę jak przedsiębiorstwa zwiększają swoje wysiłki i ich zespoły w celu tworzenia nowych produktów danych, wzajemne powiązania i wynikająca z nich złożoność mogą być paraliżujące dla tych grup. Co gorsza, często mają sprzeczne priorytety, posyłając ich na ścieżkę pełną konfliktów. W przypadku zespołów infrastruktury budowanie pod kątem skalowania, bezpieczeństwa i kosztów ma ogromne znaczenie, podczas gdy zespoły inżynierskie kładą nacisk na elastyczność, szybkość rozwoju i łatwość konserwacji. Tymczasem naukowcy i analitycy danych koncentrują się na dostępności i wykrywalności danych oraz łączności narzędzi. Zaspokojenie potrzeb tylko jednej grupy jest gwarantowaną strategią wzniecania "buntu danych", w którym użytkownicy wewnętrzni tworzą ukryte organizacje IT z mandatem do szybkiego działania i uwolnienia się od sprzecznych priorytetów. Jednak nowe procesy i technologie mogą pomóc przywrócić równowagę szybkości i elastyczności, bez narażania skali, bezpieczeństwa i łatwości konserwacji. Dzięki DevOps umożliwiliśmy większej liczbie osób niż kiedykolwiek wcześniej tworzenie coraz bardziej złożonych produktów oprogramowania szybciej i bezpieczniej, wprowadzając architektury modułowe, konfiguracje deklaratywne i zautomatyzowane systemy. To samo jest możliwe w przypadku danych, co oznacza, że możemy zastosować lekcje, których nauczyliśmy się dzięki DevOps, aby uchronić organizacje przed padnięciem ofiarą buntu danych:

Architektury modułowe: dzisiejsze rurociągi zbyt często przypominają miskę spaghetti, ale ważne jest, aby mieć dobrze zdefiniowane, zmodularyzowane projekty rurociągów. Podobnie jak w przypadku interfejsów API i mikrousług, posiadanie mniejszych usług, które koncentrują się na różnych etapach, umożliwia podejście zorientowane na dane do aranżacji potoku i zapewnia większą elastyczność.
Konfiguracje deklaratywne : podobnie do tego, co widzieliśmy wszędzie, od infrastruktury po programowanie frontendu, budowanie na platformie, która dogłębnie rozumie, jak działają potoki danych, pozwala nam przenieść znacznie więcej tej złożoności na sam silnik bazowy. W efekcie zastosowanie systemów deklaratywnych zmniejsza złożoność wdrożenia i obciążenia związane z utrzymaniem.
Systemy zautomatyzowane : automatyzacja wielu ręcznych kroków programistycznych związanych z tworzeniem potoku zapewnia stabilność, szybkość i elastyczność architektur danych niezależnie od nieuniknionych zmian typu danych i aplikacji. Automatyzacja obniża ogólne koszty projektowania i konserwacji w całym cyklu życia opracowywania danych, jednocześnie poprawiając jakość i niezawodność wynikowych potoków danych

W ciągu ostatniej dekady pojawiły się trendy, gdy zespoły inżynierów przeszły od monolitycznych do modułowych, ręcznych do zautomatyzowanych i imperatywnych do deklaratywnych, co skutkuje bardziej stabilnymi fundamentami dla krytycznych komponentów w firmach. Te same trendy można wykorzystać w zespołach danych, zapewniając harmonijną równowagę między innymi sprzecznymi celami i pomagając zapobiegać buntom w zakresie danych. W zamian zespoły danych zyskują korzyści w postaci zwiększonej produktywności, elastyczności i szybkości dostarczania nowych, innowacyjnych produktów danych.

Jak zbudować platformę danych jak produkt: Przejdź od (standardowa Dev.) Zero do Bona Fide Data Hero

W swej istocie platforma danych jest centralnym repozytorium wszystkich danych, obsługującym gromadzenie, czyszczenie, przekształcanie i stosowanie danych w celu generowania spostrzeżeń biznesowych. Dla większości organizacji budowanie platformy danych nie jest już fajną opcją, ale koniecznością, ponieważ wiele firm wyróżnia się na tle konkurencji dzięki zdolności do zbierania praktycznych wniosków ze swoich danych. W podobny sposób, w jaki wiele osób postrzega same dane jako produkt, firmy zorientowane na dane, takie jak Uber, LinkedIn i Facebook, coraz częściej postrzegają również platformy danych jako produkty, z dedykowanymi zespołami inżynieryjnymi, produktowymi i operacyjnymi. Jednak pomimo ich wszechobecności i popularności, platformy danych są często rozwijane z niewielkim przewidywaniem, kto ich używa, w jaki sposób są używane i co inżynierowie i menedżerowie produktu mogą zrobić, aby zoptymalizować te doświadczenia. Niezależnie od tego, czy dopiero zaczynasz, czy jesteś w trakcie skalowania, dzielimy się trzema najlepszymi praktykami, które pozwolą uniknąć tych typowych pułapek i zbudować platformę danych swoich marzeń.

Dopasuj cele swojego produktu do celów biznesowych

Kiedy budujesz lub skalujesz swoją platformę danych, pierwsze pytanie, które powinieneś zadać, brzmi: w jaki sposób dane mapują się do celów Twojej firmy?

Aby odpowiedzieć na to pytanie, musisz założyć czapkę menedżera produktu platformy danych. W przeciwieństwie do konkretnych menedżerów produktu, menedżer produktu platformy danych musi rozumieć ogólny obraz w porównaniu z celami specyficznymi dla danego obszaru, ponieważ dane zasilają potrzeby każdego innego zespołu funkcjonalnego, od marketingu i rekrutacji po rozwój biznesu i sprzedaż.

Uzyskaj opinie i wpisowe od właściwych interesariuszy

Nie trzeba dodawać, że otrzymywanie zarówno wpisowego z góry, jak i powtarzających się informacji zwrotnych w trakcie procesu rozwoju produktu jest niezbędnymi elementami podróży platformy danych. To, co nie jest tak szeroko rozumiane, to czyj głos powinieneś się interesować. Opracowując nowy system katalogowania danych w wiodącej firmie, firma transportowa, jeden menedżer produktu, z którym rozmawialiśmy, spędziła trzy miesiące próbując sprzedać wiceprezes ds. inżynierii pomysł swojego zespołu, ale została zamknięta w jednym e-mailu przez szefa personelu wiceprezesa. Koniec końców ważne jest, aby to doświadczenie wspierało społeczność entuzjastów danych, którzy wspólnie tworzą, udostępniają i uczą się. Ponieważ Twoja platforma ma potencjał, aby służyć całej firmie, każdy powinien czuć się zainwestowany w jej sukces, nawet jeśli oznacza to kompromisy po drodze.

Przedstaw długoterminowy wzrost i zrównoważony rozwój nad krótkoterminowymi zyskami

Platformy danych nie odnoszą sukcesu tylko dlatego, że czerpią korzyści z bycia "pierwszym na rynku". Na przykład platforma big data Ubera była budowana w ciągu pięciu lat, stale ewoluując wraz z potrzebami biznesu; Pinterest przeszedł kilka iteracji swojego podstawowego produktu do analizy danych; a LinkedIn buduje i iteruje swoją platformę danych od 2008 roku! Nasza sugestia: wybierz rozwiązania, które mają sens w kontekście Twojej organizacji i dostosuj swój plan do tych oczekiwań i terminów. Czasami szybkie wygrane w ramach większej strategii rozwoju produktu mogą pomóc w osiągnięciu wewnętrznego buy-in, o ile nie jest to krótkowzroczne. Nie od razu Rzym zbudowano, podobnie jak Twoja platforma danych.

Podpisz się na metryki bazowe dla swoich danych i jak je mierzysz

Nie ma znaczenia, jak świetna jest Twoja platforma danych, jeśli nie możesz ufać swoim danym, ale jakość danych oznacza różne rzeczy dla różnych interesariuszy. W związku z tym Twoja platforma danych nie odniesie sukcesu, jeśli Ty i Twoi interesariusze nie będziecie zgadzać się z tą definicją. Aby rozwiązać ten problem, ważne jest ustalenie podstawowych oczekiwań dotyczących wiarygodności danych - innymi słowy, zdolności organizacji do zapewnienia wysokiej dostępności i kondycji danych przez cały cykl życia danych. Wyznaczanie jasnych celów na poziomie usług (SLO) i wskaźników poziomu usług (SLI) dla niezawodności aplikacji jest oczywiste. Zespoły danych powinny zrobić to samo dla swoich potoków danych.

Ukryty koszt wejścia/wyjścia danych

Podczas gdy inżynierowie danych mają dostęp do bibliotek i funkcji pomocniczych do odczytu i zapisu danych, znajomość pewnych szczegółów dotyczących procesu operacji odczytu i zapisu pomaga zoptymalizować aplikacje. Zrozumienie i możliwość skonfigurowania różnych opcji może pomóc wielu aplikacjom intensywnie przetwarzającym dane, zwłaszcza na dużą skalę. . Poniżej znajduje się kilka ukrytych szczegółów związanych z wejściem/wyjściem danych (I/O).

Kompresja danych

Chociaż wszyscy zgadzają się, że skompresowane dane mogą zaoszczędzić miejsce na dysku i obniżyć koszty transferu sieciowego, możesz wybierać spośród wielu algorytmów kompresji danych. Przy wyborze algorytmu należy zawsze brać pod uwagę szybkość kompresji w stosunku do współczynnika kompresji. Dotyczy to zarówno operacji kompresji, jak i dekompresji. Na przykład, jeśli dane są już duże, wybór szybszego algorytmu dekompresji przy jednoczesnym poświęceniu większej ilości zasobów na wolniejszą kompresję się opłaca.

Format danych

Chociaż większość danych nieustrukturyzowanych to zbiór rekordów, może to nie być najlepszy format dla niektórych typów dostępu do danych. Na przykład rekord, który ma wiele zagnieżdżonych pól, z których tylko kilka jest często używanych, najlepiej jest przechowywać w formacie danych kolumnowych, a nie w formacie rekordu. Należy rozważyć użycie różnych poziomów zagnieżdżania i spłaszczania kolumn w celu wydajnego pisania oraz operacji pobierania danych. To również się opłaca oszczędność kosztów przechowywania danych.

Serializacja danych

Większość danych jest serializowana do rekordów przy użyciu różnych formatów. Dane strukturalne, które są reprezentowane w różnych formatach danych, powinny być serializowane podczas zapisywania, a następnie deserializowane za każdym razem, gdy są odczytywane. Ten proces jest zwykle ukryty przed użytkownikami, ale wybranie wydajnych opcji serializacji/deserializacji (w bibliotece serde) znacznie poprawi ogólną wydajność aplikacji na dużą skalę. Chociaż istnieje wiele innych aspektów wydajności we/wy, znajomość niektórych z tych szczegółów może pomóc w poprawie ogólnej wydajności aplikacji. Inżynierowie danych powinni poświęcić trochę czasu na ich zrozumienie i profilowanie swoich aplikacji, aby rozbić ukryte koszty związane z I/O.

Daj produktom danych interfejs z ukrytą dokumentacją

Pojawienie się DataOps pokazuje wartość wprowadzenia zasad DevOps do inżynierii danych. Podobna, ale mniej zbadana, jest potrzeba włączenia zasad od projektowania i zarządzania produktem do budowania danych i wyraźnego stworzenia dobrego doświadczenia użytkownika. Inżynierowie powinni krytycznie myśleć o zbudowaniu "frontendu" dla swoich danych dzięki czemu jest łatwy do zrozumienia i intuicyjny w użyciu. W szczególności w przypadku danych frontend nie jest tradycyjnym interfejsem użytkownika, ale raczej zbiorem narzędzi i dokumentów, które umożliwiają użytkownikom zrozumienie intencji, pochodzenia i jakości zestawu danych. Oczywiście zbudowanie tego frontendu nie jest łatwym zadaniem i często inżynierowie danych są w pełni przygotowani do technicznych aspektów swojej pracy. Jednakże wiele artefaktów, których chcą konsumenci danych, można utworzyć przy niewielkim lub zerowym wysiłku, jeśli inżynierowie wykorzystają ukrytą dokumentację : systematyczne dokumentowanie własnych procesów myślowych i podejmowanie decyzji podczas procesu inżynieryjnego w sposób, który może być łatwo udostępniany i interpretowany przez użytkowników. Poniżej znajdują się przykłady ukrytej dokumentacji, którą można zebrać w przypadku niedrogiego interfejsu danych:

Generuj słownik danych podczas zbierania wymagań użytkownika : Kiedy rozmawiasz z użytkownikami o wymaganiach dotyczących danych (rozmawiasz z użytkownikami, prawda?), angażuj ich w proces dokumentowania tych wymagań (takich jak nazwy zmiennych i definicje) w standardowym formacie arkusza kalkulacyjnego. To nie tylko oszczędza potencjalną przeróbkę, pomagając w dostosowaniu się do klienta na początku, ale może również służyć jako doskonały początek słownika danych napisanego w języku biznesowym.
Wykorzystaj hierarchiczną taksonomię nazewnictwa zmiennych : Nazwy zmiennych to główny sposób, w jaki użytkownicy będą wchodzić w interakcję z Twoimi danymi i jeden z najważniejszych elementów doświadczenia użytkownika. Przyjmij hierarchiczną strukturę nazewnictwa, która odzwierciedla Twój model danych. Możesz rozważyć strukturę taką jak ENTITY_ATTRIBUTE_DESCRIPTOR_TYPE; na przykład ACCT_ID, ACCT_LOGIN_DT, ACCT_LOGIN_DEVICE_CD dla danych relacyjnych. Taksonomia może zarówno pomóc w kodowaniu metadanych, aby użytkownicy poprawnie interpretowali nazwy pól i intencje, jak i ułatwiać programowanie na podstawie danych (np. poprzez zaznaczenie wszystkich pól zawierających pewne typowe "zaczątki").
Publicznie odpowiadaj na pytania użytkowników na liście FAQ : Zrozumienie listy kontrolnej InnerSource autorstwa Silony Bonewald wprowadza koncepcję dokumentacji pasywnej: odpowiadanie na pytania użytkowników na forach publicznych, takich jak Slack lub GitHub, zamiast prywatnych kanałów, takich jak bezpośrednie wiadomości, aby utworzyć trwały zapis. Tę samą strategię można wykorzystać do opracowania listy często zadawanych pytań dla użytkowników danych.

W zależności od przepływu pracy możesz również rozważyć następujące kwestie:

Wizualizuj potok danych : Wiele popularnych systemów zarządzania przepływem pracy, takich jak Apache Airflow i Prefect, wizualizuje przepływ danych na ukierunkowanym wykresie acyklicznym. Chociaż ten typ diagramu może być onieśmielający dla przeciętnego użytkownika biznesowego, bardziej zaawansowani analitycy danych i analitycy danych mogą go użyć do niezależnego śledzenia pochodzenia danych, jeśli kiedykolwiek będą potrzebowali dokładniejszego zrozumienia definicji metryk lub uzyskania dostępu do bardziej surowych form danych.
Podziel się swoimi oczekiwaniami i kontrolami jakości : Coraz częściej inżynierowie wbudowują w swój potok kontrole jakości danych za pomocą narzędzi takich jak Great Expectations. Narzędzia te mogą nie tylko pomóc w walidacji danych i wyłapywaniu błędów dla dalszych użytkowników, ale także zmusić do wyraźniejszego określenia, w jaki sposób dane mają się zachowywać.

Przywracanie "ustrukturyzowanego" powrotu do SQL

Niewiele pytań w informatyce krążyło od ponad 50 lat i wciąż się pojawia. Jednym z nich jest sposób pisania SQL. Relacyjne bazy danych zdominowały rynek od lat 70-tych. Następnie powstał cały ruch NoSQL i płynnie przekształcił się w "NewSQL". Ostatnio wszystkie główne systemy przesyłania strumieniowego dodały obsługę SQL. W tym języku musi być coś naprawdę potężnego. Z wielką mocą przychodzi - wiesz. SQL jest na tyle elastyczny, że pozwala pisać zapytania w niemal dowolnej formie i nadal uzyskiwać wyniki. Problem polega na tym, że zrozumienie, czy ten wynik ma sens, zwykle wymaga więcej wysiłku niż jego wyprodukowanie. Widziałeś to sam, "naprawianie" złączeń za pomocą instrukcji DISTINCT lub wielokrotne liczenie wierszy. Twierdzę, że większości z tego można uniknąć, pisząc zapytania w ustrukturyzowany sposób, najpierw optymalizując pod kątem czytelności. Jak więc stworzyć strukturę? Najpierw zacznij od końca: jak powinna wyglądać odpowiedź? Załóżmy na przykład, że chcesz przeanalizować przychody z określonego kanału sprzedaży podzielonego na kategorie według regionów. Widzisz, to już przygotowana instrukcja SELECT; (W tym przykładzie używam pseudo-SQL, aby uniknąć niepowiązanych szczegółów.)



Zwykle głównym tematem jest pytanie, na które próbujesz odpowiedzieć. W tym przykładzie chcesz przeanalizować przychody. Tak więc sprzedaż będzie Twoim głównym podmiotem, stołem napędowym. W OD należy zawsze umieszczać tę tabelę na pierwszym miejscu



Teraz chcesz filtrować dla określonego kanału. W tym celu przejdź do nowej tabeli, kanałów. Dodając ją, pomyśl o swoim zapytaniu jak o drzewie - główna tabela to pień, a nowa tabela to gałąź



Następnym krokiem jest pogrupowanie wyników według regionu. Tabela sprzedaży zawiera tylko dzielnice. W przypadku regionów musisz przejść do tabel districts > cities > regions. Tutaj twoja gałąź składałaby się z wielu tabel



Metafora rozgałęzień pomaga również w regułach złączeń OUTER. Ilekroć zostanie wprowadzony, przenieś podmiot we wszystkich warunkach przyłączenia do końca bieżącej gałęzi. Oczywiście przyjrzeliśmy się tutaj dość prostemu zapytaniu. A SQL jest dziś wyrafinowany. Możesz wykonywać różne funkcje okna i złożone agregacje. Jednak struktura powinna być na pierwszym miejscu. Aby Twoje zapytanie było uporządkowane i przyjemne do czytania, wykonaj następujące kroki:

1. Rozpocznij z myślą o końcu. Zastanów się, jak powinna wyglądać Twoja odpowiedź.
2. Znajdź główny temat. Zawsze umieszczaj ten temat w instrukcji FROM jako pierwszy. Jeśli istnieje więcej niż jeden temat, zapakuj każdy z nich we wspólne wyrażenie tabelowe (CTE) i zastosuj te kroki do każdego z nich.
3. Dodaj tabele do głównej, po jednej intencji na raz. Na przykład intencją może być: "Wszystkie poniższe JOIN są tutaj, aby uzyskać region na sprzedaż".
4. Uważaj na swoje sprzężenia. Upewnij się, że dodawana tabela zawiera nie więcej niż jeden wiersz na warunek łączenia.
5. Przejdź do grupowania, funkcji analitycznych itd. dopiero po zakończeniu łączenia wszystkich źródeł danych.

Gdy już nauczysz się, jak pozyskiwać potrzebne dane z różnych źródeł i udokumentować je w formie czytelnej struktury, zapytanie samo opowie historię Twojej analizy. Co ważniejsze, ta struktura pomoże innym lepiej zrozumieć twoje intencje i zaufać twoim wynikom.

Podstawowa wiedza

Wiedza rośnie wykładniczo. Trudno zmierzyć przyrost wiedzy, zwłaszcza w długim okresie czasu. Jeśli jednak użyjemy liczby publikacji naukowych jako wyznacznika wiedzy, możemy zaobserwować, że wiedza podwaja się co dziewięć lat. Jeśli zaczniesz pracować dzisiaj, za 20 lat, kiedy będziesz w połowie swojej kariery, ilość wiedzy zaangażowanej w Twoje życie zawodowe będzie około cztery razy większa niż obecnie. Ten wniosek byłby podobny (lub nawet bardziej szokujący), gdybyśmy zamiast tego wzięli pod uwagę liczbę opublikowanych książek, liczbę naukowców lub ilość danych tworzonych każdego dnia jako wskaźnik wiedzy. I to jest przerażające. Wszyscy pracownicy wiedzy, tacy jak inżynierowie danych, stają zatem przed wyzwaniem. Z jednej strony, wzrost wiedzy prowadzi do nie dającej się opanować potrzeby bycia na bieżąco z kilkoma nowymi koncepcjami, technologiami i frameworkami. Z drugiej strony wiedza staje się coraz bardziej ulotna, a to, czego uczymy się dzisiaj, jutro może być przestarzałe. Ponieważ trudno uwierzyć, że w niedalekiej przyszłości tempo wzrostu wiedzy zmniejszy się, wszystkie dane ,inżynierowie cierpią z powodu tego szczególnego przekleństwa wiedzy. Tak więc najważniejsze pytanie brzmi: jak sobie radzimy z tym wzrostem wiedzy? Jedną z możliwych odpowiedzi jest skupienie się na podstawach. W świecie ciągłych zmian podstawy są ważniejsze niż kiedykolwiek, ponieważ umożliwiają szybką naukę nowych dziedzin wiedzy w miarę ich powstawania. Z definicji podstawy są podstawowymi zasadami, z których można wyprowadzić resztę dziedziny. Tak więc, jeśli opanujesz podstawy, możesz opanować każdą nowo wschodzącą dziedzinę. Co więcej, podstawy przetrwały próbę czasu. Jest to przejaw efektu Lindy, który mówi, że przyszła oczekiwana długość życia każdej nie psującej się istoty jest proporcjonalna do jej obecnego wieku. W związku z tym możemy wywnioskować, że skoro podstawy są tworem intelektualnym (trwałą jednostką), która trwała przez długi czas, prawdopodobnie będą trwać znacznie dłużej. W świecie zalanym ogromną ilością wiedzy musimy być w stanie zrozumieć informacje, odróżnić to, co ważne od tego, co nieważne, a przede wszystkim połączyć to, co wiemy, aby napędzać naszą naukę i podtrzymywać tempo. To wymaga wiedzy. Podstawowej wiedzy.

Przyjaciele nie pozwalają znajomym na podwójne pisanie

Dawno minęły czasy, kiedy programiści aplikacji dla przedsiębiorstw mogli po prostu umieszczać dane w bazie danych swojej aplikacji i nazywać to dniem. W dzisiejszych czasach dane często muszą być utrwalane w wielu systemach w celu zaspokojenia coraz większych wymagań użytkowników: zmienione dane muszą zostać wysłane do oddzielnych usług wyszukiwania, umożliwiając bogate w funkcje wyszukiwanie pełnotekstowe, które zwykle nie jest zapewniane przez same bazy danych; a pamięci podręczne muszą być aktualizowane, co pozwala na szybkie pobieranie danych bez dostępu do samej bazy danych. Ale w jaki sposób wszystkie te magazyny danych - baza danych aplikacji, indeks wyszukiwania, pamięć podręczna - mogą być zsynchronizowane? Możemy pokusić się o po prostu wysyłanie żądań do wszystkich tych systemów o aktualizację danych, ale oto smoki. Co się stanie, jeśli na przykład indeks wyszukiwania jest tymczasowo niedostępny z powodu problemu z siecią? Moglibyśmy pomyśleć o zaimplementowaniu logiki ponawiania prób, ale sprawy szybko się komplikują. Co gorsza, nawet jeśli jesteśmy w stanie pomyślnie zaktualizować wszystkie zaangażowane zasoby, możemy skończyć z niespójnością danych. O ile wszystkie aktualizacje nie są wykonywane w ramach jednej globalnej transakcji (co z kolei wiązałoby jakość naszych usług z dostępnością wszystkich zasobów), nie mamy gwarancji porządkowania wielu zmian danych. Jeśli dwie aktualizacje tego samego rekordu następują w bliskiej odległości czasowej, mogą one zostać zastosowane w indeksie wyszukiwania w innej kolejności niż w bazie danych. Na pozór wszystko wyglądałoby dobrze, ale indeks wyszukiwania w rzeczywistości podawałby nieprawidłowe wyniki. I właśnie dlatego znajomi nie pozwalają znajomym na podwójne zapisy: zapisy do wielu rozproszonych zasobów bez współdzielonej semantyki transakcji są podatne na błędy i prowadzą do niespójności danych. Ale jest nadzieja: jeśli nie możemy zaktualizować wielu zasobów, zawsze możemy zaktualizować jeden, a jest to baza danych aplikacji. Następnie możemy przeprowadzić aktualizację indeksu wyszukiwania, pamięci podręcznej i innych systemów pomocniczych na podstawie zmian w bazie danych. W tym miejscu pojawia się funkcja przechwytywania danych zmian (CDC): pozwala użytkownikom reagować na wszystkie zmiany w bazie danych i przesyłać je jako zdarzenia do dalszych odbiorców. Pozwala to uniknąć omówionych wcześniej problemów: oparte na dziennikach rozwiązania CDC, takie jak Debezium, korzystają z dziennika transakcji bazy danych, wyodrębniając wszystkie zmiany danych w dokładnej kolejności serializacji transakcji. Propagując zdarzenia zmian do konsumentów za pośrednictwem rozproszonego dziennika zatwierdzania, takiego jak Apache Kafka, problem dostępności jest również rozwiązywany: jeśli dalszy system nie jest dostępny przez pewien czas, może po prostu kontynuować odczytywanie tematów dotyczących danych zmian od momentu, w którym został przerwany wyłączyć przed. A ponieważ proces CDC jest również asynchroniczny, jedynym wymaganym synchronicznie zasobem jest sama baza danych. Kolejną zaletą propagowania zdarzeń zmian za pośrednictwem rozproszonego dziennika zatwierdzania jest możliwość włączenia innych konsumentów i przypadków użycia poprzez ponowne odczytanie tematów zdarzeń zmian od początku. W ten sposób dane mogą być przekazywane do dowolnej innej zainteresowanej usługi, a wszystko to bez polegania na podwójnym zapisie.

Skoncentruj się na utrzymaniu i rozdziel te zadania ETL

W miarę poszerzania się data science, praktycy mogą doskonale radzić sobie z wykorzystaniem przygotowanych danych, ale nie mają umiejętności, aby wykonać to przygotowanie w sposób rzetelny. Te obowiązki można podzielić na wiele ról i zespołów, ale ogromne, produktywne korzyści można osiągnąć, stosując podejście pełnego stosu, w którym naukowcy zajmujący się danymi są właścicielami całego procesu od pomysłu do wdrożenia. Niezależnie od tego, czy jesteś naukowcem zajmującym się danymi tworzącymi własne ETL, czy inżynierem danych pomagającym analitykom danych w tym procesie, ułatwienie zrozumienia, debugowania i rozszerzania potoków danych zmniejszy obciążenie związane z pomocą techniczną dla Ciebie i Twoich kolegów z zespołu. Umożliwi to większą iterację i innowacyjność w przyszłości. Podstawowym sposobem na zwiększenie łatwości konserwacji ETL jest przestrzeganie podstawowych najlepszych praktyk inżynierii oprogramowania i rozbicie przetwarzania na małe i łatwe do zrozumienia zadania, które można połączyć ze sobą - najlepiej za pomocą przepływu pracy silnik. Małe zadania ETL są łatwiejsze do zrozumienia dla nowych współtwórców i opiekunów, są łatwiejsze do debugowania i pozwalają na większe ponowne wykorzystanie kodu. Robienie zbyt wiele na etapie przetwarzania jest częstą pułapką zarówno dla niedoświadczonych, jak i bardzo doświadczonych. Mając mniejsze doświadczenie, może być trudno wiedzieć, jak rozłożyć duży przepływ pracy na małe, dobrze zdefiniowane przekształcenia. Jeśli jesteś stosunkowo nowy w tworzeniu ETL, zacznij od ograniczenia liczby przekształceń wykonywanych w każdym zadaniu, oddzielając takie rzeczy, jak łączenie tabel źródłowych, tworzenie kolumn flag i agregowanie wyników. Powinieneś zasięgnąć porady i recenzji kodu od osób z większym doświadczeniem i członków zespołu, którzy pomogą wesprzeć Twoje ETL w produkcji. Te recenzje powinny skupiać się na prostocie, a nie na wydajności. Wysoce doświadczeni inżynierowie danych mogą również tworzyć zbyt gęste potoki, ponieważ łańcuchy złożonych transformacji są powszechne. Chociaż jest to dopuszczalne, jeśli są jedynymi, którzy utrzymują te ETL, zabrania mniej doświadczonym analitykom danych lub inżynierom wspierania, modyfikowania lub rozszerzania tych potoków. Może to blokować innowacje, ponieważ naukowcy zajmujący się danymi polegają na niewielkiej liczbie ekspertów, którzy wdrażają zmiany. Jeśli jesteś doświadczonym inżynierem danych, powinieneś zastanowić się, jak łatwo osobie z mniejszym doświadczeniem zrozumieć i wykorzystać Twoją pracę oraz rozważyć refaktoryzację, aby była bardziej dostępna. Twoja praca nie musi być powszechnie rozumiana, ale zastanów się, ile Ty i inni zyskujecie na dodatkowej złożoności. Podział potoków na małe zadania może wiązać się z kosztami obliczeniowymi, ponieważ pracy nie można zoptymalizować poza tymi granicami. Czasami jednak zbytnio skupiamy się na wydajności środowiska wykonawczego, podczas gdy zamiast tego powinniśmy skupić się na szybkości włączanych innowacji. W niektórych przypadkach wydajność ma krytyczne znaczenie, ale optymalizacja codziennych zadań wsadowych w celu skrócenia czasu pracy o godzinę może wydłużyć czas pracy o tygodnie lub nawet miesiące na wdrożenie przyszłych ulepszeń.

Pięć najlepszych praktyk dotyczących stabilnego przetwarzania danych: o czym należy pamiętać podczas konfigurowania procesów takich jak ETL lub ELT

Poniższe pięć najlepszych praktyk to podstawy, jeśli chodzi o wdrażanie procesów danych, takich jak ELT lub ETL.

Zapobiegaj błędom
W przypadku niepowodzenia należy wykonać wycofanie, podobnie jak w SQL. Jeśli zadanie zostanie przerwane z błędami, wszystkie zmiany powinny zostać wycofane. W przeciwnym razie przesłanych zostanie tylko X% transakcji, a części będzie brakować. Bardzo trudno będzie dowiedzieć się, co to za brakujące dane.

Ustaw uczciwe czasy przetwarzania
Ile czasu zajmuje zadanie przetworzenia X wierszy danych? Zapewnia to ważne informacje na temat procesu. Jak często i jak długo musi trwać proces? O jaką aktualność danych mogę zapewnić mój dział? Co się dzieje, gdy dane muszą zostać ponownie załadowane?

Użyj zadań pomiaru jakości danych
Czy moje systemy źródłowe i docelowe są zgodne? Jak mogę się upewnić, że wszystkie dane zostały przeniesione? Tutaj polecam zbudowanie strategii monitorowania. Zawsze dobrze jest mierzyć jakość danych i szybko wykrywać błędy; w przeciwnym razie może dojść do braku zaufania ze strony konsumenta.

Zapewnij bezpieczeństwo transakcji
Używając w procesie oprogramowania do replikacji baz danych (na przykład usługi migracji danych AWS lub DMS) zamiast bezpośredniego połączenia między systemem A i systemem B, możesz napotkać problemy. Miałem kiedyś zadanie replikacji, które ładowało dane z tabeli A i tabeli B w tym samym czasie. Oba były dalej przetwarzane przez zadanie ETL, ale jeśli zestaw danych z tabeli B nie był dostępny z powodu dużego opóźnienia, a zestaw danych z tabeli A został przetworzony, informacje z tabeli B byłyby niedostępne. Tutaj również polecam dodanie monitoringu lub dozowanie zbyt wielu dodatkowych składników w procesie.

Rozważ zależność od innych systemów

W przypadku systemów źródłowych należy wziąć pod uwagę różne okoliczności:

Dostępność - kiedy dostępny jest system źródłowy? Weź pod uwagę cykle konserwacji i przestoje.
Duże obciążenie danymi - systemy docelowe nie mogą otrzymywać żadnych zbędnych zmian (CDC) z systemu źródłowego; na przykład w godzinach szczytu. Zamiast tego przesyłanie danych może odbywać się w trybie wsadowym w nocy.
Niepożądane zachowanie innych systemów - jak opisano wcześniej, usługi replikacji bazy danych mogą zrujnować procesy ETL, ale mogą również wystąpić inne problemy; na przykład zduplikowane i niespójne dane. Tutaj ważne jest poznanie systemów źródłowych i ich pułapek.
Wniosek

Dla mnie jest to pięć najważniejszych elementów budujących stabilny i bezpieczny proces przetwarzania danych. Należy zawsze pamiętać, że jakość danych jest ważna. W przeciwnym razie możesz doświadczyć braku zaufania ze strony użytkowników i działów biznesowych.

Każdy potok danych wymaga pulpitu danych biznesowych w czasie rzeczywisty

Pokaż im dane; powiedzą ci, kiedy jest źle. Jak często nie masz pewności, czy prawidłowo przetwarzasz dane podczas tworzenia potoków danych w celu pozyskiwania danych? Czy wartości odstające, które przycinasz, naprawdę są wynikiem nieprawidłowego działania sprzętu? Czy sygnatura czasowa jest rzeczywiście w uniwersalnym czasie koordynowanym (UTC)? Czy dane pole jest wypełniane tylko wtedy, gdy klient zaakceptuje zamówienie? Jeśli będziesz pilny, zadasz te pytania interesariuszowi w momencie budowania rurociągu. Ale co z pytaniami, o których nie wiedziałeś, że musisz je zadać? Co się stanie, jeśli odpowiedź zmieni się w przyszłym miesiącu? Jednym z najlepszych sposobów na ciągłe obserwowanie potoku danych, zwłaszcza oczu należących do ekspertów domenowych, jest zbudowanie wizualnej reprezentacji przepływających przez niego danych. Nie mam tu na myśli bitów inżynieryjnych - nie ilości przepływających danych, liczby błędów czy liczby połączeń. Należy stworzyć wizualną reprezentację przepływających danych biznesowych. Korzystanie z pulpitów nawigacyjnych w czasie rzeczywistym, aby lepiej przyjrzeć się potoku danych Zbuduj pulpit nawigacyjny przedstawiający aspekty danych, które interesariusze uznają za istotne. Na przykład pokaż, ile razy dany element sprzętu działał nieprawidłowo w przeszłości i czy działa teraz. Aby to ustalić, użyjesz liczby wartości odstających, które wycinałeś z potoku danych. Zbuduj pulpit nawigacyjny, udostępnij go szeroko i czekaj. Ludzie są przyciągani do pulpitów nawigacyjnych w czasie rzeczywistym, tak jak koty mają kocimiętkę. W dniu, w którym te wartości odstające zostaną wygenerowane z innego powodu niż wadliwy sprzęt, ktoś zadzwoni do Ciebie i poinformuje Cię o tym. Działa to tylko wtedy, gdy dany pulpit nawigacyjny jest oparty na sieci WWW lub zintegrowany z codziennymi systemami używanymi przez decydentów. Możesz korzystać z bezpłatnych narzędzi pulpitu nawigacyjnego, takich jak Studio danych, lub narzędzi, takich jak Tableau i Looker, które mają bezpłatne warstwy. Dowiedz się, jak z nich korzystać, aby rozłożyć swój semantyczny ciężar.

Inżynieria powtarzalnych projektów nauki o danych

Jak każda dziedzina nauki, nauka o danych opiera się na odtwarzalności. W odtwarzalnym projekcie ktoś inny (w tym w przyszłości Ty) może odtworzyć Twoje wyniki, uruchamiając proste polecenie. Z jednej strony oznacza to, że powinieneś sprawdzić swój kod analityczny w narzędziu kontroli źródła, takim jak Git. Z drugiej strony oznacza to również przestrzeganie najlepszych praktyk DevOps, takich jak uwzględnianie list zależności w formularzach do odczytu maszynowego (takich jak wymagania.txt dla pip lub environment.yml dla Condy). Możesz pójść o krok dalej i użyć pliku Dockerfile. Należy również uwzględnić polecenia potrzebne do zainstalowania i uruchomienia analizy. Na koniec upewnij się, że jasno udokumentowałeś, co należy uruchomić w pliku README.md lub najlepiej w programie do uruchamiania zadań, takim jak Make. Innym ważnym elementem odtwarzalności jest wyeliminowanie z potoku czegoś, co nazwiemy algorytmiczną losowością, aby zachować spójność. Jeśli twoje dane są podzbiorem z większego zbioru danych lub twoja analiza zależy od początkowego losowego warunku (wielu z twoich ulubionych tak robi), jesteś zależny od generatora liczb losowych. Może to spowodować, że ta sama analiza da różne wyniki. Upewnij się więc, że twój generator jest powiązany z losowym ziarnem, które jest sprawdzane w kontroli wersji. Gwarantuje to, że twoja praca może zostać odtworzona, a wszelkie zmiany w twoich wynikach można przypisać kodowi lub danym, a nie przypadkowi. Jeśli pracujesz w Pythonie, notatniki Jupyter mogą łączyć kod, wizualizacje i wyjaśnienia w jednym dokumencie. W świecie akademickim laureaci Nagrody Nobla wykorzystywali notatniki, aby zademonstrować istnienie fal grawitacyjnych. W branży firmy takie jak Netflix używają szablonów notatników do dostarczania wizualizacji zainteresowanym stronom. Nie bój się sprawdzać notatników w Git (Netflix to robi i my też!). Ponownie uruchamiamy jądro i ponownie przeprowadzamy całą analizę od zera przed zapisaniem danych wyjściowych, co pozwala uniknąć błędów wykonania poza kolejnością i pomaga zagwarantować, że uzyskamy te same wyniki przy następnym uruchomieniu. Wreszcie, zawsze mądrze jest rozpocząć projekt data science z pewnym pomysłem na jego wdrożenie. Na przykład zaprojektowanie potoku, który używa tego samego formatu danych w fazie badań i produkcji, zapobiegnie późniejszym błędom i problemom z uszkodzeniem danych. Z tego samego powodu dobrym pomysłem jest ustalenie, w jaki sposób Twój kod badawczy może zostać wprowadzony do produkcji przed rozpoczęciem, zamiast tworzyć oddzielny kod dla tego drugiego. Zaczynając jako inżynier danych, kuszące jest zagłębienie się w to, co uważasz za "nowatorską przewagę" w tej dziedzinie. Jednak w oparciu o nasze doświadczenie znacznie lepszą inwestycją jest skupienie się na fundamentach i upewnienie się, że można tworzyć powtarzalne, spójne i gotowe do produkcji potoki, które są łatwo dostępne dla różnych interesariuszy. Choć na pierwszy rzut oka może nie wydawać się tak efektowne, przyniesie korzyści przez cały okres realizacji projektu i kariery.

Obejmowanie silosów danych: podróż przez rozdrobniony świat danych

Pracując w przestrzeni big data i machine learning, często słyszymy od inżynierów danych, że największą przeszkodą w wydobywaniu wartości z danych jest możliwość efektywnego dostępu do danych. Silosy danych, odizolowane wyspy danych, są często postrzegane przez inżynierów danych jako główny winowajca. Przez lata podejmowano wiele prób rozwiązania problemów związanych z silosami danych, ale próby te zaowocowały jeszcze większą liczbą silosów danych. Zamiast próbować eliminować silosy danych, uważamy, że właściwym podejściem jest ich uwzględnienie.

Dlaczego istnieją silosy danych

Silosy danych istnieją z trzech głównych powodów. Po pierwsze, w każdej organizacji istnieją dane o różnej charakterystyce (dane z Internetu rzeczy, dane behawioralne, dane transakcyjne itp.), które są przeznaczone do różnych zastosowań, a niektóre z tych danych będą miały większe znaczenie biznesowe niż inne. To napędza potrzebę różnych systemów pamięci masowej. Po drugie, historia pokazała, że co pięć do dziesięciu lat nowa fala technologii pamięci masowych tworzy systemy pamięci masowej, które są szybsze, tańsze lub lepiej zaprojektowane dla określonych typów danych. Organizacje chcą również uniknąć uzależnienia od dostawców, a w rezultacie zdywersyfikować sposób przechowywania danych. Po trzecie, przepisy nakazują segregowanie danych.

Obejmowanie silosów danych

Uważamy, że silosy danych same w sobie nie stanowią wyzwania. Podstawowym wyzwaniem jest udostępnienie danych inżynierom danych bez tworzenia większej złożoności lub duplikacji. Zamiast eliminować silosy, proponujemy wykorzystanie systemu orkiestracji danych, który znajduje się pomiędzy strukturami obliczeniowymi a systemami pamięci masowej, aby rozwiązać problemy związane z dostępem do danych. Definiujemy system orkiestracji danych jako warstwę, która oddziela dostęp do danych w różnych systemach pamięci masowej, wirtualizuje wszystkie dane i prezentuje dane za pośrednictwem ustandaryzowanych interfejsów API z globalną przestrzenią nazw dla aplikacji opartych na danych. Dzięki systemowi orkiestracji danych inżynierowie danych mogą łatwo uzyskać dostęp do danych przechowywanych w różnych systemach pamięci masowej. Na przykład inżynier danych może potrzebować połączyć dwie tabele pierwotnie przechowywane w dwóch różnych regionach - lokalny klaster Hadoop i zdalny klaster Hadoop. Wdrażając system orkiestracji danych, mogą adresować obie lokalizacje z jednego logicznego punktu końcowego, upraszczając pracę w różnych systemach. Wiele systemów orkiestracji danych (np. Alluxio) zapewnia zaawansowane możliwości buforowania, zmniejszając wpływ na wydajność powtarzanych zapytań dotyczących lokalizacji źródłowych. Ponadto zespoły zajmujące się pamięcią masową mogą podejmować najlepsze decyzje dotyczące zakupu pamięci masowej bez krępowania się wpływem ich decyzji na zespoły zajmujące się aplikacjami.

Poznaj architekturę Data Lake

Często inżynierowie danych budują potoki danych, aby wyodrębniać dane ze źródeł zewnętrznych, przekształcać je i umożliwiać innym częściom organizacji wysyłanie zapytań do wynikowych zestawów danych. Chociaż na krótką metę łatwiej jest zbudować to wszystko jako jednoetapowy potok, potrzebna jest bardziej przemyślana architektura danych, aby skalować ten model do tysięcy zestawów danych obejmujących wiele tera/petabajtów.

Typowe pułapki

Rozumiemy kilka typowych pułapek związanych z podejściem jednoetapowym. Przede wszystkim ogranicza to skalowalność, ponieważ dane wejściowe do takiego potoku są uzyskiwane przez skanowanie baz danych, systemów zarządzania relacyjnymi bazami danych (RDBMS) lub magazynów NoSQL - co ostatecznie obciąża te systemy, a nawet powoduje przestoje. Co więcej, bezpośredni dostęp do takich danych pozwala na niewielką standaryzację w potokach (np. standardowa sygnatura czasowa, pola kluczowe) i zwiększa ryzyko awarii danych z powodu braku schematów/kontraktów danych. Wreszcie, nie wszystkie dane lub kolumny są dostępne w jednym miejscu, aby swobodnie je skorelować w celu uzyskania szczegółowych informacji lub projektowania modeli uczenia maszynowego.

Jeziora danych

W ostatnich latach popularność zyskała architektura jezior danych. W tym modelu dane źródłowe są najpierw wyodrębniane z niewielką lub żadną transformacją w pierwszy zestaw nieprzetworzonych zestawów danych. Celem tych nieprzetworzonych zestawów danych jest efektywne modelowanie nadrzędnego systemu źródłowego i jego danych, ale w sposób, który można skalować pod kątem obciążeń przetwarzania analitycznego online (OLAP) (np. przy użyciu kolumnowych formatów plików). Wszystkie potoki danych, które wyrażają przekształcenia specyficzne dla firmy, są następnie wykonywane na tych nieprzetworzonych zestawach danych.

Zalety

To podejście ma kilka zalet w porównaniu z podejściem jednoetapowym, pozwalając uniknąć wszystkich wymienionych wcześniej pułapek:

Skalowalna konstrukcja : ponieważ dane są wyodrębniane raz z każdego systemu źródłowego, dodatkowe obciążenie systemu źródłowego jest drastycznie zmniejszone. Ponadto wyodrębnione dane są przechowywane w zoptymalizowanych formatach plików w systemach pamięci masowej o skali petabajtów (np. HDFS, magazyny w chmurze), które są specjalnie zoptymalizowane pod kątem obciążeń OLAP.
Standaryzacja i schematyzacja : podczas przetwarzania nieprzetworzonych zestawów danych można wykonać etapy standaryzacji i nałożyć na dane schemat, który weryfikuje zarówno integralność strukturalną, jak i semantykę. Zapobiega to przedostawaniu się złych danych do jeziora danych.
Zwinny: inżynierowie danych mogą samodzielnie opracowywać, testować i wdrażać zmiany w logice biznesowej transformacji, mając dostęp do przetwarzania równoległego na dużą skalę przy użyciu tysięcy rdzeni obliczeniowych.
Odblokuj dane : w takim jeziorze danych znajdują się wszystkie dane źródłowe obok siebie, z bogatym dostępem do SQL i innych narzędzi do eksploracji i uzyskiwania informacji biznesowych poprzez łączenie ich i tworzenie nawet pochodnych zestawów danych. Modele uczenia maszynowego mają nieograniczony dostęp do wszystkich danych.
Implementacja : Oto kilka wskazówek dotyczących wdrażania architektury jeziora danych, opartych na wnioskach wyciągniętych z rzeczywistego budowania dużych jezior danych:

•  Rozważ pozyskiwanie baz danych w sposób przyrostowy, używając systemów przechwytywania zmian, a nawet podejść opartych na Java Database Connectivity lub JDBC (np. Apache Sqoop), aby poprawić aktualność danych, a także jeszcze bardziej zmniejszyć obciążenie baz danych.
•  Standaryzuj oba strumienie zdarzeń z aplikacji i takie strumienie zmian bazy danych w jedną magistralę zdarzeń (np. Apache Kafki, Apache Pulsar).
•  Pozyskiwanie nieprzetworzonych zestawów danych z magistrali zdarzeń przy użyciu technologii obsługujących upserts w celu kompaktowania zmian bazy danych w migawkę (np. Apache Kudu, Apache Hudi, Apache Hive ACID).
•  Zaprojektuj nieprzetworzone zestawy danych, aby obsługiwać wydajne pobieranie nowych rekordów (podobnie jak w przypadku przechwytywania zmian) poprzez partycjonowanie danych (np. przy użyciu metastore Apache Hive) lub przy użyciu systemu obsługującego strumienie zmian (np. Apache Hudi).

Efektywna inżynieria danych w świecie chmury

Chmura zmieniła dynamikę inżynierii danych, a także zachowania inżynierów danych na wiele sposobów. Dzieje się tak przede wszystkim dlatego, że lokalny inżynier danych zajmował się tylko bazami danych i niektórymi częściami stosu Hadoop. W chmurze sprawy mają się nieco inaczej. Inżynierowie danych nagle muszą myśleć inaczej i szerzej. Zamiast skupiać się wyłącznie na infrastrukturze danych, jesteś teraz prawie pełnoprawnym inżynierem (być może pomijając ostateczną aplikację końcową). Obliczenia, kontenery, pamięć masowa, przenoszenie danych, wydajność i umiejętności sieciowe są coraz bardziej potrzebne w szerszym stosie. Oto kilka koncepcji projektowych i elementów stosu danych, o których należy pamiętać.

Stos zdezagregowanych danych
Historycznie bazy danych były ściśle zintegrowane, a wszystkie podstawowe komponenty były budowane razem. Hadoop zmienił to dzięki kolokacji przetwarzania i przechowywania w systemie rozproszonym, zamiast przebywania w jednym lub kilku pudełkach. Potem chmura to zmieniła. Dziś jest to w pełni zdezagregowany stos, w którym każdy podstawowy element systemu zarządzania bazą danych stanowi jego własną warstwę. Wybierz każdy składnik mądrze.

Orkiestrować, Orkiestrować, Orkiestrować

Chmura stworzyła potrzebę i umożliwiła masową orkiestrację - czy to Kubernetes w przypadku kontenerów, Alluxio w przypadku danych, Istio w przypadku interfejsów API, Kafka w przypadku zdarzeń czy Terraform w przypadku skryptów. Wydajność dramatycznie wzrasta dzięki abstrakcji i orkiestracji. Ponieważ inżynier danych w chmurze ma teraz pełne obawy, orkiestracja może być najpilniej strzeżoną tajemnicą inżyniera danych.

Kopiowanie danych stwarza problemy

Zasadniczo po tym, jak dane trafią do przedsiębiorstwa, nie należy ich kopiować, z wyjątkiem, oczywiście, scenariuszy tworzenia kopii zapasowych, odzyskiwania i odzyskiwania po awarii. Udostępnienie tych danych jak największej liczbie jednostek biznesowych, analityków danych i analityków przy jak najmniejszej liczbie utworzonych nowych kopii to zagadka do rozwiązania z zakresu inżynierii danych. W tym miejscu w starszym świecie DBMS pomogła pula buforów, zapewniająca, że obliczenia (silnik zapytań) zawsze miały dostęp do danych przechowywanych w spójny, zoptymalizowany sposób w formacie, który był odpowiedni do przetwarzania przez silnik zapytań w porównaniu z formatem zoptymalizowanym do przechowywania. Technologie takie jak Alluxio mogą radykalnie uprościć życie, przybliżając dane do mocy obliczeniowej oraz zwiększając ich wydajność i dostępność.

Kompatybilność S3

Ze względu na popularność Amazon S3 kolejnym dominującym systemem pamięci masowej będą magazyny obiektowe - przynajmniej przez kilka lat (zazwyczaj w cyklu od pięciu do ośmiu lat). Pomyśl o przyszłości, wybierz warstwę pamięci masowej, która będzie działać przez jakiś czas, a magazyny obiektów zgodne z S3 powinny być Twoim głównym wyborem. Chociaż nie są one świetne we wszystkich obciążeniach opartych na danych, wiele technologii pomaga usunąć ich braki. SQL i dane strukturalne wciąż są dostępne

Chociaż SQL istnieje od lat 70., nadal jest to najłatwiejszy sposób, w jaki analitycy mogą zrozumieć i zrobić coś z danymi. Modele AI będą nadal ewoluować, ale SQL przetrwał blisko 50 lat. Wybierz dwa lub co najwyżej trzy platformy, na które możesz postawić i zainwestować. Ale zbuduj platformę, która z czasem będzie obsługiwać tyle, ile potrzeba. Obecnie Presto staje się popularnym silnikiem zapytań SQL dla zdezagregowanego stosu

Rozwijaj społeczności, a nie tylko kod

Jako inżynier danych możesz myśleć o swoich podstawowych obowiązkach zawodowych jako o budowaniu potoku danych. W rzeczywistości prawdopodobnie to zostało określone w twoim opisie stanowiska i jak twoja wartość jest mierzona przez twojego menedżera. Masz jednak wyjątkową możliwość wywierania znacznie większego wpływu na organizację, jeśli myślisz o rozwijaniu kultury danych wraz z produktami danych. Tworzone przez Ciebie dane są prawdopodobnie wykorzystywane przez niezliczonych naukowców zajmujących się danymi, analityków danych i użytkowników rozproszonych w różnych branżach. W dużych organizacjach osoby te mogą być rozdrobnione i nieświadome podobnych pytań, które zadają i na które odpowiadają, korzystając z tych samych podstawowych zasobów danych. W tym sensie Twoje dane mają być wspólną platformą, która może łączyć sieć użytkowników o wspólnych celach. Uprawnieni użytkownicy nie tylko będą czerpać większą wartość z Twoich danych, ale także mogą być w stanie samodzielnie obsłużyć lub pozyskać więcej swoich potrzeb w zakresie danych, zamiast nadal polegać na zespole ds. inżynierii danych w przypadku żądań ad hoc. Takie sieci i społeczności nie powstaną bez wspólnego wysiłku. Dalsi użytkownicy są zazwyczaj skoncentrowani na uzyskiwaniu odpowiedzi na konkretne pytania biznesowe i strategiczne i postrzegają dane jako środek do celu, a nie centralną, wiążącą siłę w ekosystemie analitycznym. Ponadto umiejętność posługiwania się danymi i biegłość konsumentów danych w różnych narzędziach może powodować dodatkową fragmentację. . Analitycy danych mogą być ekspertami w Spark lub mieć cały swój kod w Notatniku Jupyter w serwisie GitHub, podczas gdy użytkownicy biznesowi mogą zmagać się z SQL i korzystać z pulpitów nawigacyjnych, arkuszy kalkulacyjnych lub raportów w formie puszek w celu zaspokojenia swoich potrzeb w zakresie danych. Połączenie napiętych ram czasowych, organizacji matrycowych i odmiennych narzędzi sprawia, że Twoi użytkownicy nie mają wspólnego języka ani forum do znajdowania wspólnych elementów. W jaki sposób możesz pomóc rozwijać społeczność danych lub praktykę? Przeszukuj dzienniki użytkowania i, jeśli pozwala na to prywatność, publikuj je, aby ułatwić użytkownikom nawiązywanie połączeń. Kontaktuj się z użytkownikami, aby zrozumieć, jakie pytania biznesowe wnoszą ich do Twoich danych i w jaki sposób wchodzą z nimi w interakcję. . Można to zrobić podczas indywidualnych rozmów z użytkownikami lub podczas większych sesji projektowych. Zwiększ możliwości użytkowników, zapewniając im szkolenia i zasoby, aby mogli korzystać z danych w bardziej zaawansowany sposób. Nie lekceważ tego, że to, co postrzegasz jako podstawowe umiejętności, może być transformujące. Na przykład nauczenie zespołu marketingowego podstawowego języka SQL lub szkolenie analityków danych w Airflow może pomóc tym zespołom w zautomatyzowaniu części ich przepływów pracy. Udostępnij jak najwięcej swojej pracy (np. skrypty, które są częścią potoku ETL), aby pomóc bardziej zaawansowanym użytkownikom w nauce i ponownym ich wykorzystaniu. Twórz scentralizowane narzędzia, które pomagają użytkownikom wykorzystywać dane i otwieraj je na wkład społeczności.

Zdemistyfikuj źródło i rozjaśnij potok danych

Zostałeś przydzielony do nowego projektu, nowego zespołu lub nowej firmy. Chcesz się zagłębić i wywrzeć wpływ, aby dodać wartość biznesową. Może być kuszące, aby zacząć pisać kod od razu, ale jeśli oprzesz się skłonności do wstępnych założeń i zamiast tego skupisz się na stworzeniu solidnych podstaw, przyniesie to korzyści w przyszłości. Najpierw dowiedz się, skąd i jak pochodzą dane. Gdy Twoje dane są inicjowane przez użytkowników, przydatne jest poznanie ich perspektywy na temat ich wejścia. Za każdym razem, gdy przechodzę po hali produkcyjnej lub rozmawiam z operatorem maszyny o tym, jak korzysta z systemu, zdobywam cenną wiedzę. Często odkrywam, w jaki sposób użytkownicy wprowadzają dane, które są niezgodne z pierwotnym projektem systemu lub uzasadniony powód, dla którego pomijają dane. Jeśli nie masz dostępu do osób wprowadzających dane, zapoznaj się z ich dokumentacją szkoleniową i porozmawiaj z analitykami biznesowymi związanymi z tą funkcją. Poznaj specyfikacje, gdy Twoje dane pochodzą z czujników, sprzętu lub sprzętu. Zapoznaj się z podręcznikami i dokumentacją, aby wyjaśnić, w jaki sposób generowane są dane. Będziesz mieć jasne zrozumienie, gdy napotkasz te dane w dalszej części analizy. Znajomość oczekiwanych wartości pomaga również zidentyfikować możliwe usterki w sprzęcie źródłowym. Teraz sprawdź metadane. Odkryłeś źródłowe zdarzenia biznesowe dla danych niejawnych, jawnych, wprowadzanych ręcznie lub generowanych automatycznie. Każdemu z tych źródeł towarzyszą metadane opisowe. Na przykład metadane obejmują znaczniki czasu zdarzeń sprzętu, typy urządzeń lub opisowe dane użytkownika. Sprawdź, czy te metadane z wielu źródeł są spójne i czy można je ujednolicić. Na przykład formatowanie sygnatury czasowej może się różnić w zależności od strefy czasowej. Teraz nadszedł czas na śledzenie. Niezależnie od tego, czy zidentyfikowałeś jedno, czy sto źródeł danych, w jaki sposób przemieszczają się one w potoku i docierają do miejsca, w którym uzyskasz do nich dostęp? Inną kwestią jest to, że typy danych mogą być konwertowane i może być wymagane tłumaczenie biznesowe, gdy dane przemieszczają się przez systemy. Jeśli masz szczęście otrzymać tego typu informacje podczas wdrażania, bądź niezwykle wdzięczny i uznaj, że ta dokumentacja jest prezentem. Przygotuje cię na sukces. Następnie odwołaj się do niego. Czasami podejmuje się wysiłek, aby opracować wartościową dokumentację, ale częściej nie jest ona wykorzystywana w pełni. Podczas dochodzenia utwórz dokumentację, jeśli nie istnieje. To nie musi być zbyt skomplikowane. Może być prosty, a jednocześnie wywierać silny wpływ. Przekaż ją dalej i pomóż kolejnej osobie, której zadaniem będzie wykorzystanie danych z korzyścią dla firmy.

Definiowanie i zarządzanie wiadomościami w architekturach log-centrycznych.

Systemy przesyłania wiadomości zmieniają sposób, w jaki udostępniamy dane. Zamiast skupiać się na API pomiędzy producentem a konsumentem, musimy skupić się na definicjach komunikatów. Ponieważ logi stają się centralnym elementem architektury, zaczynają pełnić rolę szkieletu danych przedsiębiorstwa, nieco podobnego do rozproszonego systemu plików Hadoop (HDFS) dla systemów przesyłania strumieniowego. Ta architektura zachęca do tworzenia kanonicznych modeli danych, ponieważ wymuszanie schematu pozwala uniknąć wielu problemów (np. błędów pisania). Nie jest to nowy pomysł - porównajmy go z kanonicznym modelem danych stosowanym w integracji aplikacji korporacyjnych (EAI) i architekturze zorientowanej na usługi (SOA) oraz koncepcją standaryzowanych kontraktów serwisowych. Uzasadnienie jest takie samo w obu przypadkach, a podejście to jest identyczne ze wzorcem komunikatów kanonicznych EAI, zapewniając, że zawartość dziennika będzie zrozumiała dla wszystkich uczestników. Kanoniczny model danych zapewnia dodatkowy poziom oddzielenia między indywidualnym formatem danych każdej usługi i upraszcza mapowanie danych między wewnętrznymi modelami różnych usług. Jeśli do implementacji zostanie dodana nowa usługa, wymagana jest tylko transformacja między kanonicznym modelem danych a modelem wewnętrznym, niezależnie od tego, jak te dane są reprezentowane przez inne korzystające z nich usługi. Idealnie, ten kanoniczny model danych nigdy nie powinien się zmieniać, ale w rzeczywistości tak się dzieje. W takich przypadkach należy dążyć do zgodności z poprzednimi wersjami podczas wprowadzania zmian w schematach komunikatów dla usług generujących komunikaty. Czasami przełomowe zmiany są nieuniknione. W takim przypadku istnieje ryzyko złamania istniejących konsumentów danego schematu komunikatów. Rozwiązaniem tego problemu, podobnie jak w przypadku najlepszych praktyk wersjonowania API, jest utworzenie nowego wdrożenia usługi z nowym tematem. Konsumenci obsługujący nowy schemat mogą korzystać z komunikatów z tego tematu, podczas gdy ci, którzy zakładają stary schemat, będą nadal korzystać z istniejących. Takie podejście do wersjonowania pozwala na niezależną ewolucję funkcjonalności bez uszkadzania reszty systemu. Minusem tego podejścia jest zwiększony rozmiar i złożoność całego systemu, spowodowany wielokrotnym wdrożeniem tej samej usługi w różnych wersjach. Aby temu zapobiec, ważne jest wprowadzenie zasad wycofywania wersji; stare wersje należy usunąć po określonym czasie. Projektowanie i zarządzanie wiadomościami to ważne elementy architektury zorientowanej na dzienniki. Aby poprawnie zbudować system, upewnij się, że wykorzystujesz następujące:

•  Dobrze zdefiniowany semantyczny model danych, który jest podstawą Twojej definicji wiadomości.

•  Dobrze zdefiniowana strategia umożliwiająca łatwe tworzenie i usuwanie tematów w celu obsługi wersji. Zaleca się również bezpośrednie zakodowanie identyfikatora wersji w nazwie tematu.

Hurtownie danych to przeszłość, teraźniejszość i przyszłość

Śmierć hurtowni danych, przepowiadana od dawna, wydaje się zawsze na horyzoncie, ale nigdy nie została uświadomiona. Najpierw NoSQL, potem Hadoop, a potem jeziora danych, które zabiją hurtownię danych. A jednak jesteśmy tutaj. Snowflake był najgorętszą początkową ofertą publiczną (IPO) w 2020 r., a zapotrzebowanie na inżynierów danych i analityków, którzy mogą wydobyć wartość z hurtowni danych, jest tak wysokie, jak nigdy dotąd. W 2010 r. przyszłość hurtowni danych wydawała się dość ponura. Większość zespołów analitycznych w swoich hurtowniach danych opierała się na tradycyjnych bazach danych opartych na wierszach przetwarzania transakcyjnego online (OLTP). Ilość danych eksplodowała. Gdy przyszło do przetwarzania i przeszukiwania wszystkich tych danych do analizy, na ratunek przyszły bazy danych kolumnowych, ale wymagały one rozbudowy sprzętu. Chociaż urządzenia typu bare metal hurtowni danych zapewniły ogromny skok mocy obliczeniowej, były one sporą inwestycją w dodanie sprzętu do serwerowni. To niewyobrażalne 10 lat później. Sytuacja zmieniła się na lepsze w 2012 roku, kiedy Amazon uruchomił Redshift, kolumnową hurtownię danych, którą można było uruchomić w kilka minut i płacić małymi krokami bez ogromnych kosztów początkowych, zbudowaną na bazie PostgreSQL. Ogromnie wzrosła liczba migracji z przeciążonych, opartych na wierszach hurtowni danych SQL do Redshift. Bariera wejścia dla wysokowydajnej hurtowni danych została znacznie obniżona i nagle coś, co wyglądało na zbliżającą się śmierć hurtowni, stało się odrodzeniem. Następnie wyodrębnij, załaduj, przekształć (ELT) wymazane wyodrębnij, przekształć, załaduj (ETL). Różnica między tymi dwoma wzorcami polega na tym, że odbywa się krok T (transformacja), a rozproszone bazy danych kolumnowych umożliwiają to wszystko. Teraz lepiej skupić się na wyodrębnieniu danych i załadowaniu ich do hurtowni danych, a następnie wykonaniu niezbędnych przekształceń. Dzięki ELT inżynierowie danych mogą skoncentrować się na krokach wyodrębniania i ładowania, podczas gdy analitycy mogą wykorzystywać SQL do przekształcania danych, które zostały pozyskane do raportowania i analizy. Innymi słowy, ten nowy rodzaj hurtowni danych umożliwił (i ekonomiczny) przechowywanie i wyszukiwanie znacznie większych ilości danych niż kiedykolwiek wcześniej. ELT uratował hurtownię danych. Koncepcja jeziora danych została po raz pierwszy wprowadzona w 2011 roku. Zaleta przechowywania ogromnych ilości danych bez konieczności definiowania struktury, kiedy są one przechowywane (schemat przy zapisie), ale raczej gdy są odpytywane (schemat przy odczycie) jest realna . Jednak takie podejście wiąże się z kosztami, jeśli chodzi o odkrywanie danych i zarządzanie nimi, a także złożoność dla analityka danych lub inżyniera analityki, który pracuje z danymi. Wraz ze spadkiem kosztów przechowywania i wysyłania zapytań do dużych ustrukturyzowanych zestawów danych oraz wzrostem wydajności, niektóre wady jezior danych do analizy stały się bardziej zauważalne. Mimo to jeziora danych mają swoje miejsce w infrastrukturze analitycznej. Nadal istnieje potrzeba przechowywania danych, które nie mają spójnej struktury lub w wolumenie, który sprawia, że nawet najsolidniejsze hurtownie danych trzeszczą. Jednak dla większości zespołów danych jeziora danych stanowią raczej uzupełnienie ich hurtowni danych, a nie ich zamiennik. Hurtownie danych w najbliższym czasie nigdzie się nie wybierają. Snowflake nadal rozsadza oczekiwania zarówno deweloperów, jak i inwestorów, i spodziewam się fali innowacji w zakresie hurtowni danych w najbliższej przyszłości. Dla tych, którzy wahają się, czy zainwestować w hurtownię danych od podstaw, przenieść starszą wersję na nowoczesną platformę lub zatrudnić inżynierów danych z know-how w zakresie hurtowni danych, nie obawiaj się! Na razie budujesz i inwestujesz inteligentnie na przyszłość.

Walidacja danych to coś więcej niż statystyki podsumowujące

Która z tych liczb nie należy? -1, 0, 1, nie dotyczy. Trudno powiedzieć. Jeśli dane nie powinny być ujemne, -1 jest wyraźnie błędne; jeśli powinna być kompletna, NA jest problematyczna; jeśli reprezentuje znaki, które mają być użyte w podsumowaniu, 0 jest wątpliwe. Krótko mówiąc, nie ma jakości danych bez kontekstu danych. Zarządzanie jakością danych jest powszechnie uznawane za kluczowy element inżynierii danych. Jednak chociaż potrzeba ciągłej walidacji nie jest kontrowersyjna, podejścia są bardzo zróżnicowane. Zbyt często te podejścia opierają się wyłącznie na statystykach podsumowujących lub podstawowych, jednowymiarowych metodach wykrywania anomalii, które są łatwo zautomatyzowane i szeroko skalowalne. Jednak na dłuższą metę bezkontekstowe kontrole jakości danych ignorują niuanse i pomagają nam wykrywać bardziej niebezpieczne błędy, które mogą pozostać niewykryte przez dalszych użytkowników. Definiowanie zasad biznesowych wzbogaconych o kontekst jako kontrole jakości danych może uzupełniać statystyczne podejście do walidacji danych poprzez kodowanie wiedzy dziedzinowej. Zamiast definiować wymagania wysokiego poziomu (np. "nonnull"), możemy zdefiniować oczekiwane interakcje między różnymi polami w naszych danych (np. "dożywotnie płatności są krótsze niż dożywotnie zakupy dla każdego klienta e-commerce"). Umożliwia to badanie wewnętrznej spójności między polami w jednym lub większej liczbie zestawów danych - nie tylko racjonalność dowolnego pola w izolacji - i pozwala nam zweryfikować, czy wygenerowane dane są zgodne z prawdziwymi intencjami biznesowymi (np. powyższe sprawdzenie jest zdecydowanie prawdziwe tylko jeśli rozważamy zakupy brutto i odliczamy wszelkie zwroty). Chociaż te sprawdzenia mogą nadal być prostą arytmetyczną, kodują poziom intuicji, którego nie znajdzie żadne autonomiczne podejście (np. potrzeba porównania bieżących sum wybranych metryk po zgrupowaniu danych na poziomie klienta) i zadają pytania, które mogą być bardziej reprezentatywny dla sposobu, w jaki nasz proces ETL może się zepsuć (np. wielokrotne ładowanie płatności). Kontrole danych zgodnie z regułami biznesowymi mogą dodatkowo wykorzystywać unikalną wiedzę człowieka na temat struktur danych, która może nie być w pełni widoczna na podstawie samych danych. Na przykład, jeśli pracujemy z danymi z powtarzanych pomiarów (panelem) dla spójnego zestawu podmiotów, wiele zamierzonych unikalnych kluczy lub oczekiwanych trendów może istnieć w obrębie każdego podmiotu, ale nie w całym zbiorze danych; alternatywnie, jeśli pracujemy z danymi o wysokiej hierarchii, kontrole mogą zbadać odpowiednie "zagnieżdżenie" tych poziomów. Chociaż kontekstowe kontrole jakości danych mogą pomóc w zapewnieniu bardziej niezawodnej i zróżnicowanej walidacji jakości danych, nie ma darmowego lunchu. Główną wadą tego podejścia jest to, że zdefiniowanie i wdrożenie takich warunków może wymagać znacznej ilości pracy ręcznej zarówno ze strony zespołów biznesowych, jak i inżynierskich. W związku z tym deweloperzy muszą starannie określić, gdzie zainwestować ograniczone zasoby. Jednak nawet dodanie tych kontroli do szczególnie krytycznych podzbiorów pól lub szczególnie podatnych na błędy kroków w potoku (duże przekształcenia lub kombinacje różnych źródeł) może znacznie przyczynić się do promowania bardziej holistycznego podejścia do jakości danych.

Bezpieczeństwo danych dla inżynierów danych

Czy Twoje dane są bezpieczne? A co z danymi, które przetwarzasz na co dzień? Skąd wiesz? Czy możesz to zagwarantować? Te pytania nie mają na celu wywołania strachu. Zamiast tego chcę, żebyś podszedł do bezpieczeństwa pragmatycznie. Jako inżynierowie danych często zarządzamy najcenniejszym zasobem firmy. Z tego powodu sensowne jest tylko to, że uczymy się i stosujemy inżynierię bezpieczeństwa w naszej pracy. Jak możemy to zrobić? Oto kilka wskazówek.

Dowiedz się więcej o bezpieczeństwie

Większość inżynierów danych wywodzi się z informatyki lub nauki o danych, więc być może nie miałeś kontaktu z koncepcjami bezpieczeństwa komputerów i sieci. Dowiedz się o nich, uczestnicząc w konferencjach dotyczących bezpieczeństwa, spotkaniach i innych wydarzeniach. Przeczytaj o najlepszych praktykach w zakresie bezpieczeństwa dla konkretnej używanej architektury lub infrastruktury. Porozmawiaj z działem IT/DevOps lub specjalistami ds. bezpieczeństwa w Twojej firmie, aby dowiedzieć się, jakie środki zostały już zastosowane. Nie proszę, abyś został ekspertem, ale chcę, żebyś był poinformowany.

Dostęp do monitorowania, rejestrowania i testowania

Monitoruj, rejestruj i śledź dostęp do maszyn lub kontenerów, z których korzystasz, do baz danych lub innych utrzymywanych przez Ciebie repozytoriów danych, a także do kodu i systemów przetwarzania, w których codziennie uczestniczysz. Upewnij się, że tylko uwierzytelnieni użytkownicy lub komputery mają dostęp do tych systemów. Twórz reguły zapory (tak, nawet w chmurze, a nawet z kontenerami) i testuj je za pomocą skanera portów lub przeszukiwania ping. Monitoruj i ostrzegaj o każdym nietypowym dostępie lub zachowaniu sieci.

Zaszyfruj dane

Zapewnienie ochrony danych wrażliwych powinno być jedną z kluczowych rzeczy, które robimy jako inżynierowie danych. Jeśli to możliwe, szyfruj dane lub wrażliwe pola - zarówno w spoczynku, jak i podczas przesyłania. Według raportu IBM o naruszeniu danych z 2018 r. jest to jeden z najlepszych sposobów zapobiegania kosztownemu naruszeniu danych.

Zautomatyzuj testy bezpieczeństwa

Używasz już CI/CD w ramach inżynierii danych? (Jeśli nie, przestań czytać i zrób to teraz.) Zaimplementuj testy bezpieczeństwa jako część tego wdrożenia. Może to być tak proste, jak testowanie złych poświadczeń, testowanie szyfrowania i testowanie, czy używane są najnowsze aktualizacje zabezpieczeń dla twoich bibliotek. Im bardziej zautomatyzujesz to testowanie i będziesz mógł zatrzymać i ostrzec o potencjalnych zagrożeniach bezpieczeństwa, tym bezpieczniejsze będzie przetwarzanie i potoki.

Zapytaj o pomoc

Jeśli masz szczęście, że masz zespół ds. bezpieczeństwa, poproś go o pomoc w ocenie bezpieczeństwa infrastruktury przetwarzania, sieci i skryptów. Jeśli nie, sprawdź, kiedy zaplanowany jest kolejny zewnętrzny przegląd zabezpieczeń Twojej firmy i poproś o czas na rozmowę z ekspertami na temat środków, które możesz podjąć, aby zapewnić lepsze bezpieczeństwo inżynierii danych. Może to obejmować testowanie penetracyjne punktów końcowych gromadzenia danych lub ujawnionych interfejsów API, których używasz lub konserwujesz, lub po prostu przegląd zabezpieczeń wdrażania, monitorowania i architektury przetwarzania. Tak czy inaczej, zasięgnięcie porady eksperta prawdopodobnie sprawi, że poczujesz się pewniej dzięki środkom, które posiadasz i tym, które chcesz nadać priorytet lub wdrożyć w przyszłości. Dla twojej konkretnej roli lub firmy może być jeszcze więcej nisko wiszących owoców bezpieczeństwa. Zaplanowanie regularnego sprintu bezpieczeństwa w planowaniu to świetny sposób, aby być na bieżąco z tymi problemami i z czasem poprawić bezpieczeństwo. Gdy ponownie napotkasz te pytania, Ty i Twój zespół możecie odpowiedzieć z łatwością, wiedząc, że przepływy pracy związane z inżynierią danych są bezpieczne.

Jakość danych dla inżynierów danych

Jeśli zarządzasz i wdrażasz potoki danych, w jaki sposób upewnisz się, że działają? Czy testujesz, że dane przechodzą? Czy monitorujesz dyspozycyjność? Czy masz w ogóle testy? Jeśli tak, to co dokładnie testujesz? Rurociągi danych nie różnią się zbytnio od innych rurociągów w naszym świecie (gaz, ropa, woda). Muszą być zaprojektowane; mają zdefiniowany punkt początkowy i końcowy. Muszą być testowane pod kątem wycieków i regularnie monitorowane. Ale w przeciwieństwie do większości potoków danych, te "rzeczywiste" potoki również testują jakość tego, co przenoszą. Regularnie. Kiedy ostatnio testowałeś potok danych pod kątem jakości danych? Kiedy ostatni raz zweryfikowałeś schemat przychodzących lub przekształconych danych lub testowałeś pod kątem odpowiednich zakresów wartości (tj. testowanie "zdrowego rozsądku")? W jaki sposób zapewniasz, że dane niskiej jakości są oznaczane lub zarządzane w znaczący sposób? Bardziej niż kiedykolwiek wcześniej, biorąc pod uwagę rozwój i wykorzystanie potoków danych na dużą skalę, walidacja danych, testowanie i kontrola jakości mają kluczowe znaczenie dla potrzeb biznesowych. Nie ma znaczenia, że zbieramy 1 TB danych dziennie, jeśli są one zasadniczo bezużyteczne do zadań takich jak data science, uczenie maszynowe lub inteligencja biznesowa ze względu na słabą kontrolę jakości. Potrzebujemy inżynierów danych, aby działali podobnie jak inni inżynierowie ds. Potoków - aby byli zaniepokojeni i skoncentrowani na jakości danych przepływających przez ich potoki. Inżynierowie danych powinni współpracować z zespołem ds. analizy danych lub wdrożyć standardowe testy. Może to być tak proste, jak walidacja schematu i sprawdzanie wartości NULL. W idealnym przypadku można również przeprowadzić test pod kątem oczekiwanych zakresów wartości, ekspozycji danych prywatnych lub wrażliwych lub danych próbnych w czasie do testów statystycznych (tj. testowania rozkładów lub innych właściwości, które powinny mieć dane w całości). I fajne jest to, że możesz wykorzystać swoją wiedzę o danych i zastosować ją do tych problemów. Czy wiesz, ile ekstremalnych wartości, anomalii lub wartości odstających może się dziś spodziewać w Twoim potoku? Prawdopodobnie nie. Ale czy mógłbyś? Dlaczego tak, mógłbyś. Śledzenie, monitorowanie i wnioskowanie o typach błędów i problemów z jakością, które widzisz w potokach lub przetwarzaniu, jest samo w sobie znaczącym zadaniem analizy danych. Więc proszę, nie tylko patrz na przychodzące i wychodzące dane i nie mów: "Mnie wygląda dobrze". Poświęć trochę czasu, aby określić, jakie pomiary jakości i walidacji mają sens dla źródła i miejsca docelowego danych, i ustal sposoby, aby zapewnić spełnienie tych standardów. Zespoły zajmujące się analizą danych i biznesem nie tylko podziękują Ci za wzrost jakości i użyteczności danych, ale także poczujesz dumę ze swojego tytułu: inżyniera.

Potoki danych - wzorce projektowe do ponownego wykorzystania i rozszerzalności: rozwijaj potoki danych pod kątem jakości, elastyczności, przejrzystości i wzrostu.

Projektowanie rozszerzalnych, modułowych potoków danych wielokrotnego użytku to duży temat, który jest istotny w inżynierii danych, ponieważ wymaga radzenia sobie z ciągłymi zmianami w różnych warstwach, takich jak źródła danych, pozyskiwanie, walidacja, przetwarzanie, bezpieczeństwo, rejestrowanie i monitorowanie. Zmiany te zachodzą z różną szybkością w różnych warstwach i wpływają na potoki danych w różny sposób, w zależności od poziomu abstrakcji i projektu potoku. Aby zapewnić kontekst warstwom potoku danych i rozpocząć mapowanie konfiguracji, potok można zobaczyć w formie destylowanej jako warstwy pozyskiwania, przetwarzania i wyników. Dla każdej warstwy możemy myśleć w kategoriach funkcji, które odwzorowują bloki funkcjonalne. Zawartość bloków zmienia się w zależności od wymagań warstwy. Pomaga nam to myśleć w kategoriach szablonów i konfiguracji, które mogłyby reprezentować skierowany graf acykliczny (DAG) potoku. Warstwy Pozyskiwania, Przetwarzania i Wyniku mogą być mapowane do różnych rejestratorów i monitorów w zależności od wymagań. Na przykład w warstwie Ingestion dziennikiem pliku może być S3, dziennikiem zdarzeń może być niestandardowy, a monitorami mogą być operacje Google Cloud i Redash. Jednak warstwa wyników może być zmapowana do dziennika zdarzeń DataDog i monitora zdarzeń DataDog. Jeśli weźmiemy ogólny potok, konkretnie patrząc na rejestrowanie i monitorowanie, ta reprezentacja zostałaby zaimplementowana jako metody DAG, w których rejestratory i monitory byłyby połączone z kodem DAG. Wiąże się to z większym kodowaniem i jest kruche, trudne do ponownego wykorzystania oraz naruszeniem zasad projektowania, w tym zasady pojedynczej odpowiedzialności (SRP), Nie powtarzaj się (DRY) i otwartej-zamkniętej, co powoduje, że cały rurociąg jest niestabilny i zawodny. Jeśli rozszerzymy to stwierdzenie problemu poza monitorowanie i rejestrowanie, zobaczymy podobne problemy w różnych blokach funkcjonalnych - jakości/walidacji danych, bezpieczeństwie/prywatności itp. Gdy widzimy podobieństwa w problemach, jest to wskaźnik do rozpoznawania wspólnych motywów. Ponadto chcemy usunąć sprzężenie między implementacjami i zwiększyć ich spójność. Daje nam to wystarczająco dużo kontekstu, aby zacząć myśleć w kategoriach wzorców projektowych. Pierwszy zestaw wzorców ma charakter twórczy lub strukturalny. Pozwalają nam oddzielić tworzenie i strukturę przekrojowych zagadnień, takich jak rejestrowanie i monitorowanie, od obszarów specyficznych dla DAG. Wzorce fabryczne i abstrakcyjne pomagają w abstrahowaniu i oddzieleniu różnych rejestratorów i monitorów od kodu DAG, umożliwiając ewolucję bazy kodu DAG bez zależności od bazy kodu rejestrowania i monitorowania. Drugi zestaw wzorców to zachowania. Pozwalają nam określić zachowanie przy zachowaniu zasad DRY i SOLID. Wzorzec dekoratora jest szeroko stosowany do modyfikowania lub dodawania zachowania do istniejących funkcji. Rejestrowanie i monitorowanie mają natychmiastowe zastosowanie. Wzór elewacji jest przydatny, gdy klient lub konsument potrzebuje węższego lub bardziej specyficznego API. Na przykład szeroki zestaw interfejsów API lub metod udostępnianych przez różne rejestratory i monitory nie musi być udostępniany warstwie DAG. Wzór elewacji pomaga zdefiniować dostęp lub interfejs do warstwy rejestrowania i monitorowania. Łącząc te wzorce, zdajemy sobie sprawę z korzyści płynących z zasad projektowania, ponieważ rozdzielenie odpowiedzialności pozwala na modularyzację bazy kodu na wielu poziomach: DAG, zagadnienia przekrojowe (osobne pakiety do monitorowania i logowania), cross-DAG (wspólne szablony można wyabstrahować). Zapewnia to bloki konstrukcyjne do uogólniania potoków danych w celu odejścia od pisania niestandardowego kodu do bardziej ogólnych modułów, szablonów i konfiguracji. Różne elementy podążają za ich cyklami rozwoju i pakietami wdrożeniowymi całkowicie oddzielonymi od bazy kodu DAG. Dodanie tych zasad projektowania zwiększa abstrakcję i poziom złożoności. Jest to jednak niewielka cena, jaką trzeba zapłacić za zwiększenie rozwoju potoku przy jednoczesnym zachowaniu jakości i szybkości.

W potoku danych nie chodzi o szybkość

Kiedyś potoki przetwarzania danych dotyczyły szybkości. Teraz żyjemy w świecie technologii chmury publicznej, w której każda firma może zapewnić dodatkowe zasoby w ciągu kilku sekund. Fakt ten zmienia nasze spojrzenie na sposób, w jaki należy konstruować potoki przetwarzania danych. W praktyce płacimy równo za korzystanie z 10 serwerów za 1 minutę i 1 serwera za 10 minut. Z tego powodu nacisk został przesunięty z optymalizacji czasu wykonywania na optymalizację skalowalności i równoległości. Wyobraźmy sobie idealny potok przetwarzania danych: dostaje się 1000 zadań, które są przetwarzane równolegle na 1000 węzłów, a następnie gromadzone są wyniki. Oznaczałoby to, że w dowolnej skali szybkość przetwarzania nie zależy od liczby zadań i jest zawsze równa jednemu zadaniu. A dziś jest to możliwe dzięki technologiom chmury publicznej, takim jak przetwarzanie bezserwerowe, które stają się coraz bardziej popularne. Umożliwiają równoległe uruchamianie tysięcy węzłów przetwarzania. Implementacje bezserwerowe, takie jak AWS Lambda, Microsoft Azure Functions i Google Cloud Functions, umożliwiają nam budowanie skalowalnych potoków danych przy niewielkim wysiłku. Wystarczy zdefiniować biblioteki i kod i gotowe. Skalowalne koordynatory, takie jak AWS Step Functions i Azure Logic Apps, umożliwiają równoległe wykonywanie setek i tysięcy zadań. Usługi takie jak AWS Batch umożliwiają łatwe uruchamianie dużego klastra instancji z niskimi cenami Spot, używanie go do przetwarzania zadań na dużą skalę i kończenie klastra. Dodatkowo coraz więcej dostawców wprowadza kontenery jako usługę, co oznacza, że po zdefiniowaniu encji (np. Docker) będzie ona wdrażana i wykonywana równolegle, a Ty płacisz tylko za czas przetwarzania. Skalowalność staje się mało znaczącym owocem, co pozwala nam skrócić czas przetwarzania z dni do godzin iz godzin do minut. Ale kiedy już osiągniemy idealną skalowalność poziomą, czy powinniśmy skupić się na czasie realizacji? Tak, ale z innego powodu. W świecie perfekcyjnej skalowalności poziomej czas wykonania nie ma dużego wpływu na szybkość przetwarzania partii, ale znacząco wpływa na koszt. Dwukrotna optymalizacja prędkości oznacza dwukrotną optymalizację kosztów i to jest nowość i motywacja do optymalizacji. W ten sposób decyzja o optymalizacji staje się decyzją kosztową, która ma bardzo wyraźny zwrot z inwestycji (ROI). Co więcej, zaprojektowanie absolutnie skalowalnego potoku danych bez uwzględnienia optymalizacji algorytmów może prowadzić do niezwykle wysokich kosztów potoku. To jedna z wad systemu, który nie ma ekonomii skali. Pojawiająca się możliwość polega na projektowaniu potoków danych w celu optymalizacji kosztów jednostkowych i umożliwienia skalowalności od początkowych faz w celu przejrzystej komunikacji między inżynierami danych a innymi zainteresowanymi stronami, takimi jak kierownicy projektów i naukowcy zajmujący się danymi.

Obserwowalność danych: kolejna granica inżynierii danych

W miarę jak firmy w coraz większym stopniu opierają się na danych, technologie leżące u podstaw tych bogatych spostrzeżeń stają się coraz bardziej zniuansowane i złożone. Chociaż nasza zdolność do gromadzenia, przechowywania, agregowania i wizualizacji tych danych w dużej mierze nadążała za potrzebami nowoczesnych zespołów danych (pomyśl: siatki danych zorientowane na domenę, hurtownie w chmurze i rozwiązania do modelowania danych), mechanika stojąca za jakością danych i integralność opóźniła się.

Jak dobre dane stają się złe?

Po rozmowie z kilkuset zespołami zajmującymi się inżynierią danych zauważyłem trzy główne powody, dla których dobre dane stają się złe:

Coraz więcej źródeł danych

W dzisiejszych czasach firmy używają od kilkudziesięciu do kilkuset wewnętrznych i zewnętrznych źródeł danych do tworzenia analiz i modeli ML. Każde z tych źródeł może zmienić się w nieoczekiwany sposób i bez uprzedzenia, narażając dane wykorzystywane przez firmę do podejmowania decyzji.

Coraz bardziej złożone potoki danych

Potoki danych są coraz bardziej złożone, z wieloma etapami przetwarzania i nietrywialnymi zależnościami między różnymi zasobami danych. Przy niewielkiej widoczności tych zależności każda zmiana wprowadzona w jednym zestawie danych może wpłynąć na poprawność zależnych zasobów danych.

Większe, bardziej wyspecjalizowane zespoły danych

Firmy coraz częściej zatrudniają coraz więcej analityków danych, naukowców i inżynierów do tworzenia i utrzymywania potoków danych, analiz i modeli ML, które napędzają ich usługi i produkty.

Błędy w komunikacji są nieuniknione i spowodują, że te złożone systemy będą załamywać się w miarę wprowadzania zmian.

Przedstawiamy: Obserwowalność danych

Dobre wieści? Inżynieria danych przeżywa swój renesans i jesteśmy winni wielkie podziękowania naszym odpowiednikom w DevOps. Przez ostatnią dekadę inżynierowie oprogramowania wykorzystywali ukierunkowane rozwiązania, aby zapewnić długi czas bezawaryjnej pracy aplikacji przy jednoczesnym ograniczeniu przestojów do minimum. W danych nazywamy to zjawisko przestojem danych. Odnosi się to do okresów, w których dane są częściowe, błędne, brakujące lub w inny sposób niedokładne, i mnożą się tylko w miarę jak systemy danych stają się coraz bardziej złożone. Stosując te same zasady obserwowalności i niezawodności aplikacji oprogramowania do danych, problemy te można identyfikować, rozwiązywać, a nawet im zapobiegać, dając zespołom danych pewność, że ich dane dostarczają cennych informacji. Obserwowalność danych ma pięć filarów. Każdy filar zawiera serię pytań, które łącznie zapewniają całościowy obraz stanu danych:

Świeżość : czy dane są aktualne? Kiedy ostatni raz został wygenerowany? Jakie dane upstream są uwzględnione/pominięte?
Dystrybucja : czy dane mieszczą się w akceptowanych zakresach? Czy jest prawidłowo sformatowany? Czy to kompletne?
Wolumen : Czy dotarły wszystkie dane?
Schemat: Jak zmienił się schemat? Kto dokonał tych zmian i z jakich powodów?
Pochodzenie : na jakie zasoby wyższego i niższego szczebla wpływa dany zasób danych? Kim są ludzie generujący te dane i kto polega na nich przy podejmowaniu decyzji?

Ponieważ liderzy danych coraz częściej inwestują w rozwiązania zapewniające niezawodność danych, które wykorzystują obserwowalność danych, przewiduję, że ta dziedzina będzie nadal przecinać się z innymi głównymi trendami w inżynierii danych, w tym siatką danych, uczeniem maszynowym, architekturą danych w chmurze i dostarczaniem produktów danych jako platform .

Inżynieria danych dla autonomii i szybkich innowacji

W wielu organizacjach inżynieria danych traktowana jest wyłącznie jako specjalność. Potoki danych są postrzegane jako złożona, tajemnicza domena inżynierów danych. Często inżynierowie danych są zorganizowani w dedykowane zespoły lub osadzone w pionowo zorientowanych zespołach produktowych. Chociaż delegowanie pracy specjalistom często ma sens, oznacza to również, że przekazanie jest wymagane w celu osiągnięcia czegoś, co wykracza poza tę specjalizację. Na szczęście, przy odpowiednich strukturach i infrastrukturze, przekazywanie nie jest konieczne do wykonania (i, co być może ważniejsze, iteracji!) wielu przepływów danych i zadań. Potoki danych można ogólnie rozłożyć na logikę biznesową lub algorytmiczną (obliczanie metryk, uczenie modeli , funkcje itp.) oraz logikę przepływu danych (połączenia złożone, konflikty danych, sesje itp.). Inżynierowie danych specjalizują się we wdrażaniu logiki przepływu danych, ale często muszą wdrażać inną logikę zgodnie ze specyfikacją w oparciu o pragnienia lub potrzeby zespołu zlecającego pracę i bez możliwości samodzielnego dostosowania tych wymagań. Dzieje się tak, ponieważ oba typy logiki są zazwyczaj ze sobą powiązane i implementowane ręcznie w potokach. Zamiast tego poszukaj sposobów na oddzielenie logiki przepływu danych od innych form logiki w potoku. Oto kilka strategii.

Implementuj wzorce wielokrotnego użytku w środowisku ETL

Zamiast przekształcać wspólne wzorce w szablony, zaimplementuj je jako funkcje w ramach struktury ETL. Minimalizuje to przekrzywienie kodu i obciążenia związane z konserwacją oraz sprawia, że potoki danych są bardziej dostępne dla wkładu spoza zespołu inżynierii danych.

Wybierz strukturę i zestaw narzędzi dostępnych w organizacji

Jednym z powodów, dla których inżynieria danych jest postrzegana jako specjalność, jest to, że potoki danych są często implementowane w języku lub zestawie narzędzi, które nie są wspólne dla reszty organizacji. Rozważ przyjęcie struktury obsługującej język, który jest powszechnie znany i używany w Twojej organizacji (wskazówka: SQL jest powszechnie znany i rozumiany poza specjalizacją z inżynierii danych).

Przenieś logikę na krawędzie potoków


Staraj się przenieść logikę przepływu danych tak daleko w górę lub w dół, jak to możliwe. Pozwala to na wykonanie pozostałej części pracy jako etapu wstępnego lub końcowego przetwarzania, skutecznie oddzielając inżynierów danych od odbiorców danych i przywracając autonomię w celu iteracji bez dalszego przekazywania.

Twórz i wspieraj tabele inscenizacyjne

Tabele przemieszczania są często wykorzystywane jako pośrednie punkty kontrolne lub dane wyjściowe między zadaniami w potokach danych. Jednak często są one traktowane jako efemeryczne zbiory danych używane tylko przez potok, w którym działają. Jeśli musisz zaimplementować trudny lub kosztowny krok łączenia lub przetwarzania, rozważ umieszczenie wyników i wsparcie ich wykorzystania przez inne, mniej wyspecjalizowane osoby w organizacji .

Wprowadź logikę przepływu danych do narzędzi i infrastruktury

Piecz wspólne wzorce we frameworkach lub narzędziach, które są wywoływane przez konfigurację. Logika inżynierii danych często może być w dużym stopniu wykorzystana przez wprowadzenie jej do kodu pozyskiwania, dostępu lub przechowywania danych. Zamiast wyrażać konfigurację logiki przepływu danych w potokach danych, rozważ osadzenie jej w magazynie metadanych jako metadane w źródłach danych wejściowych lub wyjściowych.

Inżynieria danych z perspektywy analityka danych

Ludzie od dziesięcioleci koncentrują się na przetwarzaniu danych i zarządzaniu nimi, ale dopiero niedawno inżynieria danych stała się powszechną rolą. Dlaczego? Ten post przedstawia nieco przekorny pogląd.

Administracja bazami danych, ETL i takie

Historycznie ludzie skupiali się na trzech głównych obszarach z danymi korporacyjnymi. Pierwszymi byli ci, którzy zarządzają gromadzeniem surowych danych w systemach źródłowych. Drugie to te skupione na operacjach ETL. Do niedawna role ETL były w przeważającej mierze skoncentrowane na relacyjnych bazach danych. Trzecią grupą byli administratorzy baz danych, którzy zarządzają tymi systemami relacyjnymi. Usługi tych tradycyjnych ról danych jest w dużej mierze znormalizowana. Na przykład administratorzy bazy danych nie informują bazy danych, na których dyskach mają być przechowywane dane ani jak zapewnić integralność relacyjną. Ponieważ technologia relacyjna jest dojrzała, wiele złożonych zadań jest łatwych. Podobnie narzędzia ETL mają adaptery dla typowych systemów źródłowych, funkcje do obsługi typowych operacji transformacji i podpięcia do wspólnych repozytoriów docelowych. Przez lata niewielka liczba dojrzałych narzędzi współpracowała z niewielką liczbą dojrzałych repozytoriów danych. Życie było stosunkowo proste!

Dlaczego potrzebni są inżynierowie danych?

Opisane wcześniej role istnieją do dziś w ich tradycyjnych stanach. Jednak te role już nie wystarczają. Inżynierowie danych wkroczyli, aby wypełnić pustkę. Dzisiaj mamy wiele nowych typów danych, które nie są przyjazne dla narzędzi ETL czy relacyjnych baz danych, dlatego potrzebne są nowe narzędzia. Jednak większość z tych nowych narzędzi i repozytoriów nie jest jeszcze dojrzała i wymaga skomplikowanego kodowania. Co gorsza, często konieczne jest zintegrowanie wielu niedojrzałych technologii. Inżynierowie danych zastanawiają się, jak przeprowadzić tę integrację, często z kilkoma udokumentowanymi przykładami. Wydajne i bezpieczne współdziałanie elementów potoku danych wymaga ciężkiej pracy, a często wymaga większego nakładu energii i większej złożoności niż powinno. Jeszcze większą złożoność dodają architektury obejmujące systemy wewnętrzne i zewnętrzne środowiska chmurowe. Osoby z zewnątrz mówią: "Po prostu zbierz dla nas te dane; Co się trzyma?" Niestety, zadania mogą być proste do zdefiniowania, ale trudne do wykonania. Istnieją różnice między inżynierami danych a tradycyjnymi specjalistami ds. danych. Po pierwsze, inżynierowie danych muszą być bardziej wykwalifikowani w kreatywnym rozwiązywaniu problemów. Następnie inżynierowie danych muszą przyjąć i używać coraz szerszej gamy narzędzi i podejść. Wreszcie, inżynierowie danych muszą skoncentrować się na integracji i optymalizacji narzędzi i platform, a nie na optymalizacji obciążeń w ramach danego narzędzia lub platformy.

Jaka jest przyszłość?


Wiele z tego, co inżynierowie danych robią dzisiaj za pomocą brutalnej siły, z czasem ulegnie standaryzacji. Ilustruje to podobieństwo między nauką o danych a inżynierią danych. Wiele z tego, co zajmowało czas analitykowi danych, zostało zautomatyzowane i ustandaryzowane. "Obywatele zajmujący się danymi" zajmują się teraz wieloma problemami, podczas gdy naukowcy zajmujący się danymi koncentrują się na trudniejszych problemach. Wkrótce zobaczymy "obywatelskich inżynierów danych", którzy wykorzystują standardowe narzędzia inżynierii danych do obsługi podstaw, podczas gdy inżynierowie danych zajmują się nowymi granicami.

Inżynieria danych != Spark

Powszechne jest błędne przekonanie, że Apache Spark to wszystko, czego potrzebujesz do swojego potoku danych. W rzeczywistości do stworzenia potoku danych potrzebne będą komponenty z trzech ogólnych typów technologii. Te trzy ogólne typy technologii big data są następujące:

•  Obliczenia
•  Przechowywanie
•  Wiadomości

Naprawienie i remediacja tego błędnego przekonania ma kluczowe znaczenie dla sukcesu w projektach big data lub własnej wiedzy o big data. Spark to tylko jedna część większego ekosystemu Big Data, która jest niezbędna do tworzenia potoków danych.

Innymi słowy:

Inżynieria danych = Obliczenia + Przechowywanie + Przesyłanie wiadomości + Kodowanie + Architektura + Wiedza domenowa + Przypadki użycia

Systemy wsadowe i czasu rzeczywistego

Ogólnie rzecz biorąc, musisz rozwiązać dwa podstawowe problemy w potoku danych wsadowych. Pierwsza to obliczenia, a druga to przechowywanie danych. Spark to dobre rozwiązanie do obsługi obliczeń wsadowych. Jednak trudniejszym rozwiązaniem jest znalezienie odpowiedniej pamięci masowej - lub, bardziej poprawnie, znalezienie różnych i zoptymalizowanych technologii pamięci masowej dla tego przypadku użycia.

Komponent obliczeniowy

Obliczenia to sposób przetwarzania danych. Te ramy obliczeniowe są odpowiedzialne za uruchamianie algorytmów i większości kodu. W przypadku ram Big Data odpowiadają za alokację wszystkich zasobów, uruchamianie kodu w sposób rozproszony i utrwalanie wyników.

Składnik do przechowywania


Przechowywanie to sposób, w jaki Twoje dane są trwale utrwalane. W przypadku prostych wymagań dotyczących przechowywania ludzie po prostu zrzucają swoje pliki do katalogu. Ponieważ staje się to nieco trudniejsze, zaczynamy używać partycjonowania. Spowoduje to umieszczenie plików w katalogach o określonych nazwach. Typową metodą partycjonowania jest użycie daty danych jako części nazwy katalogu.

Bazy danych NoSQL

Aby uzyskać bardziej zoptymalizowane wymagania dotyczące przechowywania, zaczynamy korzystać z baz danych NoSQL. Potrzeba baz danych NoSQL jest szczególnie rozpowszechniona, gdy masz system czasu rzeczywistego. Większość firm przechowuje dane zarówno w prostej technologii przechowywania, jak iw jednej lub kilku bazach danych NoSQL. Wielokrotne przechowywanie danych obsługuje różne przypadki użycia lub wzorce odczytu/zapisu, które są niezbędne. Jedna aplikacja może wymagać przeczytania wszystkiego, a inna może potrzebować tylko określone dane.

Komponent wiadomości

Wiadomości to sposób, w jaki wiedza lub wydarzenia są przekazywane w czasie rzeczywistym. Korzystanie z wiadomości zaczyna się, gdy zachodzi potrzeba korzystania z systemów czasu rzeczywistego. Te struktury przesyłania wiadomości służą do pozyskiwania i rozpowszechniania dużej ilości danych. To pozyskiwanie i rozpowszechnianie ma kluczowe znaczenie dla systemów czasu rzeczywistego, ponieważ rozwiązuje problemy pierwszej i ostatniej mili.

Pielęgnuj dobre relacje robocze z konsumentami danych

Relacje między inżynierami danych a konsumentami danych - niezależnie od tego, czy są to analitycy danych, zespoły Business Intelligence (BI), czy też jeden z wielu zespołów analitycznych - są zawsze złożone. Wszystkie te funkcje istnieją, aby służyć ogólnym celom organizacji opartym na danych i oczekuje się, że będą się bezproblemowo integrować. Jest więc wyraźna motywacja do współpracy, ale najczęściej podział pracy jest daleki od wyważenia, sytuacja, która może przekształcić się w prawdziwe napięcie między zespołami. Nie ma recepty na stworzenie idealnej relacji symbiotycznej, a jest to podwójnie prawdziwe, biorąc pod uwagę dużą różnorodność struktury zespołów danych w organizacjach. To powiedziawszy, poniższe punkty mogą pomóc inżynierom danych uniknąć poważnych pułapek i dążyć do lepszego kierunku.

Nie pozwól konsumentom rozwiązywać problemów inżynieryjnych

Unikaj pokusy, by konsumenci danych rozwiązywali problemy związane z inżynierią danych. Istnieje wiele rodzajów konsumentów danych, a podstawowe kompetencje każdej osoby różnią się w zależności od wielu spektrum - umiejętności kodowania, wiedza statystyczna, zdolności wizualizacji i wiele innych. . W wielu przypadkach konsumenci danych z większymi możliwościami technicznymi będą próbowali samodzielnie wypełnić luki w infrastrukturze, stosując poprawki ad hoc. Może to przybrać formę zastosowania dodatkowych przekształceń danych do potoku, który nie spełnia swojego celu, a nawet rzeczywistego projektu infrastruktury. Pozornie może się to wydawać inżynierowi danych jako sytuacja korzystna dla obu stron: oszczędza się jego własny czas, a praca konsumenta przebiega bez przeszkód. Zwykle jednak skutkuje to zawiłymi warstwami nieoptymalnych rozwiązań, które sprawiają, że zarządzanie infrastrukturą danych organizacji jest coraz trudniejsze.

Dostosuj swoje oczekiwania

Unikaj stosowania wrażliwości inżynierskiej na konsumentów danych. Jako w pełni wyszkoleni programiści, inżynierowie danych zwykle stosują współczesne najlepsze praktyki programistyczne. Sugerują one rygorystyczny styl kodowania i koncentrują się na wydajności i pokryciu testów jednostkowych. Niektóre organizacje wybierają bardzo zgrane zespoły danych lub nawet ujednolicają wszystkie funkcje w ramach jednego zespołu DataOps. W takich przypadkach inżynierowie danych powinni dostosować swoje oczekiwania do tych odbiorców danych, którzy intensywnie pracują z kodem, ale nie stosują tych najlepszych praktyk. Nie jest to zazwyczaj motywowane ignorancją z ich strony, ale raczej przestrzeganiem ich podstawowej funkcji biznesowej, co wymaga, aby priorytety traktowali inne rzeczy.

Zrozum pracę konsumentów

Postaw na wiedzę, co faktycznie robią konsumenci danych. Dane konsumentów polegają na infrastrukturze danych, aby wykonywać swoją pracę. Ich poziom komfortu, produktywności i adaptacji zależy od dopasowania tej infrastruktury do dynamiki ich pracy. Inżynierowie danych mają za zadanie rozwijać tę infrastrukturę od koncepcji do wdrożenia, dlatego rzeczywiste codzienne potrzeby poszczególnych konsumentów stanowią kontekst krytyczny. Zwykle oznacza to poświęcenie zarówno czasu, jak i wysiłku, aby uzyskać wyraźną lekturę, czy to w formie sesji shadowingu, iteracyjnych weryfikacji koncepcji (POC), czy też dyskusji na temat pomysłów na niskim i wysokim poziomie. Wzrost znajomości zawodowej między zespołami prowadzi również do wzrostu wzajemnego szacunku i życzliwości, a to samo w sobie jest potężnym motorem sukcesu.

Uzgodnione, zgodne z zasadami prywatności gromadzenie danych - przekazane przez inżynierów ds. danych .

Jak zgodne jest Twoje zbieranie danych? Czy klienci są świadomi, w jaki sposób wykorzystywane są ich dane? Czy wiedzą, jak jest przekształcany, agregowany, wprowadzany do modelu i wdrażany? Czy robi się to z poszanowaniem ich prywatności? Czy mogą poprosić o nieuwzględnianie go w żadnym z tych zautomatyzowanych procesów? Czy masz mechanizmy ochrony prywatności, które zapewniają, że wrażliwe dane nie są zagrożone? Jako inżynierowie danych dążymy do precyzji i wydajności. Jak możemy dostać dane z miejsca A do miejsca B, z niezbędnymi etapami pośrednimi do czyszczenia, testowania i walidacji, i jak możemy to zrobić najskuteczniej? To, co gubi się w tym celu przyspieszenia i automatyzacji przetwarzania, to fakt, że często mamy do czynienia z danymi osobowymi - czasami bardzo wrażliwymi. A jeśli miałeś przyjemność pracować z danymi mieszkańców Unii Europejskiej (UE), być może zastanawiałeś się nad tymi tematami dalej ze względu na ogólne rozporządzenie o ochronie danych (RODO). Jak możemy usunąć artefakty od użytkowników, do których danych nie mamy już praw? Co oznacza poddanie osoby zautomatyzowanemu przetwarzaniu? Jak wygląda dobrowolne zbieranie danych? Jeśli chcemy gromadzić dane w sposób zgodny, dla wszystkich ludzi, a nie tylko tych, którzy mają szczęście mieszkać w UE, musimy fundamentalnie zmienić niektóre sposoby przesyłania danych. Oto kilka pomysłów, jak możemy zacząć.

Dołącz metadane zgody
Możemy to zrobić w ramach naszego przetwarzania. Mamy środki, aby określić, kim jest ten użytkownik i na co wyraził zgodę lub zrezygnował. Możemy filtrować lub przekierowywać ich dane w zależności od ich poziomu zgody. Oznacza to, że możemy również wdrożyć lepsze doświadczenia użytkowników dla tych, którzy chcą zrezygnować z niektórych operacji przetwarzania (tj. Nieco mniej okropnych alertów dotyczących plików cookie!).

Śledź pochodzenie danych
Czy wiesz, skąd pochodzą te dane? Niestety dla wielu z nas odpowiedź brzmi nie. Śledzenie pochodzenia danych nie tylko pozwala na lepsze zrozumienie problemów prawnych i związanych z prywatnością, ale także pomaga nam określić jakość danych i jakie przetwarzanie mogło zostać zastosowane do danych, zanim do nas dotarły. Jest to korzystne dla wszystkich!

Upuść lub zaszyfruj wrażliwe pola
Powinniśmy stosować mechanizmy ochrony danych, gdy wiemy, jakie wrażliwe pola mogą zawierać nasze dane. Czy naprawdę potrzebujemy nazw użytkowników do analizy zbiorczej? Nie? Następnie upuść je (lub nie zbieraj ich w pierwszej kolejności). Czy potrzebujemy adresów e-mail do szkolenia z chatbota? Nie? Następnie upewnij się, że nie dostaną się do modelu. Jako inżynierowie danych możemy wykorzystać naszą wiedzę i narzędzia, aby zapewnić ochronę wrażliwych danych. Wielu z nas podejmuje różne środki, aby chronić prywatność siebie i naszych bliskich. Rozszerz uprzejmość na klientów i użytkowników tworzonych produktów, wdrażając dobrowolne gromadzenie danych i podstawowe środki ochrony prywatności danych.

Nazwy kolumn jako kontrakty

Produkty oprogramowania wykorzystują testy jednostkowe i umowy dotyczące poziomu usług (SLA), aby składać obietnice wydajności; interfejsy mają wspólne symbole i etykiety. Jednak tabele danych istnieją gdzieś pomiędzy - ani zaprojektowane jak usługa, ani zaprojektowane jak aplikacja. Ten brak rozmów i zawierania umów między producentami a konsumentami powoduje, że inżynierowie są zdezorientowani, dlaczego użytkownicy nie są zadowoleni (lub niejasno narzekają na "jakość danych"), a konsumenci są zdezorientowani, że dane nigdy nie są "właściwe". Używanie kontrolowanego słownictwa do nazywania pól w opublikowanych zbiorach danych jest low-tech, niskie tarcie rozwiązanie tego dylematu. Opracowanie wspólnego języka umożliwia wspólne zrozumienie, w jaki sposób ma działać każde pole w zestawie danych, a także może zmniejszyć obciążenie producenta w zakresie walidacji danych, dokumentacji i sporów. Inżynierowie i analitycy mogą z góry zdefiniować wielopoziomowy zestaw skrótów o niepodzielnych, dobrze zdefiniowanych znaczeniach. Po połączeniu te kody pośredniczące mogą służyć do opisywania złożonych metryk i zachowań. Wyobraź sobie, że pracujemy w firmie typu ride-share i tworzymy tabelę danych z jednego rekord na podróż. Jak może wyglądać słownictwo kontrolowane? Pierwszy poziom może charakteryzować różne miary, składające się zarówno z typu danych (np. bool lub int), jak i odpowiednich wzorców użytkowania. Na przykład:

ID : liczba całkowita. Niepuste. Unikalny identyfikator podmiotu. Prawdopodobnie klucz podstawowy.
IND: binarny. Niepuste. Wskaźnik wystąpienia zdarzenia.
N : liczba całkowita. Niepuste. Nieujemna liczba wystąpień zdarzenia.
AMT : Numeryczny. Sumowalna, ciągła kwota "bez mianownika".
VAL : Numeryczny. Nie można z natury sumować (np. współczynnik, stosunek, szerokość geograficzna lub długość geograficzna).
ID: Data. Zawsze w formie RRRR-MM-DD.
TM : Znacznik czasu.

Drugi poziom może charakteryzować przedmiot środka, taki jak DRIVER, RIDER, TRIP, ORIG i DEST. Dodatkowe poziomy zapewniłyby dodatkowe "przymiotniki" do modyfikacji przedmiotów działania. Na przykład możemy mieć CITY, ZIP, LAT i LON. Ogólnie rzecz biorąc, ta struktura zapewnia gramatykę do zwięzłego scharakteryzowania szerokiego zakresu metryk. Czy nie jest dość oczywiste, co oznaczają ID_DRIVER, TM_ORIG, VAL_DEST_LON i IND_TRIP_SURGE? Nazwy te nie tylko zapewniają przyjemny interfejs dla użytkowników, ale także w istotny sposób ujednolicają wymagania dotyczące danych, co może pomóc bezpośrednio zautomatyzować zadania związane z zarządzaniem danymi. Zadania związane z zarządzaniem metadanymi i wyszukiwaniem danych można częściowo zautomatyzować, rekonstruując definicje zmiennych z kodów pośredniczących (np. "unikalny identyfikator kierowcy współdzielonego przejazdem") i umożliwiając użytkownikom łatwe przeszukiwanie wszystkich tabel pod kątem danego zestawu pojęć (wszystkie sygnatury czasowe, wszystko do z pochodzeniem wycieczki). Podobnie umowy o wykonanie obiecane użytkownikom w kodach pośredniczących najwyższego poziomu mogą bezproblemowo przełożyć się na zautomatyzowane kontrole walidacji danych ("wszystko, co zaczyna się od DT, powinno być rzutowane jako data", "nic w polach AMT nie powinno być ułamkiem dziesiętnym", "IND zmienne nie mogą mieć wartości null") w narzędziach takich jak Great Expectations. Wreszcie, takie zmienne mogą okazać się przydatnymi wskazówkami mentalnymi w dalszej pracy (np. "nie ma sensu sumować zmiennych VAL"). Oczywiście nie istnieje jedno rozwiązanie typu "srebrna kula" dotyczące jakości, wykrywalności i komunikacji danych. Jednak używanie nazw kolumn do tworzenia umów jest przydatnym sposobem na rozpoczęcie komunikacji zarówno z użytkownikami, jak i narzędziami przepływu pracy.

Zmień przechwytywanie danych

Przechwytywanie zmian danych (CDC) to rozwiązanie konkretnego problemu. Masz swoje najcenniejsze dane w swoich produkcyjnych bazach danych. Chcesz przeanalizować te dane. Ale nie chcesz więcej obciążać tych produkcyjnych baz danych. Zamiast tego chcesz polegać na hurtowni danych lub jeziorze danych. Gdy zdecydujesz, że chcesz analizować dane z produkcyjnej bazy danych w innym systemie, potrzebujesz niezawodnego sposobu replikowania tych danych z produkcyjnej bazy danych do hurtowni danych. Okazuje się, że w skali jest to trudny problem do rozwiązania. Nie możesz po prostu zdecydować się na skopiowanie danych z produkcyjnej bazy danych do magazynu - to znacznie zwiększyłoby obciążenie produkcyjnej bazy danych, zwłaszcza jeśli chcesz uzyskać wysoką wierność. Lub, jeśli pobierzesz tylko zmienione rekordy, przegapisz usunięcia. Na szczęście wszystkie nowoczesne produkcyjne bazy danych zapisują dziennik zapisu z wyprzedzeniem (WAL) lub dziennik zmian w ramach normalnego przetwarzania transakcji; dziennik przechwytuje każdą zmianę w każdym wierszu/komórce w każdej tabeli w bazie danych. Ten dziennik jest używany w replikacji bazy danych do tworzenia replik produkcyjnych baz danych. W CDC narzędzie odczytuje ten dziennik zapisu z wyprzedzeniem i stosuje zmiany w hurtowni danych. Ta technika jest o wiele bardziej niezawodna niż eksport wsadowy tabel i zajmuje niewiele miejsca w produkcyjnej bazie danych. Należy jednak traktować CDC jako kompleksowy potok danych, aby poprawnie replikować dane zarówno na początku, jak i na bieżąco. Musisz rozważyć kilka aspektów cyklu życia złącza CDC. Oto kilka przykładów:

Skala
Potok CDC musi być wystarczająco solidny dla dużej ilości danych. Na przykład w PostgreSQL opóźnienia w odczycie WAL mogą spowodować wyczerpanie miejsca na dysku bazy danych!

Opóźnienie replikacji
Odnosi się to do czasu, jaki upływa od momentu zatwierdzenia transakcji w podstawowej bazie danych do chwili, gdy stanie się ona dostępna w magazynie danych. Musisz skompilować kontrole, aby upewnić się, że potok minimalizuje czas opóźnienia, uruchamiając kontrole przed uruchomieniem przekształceń.

Zmiany schematu
Z biegiem czasu schematy bazy danych ewoluują, ponieważ dodawane są lub usuwane tabele lub kolumny są dodawane, usuwane lub aktualizowane typy. Ważne jest, aby propagować zmianę schematu do hurtowni danych. Czasami zmiana schematu może wymagać synchronizacji historycznej.

Maskowanie
Musisz zamaskować wrażliwe kolumny w celu zapewnienia zgodności.

Synchronizacje historyczne
Przed zastosowaniem zmian CDC potrzebna jest początkowa synchronizacja historyczna tabel. Może to chwilę potrwać i może przeciążyć źródło. Lepiej jest wykonywać synchronizacje historyczne z bazy danych repliki, aby je przyspieszyć i zmniejszyć obciążenie podstawowej bazy danych. Czasami w warstwie WAL mogą wystąpić częściowe przerwy, więc do szybkiego przywrócenia potrzebne są częściowe synchronizacje historyczne zamiast pełnych synchronizacji historycznych.

Zazwyczaj nie ma mocnych powodów, aby budować własne złącza CDC. Zamiast tego użyj istniejących narzędzi!

Uwaga: projekty z zakresu analizy danych mogą zmienić się w nowe szaty cesarza

Czwarta rewolucja przemysłowa rozpoczęła erę analityki. Istnieje szalony pośpiech w opracowywaniu modeli predykcyjnych i algorytmów, aby ustanowić przewagę w niezwykle konkurencyjnym, opartym na danych świecie. Zaczynając od analiz predykcyjnych i przechodząc w sferę uczenia maszynowego i sztucznej inteligencji, większość firm rozszerza swoje możliwości, aby tworzyć projekty z zakresu data science. Na zespoły zajmujące się analizą danych, podobnie jak wszystkie inne rodzaje zespołów projektowych, wywierana jest ogromna presja, aby dostarczać wartość biznesową, która jest użyteczna i potencjalnie możliwa do uwolnienia w określonych ramach czasowych. Dużym wyzwaniem dla zespołów zajmujących się analizą danych jest pokazanie widocznego i wymiernego postępu/wykonanej pracy, aby utrzymać zainteresowanie interesariuszy i stabilne finansowanie. Jednak około 80% czasu projektu poświęca się na zbieranie/wybór danych, przygotowanie danych i analizę eksploracyjną. Koszty ogólne projektu są ogromne, ale nie ma widocznych wyników. Obiecany model lub algorytm predykcyjny nie jest ujawniany na wczesnych, ani nawet środkowych stadiach. . Niekiedy na etapie oceny lub walidacji pojawia się możliwość odrzucenia całej analizy i powrotu do deski kreślarskiej. W takich sytuacjach zasoby zostały zużyte, spalone godziny, ale nic nie zaowocowało - a la nowe szaty cesarza! Jak uchronić swój zespół analityków danych przed wstydem cesarza? Projekty z zakresu nauki o danych wymagają strategicznego planowania i zarządzania priorytetami, zasobami i infrastrukturą, jak opisano w następujących krokach:

1. Zrozum podejście "najpierw sprzedaj": Jaką podstawową potrzebę obiecano interesariuszom? Przemysł informatyczny (IT) odchodzi od wdrożeń typu "big bang". Chodzi o iteracje. Bez względu na to, ile źródeł danych przeszukujemy lub jaką najnowocześniejszą technologię prezentujemy, mapy drogowe dotyczące publikacji danych naukowych powinny być zaprojektowane w taki sposób, aby każda iteracja popychała w jakimś kierunku spełnienie tej bardzo podstawowej potrzeby.
2. Nadaj "twarz" projektowi: Nie tylko dla interesariuszy, ale także z perspektywy kierownika projektu lub właściciela produktu, musi być wgląd w to, co się dzieje. Interfejs użytkownika (UI), który działa jak twarz dla analityków pod maską, może pomóc w wizualizacji procesu analitycznego i dać zrozumienie postępów w projekcie. Ten interfejs użytkownika lub pulpit nawigacyjny powinien być interaktywny i identyfikować konkretne wykorzystywane zestawy danych oraz dokładny model używany do uzyskania określonego zestawu wyników. Może być również używany do walidacji i akceptacji wśród grupy użytkowników.
3. Zapewnij gotowość środowiska: Środowisko programistyczne powinno być zdolne do szybkiego zapełniania baz danych i zmieniania zestawów danych do analizy eksploracyjnej. Problemy z zarządzaniem pamięcią są głównymi przeszkodami w większości projektów dotyczących nauki o danych. Ogromne ilości danych będą pobierane z różnych źródeł danych. Mogą to być pliki kształtu, arkusze kalkulacyjne lub pliki tekstowe. Powinien istnieć skuteczny plan zarządzania pamięcią dla wszystkich urządzeń obliczeniowych i pamięci masowej w środowisku programistycznym.
4. Skrypty katalogowe: Skrypty do pobierania danych, skrypty do czyszczenia i przygotowania danych oraz skrypty do archiwizacji danych powinny być odpowiednio oznakowane do ponownego wykorzystania.

Ekosystem nauki o danych może składać się ze zróżnicowanego zespołu zajmującego się badaniem danych, zróżnicowanych zestawów narzędzi i różnorodnych danych. Jest to ostateczny cel projektu, który łączy wszystkie wysiłki analityczne ze sobą. Może to skutkować sformułowaniem sprytnego algorytmu AI lub może spowodować awarię. Tak czy inaczej, wynik kroków od 1 do 4 zapewni, że nasi interesariusze nie stracą wiary w nasze wysiłki i nie wyprodukujemy zaawansowanej technologicznie wersji nowych szat cesarza!

Budowanie kariery jako inżynier danych

Organizacje w każdym sektorze zdają sobie sprawę z wagi danych i utrzymywania silnych operacji na danych. Jego uznanie jako potężnego zasobu biznesowego spowodowało pojawienie się dedykowanych zespołów danych obejmujących pełnoetatowe role dla naukowców zajmujących się danymi, architektów, analityków i, co najważniejsze, inżynierów danych. W tej części przyjrzymy się, jak początkujący profesjonaliści mogą zrobić ten ważny krok na drabinie kariery inżyniera danych. Inżynieria danych ma wiele nakładających się dyscyplin. Trudno jest wytyczyć jedną drogę do zostania inżynierem danych. Pomogą w tym studia w dziedzinach takich jak technologie informacyjne i komunikacyjne (ICT) lub inżynieria oprogramowania, ale widziałem też niesamowitych inżynierów danych z dyplomami z fizyki i matematyki. Zróżnicowane są również ścieżki kariery. Silni inżynierowie danych przeszli z ról tak różnych, jak sprzedaż, operacje, a nawet marketing. Tak długo, jak masz podstawowe doświadczenie w pisaniu małych skryptów i prowadzeniu projektów oczyszczania danych, powinieneś być gotowy do stawiania pierwszych kroków w świecie inżynierii danych. Tak więc, jeśli doświadczenie nie jest tak ważne, jakich umiejętności potrzebuje początkujący inżynier danych, aby odnieść sukces? Trzy wyróżniające się umiejętności zapewnią ci ważny początek. Pierwszym z nich jest solidne doświadczenie w całym cyklu życia oprogramowania. Mogę być tutaj nieco stronniczy, biorąc pod uwagę moje własne doświadczenie jako inżyniera oprogramowania, ale umiejętności, które daje praca w całym cyklu życia oprogramowania, są nieocenione w świecie inżynierii danych. Drugi to wiedza o tym, jak prawidłowo używać standardowego języka zapytań (SQL), a także dobra znajomość co najmniej jednego innego statycznego i jednego dynamicznego języka programowania. To może wydawać się proste, ale nie można przecenić tego, jak bardzo organizacje polegają na SQL w swoich operacjach na danych. Połączenie tego ze zrozumieniem, jak pracować na przykład z Pythonem i Rustem, da ci ważne pojęcie o tym, jak budowane jest wspaniałe oprogramowanie i, ostatecznie, jak można je zastosować w świecie danych. Trzecia podstawowa umiejętność zależy od podroli inżynierii danych, w której chcesz się specjalizować. Dla tych, którzy chcą specjalizować się w przetwarzaniu danych, kluczowe jest rozwijanie wiedzy na temat technologii przechowywania danych, a także dalsze doskonalenie umiejętności w zakresie SQL. Dla tych, którzy chcą pójść bardziej tradycyjną ścieżką inżynierii oprogramowania, doskonalenie umiejętności analitycznych będzie kluczowe, ponieważ skupisz się głównie na projektach big data. Najważniejsze jest to, że powinieneś wcześnie zdecydować, na którym obszarze chcesz się skoncentrować i rozwijać swoje umiejętności, aby uzupełnić tę funkcję. Moja ostatnia rada dotyczy każdego poziomu, od początkujących inżynierów danych po uznanych inżynierów oprogramowania, którzy chcą zrobić kolejny krok w górę: wejdź w open source! Jeśli uczysz się budować i bawić się inżynierią danych open source, poszerzasz swój repertuar umiejętności. Najlepszym sposobem na awans w swojej karierze inżyniera danych jest rozpoczęcie korzystania z narzędzi typu open source.

Uważaj na syndrom srebrnej kuli: czy naprawdę chcesz, aby Twoja tożsamość zawodowa była stosem narzędzi?

Oferty pracy związane z technologią często opisują zapotrzebowanie na ludzi z pasją, którzy ciężko pracują i mocno popierają swoje pomysły. . W końcu Steve Jobs był pasjonatem, więc może to cecha ludzi sukcesu! Ale w świecie inżynierii danych i analityki ludzie z pasją często mają silne zdanie na temat korzystania z określonej platformy. Wszyscy zetknęliśmy się z tą osobą: tą, która gorliwie promuje Apache Spark lub naciska na wykonanie całej pracy związanej z danymi w Alteryx Designer. Duży nacisk kładzie się na narzędzie, a nie na powiązanie problemu z rozwiązaniem. Czasami takie zachowanie jest napędzane chęcią standaryzacji i uproszczenia zatrudniania, co z pewnością jest zasadne. Ale częściej niż nie widziałem ludzi gorliwie opowiadających się za narzędziem po prostu dlatego, że byli nim z pasją lub, co gorsza, budowali wokół niego swoją zawodową tożsamość. Mówiąc prościej, budowanie tożsamości zawodowej wokół narzędzia nigdy nie jest dobrym pomysłem. Narzędzia i aplikacje pojawiają się i znikają, a to, co dziś jest gorące, jutro może zostać przestarzałe. Już samo to powinno dać powód do wstrzymania się przed zbyt szybkim wprowadzeniem technologii. Zapytaj każdego, kto zrobił JavaScript. Inny powód, dla którego nadmierne popieranie narzędzia jest złym pomysłem, najlepiej opisuje wyrażenie "Kiedy masz tylko młotek, wszystko zaczyna wyglądać jak gwóźdź". Niejednokrotnie w mojej karierze miałem trudne problemy, które wymagały bardzo niekonwencjonalnych rozwiązań. Podczas gdy miałem zachwyconych klientów, czasami miałem kolegę, który zastanawiał się, dlaczego nie użyłem preferowanego/konwencjonalnego narzędzia do rozwiązania tego problemu. Musiałem wskazać na ironię proszenia o konwencjonalne rozwiązanie niekonwencjonalnego problemu. Hadi Hariri z JetBrains najlepiej opisał to zachowanie jako syndrom srebrnej kuli: oczekujemy, że jedno narzędzie rozwiąże wszystkie nasze problemy, tylko po to, by gonić za następnym, gdy jesteśmy rozczarowani. Nie padnij ofiarą syndromu srebrnej kuli i nie zafascynuj się platformą lub narzędziem. Zamiast tego odsuń się. Bądź bezstronny i obiektywny. Zdaj sobie sprawę, że różne narzędzia mogą być uzasadnione dla różnych rodzajów problemów. To prawda, że powinieneś dążyć do jak największej standaryzacji narzędzi w swoim miejscu pracy, ale nie kosztem skuteczności. Czy naprawdę chcesz, aby Twoja tożsamość zawodowa była po prostu zestawem narzędzi? Czy wolałbyś, aby Twoje CV mówiło: "Znam SQL, MongoDB i Tableau" czy "Jestem elastycznym profesjonalistą, który potrafi poruszać się w niejednoznacznych środowiskach, pokonywać bariery działów i dostarczać spostrzeżenia techniczne, aby zmaksymalizować wartość danych dla organizacji"? Zbuduj swoją tożsamość zawodową dzięki umiejętnościom, rozwiązywaniu problemów i zdolności adaptacyjnej, a nie przelotnej technologii.

Bądź świadomy modelu wsadowego w swoich potokach danych

Jeśli pozyskujesz rekordy danych w partiach i tworzysz potoki danych wsadowych, musisz wybrać sposób tworzenia partii w określonym czasie. Partie mogą być oparte na data_timestamp lub arrival_timestamp rekordu. Data_timestamp to ostatni zaktualizowany znacznik czasu zawarty w samym rekordzie. Znacznik_czasu_przybycia jest znacznikiem czasu dołączonym do rekordu w zależności od tego, kiedy rekord został odebrany przez system przetwarzania.

Model wsadowy okna czasowego danych

W modelu przetwarzania wsadowego okna czasu danych (DTW) partia jest tworzona dla okna czasu po odebraniu wszystkich rekordów z data_timestamp w tym oknie. Użyj tego modelu wsadowego, gdy

•  Dane są pobierane ze źródła (w przeciwieństwie do wypychania przez źródło).
•  Logika wyodrębniania może odfiltrować rekordy z data_timestamp poza oknem czasowym.

Na przykład użyj przetwarzania wsadowego DTW podczas wyodrębniania wszystkich transakcji w oknie czasowym z bazy danych. Grupowanie DTW ułatwia życie analitykowi dzięki analityce, ponieważ można zagwarantować, że wszystkie rekordy dla danego okna czasowego są obecne w tej partii. Tak więc analityk dokładnie wie, z jakimi danymi pracuje. Jednak grupowanie DTW nie jest zbyt przewidywalne, ponieważ niesprawne rekordy mogą powodować opóźnienia.

Model dozowania okna czasowego przybycia

W modelu wsadowym okna czasu przybycia (ATW) partia jest tworzona o określonej godzinie zegara ściennego z rekordami, które zostały odebrane w oknie czasowym przed tym czasem. Użyj tego modelu wsadowego, gdy

•  Zapisy w partii mogą być odbierane poza kolejnością; tj. mogą mieć data_timestamps, które są poza oknem czasu przybycia.
•  Ilość nagrań jest naprawdę duża.

Grupowanie ATW jest bardziej przewidywalne, ponieważ partie są tworzone na podstawie czasu zegara ściennego bez konieczności oczekiwania na wszystkie rekordy dla danego okna czasowego. Ta przewidywalność pozwala na bardziej solidną alokację zasobów i tolerancję na awarie. W takim przypadku analityk będzie musiał wysłać zapytanie do wielu partii, aby zagwarantować, że uwzględnione zostaną wszystkie rekordy z data_timestamps w danym oknie czasowym. Jednak w przypadkach, w których 100% dokładność nie jest niezbędna, dozowanie ATW jest wystarczające. Na przykład podczas analizowania codziennych aktywnych użytkowników konsumenckiej firmy internetowej poprzez odpytywanie dzienników użytkowania, margines błędu spowodowany przez nieprawidłowe rekordy może być akceptowalny.

Dozowanie ATW i DTW w tym samym potoku

Nie jest to wykluczająca się decyzja o stosowaniu wsadów DTW w porównaniu z ATW. Rozważmy na przykład zestaw rekordów, które docierają w różnym czasie . Zacznij od grupowania ATW, aby uzyskać solidność. Tak więc rekordy z data_timestamps w tym samym oknie czasowym (zacieniowane na żółto) są w rzeczywistości grupowane w oddzielne partie. Arrival_time_table to tabela wsadowa ATW.



W oparciu o to, jak duże może być opóźnienie w zapisach - powiedzmy trzy godziny - można wykonać krok w potoku zwany zamknięciem ksiąg. Ten krok tworzy partię danych na 23. godzinę, wyszukując wiersze w kilku następnych partiach



Powyższe zapytanie jest uruchamiane o godzinie zegara ściennego z trzygodzinnym opóźnieniem (24.07.2020 03:00), ponieważ do tego czasu mogliśmy otrzymać rekordy z data_timestamp w przedziale godzinowym 23.07.2020 23 :00. Ta tabela closed_books_table z 23 godziny zawiera wszystkie wiersze z tej godziny. Tak więc closed_books_table jest tabelą wsadową DTW . Analityk może wysłać zapytanie do tej partii i mieć gwarancję, że ich analiza zostanie zakończona przez 23 godzinę



Ten przykład pokazuje, że kompromisy dotyczące wymagań dotyczących kompletności i opóźnień można włączyć do tego samego potoku danych. Analitycy mogą wtedy podjąć świadomą decyzję, kiedy przeprowadzić analizę, przed lub po zamknięciu ksiąg. Mogą wybrać zapytanie do tabeli_godziny_przybycia, aby uzyskać odpowiedzi z mniejszym opóźnieniem, lub do tabeli closed_books_table, aby uzyskać pełne odpowiedzi.

Zautomatyzuj testy potoków

Trzymając się poniższych wskazówek podczas budowania potoków danych i traktując inżynierię danych jak inżynierię oprogramowania, możesz pisać dobrze przemyślane, niezawodne i solidne potoki:

Zbuduj test end-to-end całego potoku na początku : nie wkładaj żadnego wysiłku w to, co robi potok na tym etapie. Skoncentruj się na infrastrukturze: jak zapewnić znane dane wejściowe, wykonać proste przekształcenie i przetestować, czy dane wyjściowe są zgodne z oczekiwaniami. Użyj standardowego frameworka do testowania jednostkowego, takiego jak JUnit lub pytest.
Użyj małej ilości reprezentatywnych danych : powinny być na tyle małe, aby test można było uruchomić w ciągu najwyżej kilku minut. Najlepiej byłoby, gdyby te dane pochodziły z Twojego rzeczywistego (produkcyjnego) systemu (ale upewnij się, że tak anonimowy).
Preferuj formaty danych tekstowych do testów binarnych : Pliki danych powinny być możliwe do porównania, dzięki czemu możesz szybko zobaczyć, co się dzieje, gdy test się nie powiedzie. Możesz sprawdzić dane wejściowe i oczekiwane wyjścia w wersji aby kontrolować i śledzić zmiany w czasie. Jeśli potok akceptuje lub generuje tylko formaty binarne, rozważ dodanie obsługi tekstu w samym potoku lub wykonaj niezbędną konwersję w teście.
Upewnij się, że testy mogą być uruchamiane lokalnie : Uruchamianie testów lokalnie ułatwia debugowanie błędów testów. Używaj w procesie wersji używanych systemów, takich jak tryb lokalny Apache Spark lub miniklaster Apache HBase, aby zapewnić samodzielne środowisko lokalne. Zminimalizuj wykorzystanie usług w chmurze w testach. Mogą zapewnić jednolite środowisko, ale mogą zwiększać trudności w zakresie czasu udostępniania, debugowania i dostępu (np. użytkownicy muszą podać własne poświadczenia dla projektów open source). Oczywiście przeprowadzaj testy również pod CI.
Uczyń testy deterministycznymi : Czasami kolejność rekordów wyjściowych nie ma znaczenia w aplikacji. Jednak do testowania możesz chcieć wykonać dodatkowy krok, aby posortować według pola, aby uzyskać stabilne dane wyjściowe. Niektóre algorytmy wykorzystują losowość, na przykład algorytm grupowania, aby wybrać sąsiadów kandydatów. Ustawienie materiału siewnego jest standardową praktyką, ale może nie pomóc w środowisku rozproszonym, w którym pracownicy wykonują operacje w niedeterministycznej kolejności. W takim przypadku rozważ uruchomienie tej części potoku testowego z jednym procesem roboczym lub umieszczanie na partycji danych. Unikaj umieszczania pól zmiennych czasu w danych wyjściowych. Powinno to być możliwe dzięki zapewnieniu stałego wkładu; w przeciwnym razie rozważ wyszydzanie czasu lub przetwarzanie końcowe danych wyjściowych w celu usunięcia pól czasu. Jeśli wszystko inne zawiedzie, dopasuj wyniki według miary podobieństwa, a nie ścisłej równości.
Ułatw sobie dodawanie kolejnych testów : Sparametryzuj według pliku wejściowego, aby móc uruchomić ten sam test na wielu wejściach. Rozważ dodanie przełącznika, który umożliwia testowi rejestrowanie danych wyjściowych dla nowego wejścia przypadku krawędzi, aby można było sprawdzić poprawność i dodać jako oczekiwany wynik.

Zautomatyzuj swoją infrastrukturę

Podobnie jak wielu innych inżynierów danych, jedną z naszych ról jest wdrażanie potoków danych przy użyciu dostawcy usług w chmurze, takiego jak Amazon Web Services (AWS), Google Cloud, Microsoft Azure lub innych. Możemy łatwo użyć konsoli internetowej do połączenia komponentów i zapewnienia pełnego potoku danych. Biorąc pod uwagę AWS jako przykład, możemy chcieć użyć API Gateway jako naszego interfejsu reprezentacji stanu (REST) do odbioru danych, kilku funkcji Lambda do walidacji pozyskiwania, Kinesis Data Streams do analizy w czasie rzeczywistym, Kinesis Data Firehose dostarczanie danych oraz Simple Storage Service (S3) jako warstwę trwałości. Możemy również chcieć użyć Ateny jako warstwy wizualizacyjnej. W tym przykładzie mamy do czynienia z około sześcioma komponentami. Każdy składnik może wymagać dodatkowej konfiguracji. Na koniec mamy do czynienia z wieloma rolami zarządzania tożsamością i dostępem (IAM) do obsługi uprawnień i list kontroli dostępu (ACL). OK, możemy zrobić wszystko, klikając konsolę i łącząc wszystkie komponenty razem; to najszybszy sposób na utworzenie infrastruktury, jeśli potrzebujesz tylko jednego prostego potoku pozyskiwania. Jeśli musisz ustawić wszystko ręcznie, i znowu, i znowu, będzie to wymagało dużo dodatkowego czasu i zapewni więcej okazji do popełnienia błędów, a nawet otwarcia naruszenia bezpieczeństwa. Dlatego inżynierowie danych muszą nauczyć się automatyzować swój kod. Oto kilka wskazówek:

Nigdy nie używaj konsoli internetowej : Wybierz narzędzie infrastruktury jako kodu, aby to zrobić (na przykład Terraform lub AWS CloudFormation).
Zrób to modułowo: Na przykład użyj jednego modułu do wdrożenia bramy API, innego modułu do wdrażania Kinesis, jeden dodatkowy moduł do zarządzania rolami uprawnień i tak dalej. Większość narzędzi umożliwia ponowne wykorzystanie kodu w różnych komponentach (na przykład udostępnianie zasad uprawnień do pisania tylko raz i używania wszędzie).
Użyj systemu kontroli wersji do zarządzania kodem: Jest to pomocne, jeśli pracujesz w zespole; możesz włączyć opcję pull request, aby sprawdzić kod przed zastosowaniem go do gałęzi master.
Przetestuj kod przed zastosowaniem zmian: Na przykład Terraform pokazuje wszystkie zmiany w Twojej infrastrukturze przed ich zastosowaniem. Możesz uniknąć uszkodzenia swojej infrastruktury.
Użyj potoku ciągłej integracji/ciągłego dostarczania (CI/CD): Możesz wszystko zautomatyzować i znacznie ułatwić sobie pracę, korzystając z potoku CI/CD.
Jeśli nigdy wcześniej nie korzystałeś z tego podejścia, poświęć trochę czasu na przestudiowanie Terraform lub CloudFormation, a następnie napisz całą infrastrukturę jako kod. Wymagany czas i wysiłek będą warte zachodu: będziesz mieć pełną kontrolę nad swoją infrastrukturą i umożliwi Ci wdrożenie zupełnie nowego potoku danych w ciągu kilku minut, po prostu wykonując kod infrastruktury.

Analityka jako sekretny klej do architektury mikroserwisów

Ostatnio zaobserwowaliśmy poważną zmianę w kierunku architektur mikroserwisowych. Dzięki temu, napędzane przez firmy odnoszące największe sukcesy w branży, zespoły mogły mieć mniej zależności, działać szybciej i łatwiej skalować. Ale to oczywiście wprowadziło wyzwania. Większość jest związana z rozproszonym charakterem architektury i zwiększonymi kosztami komunikacji. Poczyniono znaczne postępy, aby sprostać tym wyzwaniom, głównie w obszarach obserwowalności i działania systemu. Sama podróż traktowana jest jako problem techniczny do rozwiązania. Analityka jest często pomijana jako coś, co nie ma bezpośredniego związku z projektem systemu. Jednak heterogeniczny charakter mikrousług doskonale nadaje się do analizy danych. W ten sposób narodziła się hurtownia danych, w końcu jako centralne repozytoria zintegrowanych danych z jednego lub większej liczby różnych źródeł. W konfiguracji rozproszonej rola platformy analitycznej obejmującej całą firmę może być ogromna. Spójrzmy na przykład. Wyobraź sobie, że Twój zespół udostępnia funkcję. Przeprowadzasz eksperyment i zauważasz, że funkcja podnosi docelowy kluczowy wskaźnik wydajności (KPI) Twojego zespołu. To wspaniale. Czy powinieneś go wdrożyć dla całej bazy użytkowników? Jasne, ruszaj, świętuj i wracaj do domu. Co jednak, jeśli w tym samym czasie spadnie kolejny KPI dla innego zespołu? Może się tak zdarzyć, gdy kanibalizujesz kanał lub wprowadzasz poważne zmiany w zachowaniu na platformie. Czy chcesz teraz zwolnić tę funkcję? I oczywiście nie ma na to poprawnej odpowiedzi. Nie ma też żadnego szablonu. Podejmowanie decyzji wymaga starannego zaplanowania eksperymentu, dopasowania między zespołami i chęci robienia niewielkich spadków tam, gdzie jest to potrzebne, tak aby cały system poruszał się optymalnie, a nie pojedynczy komponent. Posiadanie danych zapewnia wspólną podstawę dla tych decyzji, umożliwia firmom dokonywanie uzasadnionych przypuszczeń i zapewnia możliwość oszacowania wpływu. Bez danych zespoły mogą wpaść w błędne koło ciągnięcia w różnych kierunkach, co skutkuje dużym ruchem bez postępów. O jakich wskaźnikach warto pomyśleć, rozpoczynając nowy projekt lub planując eksperyment? Rozważ następujące:

Ogólne dane firmy: są najtrudniejsze do przeniesienia i rzadko są zmieniane przez pojedynczy eksperyment lub funkcję. Bardziej prawdopodobne jest, że zostaną zmienione w wyniku złożonego efektu wielu iteracji.
Wskaźniki zespołu: chcesz podnieść wskaźniki zespołu, ale ważnym czynnikiem jest tutaj spojrzenie na nie w kontekście bycia częścią systemu.
Bardziej szczegółowe eksperymenty lub dane związane z projektem : zwykle przychodzą one na myśl podczas projektowania funkcji. Powinny być tak szczegółowe, jak to tylko możliwe, aby można było zmierzyć bezpośredni i odosobniony wpływ.
W zależności od projektu może być więcej metryk. Tylko przeglądając różne poziomy szczegółowości, będziesz w stanie podejmować decyzje świadome danych i mieć podstawy do ich komunikowania. Dlatego, wchodząc na ścieżkę mikroserwisów, kultura analityczna i eksperymentalna w całej firmie powinna być jednym z warunków wstępnych, a nie refleksją. Bogata platforma analityczna może stać się Twoim spoiwem łączącym poszczególne elementy systemu. Pozwala również na orkiestrację luźno połączonych komponentów, aby kołysać się w tym samym kierunku.

O warstwie pamięci masowej

Głównym celem abstrakcji w oprogramowaniu jest ukrycie złożoności. Tak jak udowadniamy twierdzenia matematyczne za pomocą innych twierdzeń, które zostały wcześniej sprawdzone, tak tworzymy oprogramowanie na warstwach abstrakcji bez konieczności dokładnego poznania sposobu ich implementacji. Możemy je zrozumieć; po prostu nie musimy pamiętać o każdym szczególe, kiedy ich używamy, uwalniając nasze myśli, aby skoncentrować się na tym, co staramy się osiągnąć. Teraz warto (ale nie jest to konieczne) przejrzeć te szczegóły przynajmniej raz. Zrozumienie języka asemblera lub kompilatorów czyni nas lepszymi programistami, nawet jeśli nie bawimy się nimi na co dzień. To samo dotyczy warstwy przechowywania bazy danych lub dowolnej struktury przetwarzania danych. Ta warstwa przechowywania zapewnia znajomą dwuwymiarową abstrakcję tabeli na wierzchu warstwy liniowej trwałości. Na przykład, pisząc SQL, skupiamy się na definiowaniu ograniczeń, które definiują wynik (join, filtr,...) bez konieczności znajomości formatu danych czy układu. Optymalizator znajdzie skuteczny sposób na uzyskanie prawidłowego wyniku. Aparat zapytań naiwnych ładuje dane do pamięci, a następnie stosuje filtry i inne wyrażenia. Oczywiście chcemy uniknąć ładowania wszystkiego, co zostanie odrzucone w ramach przetwarzania zapytania. Oszczędza to koszty we/wy, a także koszty procesora, unikając późniejszej deserializacji. Chcemy również zmniejszyć ilość danych, dzięki czemu ich przechowywanie kosztuje mniej, a ich pobieranie jest szybsze. Kombinacja kodowania i kompresji zapewnia kompromis między zmniejszeniem kosztu operacji we/wy a zwiększeniem kosztu procesora. Przepustowość pamięci masowej będzie decydować o tym, ile procesora należy wykorzystać, a tanie techniki dekodowania mają pierwszorzędne znaczenie. Te szczegóły implementacji są zwykle ukryte za tym, co jest powszechnie znane jako pushdown. Te operacje zapytań wypychają do warstwy magazynu, aby zminimalizować koszt ładowania danych. Występują w kilku smakach. Po pierwsze, rzutowanie w dół polega na odczytaniu tylko żądanych kolumn. Po drugie, pushdown predykatu polega na unikaniu deserializacji wierszy, które mają zostać odrzucone przez filtr. Wreszcie, częściowe agregacje i ocenę funkcji/wyrażenia można zepchnąć w dół, aby uniknąć zmaterializowania danych pośrednika. Definiują naszą abstrakcję: jakich kolumn potrzebujesz? Jak filtrujesz wiersze? Jakie wyrażenie do nich stosujesz? Różne cechy pamięci masowej będą miały wpływ na wydajność pushdown. Układy kolumnowe (na przykład w Apache Parquet) umożliwiają przesuwanie projekcji oraz lepsze kodowanie i kompresję. Statystyki (takie jak wartości minimalne i maksymalne) na różnych poziomach szczegółowości umożliwiają przesuwanie predykatów. Na przykład, jeśli maksymalna wartość dla grupy wierszy jest mniejsza niż jakakolwiek wartość, która może pasować do filtra, możemy pominąć odczytywanie i całkowicie deserializować. Sortowanie i partycjonowanie danych - być może w różnych kolumnach (tak jak to umożliwia Apache Iceberg) - sprawi, że zarówno kompresja, jak i predykaty będą bardziej wydajne, ponieważ statystyki będą bardziej precyzyjnie zawężać odczytywane dane.

A/B

W istocie testy A/B to metoda porównywania dwóch wersji czegoś, aby zobaczyć, która z nich działa lepiej. Bardzo prostym przykładem jest dostosowanie lokalizacji obrazu koszyka na zakupy w witrynie e-commerce od prawego górnego rogu do prawego dolnego rogu. Być może niektórzy członkowie zespołu uważają, że dodanie go w prawym dolnym rogu doprowadzi do mniejszej liczby porzuconych wózków. W zależności od wielkości i charakteru eksperymentu inżynieria danych może być zaangażowana we wszystko, od oprzyrządowania i śledzenia po analizę. W związku z tym tematem ważne jest, aby wiedzieć, że istnieją narzędzia innych firm, które pomagają skonfigurować śledzenie zaplecza dla eksperymentów. Niezależnie od tego, czy używane jest narzędzie innej firmy, czy rozwiązanie wewnętrzne, ważne jest, aby zweryfikować wyniki i poczuć wygodne rejestrowanie eksperymentu. Podczas walidacji danych eksperymentalnych niuanse zawsze będą wymagały dalszych badań. Lista może być dość długa, ale obszary, które umożliwiają szybkie wykrycie problemu, obejmują:

Rozmiary próbek :
Jeśli eksperyment jest podzielony w stosunku 50/50, wielkości próbek powinny być bardzo zbliżone. Jeśli eksperyment jest kolejnym podziałem, zweryfikuj wielkość próby względem oczekiwanej wagi.

Daty rozpoczęcia i zakończenia (z dowolnymi wagami narastania) :

Eksperyment mógł być powoli rozwijany na drabinie, od 1%, 5%, 10% itd., aby uniknąć potencjalnie dużego negatywnego wpływu. Eksperyment mógł również zawierać błąd (w projektowaniu, randomizacji itp.) lub był przeprowadzany w okresie wakacyjnym, a dane z tych okresów mogą wymagać oddzielnego wykluczenia lub oceny.

Użytkownik w obu grupach :

Jeśli użytkownikowi błędnie podano zarówno kontrolę, jak i eksperyment, należy go wykluczyć z eksperymentu. (Jeśli to jest powszechny problem, eksperyment może wymagać powtórzenia).

Ograniczenia kontekstowe :

W zależności od eksperymentu mogą też obowiązywać określone ograniczenia dla użytkowników, którzy otrzymują eksperyment. Na przykład linia lotnicza może zapewnić to samo doświadczenie wszystkim użytkownikom pod tym samym identyfikatorem rezerwacji. Może to powodować momenty braku równowagi w wielkościach próbek do eksperymentu, ale powinno to samo rozwiązać.

Po wprowadzeniu zmian w procesie zaplecza eksperymentów należy rozważyć przeprowadzenie testu A/A. Test A/A zapewnia takie same wrażenia wszystkim użytkownikom. Jego celem jest zapewnienie prawidłowego gromadzenia oprzyrządowania i rejestrowania. Gdy eksperyment jest aktywny, ustalenie, czy wystąpił błąd śledzenia, może być trudne, ponieważ może zostać zamaskowany przez same wyniki eksperymentu. I odwrotnie, błąd może być łatwy do wykrycia, ale jeśli zostanie wykryty po uruchomieniu eksperymentu, prawdopodobnie będzie musiał zostać wstrzymany, aby naprawić problem, a następnie wznowiony, co spowoduje utratę cennego czasu. Spodziewaj się, że większość eksperymentów się nie powiedzie. Netflix uważa, że 90% tego, co próbuje się mylić. Wiedząc o tym, spodziewaj się wielu pytań! Spodziewaj się pytań dotyczących dokładności oprzyrządowania i rejestrowania. Kiedy zauważysz radykalną poprawę dzięki eksperymentowi, bądź sceptyczny. Możesz ponownie ocenić wyniki i przeanalizować ponownie podczas pełnego wdrożenia. Wreszcie, nie bądź dla siebie surowy! Eksperymenty są złożone, a w miarę dalszej pracy w terenie nauczysz się więcej i będziesz w stanie lepiej zadawać pytania.

(Książkowy) przypadek ostatecznej spójności: krótka historia prowadzenia zapasów w księgarni w celu wyjaśnienia silnej i ostatecznej spójności w architekturze oprogramowania.

Zastanów się nad posiadaniem księgarni. W pewnym momencie będziesz chciał skonfigurować system, który będzie utrzymywał spis wszystkich książek w twoim sklepie. Na początku istnienia Twojego sklepu wybrałeś system zaprojektowany dla około 1000 książek w jednym miejscu. Ten system aktualizuje zapis książki podczas kasy klienta. Gdy klient podchodzi do lady, aby kupić książkę, system inwentaryzacji wykonuje następujące czynności:

1. Sprawdza swoje księgi pod kątem szczegółów inwentarza
2. Rejestruje nowy zakup
3. Aktualizuje wszystkie rekordy
4. Zwraca paragon do klienta.

Paragon potwierdza zarówno zakup klienta, jak i aktualność systemu magazynowego. Ten typ systemu zapasów wymaga dużej spójności wszystkich transakcji. W tym sensie silna spójność odnosi się do tego, że cały dostęp do zapasów Twojego sklepu jest przetwarzany sekwencyjnie i odczytywany z tego samego stanu w systemie zapasów Twojego sklepu. Dobra wiadomość, właściciel sklepu! Biznes książkowy kwitnie, a Ty otwierasz wiele sklepów, aby dotrzeć do rosnącej bazy klientów. Jak na tym świecie utrzymujesz zapasy swojej firmy w wielu sklepach? Może rozważasz przeprojektowanie swojego obecnego systemu. Postanawiasz mieć jeden rejestr główny w Twoim pierwszym sklepie. Wtedy wszystkie inne twoje sklepy będą miały nowy rejestr, który łączy się z masterem. Ten nowy system działał świetnie … dopóki nie stracisz zasilania w swoim rejestrze głównym. Teraz wszyscy klienci we wszystkich Twoich sklepach nie mogą dokonać jednego zakupu. Twoje wiersze są długie i nieruchome. Czy pozwolisz swoim klientom odejść sfrustrowany, gdy kolejka trwa zbyt długo? Aby rozwiązać ten problem, być może zdecydujesz, że weryfikację i aktualizację zapasów Twojego sklepu można wykonać w inny sposób. Może tym razem rozważysz codzienne aktualizowanie ksiąg rachunkowych. W tym nowym systemie, podczas nocnego zamknięcia, aktualizujesz stan swoich książek, licząc je wszystkie w każdym sklepie i sprawdzając, czy każdy oczekiwany tytuł znajduje się na Twoich półkach. Każdej nocy Twoje półki sklepowe przechodzą testy, a Ty możesz wrócić do domu, mając pewność, że Twoje książki są zrównoważone. Ten drugi rodzaj systemu zapasów planuje dla wszystkich transakcji, aby zachować ostateczną spójność. Każdy dostęp do inwentarza Twojego sklepu jest przetwarzany równolegle i rejestruje aktualizację w systemie inwentaryzacji Twojej książki. Ostatecznie każdy dostęp do określonej książki zwróci ostatnią zaktualizowaną wartość. A co się stanie, jeśli klient zacznie szukać tytułu, którego nie ma na twoich półkach? Cóż, możesz się tym zająć. Rozwiązywanie niespójności po ich znalezieniu przypomina naprawę odczytu w systemie rozproszonym. Dopiero po znalezieniu niespójności rozpoczyna się cięższy proces aktualizacji stanu we wszystkich księgach. Podczas tego procesu możesz sprawdzić swoje dzienniki sprzedaży, aby sprawdzić, czy zapisy nie są aktualne. Wynikiem tych wielokrotnych inspekcji stanu byłoby upewnienie się, że twoje dane są aktualne i spójne. Czy ten proces jest dla Ciebie wystarczająco dobry? W przypadku systemów, które muszą handlować przetwarzaniem dużych ilości danych w celu uzyskania spójności stanu, tak. Zamiana na ostatecznie spójny system z naprawą odczytu w celu usunięcia niespójności uchroni Twoich klientów przed niebezpieczeństwem długich linii przy kasie. Dzięki temu architekci będą mniej stresować się ochroną dostępności bazy danych rejestru głównego. Mówiąc ogólnie, te dwa podejścia do prowadzenia inwentarza w Twojej księgarni reprezentują dwie różne szkoły myślenia. Opisują dwie różne architektury: jedną, która jest silnie spójna (skala adresowania z architekturami w stylu serwer-klient) i druga, która jest ostatecznie spójna (obsługa transakcji o dużej objętości i rozwiązywanie niespójności stanowych kiedy zostaną znalezione). Więc dla systemu, który projektujesz, z jaką szkołą myślenia chcesz zaplanować?

Siedem rzeczy, na które inżynierowie danych muszą uważać w projektach ML

87% projektów uczenia maszynowego (ML) kończy się niepowodzeniem! Tu omówiono siedem najważniejszych rzeczy, które z punktu widzenia inżynierii danych zaobserwowano w projekcie ML. Lista jest posortowana w porządku malejącym na podstawie liczby napotkanych problemów pomnożonej przez wpływ zdarzenia na cały projekt.

1. Myślałem, że ten atrybut zestawu danych oznacza coś innego. Przed erą big data dane były poddawane selekcji przed dodaniem do centralnej hurtowni danych. Nazywa się to schematem przy zapisie. Obecnie podejście z jeziorami danych polega na najpierw agregacji danych, a następnie wywnioskowaniu ich znaczenia w momencie ich wykorzystania. Nazywa się to schematem przy odczycie. Jako inżynier danych uważaj na używanie zestawów danych bez odpowiedniej dokumentacji szczegółów atrybutów lub wyraźnego stewarda odpowiedzialnego za aktualizowanie szczegółów!
2. Istnieje pięć definicji tego samego miernika biznesowego - których powinienem użyć? Pochodne dane lub metryki mogą mieć wiele źródeł prawdy! Na przykład widziałem nawet podstawowe metryki, takie jak liczba nowych klientów, mające wiele definicji w różnych jednostkach biznesowych. Jako inżynier danych, jeśli metryka biznesowa jest używana w modelu, poszukaj wszystkich dostępnych definicji i odpowiadających im definicji wdrożenia ETL.
3. Wygląda na to, że zmienił się schemat źródła danych. Ten jest niezwykle powszechny w dużych rozproszonych zespołach. Zmiany schematu w źródłowej bazie danych zwykle nie są koordynowane z dalszymi zespołami przetwarzającymi ETL. Zmiany mogą wahać się od zmian schematu (przerywanie istniejących potoków) na zmiany semantyczne, które są niezwykle trudne do debugowania. Ponadto, gdy metryki biznesowe ulegają zmianie, definicjom biznesowym brakuje wersji, co sprawia, że dane historyczne są niespójne.
4. Logika potoku ETL do trenowania i obsługi jest identyczna - nie do końca! Typowym powodem pochylenia wydajności modelu podczas uczenia i wnioskowania są rozbieżności w trenowaniu i obsłudze potoków. Chociaż logika może zacząć się identycznie, poprawki wprowadzone w jednym potoku mogą nie zostać odzwierciedlone w drugim. W szczególności unikaj scenariuszy, w których potoki szkolenia i obsługi są napisane w różnych językach.
5. Powolne zatruwanie modeli. Łatwiej jest wykryć błędy 0-1 w przypadku potoków danych. Najtrudniejsze problemy do debugowania to te, w których tabela jest sporadycznie aktualizowana lub dołącza do tabel, które nie są poprawnie aktualizowane. W takich scenariuszach modele będą się stopniowo degradować i dostosowywać do zmian. Kluczem jest zbudowanie odpowiednich wyłączników do wykrywania i zapobiegania złej jakości danych podczas ich przyjmowania.
6. Wszystkie zbiory danych zarządzane przez dany zespół mają tę samą jakość. To klasyczny błąd. Nie wszystkie zbiory danych z tego samego zespołu mogą być wiarygodne. Niektóre są aktualizowane i zarządzane bardzo dokładnie, podczas gdy inne mogą być aktualizowane nieregularnie lub mają źle napisane potoki ETL! Zawsze opracowuj reguły walidacji dla wszelkich danych wejściowych wykorzystywanych przez modele.
7. Systematyczne problemy z danymi powodują stronniczość w całym zbiorze danych. Jeśli błędy w zestawie danych są losowe, są mniej szkodliwe dla uczenia modelu. Ale błąd, który powoduje systematyczny brak określonego wiersza lub kolumny, może prowadzić do błędu w zestawie danych. Na przykład, jeśli z powodu błędu brakuje szczegółów urządzenia o kliknięciach klientów dla użytkowników Androida, zbiór danych będzie stronniczy pod kątem aktywności użytkowników iPhone′a. Podobnie ważne jest śledzenie nagłych zmian rozkładu danych. Podsumowując, uważam, że projekty ML to sport zespołowy, w którym biorą udział inżynierowie danych, badacze danych, statystycy, inżynierowie DataOps/MLOps i eksperci z dziedziny biznesu. Każdy gracz musi odegrać swoją rolę w sukcesie projektu.

Trzy koncepcje programowania rozproszonego, o których należy pamiętać przy wyborze platformy Open Source.

Wielu inżynierów danych tworzy potoki do operacji wyodrębniania, przekształcania i ładowania (ETL) lub wyodrębniania, ładowania i przekształcania (ELT). Podczas zadania transformacji (T) możesz pracować z danymi, które mieszczą się w pamięci jednego komputera. Jednak często dane będą wymagały użycia platform/rozwiązań, które wykorzystują rozproszone obliczenia równoległe, aby osiągnąć pożądany cel. Aby to wspierać, wielu badaczy opracowało modele programowania i obliczeń rozproszonych zawarte w znanych frameworkach, takich jak Apache Spark, Apache Cassandra, Apache Kafka, TensorFlow i wiele innych. Przyjrzyjmy się trzem najczęściej używanym modelom programowania rozproszonego do analizy danych i rozproszonego uczenia maszynowego.

Algorytm MapReduce

MapReduce to algorytm obliczeń rozproszonych opracowany przez Google w 2004 roku. Jako programiści określamy funkcję mapy, która przetwarza parę klucz/wartość w celu wygenerowania zestawu pośrednich par klucz/wartość, oraz funkcję redukcji, która łączy wszystkie wartości pośrednie powiązane z ten sam klucz pośredni. Takie podejście jest rozszerzeniem strategii split-apply-combine do analizy danych. W praktyce każde zadanie jest podzielone na wiele map i ogranicza funkcje. Dane są dystrybuowane na wiele węzłów/maszyn, a każda porcja danych jest przetwarzana w węźle. Funkcja logiczna jest stosowana do danych w tym węźle, a później operacja zmniejszania łączy dane za pomocą mechanizmu losowego. W tym procesie węzły redystrybuują dane w oparciu o klawisz funkcyjny mapy wynikowej. Później możemy zastosować więcej logiki do połączonych danych lub w razie potrzeby przejść do kolejnej rundy podziału-zastosuj-łącz. Rozwiązania typu open source wdrażające te koncepcje to Apache Spark, Hadoop MapReduce, Apache Flink i inne.

Model rozproszonej pamięci współdzielonej

Modele pamięci współdzielonej wywodzą się z systemów operacyjnych, takich jak POSIX i Microsoft Windows, w których procesy działające na tej samej maszynie musiały komunikować się we wspólnej przestrzeni adresowej. Modele rozproszonej pamięci współdzielonej starają się odpowiedzieć na tę samą potrzebę. W środowisku rozproszonym wiele węzłów/użytkowników komunikuje się przez sieć i potrzebuje dostępu do tych samych danych z różnych maszyn. Obecnie nie ma jednej partycjonowanej globalnej przestrzeni adresowej. Jednak bazy danych pamięci stanowią odpowiedź na tę potrzebę, przestrzegając wielu poziomów spójności danych. Pozwala to na rozproszoną operację programowania na danych, w której procesy mogą zapisywać i odczytywać. Dostępne rozwiązania typu open source zapewniające funkcje bazy danych w pamięci to Redis, Apache Ignite, Hazelcast In-memory Data Grid (IMDG) i inne.

Model przekazywania wiadomości/aktorów

Aktorzy to wątki/obiekty, które hermetyzują stan i zachowanie. Komunikują się wyłącznie poprzez asynchroniczną wymianę wiadomości, które są umieszczane w skrzynce pocztowej odbiorcy. Pozwalają na przepływ komunikacji/wiadomości bez zamków i blokad. Budowanie rozproszonego systemu obliczeniowego w oparciu o ten model ma przywilej unikania blokad. Wybierając w tym celu rozwiązania typu open source, sprawdź, czy nie ma gwarancji wiadomości. Czy możesz zagwarantować, że wiadomości zostaną dostarczone co najwyżej raz? Przynajmniej pewnego razu? Dokładnie raz? Wpłynie to na działanie Twojego systemu. Rozwiązania typu open source, które to implementują, to Apache Kafka, Aache Pulsar i inne.

Wnioski

Teraz, gdy znasz już te koncepcje, możesz zacząć rozumieć szerszy obraz architektur danych i gdzie każda z tych koncepcji wchodzi w grę.