Zniszczona sonda kosmiczna o wartości 125 mln dolarów. Rozbity samolot pasażerski, w którym zabrakło paliwa. Jak mogło do tego dojść? W obu przypadkach przyczyną zdarzeń było niedbałe podejście do danych, które doprowadziło do katastrofy. Podstawą budowy systemów informatycznych, zwłaszcza tych integrujących dane z różnych źródeł, jest sprawdzenie ich integralności, czyli jakości. Nawet najlepszy system, zasilony błędnymi danymi, będzie bezużyteczny.
Organizacje chcą podejmować lepsze decyzje na podstawie zgromadzonych danych. W tym celu budują hurtownie danych i integrują w nich dane pochodzące z różnych źródeł, aby następnie je przetwarzać i wyciągać z nich wnioski. Warunkiem sukcesu jest odpowiednio duża liczba dobrej jakości danych. Im więcej danych i ich źródeł, tym większe jest to wyzwanie. Ale tylko wysokiej jakości dane wejściowe pozwolą na opracowanie rzetelnych raportów i podjęcie na ich podstawie prawidłowych decyzji.
Dlaczego jakość danych jest ważna?
Przy projektach o małej skali pomyłka jest dotkliwa, ale niezbyt kosztowna. W końcu korekta kilku błędnych faktur w miesiącu nie stanowi problemu. Trudności zaczynają się w przypadku projektów o dużej skali.
Boleśnie przekonali się o tym amerykańscy naukowcy, którzy w 1999 r. przez drobny błąd przypadkowo zniszczyli sondę badawczą Mars Climate Orbiter, wartą 125 mln dolarów. Jak to się stało? Odpowiedzialne za projekt dwa zespoły naukowców korzystały z różnych systemów miar: anglosaskiego i metrycznego. Spowodowało to błąd w obliczeniach, przez który sonda, zamiast przelecieć 150 km nad Marsem, zbliżyła się do niego na 60 km i prawdopodobnie spłonęła. Grupa doświadczonych i wykształconych na najlepszych uczelniach naukowców nie zauważyła, że część zespołu wykonywała obliczenia w kilometrach, a część w milach.
O ile katastrofa bezzałogowej sondy Mars Climate Orbiter to duża strata finansowa, to w przypadku pomyłki w lotnictwie stawką jest życie pasażerów. W 1983 r. w samolocie rejsowym Air Canada oba silniki wyłączyły się w połowie drogi do celu. Okazało się, że maszyna w ogóle nie ma paliwa. Jak do tego doszło? Przed wylotem zamiast 22 300 kg paliwa, które według obliczeń powinno zostać zatankowane na tę trasę, obsługa naziemna wlała… 22 300 funtów (10 115 kg), czyli zaledwie połowę.
Co było powodem pomyłki? Dokładnie w tamtym roku Kanada zrezygnowała z brytyjskiego systemu miar na rzecz metrycznego. Nowy samolot miał ustawione wskaźniki według nowego systemu miar, ale obsługa była przyzwyczajona do dawnych jednostek. Dodatkowo nastąpiła awaria systemu pomiarowego paliwa znajdującego się w zbiornikach, dlatego załoga samolotu nie dowiedziała się wcześniej o błędzie podczas tankowania.
To mogła być jedna z większych tragedii lotniczych, na szczęście doświadczony kapitan doleciał lotem ślizgowym na zamknięte lotnisko. Nikt z 70 osób znajdujących się na pokładzie nie zginął ani nie został poważnie ranny. Tak jak w przypadku kłopotów NASA, powodem była pomyłka w jednostkach – błąd rodem z lekcji fizyki w szkole podstawowej.
Do katastrofy, która również mogła zakończyć się tragicznie, doszło w 2003 r. w japońskim Disneylandzie. Podczas jazdy kolejki górskiej pękła oś w wagoniku. Zadziałały systemy bezpieczeństwa, więc obyło się bez rannych i ofiar. Dlaczego ta sytuacja w ogóle się wydarzyła? Okazało się, że nową oś zamawiano na podstawie planów technicznych z połowy lat 90., w których wymiary podano w calach. Niestety zamawiający część podali tę samą wartość, ale w centymetrach. W efekcie nowa oś była 2,5 razy cieńsza od oryginalnej i dlatego nie wytrzymała obciążeń.
Rodzajów błędów w zarządzaniu danymi mogą być dziesiątki: różnice w zaokrągleniach liczb, różne systemy pomiarowe (anglosaskie, metryczne, mieszane), błędne dane z czujników, różne formaty dat, błędy we wpisywaniu danych przez ludzi (np. powszechne błędy w dowodach rejestracyjnych), niezgodność formatów plików, itd. Im większy chaos w danych, tym większe błędy mogą wystąpić w obliczeniach.
Zadbaj o jakość danych
Jak zapewnić odpowiednią jakość danych, czyli upewnić się, że zbierane dane są prawidłowe, a podczas procesu ich integracji z różnych źródeł porównujesz ze sobą odpowiednie wartości? W dużej organizacji błędne decyzje, spowodowane przez nieprawidłowe dane, mogą kosztować miliony złotych, a w skrajnych przypadkach stanowić zagrożenie dla życia lub zdrowia ludzi.
Integralność danych (ang. data integrity) to własność, która wyklucza wprowadzenie do danych zmian w nieautoryzowany sposób, co może prowadzić do nieintencjonalnych błędów.
Oto 6 kroków do zapewnienia integralności danych:
1. Ewidencja źródeł danych
Pierwszym krokiem do zapewnienia integralności danych w organizacji jest przeprowadzenie analizy, w jaki sposób oraz z jakich systemów dostawcy mogą udostępnić nam dane. Dostawcami mogą być zarówno systemy funkcjonujące w organizacji, urządzenia połączone w ramach internetu rzeczy (zwłaszcza w branży produkcyjnej czy logistycznej), jak również firmy współpracujące (np. biura rachunkowe, operatorzy logistyczni) lub zewnętrzne czy niezależne źródła danych (np. ogólnodostępne informacje o prognozie pogody, bazy danych administracji publicznej, itp.).
Z pozoru taka ewidencja to dosyć oczywisty krok. W praktyce natomiast, wraz z rosnącą skalą działania organizacji, dane mogą pochodzić nawet z kilkudziesięciu czy kilkuset źródeł, przy czym nie zawsze idzie za tym odpowiedzialność za ich jakość.
2. Połączenie z systemem udostępniającym dane
Obecnie znaczna większość systemów informatycznych umożliwia wymianę danych pomiędzy aplikacjami różnych dostawców przez API. API standaryzuje i automatyzuje, a tym samym upraszcza ten proces.
W celu uzyskania danych z aplikacji należy się z nią najpierw połączyć. Z reguły proces uwierzytelniania nie jest skomplikowany, a dostawcy aplikacji oferują gotowe rozwiązania, np. logowanie albo wymiana tokenów.
Ważnym aspektem, który wpływa na udostępnienie danych, jest typ relacji, która łączy Cię z ich dostawcą. Jeśli jest to relacja partnerska, uregulowana umową, masz większy wpływ na sposób udostępniania czy zakres danych. Inaczej jest w sytuacji, gdy relacja jest niesymetryczna, np. jest to API publiczne. W tym wypadku dane są zależne od ich dostawcy, a ty nie masz wpływu na to, co jest udostępniane.
3. Pobieranie danych
Po uzyskaniu połączenia z dostawcą, następnym krokiem jest pobranie danych. Dane pobrane bezpośrednio od dostawcy często określane są jako tzw. „surowe dane” (ang. raw data), ponieważ nie zostały na razie poddane żadnym transformacjom.
Najpopularniejszym sposobem udostępniania danych są serwisy webowe, które umożliwiają pobranie danych przez użytkownika, za pośrednictwem odpowiednio zbudowanego zapytania wysłanego na wskazany adres URL. W palecie rozwiązań można również wymienić łączenie się z systemami bazodanowymi czy odtwarzanie baz danych na podstawie tak zwanych „zrzutów” (które stanowią obraz bazy danych w momencie wygenerowania zrzutu). Często jednak systemy udostępniają swoje dane poprzez ich eksport do plików płaskich (to sekwencyjny plik, w którym dane przechowywane są w sposób liniowy). Mogą być to pliki programu Excel czy pliki tekstowe.
W najgorszym wypadku system informatyczny nie udostępnia danych, a twórcy nie przewidzieli możliwości ich wyeksportowania, co wymusza konieczność użycia bardziej kreatywnych środków. Może to być np. „scraping” strony internetowej. Polega on na pobieraniu strony internetowej w taki sposób, w jaki robi to przeglądarka internetowa, z tym że zwrócone dane interpretujesz we własny sposób. Ważne zastrzeżenie: należy to robić zgodnie z obowiązującym prawem, aby nie łamać praw autorskich.
4. Przetwarzanie i sprawdzenie jakości danych
Posiadając surowe dane, możesz je w jakiś sposób przetworzyć. By móc poddać zgromadzone dane analizie, należy je najpierw zunifikować, czyli doprowadzić do stanu, w którym możliwe będzie ich porównanie czy wzajemne dopasowanie. Ten krok może być najbardziej pracochłonny.
Najbardziej widoczną różnicą pomiędzy danymi pochodzącymi z różnych systemów może być ich format. Jeśli nie jest on taki sam, rozpoznanie wartości, jaką niosą dane, może stanowić największe wyzwanie.
Przykładem może być zastosowanie różnych formatów zapisu daty w europejskich (DD/MM/RRRR) i anglosaskich aplikacjach (MM/DD/RRRR). Kolejnym – wspomniane wcześniej niespójności w jednostkach miary – nawet w obrębie systemu metrycznego jeden dostawca danych może podawać odległości w metrach (260 m), inny w kilometrach (0,26 km), itd. We wspomnianej historii z sondą NASA jeden zespół używał systemu metrycznego, natomiast drugi systemu anglosaskiego, w wyniku czego finalne obliczenia zawierały błąd o wartości blisko 90 km.
5. Wykorzystanie danych
Mając ujednolicone dane, które znajdują się w jednym miejscu (np. w hurtowni danych), możesz je zaimportować i połączyć z rozwiązaniami Business Intelligence, takimi jak Data Studio czy PowerBI. Pozwalają one stworzyć interaktywne dashboardy oraz raporty.
Posiadane dane mogą również stanowić nowe źródło danych, z którego będą korzystać inne narzędzia. Przykładem może być system biletowy budowany przez samorząd. Po zebraniu i ujednoliceniu danych od różnych podmiotów (przewoźników), można stworzyć nowy system, który w całości opiera się na zebranych danych (np. kompleksową aplikację integrującą informacje o różnych środkach transportu).
6. Walidacja danych
Walidacji danych, czyli ich weryfikacji, mogą przyświecać dwa cele. Pierwszy to identyfikacja danych, które niosą bezużyteczne wartości i zaburzają obraz całości. W tym wypadku warto przeprowadzić proces tak zwanego czyszczenia, czyli usunięcia danych odstających, ponieważ może to świadczyć o dokonaniu błędnego pomiaru czy przypadkowemu zagregowaniu błędnych danych.
Drugim celem może być weryfikacja danych, dzięki czemu upewniasz się, że obiekty, których dane dotyczą, działają prawidłowo. Na przykład, jeżeli supermarket monitoruje temperaturę w chłodniach przechowujących żywność i odnotowana zostanie temperatura o wartości -1000 st. C, oznacza to, że czujnik jest uszkodzony. Niesprawne urządzenie należy wymienić, a do czasu wymiany nie ujmować jego wartości w zestawieniu miesięcznym. Jest to jednocześnie przykład wartości nierealnej, ponieważ w przyrodzie nie jest możliwa temperatura poniżej zera absolutnego.
Zintegrowanie danych z niezależnych, budowanych w różnym czasie systemów, z jednej strony może przynosić dużą wartość biznesową, z drugiej może być poważnym wyzwaniem. Zasoby mogą nie tylko różnić się rozszerzeniem, ale również zawartością merytoryczną. W momencie, gdy uda Ci się z powodzeniem przeprowadzić cały proces od momentu pobrania danych do ich przetworzenia, zyskujesz możliwość dysponowania nowymi zasobami, które mogą stanowić fundament nowego oprogramowania lub podstawę do podejmowania bardziej przemyślanych decyzji biznesowych.
Opisane przez nas kroki, w przypadku złożonego projektu mogą oznaczać tygodnie, a nawet miesiące pracy zespołu analityków, programistów i specjalistów baz danych. W OChK mamy już doświadczenie w prowadzeniu takich projektów dla naszych klientów. Weryfikacja i integracja źródeł danych była fundamentem do budowy i dalszego rozwoju systemów IT.
Zapraszamy do kontaktu – wspólnie zastanowimy się, jak pomóc Twojej organizacji zapewnić integralność danych.
