Dlaczego zespoły danych mają problemy z weryfikacją danych (i jak to zmienić)

Uwaga edytora: ten artykuł został pierwotnie opublikowany na blogu Iteratively 18 grudnia 2020 r.

Znasz stare powiedzenie: „Śmieci na wejściu, śmieci na wyjściu”? Prawdopodobnie słyszałeś to zdanie w odniesieniu do higieny danych. Ale jak naprawić śmieci, które są złym zarządzaniem i jakością danych? Cóż, to trudne. Zwłaszcza jeśli nie masz kontroli nad implementacją kodu śledzącego (jak ma to miejsce w przypadku wielu zespołów danych).

Jednak to, że potencjalni klienci danych nie są właścicielami swojego potoku od projektu danych do zatwierdzenia, nie oznacza, że ​​cała nadzieja jest stracona. Jako pomost między odbiorcami danych (m.in. menedżerami produktów, zespołami ds. produktów i analitykami) a producentami danych (inżynierami) możesz pomóc w opracowaniu i zarządzaniu walidacją danych, która poprawi ogólną higienę danych.

Zanim przejdziemy do sedna, kiedy mówimy o walidacji danych, mamy na myśli proces i techniki, które pomagają zespołom ds. danych w utrzymaniu jakości ich danych.

Przyjrzyjmy się teraz, dlaczego zespoły danych mają problemy z tą weryfikacją i jak mogą przezwyciężyć jej wyzwania.

Po pierwsze, dlaczego zespoły zajmujące się danymi mają trudności z weryfikacją danych?

Istnieją trzy główne powody, dla których zespoły ds. danych mają trudności z weryfikacją danych do celów analitycznych:

1. Często nie są oni bezpośrednio zaangażowani we wdrażanie kodu śledzenia zdarzeń i rozwiązywanie problemów , co sprawia, że ​​zespoły ds. danych mają bardziej Często nie istnieją ustandaryzowane procesy dotyczące sprawdzania poprawności danych do celów analitycznych , co oznacza, że ​​testowanie jest zdane na łaskę niespójnych kontroli jakości.
2. Zespoły danych i inżynierowie polegają na reaktywnych technikach walidacji, a nie na proaktywnych metodach walidacji danych , co nie eliminuje podstawowych problemów związanych z higieną danych.

Każde z tych trzech wyzwań wystarczy, aby sfrustrować nawet najlepszego leada danych (i zespół, który go wspiera). I ma sens, dlaczego: Słaba jakość danych jest nie tylko kosztowna — według IBM złe dane kosztują średnio 3 biliony dolarów . W całej organizacji podkopuje to również zaufanie do samych danych i powoduje, że zespoły zajmujące się danymi i inżynierowie tracą godziny produktywności na usuwanie błędów.

Morał tej historii jest? Nikt nie wygrywa, gdy walidacja danych jest odkładana na dalszy plan.

Na szczęście te wyzwania można przezwyciężyć dzięki dobrym praktykom sprawdzania poprawności danych. Przyjrzyjmy się bliżej każdemu punktowi bólu.

Zespoły danych często nie kontrolują samego gromadzenia danych

Jak powiedzieliśmy powyżej, głównym powodem, dla którego zespoły danych mają problemy z weryfikacją danych, jest to, że to nie one przeprowadzają instrumentację śledzenia zdarzeń, o których mowa (w najlepszym przypadku widzą problem, ale nie mogą go naprawić ).

To pozostawia analityków danych i menedżerów produktów, a także każdego, kto chce, aby ich podejmowanie decyzji było bardziej oparte na danych, obarczone jest zadaniem rozwikłania i oczyszczenia danych po fakcie. I nikt — i mamy na myśli nikogo — nie lubi rekreacyjnie przeglądać danych.

Ten problem jest szczególnie trudny do pokonania dla większości zespołów zajmujących się danymi, ponieważ niewiele osób na liście danych, poza inżynierami, ma umiejętności techniczne, aby samodzielnie przeprowadzać walidację danych. Silosy organizacyjne między producentami danych a odbiorcami danych sprawiają, że ten problem jest jeszcze bardziej wrażliwy. Aby temu zaradzić, liderzy danych muszą wspierać współpracę między zespołami, aby zapewnić czyste dane.

W końcu dane to sport zespołowy i nie wygrasz żadnego meczu, jeśli twoi gracze nie będą mogli ze sobą rozmawiać, trenować razem ani przeprowadzać burzy mózgów nad lepszymi zagraniami, aby uzyskać lepsze wyniki.

