Od zera do bohatera #1: Zrozum dane, które przetwarzasz. Przykład z życia

Jest to pierwszy artykuł z serii Od zera do bohatera. W tej serii chciałbym trochę wprowadzić Cię w świat przetwarzania danych. Całość ubieram w serię artykułów, które będą przeplatane innymi wpisami, ale dzięki temu łatwo będzie Ci odnaleźć całą serię na blogu.

W samych artykułach będę bazował zarówno na swoim doświadczeniu, jak i tym, czego aktualnie się uczę. Wierzę, że te kilkanaście lat zaowocowało wypracowanymi, dobrymi praktykami wyniesionymi z “placu boju” 🙂

Na pewno potrzebujemy trochę wprowadzenia (niezbędne minimum teorii), aby z czasem trochę “pobrudzić sobie ręce”, tworząc swoje przepływy danych.

Zacznijmy od przykładu – co się dzieje, gdy nie rozumiesz danych, które przetwarzasz.

Konsekwencje braku zrozumienia danych – przykład z życia

Dla jednego z banków inwestycyjnych tworzyliśmy system integrujący dane referencyjne z tzw. złotych źródeł (ang. golden sources). W założeniu jest to najlepsze źródło danych z danej domeny. W naszym przypadku były to m.in. tzw. księgi (ang. books), produkt (ang. products) oraz instrumenty (ang. instruments). W samym systemie był ustalony interfejs wymiany danych (o tym będzie bardziej szczegółowo w którymś z kolejnych artykułów).

W pierwszym kroku poprosiliśmy właścicieli danych o tzw. słownik danych. Znowu – będę o tym pisał osobno artykuł, ale na potrzeby tego wpisu uznajmy, że jest to taki zbiór informacji o danych, tzw. metadane. Inaczej mówiąc – są to dane o danych.

Okazało się, że taki słownik posiadają, więc to już był mały sukces 🙂 Jednym z atrybutów takiego słownika jest typ przetwarzanych atrybutów. Mnie jako konsumenta danych nie powinno interesować, jak system trzyma te dane u siebie wewnętrznie. Dla mnie istotna jest informacja, jakie dane my dostaniemy i co w nich jest.

Słownik danych, który otrzymaliśmy zawierał Oraclowe typy danych, co wskazywałoby na dużą precyzję. Typy te często przechowują np. maksymalną długość pola. Zdecydowanie ułatwiło to nam modelowanie danych po naszej stronie, bo także używaliśmy bazy danych Oracle. Robota wydawała się łatwa, prosta i przyjemna… do czasu, aż nie napotkaliśmy na różne dziwne przypadków.

Nieprecyzyjne typy danych

Jednym z nich były atrybuty z sufiksem _flag (co sugeruje na flagę lub indykator) i typem VARCHAR2(4000). Dla osób niezaznajomionych z tematyką – w uproszczeniu, typ ten określa, że pole może mieć maksymalnie 4000 znaków.

Zdecydowanie nam się to nie zgadzało – 4000 znaków dla flagi, która z reguły może być jednoznakowa 1/0, Y/N lub po polsku T/N. Nawet jeżeli będzie to pełny wyraz YES/NO i po uwzględnieniu wartości nieznanej, np. UNKNOWN. Nic, co by się zbliżało do 4000. Takie “nieścisłości” mają swoje konsekwencje i powodują różne problemy. Wymienię dwa.

Po pierwsze. Co z tym dalej robić? Z jednej strony, mamy bardzo precyzyjne typy danych, czyli powinniśmy oczekiwać bardzo dokładnych informacji o danych. Z drugiej strony, dostarczona informacja kompletnie nam nic nie mówi. Jeżeli system nie był nam w stanie wyjaśnić, dlaczego tam jest 4000, to też nie moglibyśmy być pewni, że wartości, które teraz się tam znajdują (Y/N) nie zmienią się zaraz na coś bardziej opisowego.

