Co to jest Big Data i jak wykorzystuje się duże zbiory danych?

Big Data to pojęcie opisujące bardzo duże, szybko powstające lub złożone zbiory danych, których przechowywanie i analizowanie wymaga bardziej zaawansowanych metod niż klasyczna praca z pojedynczym arkuszem, plikiem czy niewielką bazą danych.

Nie istnieje jednak jedna konkretna liczba rekordów, po której dane automatycznie stają się Big Data.

Dla niewielkiej firmy problemem może być milion rekordów.

Dla globalnej platformy przetwarzającej miliardy zdarzeń dziennie milion rekordów może być zbiorem bardzo małym.

Dlatego Big Data opisuje przede wszystkim sytuację, w której skala lub charakter informacji zaczyna wymagać specjalnej architektury, odpowiednich narzędzi i innego sposobu myślenia o danych.

Co oznacza Big Data?

Angielskie określenie Big Data oznacza dosłownie duże dane.

W praktyce nie chodzi jednak wyłącznie o ich rozmiar.

Problem może wynikać również z tego, że:

• dane powstają bardzo szybko,
• pochodzą z wielu źródeł,
• mają różne formaty,
• trzeba analizować je niemal w czasie rzeczywistym,
• ich jakość jest nierówna,
• relacje pomiędzy nimi są bardzo złożone.

Big Data jest więc zarówno problemem technologicznym, jak i analitycznym.

Big Data a zwykła baza danych

Typowa aplikacja biznesowa może przechowywać:

• klientów,
• zamówienia,
• produkty,
• faktury,
• statusy.

Jeżeli danych jest relatywnie niewiele i posiadają przewidywalną strukturę, klasyczna relacyjna baza danych może być całkowicie wystarczająca.

Big Data zaczyna mieć znaczenie wtedy, gdy tradycyjne podejście przestaje być wygodne, ekonomiczne albo wystarczająco wydajne.

Nie oznacza to jednak, że po przekroczeniu określonej skali trzeba wyrzucić SQL i wdrożyć zupełnie inną technologię.

Współczesne systemy bardzo często łączą kilka różnych sposobów przechowywania i przetwarzania danych.

Model 3V Big Data

Jednym z najbardziej znanych sposobów opisywania Big Data jest model 3V.

Trzy litery oznaczają:

• Volume,
• Velocity,
• Variety.

Czyli odpowiednio:

• objętość,
• szybkość,
• różnorodność.

Volume, czyli objętość danych

Volume odnosi się do ilości informacji.

Dane mogą być liczone w:

• milionach rekordów,
• miliardach zdarzeń,
• terabajtach,
• petabajtach,
• jeszcze większych jednostkach.

Sama duża objętość powoduje konkretne problemy.

Trzeba odpowiedzieć na pytania:

• gdzie dane przechowywać,
• jak wykonywać kopie,
• jak szybko je przeszukiwać,
• jak przenosić je pomiędzy systemami,
• jak długo je przechowywać.

Operacja łatwa na tysiącu rekordów może stać się bardzo kosztowna przy miliardzie.

Velocity, czyli szybkość powstawania danych

Dane mogą napływać nieustannie.

Przykładem są:

• zdarzenia z aplikacji,
• transakcje,
• logi serwerów,
• dane z urządzeń IoT,
• kliknięcia użytkowników,
• lokalizacje pojazdów.

System musi wtedy nie tylko przechować bardzo dużą liczbę informacji.

Musi nadążyć z ich przyjmowaniem.

Jeżeli aplikacja generuje kilkaset tysięcy zdarzeń na sekundę, nie można po prostu raz dziennie wkleić ich do Excela.

Variety, czyli różnorodność

Informacje nie zawsze mają identyczną strukturę.

Mogą pochodzić z:

• baz danych,
• plików CSV,
• JSON,
• logów,
• zdjęć,
• filmów,
• sensorów,
• systemów zewnętrznych.

Łączenie takich źródeł jest jednym z największych wyzwań projektów danych.

Ten sam klient może być zapisany pod różnymi identyfikatorami, adres może mieć kilka formatów, a jedna aplikacja zapisuje datę inaczej niż druga.

Model 5V

Model 3V został później rozszerzony o kolejne cechy.

Często mówi się o 5V, dodając:

• Veracity,
• Value.

Veracity, czyli wiarygodność danych

Duża liczba rekordów nie oznacza automatycznie wysokiej jakości informacji.

Dane mogą zawierać:

• błędy,
• duplikaty,
• braki,
• nieaktualne wartości,
• sprzeczne informacje.

Jeżeli system posiada miliard rekordów złej jakości, analiza może prowadzić do bardzo precyzyjnych, ale całkowicie błędnych wniosków.

Dlatego jakość danych jest równie istotna jak ich ilość.

Value, czyli wartość

Najważniejszym pytaniem biznesowym jest:

co firma może zrobić dzięki tym danym?

Przechowywanie ogromnego zbioru tylko dlatego, że technicznie jest to możliwe, generuje koszt.

Wartość pojawia się dopiero wtedy, gdy dane pomagają:

• podejmować decyzje,
• wykrywać problemy,
• przewidywać zdarzenia,
• automatyzować procesy,
• lepiej rozumieć klientów.

Czy każdy duży plik to Big Data?

Nie.

Plik CSV posiadający kilka milionów rekordów może być duży, ale jeżeli jest analizowany raz na miesiąc i bez problemu mieści się w dostępnych narzędziach, nie musi wymagać architektury kojarzonej z Big Data.

Z kolei stosunkowo niewielka ilość informacji może tworzyć problem Big Data, jeśli napływa w ogromnym tempie i musi zostać przeanalizowana niemal natychmiast.

Skąd pochodzą duże zbiory danych?

Współczesne systemy generują dane praktycznie przy każdej interakcji.

Źródłem Big Data mogą być między innymi:

• sklepy internetowe,
• aplikacje mobilne,
• systemy bankowe,
• media społecznościowe,
• maszyny przemysłowe,
• czujniki IoT,
• systemy transportowe,
• platformy streamingowe,
• serwery i infrastruktura IT.