Instrumentacja danych i walidacja nie różnią się od siebie. Twoi konsumenci danych muszą współpracować z producentami danych, aby wprowadzać i egzekwować praktyki zarządzania danymi u źródła, w tym testowanie, które proaktywnie wykrywa problemy z danymi, zanim ktokolwiek przejmie obowiązki na dalszych etapach.

To prowadzi nas do następnego punktu.

Zespoły ds. danych (i ich organizacje) często nie mają ustalonych procesów dotyczących sprawdzania poprawności danych na potrzeby analiz

Twoi inżynierowie wiedzą, że testowanie kodu jest ważne. Nie każdemu może się to podobać, ale upewnienie się, że aplikacja działa zgodnie z oczekiwaniami, jest podstawową częścią dostarczania świetnych produktów.

Okazuje się, że upewnienie się, że kod analityczny zarówno zbiera, jak i dostarcza dane o zdarzeniach zgodnie z zamierzeniami, jest również kluczem do budowania i iteracji świetnego produktu.

Więc gdzie jest rozłączenie? Praktyka testowania danych analitycznych jest wciąż stosunkowo nowa w zespołach inżynierskich i zajmujących się danymi. Zbyt często kod analityczny jest traktowany jako dodatek do funkcji, a nie podstawowa funkcjonalność. To, w połączeniu z nijakimi praktykami zarządzania danymi, może oznaczać, że jest wdrażane sporadycznie we wszystkich obszarach (lub wcale).

Mówiąc najprościej, dzieje się tak często dlatego, że osoby spoza zespołu danych nie rozumieją jeszcze, jak cenne są dane zdarzeń w ich codziennej pracy. Nie wiedzą, że czyste dane zdarzeń to drzewo pieniędzy na ich podwórku i że wszystko, co muszą zrobić, to regularnie je podlewać (sprawdzać), aby zarobić.

Aby wszyscy zrozumieli, że muszą dbać o drzewo pieniędzy, czyli dane o zdarzeniach, zespoły ds. danych muszą poznać wszystkie sposoby wykorzystania dobrze zweryfikowanych danych w całej organizacji. Chociaż zespoły ds. danych mogą być ograniczone i odizolowane w swoich organizacjach, ostatecznie to ci mistrzowie danych muszą wykonać pracę, aby przełamać bariery między nimi a innymi interesariuszami, aby zapewnić odpowiednie procesy i narzędzia w celu poprawy jakości danych.

Aby przezwyciężyć ten dziki zachód zarządzania danymi i zapewnić właściwe zarządzanie danymi, zespoły danych muszą zbudować procesy, które określają, kiedy, gdzie i jak dane powinny być testowane proaktywnie. Może to brzmieć zniechęcająco, ale w rzeczywistości testowanie danych może bezproblemowo wpasować się w istniejący cykl życia oprogramowania (SDLC), narzędzia i potoki CI/CD.

Jasne procesy i instrukcje zarówno dla zespołu danych projektującego strategię danych, jak i zespołu inżynierów wdrażającego i testującego kod pomogą wszystkim zrozumieć dane wyjściowe i wejściowe, których powinni się spodziewać.

Zespoły danych i inżynierowie polegają raczej na reaktywnych niż proaktywnych technikach testowania danych

W prawie każdej dziedzinie życia lepiej jest być proaktywnym niż reaktywnym. Dotyczy to również sprawdzania poprawności danych do celów analitycznych.

Jednak wiele zespołów zajmujących się danymi i ich inżynierowie czują się uwięzieni w reaktywnych technikach sprawdzania poprawności danych. Bez solidnego zarządzania danymi, narzędzi i procesów, które ułatwiają proaktywne testowanie, śledzenie zdarzeń często musi zostać zaimplementowane i szybko wysłane, aby mogło zostać uwzględnione w wersji (lub dodane z mocą wsteczną po jednym opublikowaniu). Zmusza to liderów danych i ich zespoły do ​​stosowania technik, takich jak wykrywanie anomalii lub transformacja danych po fakcie.

Takie podejście nie tylko nie rozwiązuje głównego problemu z błędnymi danymi, ale kosztuje inżynierów danych wiele godzin ich czasu na usuwanie błędów. Kosztuje to również analityków wiele godzin poświęconych na czyszczenie błędnych danych i utratę przychodów ze wszystkich ulepszeń produktów, które mogłyby mieć miejsce, gdyby dane były lepsze.