Po drugie. Nawet jeżeli dojdziemy do tego, jaki powinien być typ tych atrybutów, to co powinniśmy zrobić dalej? W teorii powinniśmy zamodelować dane tak jak dostarcza je właściciel. Staliśmy przed dylematem. Czy zostawić to w takiej formie i tłumaczyć się przed konsumentami naszych danych? Czy może doprecyzować typ u siebie i brać odpowiedzialność jeżeli dane się zmienią?

Jak sobie poradziliśmy?

Postanowiłem wybrać jeszcze inną opcję i trochę powalczyć o jakość tych danych. Musieliśmy to zrobić w uzgodnieniu z systemem źródłowym, ponieważ my za te dane nie odpowiadamy, a propagowaliśmy je dalej do naszych konsumentów.

Po długich rozmowach zgodzili się, że coś jest nie tak i zmienili typ danych na… VARCHAR2(10). A dalej wysyłali Y/N (sic!), argumentując – bo może się zmieni w przyszłości.

Możesz powiedzieć, to tylko jedno pole, czepia się. Zrobiłby 4000 u siebie i tyle. Nie do końca… Jak wspomniałem, później dane, które nasz system pobierał i przetwarzał, będzie udostępniał dalej. I co mieliśmy powiedzieć konsumentom naszych danych? Żeby też nie marudzili i oczekiwali czegokolwiek? 🙂

I jeszcze raz – nie chodzi tak bardzo o typ pola przechowywanego w bazie, bo to nie jest najbardziej istotne. Pobierając dane, musisz wiedzieć czego oczekiwać, ponieważ najprawdopodobniej na tych danych będzie implementowana logika biznesowa.

Problemów często pojawia się więcej

To jest jeden z wielu problemów z danymi, które poruszyliśmy w tamtym projekcie. Przywołałem akurat ten, bo był dość obrazowy. Dodatkowo jeżeli trafiacie na coś takiego, to można mieć spore wątpliwości co do jakości i zrozumienia danych po stronie systemu źródłowego.

Często w ogóle brakuje bliższych informacji o danych. Zdarzało się, że system źródłowy nie posiadał żadnego słownika danych, ani nic co by go przypominało. Z racji, że dane pobieraliśmy przez RESTowe API, w wielu z tych przypadków byliśmy odsyłani do plików XSD (XML Schema) lub ich odpowiedników dla plików typu JSON. O tym sobie jeszcze trochę opowiemy, ale z założenia pliki te mają za zadanie zdefiniować strukturę danych. Jest to jakiś częściowy substytut słownika, ale nie dostarcza wszystkich potrzebnych informacji biznesowych.

Potencjalnie mogłoby to nam pomóc, ale w większości przypadków, pliki te były stworzone bez uzupełnienia wszystkich atrybutów, np. brakowało informacji o liczbie wystąpień danych atrybutów lub całych encji/obiektów.

Przykładowo (abstrahując od omawianego projektu) z takiego pliku dowiecie się, że np. jeden klient może posiadać adres (obiekt złożony z kilku atrybutów). Nie wiecie natomiast (jeżeli tej informacji brakuje) czy tych adresów może być więcej, czy tylko jeden. A może to pole jest opcjonalne?

To wszystko powodowało, że analiza danych była mocno utrudniona. Mając to na uwadze, pamiętaj, że system, nad którym pracujesz, może być źródłem danych dla innych systemów. Warto więc zadbać o jakość i odpowiedni opis danych.

Po co osoba techniczna ma rozumieć dane?

Staram się kłaść duży nacisk na zrozumienie tego co robimy. Nie inaczej jest w tym przypadku. Jest to przekonanie, które wyniosłem z doświadczenia w różnych projektach.

Trochę więcej pisałem o tym w artykule: Technologia to jedynie narzędzie. Jeżeli Cię to nie przekonuje, to spójrz proszę na zwinne metodyki prowadzenia projektów. One również zakładają sporą interdyscyplinarność w zespole i rozumienie tego co robimy. Z implementacją bywa już różnie, ale widać trend.

