Data Pipeline

Potok danych to seria kroków przetwarzania danych. Jeśli dane nie są aktualnie załadowane do platformy danych, są one pobierane na początku potoku. Następnie wykonywana jest seria kroków, w których każdy krok dostarcza dane wyjściowe, które są danymi wejściowymi dla następnego kroku. Trwa to do momentu, gdy potok jest kompletny. W niektórych przypadkach niezależne kroki mogą być uruchamiane równolegle.

Rurociągi danych składają się z trzech kluczowych elementów: źródła, kroku lub kroków przetwarzania oraz miejsca docelowego. W niektórych rurociągach danych miejsce docelowe może być nazywane zlewem. Rurociągi danych umożliwiają przepływ danych z aplikacji do hurtowni danych, z jeziora danych do bazy danych analitycznych lub na przykład do systemu przetwarzania płatności. Rurociągi danych mogą również mieć to samo źródło i zlew, co oznacza, że rurociąg polega wyłącznie na modyfikacji zbioru danych. Za każdym razem, gdy dane są przetwarzane między punktem A i punktem B (lub punktami B, C i D), istnieje rurociąg danych między tymi punktami.

As organizations look to build applications with small code bases that serve a very specific purpose (these types of applications are called „microservices”), they are moving data between more and more applications, making the efficiency of data pipelines a critical consideration in their planning and development. Dane generowane w jednym systemie źródłowym lub aplikacji mogą zasilać wiele potoków danych, a te potoki mogą mieć wiele innych potoków lub aplikacji, które są zależne od ich danych wyjściowych.

Rozważmy pojedynczy komentarz w mediach społecznościowych. Zdarzenie to może generować dane do zasilenia raportu w czasie rzeczywistym zliczającego wzmianki w mediach społecznościowych, aplikacji do analizy sentymentu, która podaje wynik pozytywny, negatywny lub neutralny, lub aplikacji wyświetlającej każdą wzmiankę na mapie świata. Chociaż dane pochodzą z tego samego źródła we wszystkich przypadkach, każda z tych aplikacji jest zbudowana na unikalnych potokach danych, które muszą być płynnie zakończone, zanim użytkownik końcowy zobaczy wynik.

Wspólne kroki w potokach danych obejmują przekształcanie danych, powiększanie, wzbogacanie, filtrowanie, grupowanie, agregowanie i uruchamianie algorytmów względem tych danych.

Czym jest potok Big Data?

Ponieważ ilość, różnorodność i szybkość danych dramatycznie wzrosły w ostatnich latach, architekci i programiści musieli dostosować się do „big data”. Termin „big data” sugeruje, że mamy do czynienia z ogromną objętością danych. Ta ilość danych może otworzyć możliwości dla przypadków użycia, takich jak analityka predykcyjna, raportowanie w czasie rzeczywistym i ostrzeganie, wśród wielu przykładów.

Jak wiele komponentów architektury danych, potoki danych ewoluowały, aby wspierać big data. Rurociągi big data to rurociągi danych zbudowane w celu dostosowania się do jednej lub więcej z trzech cech big data. Szybkość big data sprawia, że atrakcyjnym rozwiązaniem jest budowanie potoków danych strumieniowych dla big data. Wówczas dane mogą być przechwytywane i przetwarzane w czasie rzeczywistym, dzięki czemu może nastąpić jakaś akcja. Objętość big data wymaga, aby rurociągi danych były skalowalne, ponieważ objętość może być zmienna w czasie. W praktyce może wystąpić wiele zdarzeń big data, które występują jednocześnie lub bardzo blisko siebie, więc potok big data musi być w stanie skalować się do jednoczesnego przetwarzania znacznych ilości danych. Różnorodność big data wymaga, aby potoki big data były w stanie rozpoznawać i przetwarzać dane w wielu różnych formatach – ustrukturyzowanych, nieustrukturyzowanych i półstrukturalnych.

Potok danych a ETL

ETL odnosi się do określonego typu potoku danych. ETL to skrót od „extract, transform, load”. Jest to proces przenoszenia danych ze źródła, takiego jak aplikacja, do miejsca docelowego, zwykle hurtowni danych. „Extract” odnosi się do wyciągania danych ze źródła; „transform” dotyczy modyfikowania danych, aby można je było załadować do miejsca docelowego, a „load” dotyczy wstawiania danych do miejsca docelowego.

ETL był historycznie używany do obciążeń wsadowych, zwłaszcza na dużą skalę. Ale nowa rasa strumieniowych narzędzi ETL pojawia się jako część rurociągu dla strumieniowych danych zdarzeń w czasie rzeczywistym.

Rozważania dotyczące rurociągu danych

Architektury rurociągów danych wymagają wielu rozważań. Na przykład, czy Twój rurociąg musi obsługiwać dane strumieniowe? Jakiej szybkości danych oczekujesz? Jak dużo i jakiego rodzaju przetwarzanie musi się odbywać w rurociągu danych? Czy dane są generowane w chmurze czy w siedzibie firmy i dokąd muszą trafić? Czy planujesz zbudować rurociąg z mikroserwisów? Czy istnieją konkretne technologie, w których twój zespół jest już dobrze zaznajomiony z programowaniem i utrzymaniem?

Przykłady architektury

Rurociągi danych mogą być projektowane na kilka różnych sposobów. Jednym z powszechnych przykładów jest rurociąg danych oparty na danych wsadowych. W tym przykładzie można mieć aplikację, taką jak system punktu sprzedaży, która generuje dużą liczbę punktów danych, które trzeba przesłać do hurtowni danych i bazy danych analitycznych. Oto przykład tego, jak by to wyglądało:

Przykład potoku danych
Podstawowy przykład potoku danych.

Innym przykładem jest potok danych strumieniowych. W potoku danych strumieniowych dane z systemu punktów sprzedaży byłyby przetwarzane w miarę ich generowania. Silnik przetwarzania strumieniowego mógłby przekazywać dane wyjściowe z potoku do sklepów z danymi, aplikacji marketingowych i CRM, wśród innych aplikacji, jak również z powrotem do samego systemu punktu sprzedaży.

Schemat potoku danych strumieniowych
Schemat ten modeluje potok danych strumieniowych. Strumień danych jest zarządzany przez framework przetwarzania strumieniowego, gdzie może być przetwarzany i dostarczany do aplikacji i/lub rozwiązań.

Trzecim przykładem potoku danych jest architektura Lambda, która łączy potoki wsadowe i strumieniowe w jedną architekturę. Architektura Lambda jest popularna w środowiskach big data, ponieważ umożliwia programistom uwzględnienie zarówno przypadków użycia strumieniowego w czasie rzeczywistym, jak i historycznej analizy wsadowej. Jednym z kluczowych aspektów tej architektury jest to, że zachęca ona do przechowywania danych w surowym formacie, dzięki czemu można stale uruchamiać nowe potoki danych w celu poprawienia błędów kodu w poprzednich potokach lub tworzenia nowych miejsc docelowych danych, które umożliwiają nowe typy zapytań.

Schemat architektury Lambda
Architektura Lambda uwzględnia zarówno tradycyjny potok danych wsadowych, jak i potok strumieniowy danych w czasie rzeczywistym. Posiada również warstwę obsługi, która odpowiada na zapytania.

Powiązane tematy

Streaming ETL

Architektura Lambda

Przetwarzanie strumieniowe

.

Dodaj komentarz