Big Data w e-commerce

Sklep internetowy może generować znacznie więcej danych niż same zamówienia.

Można rejestrować:

• wyświetlenia produktów,
• kliknięcia,
• wyszukiwane frazy,
• dodania do koszyka,
• porzucenia koszyka,
• transakcje,
• zwroty,
• zmiany cen,
• stany magazynowe,
• źródła ruchu.

Przy dużej skali każdy użytkownik może wygenerować dziesiątki lub setki zdarzeń podczas jednej wizyty.

Milion użytkowników nie oznacza więc miliona rekordów, ale potencjalnie setki milionów zdarzeń.

Clickstream

Clickstream to strumień danych opisujących kolejne interakcje użytkownika.

Może obejmować między innymi:

• wejście na stronę,
• wyświetlenie kategorii,
• otwarcie produktu,
• użycie filtra,
• kliknięcie przycisku,
• dodanie produktu do koszyka,
• zakup.

Analiza takiego strumienia pozwala badać rzeczywiste ścieżki użytkowników.

Big Data a analityka internetowa

Klasyczna analityka może przedstawiać zagregowane informacje:

• liczbę użytkowników,
• liczbę sesji,
• konwersję,
• przychód.

Przy bardziej zaawansowanej analizie można pracować na poziomie pojedynczych zdarzeń i próbować odpowiadać na znacznie bardziej szczegółowe pytania.

Przykładowo:

Jakie zachowania najczęściej poprzedzają zakup określonego produktu?

To wymaga analizy dużej liczby zdarzeń, a nie tylko końcowego raportu.

Big Data a logi serwerowe

Serwery i aplikacje generują ogromne ilości logów.

Mogą zawierać informacje o:

• żądaniach HTTP,
• błędach,
• czasie odpowiedzi,
• adresach IP,
• działaniu aplikacji,
• zdarzeniach bezpieczeństwa.

W dużym systemie liczba takich wpisów może być ogromna.

Ich analiza pomaga między innymi wykrywać awarie i anomalie.

Big Data a Internet of Things

IoT, czyli Internet of Things, jest jednym z naturalnych źródeł dużych zbiorów danych.

Czujnik może wysyłać odczyt co kilka sekund.

Jeżeli firma posiada milion urządzeń, liczba pomiarów rośnie bardzo szybko.

Dane mogą dotyczyć:

• temperatury,
• wibracji,
• lokalizacji,
• zużycia energii,
• stanu urządzenia.

Dane strukturalne i niestrukturalne

Nie wszystkie dane wyglądają jak klasyczna tabela.

Dane strukturalne posiadają określony schemat.

Przykład:

• ID klienta,
• imię,
• data zakupu,
• kwota.

Dane niestrukturalne mogą obejmować:

• zdjęcia,
• nagrania,
• tekst,
• dokumenty,
• wiadomości.

Ich analiza wymaga innych metod.

Dane półstrukturalne

Pomiędzy tymi kategoriami znajdują się dane półstrukturalne.

Przykładem może być JSON.

Dokument posiada określone pola, ale nie każdy rekord musi mieć identyczny zestaw właściwości.

Taki model jest bardzo popularny w API i aplikacjach internetowych.

Big Data a SQL

SQL nadal odgrywa ogromną rolę w pracy z dużymi zbiorami danych.

Nie należy myśleć, że Big Data oznacza automatycznie rezygnację z relacyjnych baz.

Współczesne systemy analityczne potrafią wykonywać zapytania SQL na bardzo dużych zbiorach informacji.

Różnica może dotyczyć głównie architektury znajdującej się pod spodem.

Big Data a NoSQL

NoSQL to szeroka grupa baz danych, które nie wykorzystują klasycznego relacyjnego modelu jako jedynego sposobu organizacji informacji.

Mogą to być między innymi bazy:

• dokumentowe,
• klucz-wartość,
• kolumnowe,
• grafowe.

Nie oznacza to, że NoSQL jest zawsze lepsze od SQL.

Technologię trzeba dopasować do rodzaju problemu.

Skalowanie pionowe

Jednym ze sposobów zwiększenia wydajności systemu jest wykorzystanie mocniejszej maszyny.

Można zwiększyć:

• procesor,
• pamięć RAM,
• przestrzeń dyskową.

To skalowanie pionowe.

Ma jednak naturalne ograniczenia.

Skalowanie poziome

Skalowanie poziome polega na wykorzystaniu wielu maszyn.

Dane i praca mogą zostać rozdzielone pomiędzy kilka lub tysiące węzłów.

To jedna z najważniejszych idei infrastruktury Big Data.

Zamiast próbować stworzyć jeden niewiarygodnie potężny komputer, system wykorzystuje wiele współpracujących jednostek.

Przetwarzanie rozproszone

Przy bardzo dużych zbiorach zadanie można podzielić na mniejsze części.

Każdy węzeł analizuje fragment danych.

Następnie wyniki są łączone.

Dzięki temu operacja może zostać wykonana znacznie szybciej niż na pojedynczej maszynie.

Hadoop

Jedną z technologii silnie kojarzonych z rozwojem Big Data jest Apache Hadoop.

Ekosystem ten pozwolił przechowywać i przetwarzać ogromne zbiory danych na klastrach złożonych z wielu maszyn.

Hadoop odegrał bardzo ważną rolę w popularyzacji przetwarzania rozproszonego.

Nie oznacza to jednak, że każdy współczesny projekt Big Data musi wykorzystywać Hadoop.

HDFS

Hadoop Distributed File System to rozproszony system plików.

Dane mogą być dzielone na fragmenty i przechowywane na wielu maszynach.

System może również posiadać redundancję, dzięki której awaria pojedynczego węzła nie oznacza utraty całego zbioru.

MapReduce

MapReduce to model przetwarzania dużych zbiorów poprzez dzielenie zadania na etapy.

W uproszczeniu:

• Map przetwarza fragmenty danych,
• Reduce łączy częściowe wyniki.

Idea była przełomowa dla masowego przetwarzania danych, choć współczesne systemy często wykorzystują bardziej elastyczne mechanizmy.

Apache Spark

Apache Spark jest platformą przetwarzania danych wykorzystywaną między innymi do:

• analiz,
• ETL,
• przetwarzania rozproszonego,
• machine learning,
• pracy na dużych zbiorach.

Jedną z jego zalet jest możliwość wykonywania wielu operacji szybciej niż klasyczne podejścia oparte na ciągłym zapisie danych na dysku.

Batch processing

Batch processing oznacza przetwarzanie danych partiami.

Przykładowo raz w nocy system:

1. pobiera wszystkie zdarzenia z poprzedniego dnia,
2. przetwarza je,
3. tworzy raport,
4. zapisuje wynik.

Jeżeli firma nie potrzebuje informacji natychmiast, taki model może być całkowicie wystarczający.

Stream processing

Stream processing oznacza przetwarzanie strumienia informacji w momencie ich napływania albo z bardzo niewielkim opóźnieniem.

Może być potrzebne, gdy system ma:

• wykryć oszustwo podczas transakcji,
• zareagować na awarię urządzenia,
• aktualizować rekomendacje,
• monitorować ruch w czasie rzeczywistym.

Big Data w czasie rzeczywistym

Określenie real-time jest często używane bardzo swobodnie.

Nie każdy biznes naprawdę potrzebuje reakcji w ciągu milisekund.

Czasami wystarczy aktualizacja:

• co minutę,
• co godzinę,
• raz dziennie.

Im krótsze wymagane opóźnienie, tym większa może być złożoność i koszt systemu.

Data Warehouse

Data Warehouse, czyli hurtownia danych, jest systemem przygotowanym do przechowywania danych analitycznych pochodzących z różnych źródeł.

Może łączyć informacje z:

• CRM,
• ERP,
• sklepu internetowego,
• systemów reklamowych,
• aplikacji,
• narzędzi analitycznych.

Dane są organizowane w sposób ułatwiający raportowanie i analizę.

Data Lake

Data Lake to repozytorium pozwalające przechowywać duże ilości danych w bardziej surowej formie.

Nie wszystkie informacje muszą zostać wcześniej dokładnie dopasowane do jednego sztywnego modelu.

Można przechowywać:

• pliki,
• logi,
• dane strukturalne,
• dane półstrukturalne,
• dane niestrukturalne.

Data Warehouse a Data Lake

W dużym uproszczeniu hurtownia danych zawiera dane przygotowane do konkretnych analiz, a Data Lake może przechowywać również dane bardziej surowe.

Nie należy jednak traktować tych architektur jako dwóch całkowicie przeciwstawnych światów.

Współczesne systemy bardzo często łączą cechy obu podejść.

Data Lakehouse

Data Lakehouse to podejście próbujące połączyć elastyczność Data Lake z możliwościami zarządzania i analizy charakterystycznymi dla hurtowni danych.

Celem jest ograniczenie sytuacji, w której te same dane trzeba wielokrotnie kopiować pomiędzy różnymi platformami.

ETL

ETL oznacza:

• Extract,
• Transform,
• Load.

Czyli:

• pobierz dane,
• przekształć je,
• załaduj do systemu docelowego.

To jeden z podstawowych procesów wykorzystywanych podczas budowania systemów analitycznych.

Przykład procesu ETL

Firma posiada:

• WooCommerce,
• system magazynowy,
• CRM,
• platformę reklamową.

ETL może:

1. pobrać dane z każdego źródła,
2. ujednolicić format dat,
3. połączyć identyfikatory klientów,
4. wyliczyć dodatkowe wartości,
5. zapisać wszystko w hurtowni.

Analityk może później wykonywać zapytania bez bezpośredniego łączenia się z czterema systemami produkcyjnymi.

ELT

ELT wykorzystuje podobne etapy, ale transformacja odbywa się już po załadowaniu danych do systemu docelowego.

Kolejność wygląda więc:

Extract → Load → Transform

Takie podejście stało się popularne między innymi dzięki dużej mocy współczesnych platform danych.

Data Pipeline

Data pipeline to cały przepływ danych pomiędzy źródłem a miejscem wykorzystania.

Może obejmować:

• pobieranie,
• kolejkowanie,
• walidację,
• oczyszczanie,
• transformację,
• zapis,
• raportowanie.

W zaawansowanym systemie działa automatycznie i jest stale monitorowany.

Big Data a API

API jest jednym ze sposobów dostarczania danych.

Jeżeli trzeba pobrać kilka tysięcy rekordów raz dziennie, zwykła integracja API może wystarczyć.

Przy ogromnej skali mogą jednak pojawić się problemy związane z:

• limitami zapytań,
• paginacją,
• czasem transferu,
• kosztem,
• opóźnieniami.

Wtedy potrzebne mogą być inne mechanizmy wymiany informacji.

Kolejki komunikatów

W systemach przetwarzających duży strumień zdarzeń często wykorzystuje się kolejki lub platformy strumieniowe.

Zamiast wysyłać każde zdarzenie bezpośrednio do systemu analitycznego, aplikacja przekazuje je do warstwy pośredniej.

Dzięki temu:

• producent danych nie musi czekać na analizę,
• zdarzenia mogą być buforowane,
• kilka systemów może korzystać z tego samego strumienia.

Apache Kafka

Apache Kafka jest jedną z najbardziej znanych technologii wykorzystywanych do obsługi strumieni zdarzeń.

Może pośredniczyć pomiędzy systemami generującymi informacje a aplikacjami, które je później przetwarzają.

Przykładowo zdarzenie zakupu może zostać wykorzystane jednocześnie przez:

• analitykę,
• system rekomendacji,
• monitoring fraudów,
• system powiadomień.

Event-driven architecture

Architektura sterowana zdarzeniami opiera się na informowaniu innych komponentów, że coś właśnie się wydarzyło.

Zdarzeniem może być:

• utworzenie zamówienia,
• zmiana ceny,
• logowanie użytkownika,
• wysyłka paczki,
• awaria urządzenia.

To podejście bardzo dobrze współpracuje z systemami przetwarzającymi duże ilości danych w czasie rzeczywistym.

Big Data a chmura

Cloud computing bardzo ułatwił dostęp do infrastruktury potrzebnej do pracy z dużymi zbiorami.

Firma nie musi od razu kupować własnego klastra serwerów.

Może korzystać z usług umożliwiających skalowanie:

• mocy obliczeniowej,
• przestrzeni,
• baz danych,
• hurtowni,
• narzędzi analitycznych.

Nie oznacza to jednak, że chmura automatycznie gwarantuje niskie koszty.

Koszty Big Data

Przechowywanie danych kosztuje.

Ich przetwarzanie również.

Do kosztów mogą dochodzić:

• transfer,
• zapytania,
• backup,
• monitoring,
• utrzymanie pipeline'ów,
• praca specjalistów.

Dlatego nie warto przechowywać wszystkiego bez żadnej strategii tylko dlatego, że dane być może kiedyś się przydadzą.

Data retention

Data retention określa, jak długo przechowuje się określony rodzaj informacji.

Nie wszystkie dane muszą istnieć bezterminowo.

Można na przykład zachowywać:

• surowe logi przez krótki okres,
• zagregowane statystyki przez kilka lat.

Polityka powinna uwzględniać potrzeby biznesowe, techniczne i obowiązujące wymagania dotyczące danych.

Data Governance

Data Governance to zasady zarządzania danymi w organizacji.

Obejmuje między innymi:

• własność danych,
• jakość,
• dostęp,
• bezpieczeństwo,
• definicje,
• odpowiedzialność.

Przy niewielkim zbiorze wiele rzeczy można ustalić nieformalnie.

Przy tysiącach tabel i setkach systemów brak zasad prowadzi szybko do chaosu.

Data Owner

W większych organizacjach warto określić, kto jest odpowiedzialny za konkretny rodzaj danych.

Jeżeli nikt nie odpowiada za definicję klienta, pięć działów może używać pięciu różnych definicji.

Wtedy raporty zaczynają sobie przeczyć.

Jedno źródło prawdy

Problemem nie jest tylko ilość danych.

Problemem jest również istnienie wielu wersji tej samej informacji.

Przykładowo liczba aktywnych klientów może wynosić:

• 20 000 w CRM,
• 24 000 w sklepie,
• 17 000 w systemie marketingowym.

Każda wartość może być poprawna, jeżeli systemy inaczej definiują „aktywnego klienta”.

Dlatego przed budowaniem dashboardu trzeba ustalić definicje.

Data Quality

Jakość danych można oceniać na podstawie wielu cech.

Dane powinny być między innymi:

• poprawne,
• kompletne,
• spójne,
• aktualne,
• jednoznaczne.

Każdy problem jakościowy może zostać powielony podczas późniejszych analiz.

Garbage in, garbage out

W informatyce funkcjonuje zasada określana jako garbage in, garbage out.

Jeżeli na wejściu znajdują się złe dane, nawet najlepszy algorytm nie stworzy z nich wiarygodnego wyniku.

Big Data nie rozwiązuje problemu jakości.

Może wręcz zwielokrotnić jego skalę.

Czyszczenie danych

Przed analizą często trzeba wykonać proces data cleaning.

Może obejmować:

• usuwanie duplikatów,
• normalizację formatów,
• poprawianie błędów,
• uzupełnianie albo oznaczanie braków,
• walidację wartości.

W wielu projektach właśnie przygotowanie danych zajmuje więcej czasu niż późniejsze stworzenie wykresu czy modelu.

Normalizacja danych

Ta sama wartość może być zapisana na wiele sposobów.

Przykładowo kraj może występować jako:

• Polska,
• PL,
• POL,
• Poland.

Jeżeli system ma analizować dane wspólnie, trzeba zdefiniować jednolity model.

Deduplikacja

Jedna osoba może istnieć w kilku systemach.

Jeżeli rekordy nie zostaną prawidłowo połączone, system może uznać je za kilku różnych klientów.

Do deduplikacji można wykorzystywać:

• unikalne identyfikatory,
• adres e-mail,
• numer klienta,
• kombinacje kilku cech.

Im mniej jednoznaczny identyfikator, tym większe ryzyko błędnego połączenia.

Entity Resolution

Entity Resolution to proces ustalania, które rekordy dotyczą tego samego rzeczywistego obiektu.

Może dotyczyć:

• osób,
• firm,
• produktów,
• adresów.

Przy dużej liczbie źródeł jest to jedno z trudniejszych zagadnień.

Big Data a Business Intelligence

Business Intelligence koncentruje się na przekształcaniu danych w informacje przydatne do podejmowania decyzji.

Może wykorzystywać:

• raporty,
• dashboardy,
• KPI,
• analizy trendów.

Big Data może dostarczać ogromnego źródła informacji dla BI, ale oba pojęcia nie oznaczają tego samego.

Big Data a Data Analytics

Data Analytics oznacza analizowanie danych w celu odkrywania informacji i zależności.

Może być wykonywane zarówno na tysiącu rekordów, jak i na miliardzie.

Big Data opisuje bardziej skalę i charakter zbioru niż samą metodę analizy.

Analiza opisowa

Descriptive analytics odpowiada głównie na pytanie:

co się wydarzyło?

Przykłady:

• jaki był przychód,
• ile produktów sprzedano,
• ile klientów dokonało zakupu.

Analiza diagnostyczna

Diagnostic analytics próbuje odpowiedzieć:

dlaczego to się wydarzyło?

Przykładowo sprzedaż spadła o 20%.

Analiza może sprawdzić:

• kanały ruchu,
• regiony,
• produkty,
• urządzenia,
• zmiany cen.

Analiza predykcyjna

Predictive analytics próbuje oszacować, co może wydarzyć się w przyszłości.

Przykłady:

• prognoza sprzedaży,
• prawdopodobieństwo rezygnacji klienta,
• przewidywanie awarii,
• ocena ryzyka.

Analiza preskryptywna

Prescriptive analytics idzie krok dalej i próbuje odpowiedzieć:

co powinniśmy zrobić?

System może na przykład wskazać, jak rozdzielić zapasy albo jak zmienić harmonogram, aby osiągnąć lepszy rezultat.

Big Data a machine learning

Duże zbiory są często wykorzystywane do trenowania modeli machine learning.

Model może wykrywać zależności, których ręczna analiza byłaby bardzo trudna.

Zastosowania obejmują między innymi:

• rekomendacje,
• wykrywanie fraudów,
• klasyfikację,
• prognozowanie,
• analizę zachowań.

Czy AI wymaga Big Data?

Nie każdy projekt AI potrzebuje miliardów rekordów.

Zapotrzebowanie zależy od rodzaju problemu i modelu.

Czasami kilka tysięcy wysokiej jakości przykładów jest bardziej wartościowe niż milion rekordów pełnych błędów.

Więcej nie zawsze oznacza lepiej.

Big Data a generatywna AI

Duże modele generatywne są trenowane na ogromnych zbiorach danych.

W firmach jednak często bardziej praktyczne jest wykorzystanie własnych, znacznie mniejszych zbiorów jako kontekstu dla gotowego modelu niż próba trenowania dużego modelu od podstaw.

To dwa zupełnie różne problemy technologiczne i kosztowe.

Recommendation Engine

System rekomendacji może analizować:

• zakupy,
• wyświetlenia,
• podobieństwo produktów,
• zachowanie podobnych użytkowników.

Na tej podstawie proponuje elementy, które mogą być interesujące dla konkretnego odbiorcy.

Im większa platforma, tym więcej sygnałów może zostać wykorzystanych.

Personalizacja

Big Data umożliwia tworzenie bardziej szczegółowych segmentów użytkowników.

Można dostosowywać między innymi:

• rekomendacje,
• komunikację,
• kolejność treści,
• oferty.

Personalizacja nie powinna jednak oznaczać zbierania maksymalnej liczby informacji bez konkretnego celu.

Segmentacja klientów

Klientów można grupować według:

• wartości zakupów,
• częstotliwości transakcji,
• zainteresowań,
• zachowań,
• etapu relacji z firmą.

Duża liczba danych pozwala tworzyć bardziej szczegółowe segmenty, ale trzeba uważać, żeby segmentacja nie stała się tak skomplikowana, że nikt później nie potrafi jej wykorzystać.

Analiza koszyka zakupowego

Można analizować, które produkty są często kupowane razem.

Takie informacje mogą wspierać:

• cross-selling,
• układ sklepu,
• promocje,
• zarządzanie zapasami.

Przy milionach transakcji można wykrywać wzorce niewidoczne przy ręcznej analizie.

Dynamic pricing

Dane mogą być również wykorzystywane do dynamicznego ustalania cen.

Algorytm może brać pod uwagę między innymi:

• popyt,
• zapas,
• czas,
• konkurencję,
• historię sprzedaży.

Taki system wymaga jednak dużej ostrożności, ponieważ błędny model może automatycznie generować bardzo złe decyzje cenowe.

Fraud Detection

W finansach i e-commerce duże zbiory zdarzeń mogą służyć do wykrywania nietypowych zachowań.

System może analizować:

• częstotliwość transakcji,
• lokalizację,
• wartość,
• urządzenie,
• historię użytkownika.

Nagłe odstępstwo od normalnego wzorca może uruchomić dodatkową weryfikację.

Predictive Maintenance

W przemyśle dane z maszyn mogą pomagać przewidywać awarie.

Zamiast wymieniać część dopiero po uszkodzeniu, można analizować:

• wibracje,
• temperaturę,
• zużycie energii,
• historię wcześniejszych awarii.

System może wtedy sugerować konserwację przed wystąpieniem problemu.

Big Data w logistyce

Duże zbiory danych można wykorzystywać do optymalizacji:

• tras,
• magazynów,
• zapasów,
• prognoz popytu,
• czasu dostawy.

Im większa sieć logistyczna, tym więcej zmiennych trzeba uwzględnić.

Big Data a prognozowanie popytu

Historyczna sprzedaż jest jednym z podstawowych źródeł informacji.

Bardziej rozbudowany model może uwzględniać również:

• sezonowość,
• promocje,
• pogodę,
• wydarzenia,
• trendy.

Dokładniejsza prognoza może pomóc ograniczyć zarówno braki magazynowe, jak i nadmierne zapasy.

Big Data a marketing

Marketing generuje ogromną ilość informacji.

Można analizować:

• kampanie,
• wyświetlenia reklam,
• kliknięcia,
• konwersje,
• segmenty klientów,
• ścieżki między kanałami.

Największym wyzwaniem często nie jest brak danych, ale ich połączenie w spójny obraz.

Atrybucja

Klient może przed zakupem zetknąć się z marką wielokrotnie.

Przykładowo:

1. zobaczy reklamę,
2. wejdzie z Google,
3. zapisze się do newslettera,
4. wróci bezpośrednio,
5. dokona zakupu.

Przypisanie całej wartości ostatniemu wejściu może nie przedstawiać rzeczywistej roli wcześniejszych kontaktów.

Big Data pozwala analizować bardziej rozbudowane ścieżki, choć sama duża liczba informacji nie rozwiązuje wszystkich problemów atrybucji.

Big Data a automatyzacja

Dane stają się szczególnie wartościowe, gdy mogą uruchamiać automatyczne działania.

Przykład:

1. system analizuje stany i tempo sprzedaży,
2. wykrywa ryzyko braku produktu,
3. uruchamia alert,
4. przekazuje dane do procesu zamówienia.

To krok dalej niż zwykły raport.

W ramach automatyzacji najpierw sprawdzam jednak, czy dane są wystarczająco wiarygodne, aby mogły bezpiecznie sterować procesem. Automat wykonujący decyzje na podstawie błędnych informacji może generować problemy znacznie szybciej niż człowiek.

Raport a automatyczna decyzja

Istnieje ogromna różnica pomiędzy systemem, który pokazuje:

„produkt może się wyprzedać”,

a systemem, który automatycznie składa zamówienie u dostawcy.

Im większa odpowiedzialność automatu, tym większe znaczenie mają:

• walidacja,
• monitoring,
• progi bezpieczeństwa,
• możliwość cofnięcia operacji.

Big Data a prywatność

Duże zbiory mogą zawierać informacje dotyczące użytkowników i klientów.

Wtedy pojawia się kwestia odpowiedzialnego przetwarzania.

Należy zwracać uwagę między innymi na:

• zakres zbieranych danych,
• cel ich wykorzystania,
• czas przechowywania,
• dostęp,
• bezpieczeństwo.

Techniczna możliwość zapisania informacji nie oznacza automatycznie, że należy ją zbierać.

Data Minimization

Minimalizacja danych polega na zbieraniu informacji potrzebnych do określonego celu zamiast gromadzenia wszystkiego „na wszelki wypadek”.

Ma to również praktyczną korzyść techniczną.

Mniej niepotrzebnych danych oznacza:

• niższy koszt,
• prostsze zarządzanie,
• mniejsze ryzyko,
• łatwiejszą analizę.

Anonimizacja i pseudonimizacja

W zależności od zastosowania można ograniczać możliwość bezpośredniego powiązania rekordu z konkretną osobą.

Anonimizacja i pseudonimizacja są jednak różnymi pojęciami i nie powinny być traktowane zamiennie.

Projektując system, trzeba ustalić, czy identyfikacja konkretnego użytkownika jest w ogóle potrzebna do wykonania analizy.

Bezpieczeństwo Big Data

Im większy i bardziej wartościowy zbiór, tym poważniejsze mogą być konsekwencje wycieku.

Bezpieczeństwo powinno obejmować między innymi:

• kontrolę dostępu,
• uwierzytelnianie,
• szyfrowanie,
• monitorowanie,
• kopie zapasowe,
• zarządzanie uprawnieniami.

Zasada najmniejszych uprawnień

Nie każdy pracownik powinien posiadać dostęp do wszystkich informacji tylko dlatego, że technicznie znajdują się w tej samej platformie.

Użytkownik powinien otrzymać taki zakres uprawnień, jaki jest potrzebny do wykonywania jego pracy.

Big Data a backup

Kopia kilku terabajtów danych jest znacznie bardziej wymagająca niż kopia małej strony internetowej.

Trzeba ustalić:

• co naprawdę wymaga backupu,
• jak często,
• jak długo przechowywać kopie,
• jak szybko można odtworzyć system.

Sam fakt posiadania kopii nie oznacza jeszcze, że da się ją sprawnie wykorzystać.

Disaster Recovery

Disaster Recovery opisuje sposób przywracania działania po poważnej awarii.

W dużym systemie danych trzeba wiedzieć:

• które elementy są krytyczne,
• w jakiej kolejności je odtwarzać,
• ile danych można utracić,
• jak długo system może być niedostępny.

Big Data a monitoring

Im bardziej złożony pipeline, tym więcej miejsc potencjalnej awarii.

Może przestać działać:

• źródło,
• API,
• kolejka,
• transformacja,
• baza,
• dashboard.

Dlatego potrzebny jest monitoring całego przepływu.

Data Observability

Data Observability oznacza możliwość obserwowania jakości i stanu danych oraz pipeline'ów.

System może kontrolować:

• czy dane napływają,
• czy liczba rekordów jest normalna,
• czy pojawiły się wartości puste,
• czy struktura się zmieniła,
• czy pipeline działa w oczekiwanym czasie.

Brak błędu nie oznacza poprawnych danych

Pipeline może zakończyć się technicznie sukcesem i zapisać milion rekordów.

Jeżeli wszystkie ceny wynoszą 0, proces nie jest poprawny biznesowo.

Dlatego monitoring powinien sprawdzać również samą zawartość danych.

Schema Evolution

Źródła danych zmieniają się.

API może dodać pole albo zmienić typ wartości.

System, który zakłada niezmienną strukturę przez wiele lat, może przestać działać po niewielkiej aktualizacji źródła.

W dużych pipeline'ach trzeba planować obsługę zmian schematu.

Data Lineage

Data lineage opisuje drogę konkretnej informacji od źródła do raportu lub modelu.

Jeżeli dashboard pokazuje przychód, warto móc odpowiedzieć:

• z jakiego systemu pochodzi,
• jak został przeliczony,
• które transformacje wykonano,
• kiedy dane zostały zaktualizowane.

Bez tego znalezienie przyczyny błędnego raportu może być bardzo trudne.

Metadata

Metadane opisują same dane.

Mogą informować:

• co oznacza pole,
• jaki ma typ,
• kto jest jego właścicielem,
• z jakiego źródła pochodzi,
• kiedy zostało zaktualizowane.

Przy ogromnych platformach katalog danych staje się niemal tak ważny jak same dane.

Data Catalog

Data Catalog pomaga użytkownikom odnajdywać dostępne zbiory i rozumieć ich znaczenie.

Bez niego analityk może poświęcić więcej czasu na szukanie właściwej tabeli niż na właściwą analizę.

Big Data a dedykowane systemy

Nie każda firma potrzebuje platformy klasy Big Data.

Czasami wystarczy dobrze zaprojektowana baza, kilka integracji i poprawne raportowanie.

Problem zaczyna się wtedy, gdy organizacja wdraża skomplikowaną technologię tylko dlatego, że brzmi nowocześnie.

Przy projektowaniu dedykowanych systemów operacyjnych zaczynam od rzeczywistego przepływu informacji, wolumenu danych i celu biznesowego. Technologia powinna wynikać z problemu, a nie odwrotnie.

Kiedy klasyczna baza wystarczy?

Jeżeli system posiada:

• kilkaset tysięcy rekordów,
• przewidywalną strukturę,
• niewielką liczbę użytkowników,
• proste raporty,

dobrze zoptymalizowana relacyjna baza może działać znakomicie.

Nie ma sensu budować rozproszonego klastra tylko po to, aby móc używać określenia Big Data.

Kiedy architektura danych zaczyna mieć znaczenie?

Sygnałami mogą być:

• zapytania trwające coraz dłużej,
• bardzo szybki przyrost danych,
• problemy z importami,
• wiele niezależnych źródeł,
• potrzeba analizy strumieniowej,
• rosnący koszt infrastruktury.

Wtedy warto przeanalizować, czy obecny model nadal jest odpowiedni.

Big Data a Excel

Excel jest świetnym narzędziem do wielu zastosowań analitycznych.

Nie jest jednak systemem zaprojektowanym do przechowywania miliardów rekordów ani obsługi strumieni zdarzeń.

Problem pojawia się, gdy arkusz zaczyna pełnić jednocześnie rolę:

• bazy danych,
• systemu operacyjnego,
• integracji,
• raportu.

Wtedy trudniej kontrolować wersje, uprawnienia i spójność informacji.

Big Data a dashboard

Dashboard jest tylko końcową warstwą.

Ładny wykres nie oznacza, że stojące za nim dane są poprawne.

Przed wizualizacją trzeba zadbać o:

• źródła,
• definicje,
• transformacje,
• jakość.

Najdroższy dashboard nadal będzie pokazywał błędny wynik, jeśli pipeline dostarcza błędne dane.

Big Data nie oznacza „zbieraj wszystko”

To jeden z najbardziej kosztownych mitów.

Firma zaczyna zapisywać każdą możliwą informację, ponieważ „kiedyś może się przydać”.

Po kilku latach posiada ogromne repozytorium, ale nikt nie wie:

• co w nim jest,
• które dane są aktualne,
• czy można im ufać,
• do czego można ich użyć.

To nie jest przewaga wynikająca z Big Data.

To kosztowny bałagan.

Data Swamp

Data Swamp to określenie używane wobec Data Lake, który przestał być uporządkowanym źródłem informacji.

Dane istnieją, ale:

• nie są opisane,
• nie wiadomo, skąd pochodzą,
• nie wiadomo, czy są aktualne,
• trudno je odnaleźć.

Dlatego samo stworzenie miejsca do przechowywania ogromnej ilości plików nie rozwiązuje problemu.

Najczęstszy błąd: projekt bez pytania biznesowego

Firma rozpoczyna budowę platformy danych, ale nie wie, jakie decyzje ma dzięki niej podejmować.

Powstaje skomplikowana infrastruktura bez konkretnego zastosowania.

Lepiej rozpocząć od pytań:

• co chcemy wiedzieć,
• jaką decyzję ma wspierać odpowiedź,
• jakich danych potrzebujemy.

Najczęstszy błąd: więcej danych zamiast lepszych danych

Jeżeli raport jest niewiarygodny z powodu złych identyfikatorów produktów, dodanie kolejnych stu milionów rekordów nie pomoże.

Najpierw trzeba poprawić jakość.

Najczęstszy błąd: technologia przed procesem

Organizacja wybiera platformę, a dopiero później zastanawia się, co ma w niej robić.

To odwrócona kolejność.

Najpierw trzeba zrozumieć:

• źródła,
• skalę,
• częstotliwość,
• cele.

Najczęstszy błąd: raporty bez wspólnych definicji

Marketing mówi, że było 5000 klientów.

Sprzedaż mówi 4200.

Finanse mówią 3700.

Każdy raport może działać poprawnie technicznie.

Problemem są różne definicje.

Najczęstszy błąd: brak monitoringu pipeline'u

Raport nie zaktualizował się przez trzy dni, ale nikt tego nie zauważył.

Manager podejmuje decyzję na podstawie starych danych.

System analityczny jest procesem produkcyjnym i również wymaga monitorowania.

Najczęstszy błąd: brak kontroli kosztów

Chmurowa infrastruktura pozwala łatwo zwiększać skalę.

To również oznacza, że źle napisane zapytanie może przetwarzać ogromne ilości danych i generować niepotrzebny koszt.

Wydajność i koszt powinny być monitorowane razem.

Najczęstszy błąd: przechowywanie wszystkiego bez końca

Jeżeli każdego dnia powstaje terabajt danych, po roku zbiór jest ogromny.

Trzeba określić, które dane rzeczywiście wymagają długiego przechowywania.

Najczęstszy błąd: dashboard jako cel projektu

Firma zamawia dashboard.

Projekt rozpoczyna się od wyboru kolorów wykresów.

Dopiero później okazuje się, że dane pochodzą z pięciu niespójnych arkuszy.

Prawidłowa kolejność jest odwrotna.

Jak rozpocząć projekt Big Data?

Najpierw warto odpowiedzieć na kilka pytań.

1. Jaki problem chcemy rozwiązać?
2. Jakie decyzje mają być podejmowane?
3. Jakie dane są potrzebne?
4. Skąd pochodzą?
5. Jaki mają wolumen?
6. Jak szybko powstają?
7. Jak długo muszą być przechowywane?
8. Jakiej aktualności wymaga wynik?
9. Kto będzie korzystać z informacji?

Dopiero później dobiera się technologię.

Proof of Concept

Przed budową ogromnej platformy można przygotować mały eksperyment.

PoC pozwala sprawdzić:

• czy dane rzeczywiście istnieją,
• czy mają wystarczającą jakość,
• czy analiza daje wartość,
• czy technologia jest odpowiednia.

To znacznie tańsze niż odkrycie po roku, że cały projekt opierał się na błędnych założeniach.

MVP platformy danych

Podobnie jak w przypadku innych produktów, można rozpocząć od minimalnego zakresu.

Przykładowo najpierw połączyć:

• sprzedaż,
• reklamy,
• stany magazynowe.

Jeżeli rozwiązanie daje wartość, można później dodawać kolejne źródła.

Big Data w małej firmie

Mała firma zazwyczaj nie posiada problemu Big Data w klasycznym znaczeniu.

Znacznie częściej ma problem:

• rozproszonych danych,
• braku integracji,
• ręcznych raportów,
• niespójnych identyfikatorów.

Nie należy rozwiązywać problemu pięciu plików Excel systemem zaprojektowanym dla miliardów zdarzeń.

Prostota jest wartością.

Kiedy mała firma może zetknąć się z Big Data?

Może się to wydarzyć, jeśli jej produkt sam generuje ogromną ilość informacji.

Przykładem może być firma oferująca:

• platformę SaaS,
• system IoT,
• analitykę ruchu,
• monitoring urządzeń.

Wielkość przedsiębiorstwa i wielkość danych nie muszą więc być bezpośrednio powiązane.

Big Data a decyzje biznesowe

Największą wartością danych nie jest sam raport.

Jest nią lepsza decyzja.

Przykładowo analiza może pokazać:

• które produkty warto zatowarować,
• które procesy generują straty,
• gdzie rośnie ryzyko awarii,
• który segment klientów rezygnuje.

Jeżeli firma nie podejmuje na tej podstawie żadnego działania, projekt analityczny może nie tworzyć realnej wartości.

Correlation is not causation

Duże zbiory pozwalają odkrywać bardzo wiele korelacji.

Nie każda oznacza związek przyczynowy.

Dwie wartości mogą zmieniać się razem z zupełnie innego powodu.

Im więcej danych analizujemy, tym więcej przypadkowych zależności możemy znaleźć.

Dlatego wyniki nadal wymagają interpretacji.

Big Data nie zastępuje eksperymentów

Analiza historyczna może sugerować hipotezę.

Jeżeli chcemy sprawdzić, czy konkretna zmiana rzeczywiście powoduje wzrost konwersji, eksperyment może dać znacznie mocniejszy dowód.

Dane obserwacyjne i eksperymenty rozwiązują trochę inne problemy.

Bias w danych

Zbiór może być ogromny i jednocześnie niereprezentatywny.

Jeżeli dane pochodzą tylko od określonej grupy użytkowników, model może działać gorzej dla pozostałych.

Duża liczba rekordów nie eliminuje automatycznie błędu próby.

Big Data a człowiek

Automatyczne systemy mogą analizować ogromne ilości informacji, ale nadal potrzebne jest zrozumienie kontekstu biznesowego.

Analityk może zobaczyć nietypowy wzrost sprzedaży.

Osoba znająca biznes wie, że tego dnia rozpoczęła się konkretna promocja.

Najlepsze rezultaty często powstają z połączenia danych i wiedzy domenowej.

Data-driven a data-informed

Organizacja data-driven próbuje podejmować decyzje na podstawie danych.

Określenie data-informed podkreśla natomiast, że dane są jednym z elementów decyzji, a nie jedynym źródłem prawdy.

W praktyce drugie podejście bywa rozsądniejsze.

Dane mogą być:

• niepełne,
• opóźnione,
• błędnie zinterpretowane.

Demokratyzacja danych

W dobrze działającej organizacji nie każda odpowiedź powinna wymagać kontaktu z jednym analitykiem.

Odpowiednio przygotowane narzędzia mogą pozwolić pracownikom samodzielnie analizować podstawowe informacje.

Trzeba jednak zadbać o wspólne definicje i jakość, żeby każdy nie tworzył własnej wersji prawdy.

Self-Service Analytics

Self-Service Analytics oznacza możliwość tworzenia analiz przez użytkowników biznesowych bez ciągłego angażowania zespołu technicznego.

Może to znacznie przyspieszyć pracę.

Warunkiem jest jednak dobrze przygotowana warstwa danych.

Czy Big Data to przyszłość każdej firmy?

Nie każda firma potrzebuje systemu Big Data.

Każda firma natomiast korzysta na tym, że jej dane są:

• uporządkowane,
• spójne,
• dostępne,
• wiarygodne.

Czasami najlepszą decyzją technologiczną jest świadome pozostanie przy prostszym rozwiązaniu.

Najważniejsze pytanie: po co te dane?

Big Data potrafi imponować skalą.

Miliardy rekordów, klastry, strumienie i machine learning brzmią zaawansowanie.

Technologia nie jest jednak celem samym w sobie.

Najważniejsze pytanie pozostaje bardzo proste:

jaką wartość biznesową uzyskam dzięki przechowywaniu i analizowaniu tych informacji?

Jeżeli nie ma dobrej odpowiedzi, największym osiągnięciem projektu może być wyłącznie bardzo duży rachunek za infrastrukturę.

Co warto zapamiętać o Big Data?

Big Data opisuje zbiory danych, których skala, szybkość powstawania lub różnorodność powodują, że ich obsługa wymaga bardziej zaawansowanego podejścia.

Najpopularniejszy model 3V opisuje Volume, Velocity i Variety, czyli objętość, szybkość oraz różnorodność. Rozszerzony model uwzględnia także wiarygodność i wartość danych.

Duże zbiory mogą pochodzić ze sklepów internetowych, aplikacji, czujników, logów serwerowych, transakcji i wielu innych źródeł.

Do ich przetwarzania wykorzystuje się między innymi systemy rozproszone, hurtownie danych, Data Lake, pipeline'y ETL i ELT, przetwarzanie batchowe oraz strumieniowe.

Największym problemem nie zawsze jest jednak sama skala. Bardzo często większym wyzwaniem są jakość danych, identyfikatory, różne definicje, brak monitoringu i niespójne źródła.

Big Data może wspierać analitykę, rekomendacje, prognozowanie, logistykę, wykrywanie fraudów i automatyzację procesów. Nie daje jednak wartości automatycznie.

Najlepszy system danych nie zaczyna się od wyboru najbardziej zaawansowanej technologii. Zaczyna się od konkretnego pytania biznesowego, jasnej definicji danych i zrozumienia, jaka decyzja ma zostać dzięki nim podjęta.