Zwróć uwagę, jak rozwijają się dzisiaj języki programowania. Przykładowo – w obszarze przetwarzania danych odgrywa znaczną rolę Python. Oprócz wielu innych zalet dostarcza mnóstwo bibliotek, których z każdym dniem przybywa. W dużym uproszczeniu można by rzec, że Tobie, jako programiście pozostaje “tylko” odpowiednio ich użyć.

Dodatkowo z pomocą chmur obliczeniowych, idziemy mocno w “usługowość”. Pojawia się mnóstwo usług, które niejako są gotowe do użycia.

Skrajnym, ale realnym przykładem jest tutaj trend no-code oraz low-code, czyli dążenie, aby aplikacje np. PoC (wyjaśnienie terminu poniżej, w sekcji ITmowa) były tworzone bez lub przy minimalnym użyciu kodu.

Wszelkie ułatwienia w tym obszarze są podyktowane szybkością tworzenia rozwiązań. Czy to znaczy, że wymagamy mniej od specjalistów? Moim zdaniem, zdecydowanie nie. Wymagamy po prostu innych umiejętności.

Bądź jak Mr. Wolf i rozwiązuj probemy

Wiem, że może trochę to upraszczam, ale zależy mi, abyś zwrócić Twoją uwagę na trend. A ten moim zdaniem jest jednoznaczny – w cenie są ludzie, którzy potrafią dany problem zrozumieć i rozwiązać, stosując odpowiednie narzędzia. Niczym Mr. Wolf z Pulp Fiction 🙂

Nawiasem mówiąc, ta scena dobrze obrazuje jeden ze stylów zarządzania. Ale o tym może innym razem 🙂

Tymczasem, zastanówmy się, po co to wszystko.

Zadajmy fundamentalne pytanie – po co przetwarzać dane?

Abstrahując od technologii, przetwarzając i analizując dane, szukamy informacji, które mogą nam się przydać. Jeżeli zaczniemy analizować ten proces od strony teoretycznej, to natrafimy na tzw. hierarchię pojęć poznawczych: DIKW (Data -> Information -> Knowledge -> Wisdom)

Jeżeli ktoś jest zainteresowany teoretyczną stroną tego rozważania, to odsyłam do artykułu naukowego Dane, informacja, wiedza – próba definicji, autorstwa Pani Agnieszki Zając i Pana Mariusza Grabowskiego z Katedry Informatycznej, Uniwersytetu Ekonomicznego w Krakowie.

A co na to praktyka?

Najprościej rzecz ujmując, przetwarzamy dane po to, aby wyciągnąć z nich informacje, które dają nam wartość. I teraz pytane – co to będzie w Twoim przypadku? W momencie, kiedy nie znam Twojego biznesu lub problemu do rozwiązania, to jedyna słuszna odpowiedź jest: nie mam pojęcia! Moim zdaniem, próba udzielenia innej odpowiedzi byłaby na poziomie wciskania magicznych garnków starszym osobom na różnego rodzaju wydarzeniach.

Dostępnych danych możesz mieć mnóstwo, ale musisz wiedzieć, czego oczekujesz po ich przetworzeniu i przeanalizowaniu. Na inne pytania możesz chcieć sobie odpowiedzieć analizując dane dla sklepu internetowego sprzedającego kawę, inne dla firmy działającej w branży farmaceutycznej, a jeszcze inne dla instytucji finansowych podlegających regulacjom.

A co gdy nie wiem, co chce analizować?

Jeżeli jesteś osobą z tzw. biznesu, to… nie dobrze 🙂 Bo właśnie Ty jesteś osobą odpowiedzialną za wskazanie czego potrzebujesz. A jeżeli jesteś inżynierem danych, to warto przecież wiedzieć, po co robisz to co robisz.

Wiedza o tym co chcesz osiągnąć, pozwoli Ci dobrać odpowiednie narzędzia, aby efektywnie zaplanować i zaimplementować cały proces oraz dane, które są do tego niezbędne.

Istnieją narzędzia, które od strony technicznej pomagają nam zrozumieć dane, poprzez ich profilowanie (ang. Data profiling). Nie zastąpią one jednak zrozumienia tego, czego oczekuje Twój klient.