Zamiast pozostawać w ciągłym stanie nadrabiania danych, liderzy danych muszą pomagać w kształtowaniu procesów zarządzania danymi, które obejmują proaktywne testowanie na wczesnym etapie oraz narzędzia, które zawierają bariery ochronne, takie jak bezpieczeństwo typów, w celu poprawy jakości danych i zmniejszenia liczby poprawek na późniejszym etapie.

Jakie są więc proaktywne środki weryfikacji danych? Spójrzmy.

Metody i techniki walidacji danych

Proaktywna walidacja danych oznacza stosowanie odpowiednich narzędzi i procesów testowania na każdym etapie potoku danych:

• W kliencie z narzędziami takimi jak Amplitude, aby wykorzystać bezpieczeństwo typów, testy jednostkowe i testy A/B.
• W przygotowaniu z narzędziami takimi jak Amplitude, Segment Protocols i repozytorium schematów open-source Snowplow Iglu do sprawdzania poprawności schematów, a także inne narzędzia do testowania integracji i komponentów, testowania świeżości i testów dystrybucji.
• W magazynie z narzędziami takimi jak dbt, Dataform i Great Expectations, aby wykorzystać schematyzację, testy bezpieczeństwa, testowanie relacji, testowanie świeżości i dystrybucji oraz sprawdzanie zakresu i typu.

Gdy zespoły ds. danych aktywnie utrzymują i egzekwują proaktywne środki weryfikacji danych, mogą zapewnić, że gromadzone dane są użyteczne, jasne i czyste oraz że wszyscy posiadacze danych rozumieją, jak je zachować.

Co więcej, wyzwania związane z gromadzeniem danych, procesami i technikami testowania mogą być trudne do pokonania w pojedynkę, dlatego ważne jest, aby liderzy przełamywali organizacyjne silosy między zespołami ds. danych i zespołami inżynierskimi.

Jak zmienić walidację danych dla analityki na lepsze

Pierwszym krokiem w kierunku funkcjonalnych praktyk sprawdzania poprawności danych dla analityki jest uznanie, że dane to sport zespołowy , który wymaga inwestycji ze strony posiadaczy danych na każdym poziomie, niezależnie od tego, czy chodzi o Ciebie, jako lidera danych, czy przez Twojego indywidualnego inżyniera wdrażającego linie kodu śledzenia.

Wszyscy w organizacji odnoszą korzyści z dobrego gromadzenia i sprawdzania poprawności danych, od klienta po hurtownię.

Aby to prowadzić, potrzebujesz trzech rzeczy:

1. Odgórne wytyczne od kierowników ds. danych i kierownictwa firmy , które ustanawiają procesy utrzymywania i wykorzystywania danych w całej firmie
2. Ewangelizacja danych na wszystkich poziomach firmy , aby każdy zespół zrozumiał, w jaki sposób dane pomagają im lepiej wykonywać pracę i jak regularne testowanie to wspiera
3. Przepływy pracy i narzędzia do dobrego zarządzania danymi , niezależnie od tego, czy jest to narzędzie wewnętrzne, połączenie narzędzi, takich jak protokoły segmentowe lub pług śnieżny i dbt, czy nawet lepiej, wbudowana platforma analityczna, taka jak Amplitude. Na każdym z tych etapów ważne jest również, aby liderzy ds. danych dzielili się zwycięstwami i postępami w kierunku doskonałych danych wcześnie i często. Ta przejrzystość nie tylko pomoże konsumentom danych zobaczyć, jak mogą lepiej wykorzystywać dane, ale także pomoże producentom danych (np. inżynierom przeprowadzającym testy) zobaczyć owoce ich pracy. To wygrana-wygrana.

Pokonaj problemy z weryfikacją danych

Walidacja danych jest trudna dla zespołów zajmujących się danymi, ponieważ konsumenci danych nie mogą kontrolować implementacji, producenci danych nie rozumieją, dlaczego implementacja ma znaczenie, a fragmentaryczne techniki walidacji sprawiają, że wszyscy reagują na złe dane, zamiast im zapobiegać. Ale tak nie musi być.

Zespoły ds. danych (i inżynierowie, którzy je wspierają) mogą przezwyciężyć problemy z jakością danych, współpracując, wykorzystując wielofunkcyjność dobrych danych i korzystając z doskonałych narzędzi, które ułatwiają zarządzanie danymi i testowanie.