Dodatkowo istnieją również metody eksploracji danych, które pozwalają nam np. znaleźć zależności, które trudno byłoby dostrzec “gołym okiem”. Natomiast nie zwalnia nas to ze zrozumienia tego, co przetwarzamy. Ba! Jest to wymagane, żeby taki proces przeprowadzić.

Przykład – coś prostego na początek

Wyobraź sobie sytuację, że robisz projekt dla firmy prowadzącej sklep internetowy z kawą z całego świata. Nie wnikam tutaj jakie funkcjonalności mają silniki sklepów internetowych. Na potrzeby naszych analiz, załóżmy, że marne. Masz bazę danych produktów, cen, transakcji, dane użytkowników oraz dostawców itp. Jakie informacje były dla Ciebie cenne? Pewnie najlepiej zapytać osobę, która zna się na tym biznesie, ale jest kilka rzeczy, które przychodzą automatycznie do głowy.

Moim zdaniem, warto byłoby wiedzieć, jak produkty się ze sobą łączą. Mam na myśli to, że jeżeli ktoś wybierze produkt X, to system mu podpowie, że klienci często wybierają produkt Y. Tu ma zastosowanie eksploracja danych.

Oczywiście jeżeli taka firma ma kilka oddziałów i magazynów, to tutaj możemy zbudować system OLAPowy, dzięki którym będziemy mogli analizować dane po różnym kątem: skąd pochodzą zamówienia, jak to wygląda w poszczególnych oddziałach. Będziemy mogli analizować przychody i koszty używając różnych wymiarów, np. czasu.

Oczywiście możemy wyobrazić sobie ciekawsze analizy jak np. próba ustalenia, w którym miejscu otworzyć punkt detaliczny. Wykorzystamy dane, którymi dysponujemy, wzbogacając je np. o dane demograficzne i zarobki w Polsce. Ponadto, możemy uwzględnić ceny najmu lub zakupu lokali użytkowych.

Sklep internetowy jest dość prostym do zrozumienia przykładem. Natomiast już tutaj widać, że warto rozumieć domenę biznesową, w której się poruszamy.

Podsumowanie

Jest to wpis wprowadzający do serii, gdzie zaczniemy pracować nad przetwarzaniem danych. Chciałbym, żebyś po przeczytaniu tego artykułu zapamiętał, że warto rozumieć dane, które przetwarzasz. Nie musisz być specjalistą z danej branży, ale powinieneś blisko współpracować z osobą, która takim specjalistą jest.

Zachęcam do tego, ponieważ doświadczenie podpowiada mi, że brak zrozumienia na linii: ludzie techniczni – biznes, prowadzi do nadmiernego przeciągania w swoją stronę. Osoby techniczne często skupione na swoim kawałku, gubią kontekst, w ramach którego się poruszają. Z kolei osoby biznesowe lub odpowiedzialne za zarządzanie danymi w organizacji mogą nie do końca “czuć” technikalia. Powoduje to, że czasem budują procedury, które bywają przerostem formy nad treścią.

Mam nadzieję, że znalazłeś tu informacje, którą pomogą Ci lepiej poruszać się w tym świecie. Jeżeli jest coś konkretnego, o czym chciał(a)byś przeczytać, to daj mi proszę znać w komentarzu lub mailowo.

W kolejnych artykułach z tej serii przybliżę m.in. jak wyglądają przykładowe procesy przetwarzania danych. Dowiesz jakie źródła danych możesz napotkać, gdzie te dane przechowujemy i co się z nimi później dzieje 🙂

---

Słowo na dziś z ITmowy

W kontekście IT – rozwiązanie możliwie minimalne, które ma za zadanie wykazać, że np. dana aplikacja jest możliwa do wykonania. Weryfikuje się przy tych również technologie, które mają zostać użyte.

To wyrażenie nie występuję jedynie w IT, ale jest często w tej branży używane. Poniżej przykłady użycia: