Styl architektury danych big data

Architektura danych big data została zaprojektowana do obsługi wprowadzania, przetwarzania i analizy danych, które są zbyt duże lub zbyt złożone dla tradycyjnych systemów baz danych.

Diagram logiczny stylu architektury danych big data

Rozwiązania do obsługi danych big data obejmują na ogół co najmniej jeden z następujących typów obciążenia:

  • Przetwarzanie wsadowe źródeł danych big data w stanie spoczynku.
  • Przetwarzanie w czasie rzeczywistym danych big data w ruchu.
  • Interakcyjna eksploracja danych big data.
  • Analiza predykcyjna i uczenie maszynowe.

Większość architektur big data zawiera niektóre lub wszystkie z następujących składników:

  • Źródła danych: wszystkie rozwiązania typu big data powstają w oparciu o co najmniej jedno źródło danych. Przykłady:

    • Magazyny danych aplikacji, takie jak relacyjne bazy danych.
    • Pliki statyczne tworzone przez aplikacje, takie jak pliki dzienników serwerów internetowych.
    • Źródła danych czasu rzeczywistego, np. urządzenia IoT.
  • Magazyn danych: dane do operacji przetwarzania wsadowego są na ogół przechowywane w rozproszonym magazynie plików, który może pomieścić duże ilości dużych plików w różnych formatach. Taki rodzaj magazynu jest często określany jako data lake. Opcje implementacji tego magazynu obejmują usługę Azure Data Lake Store lub kontenery obiektów blob w usłudze Azure Storage.

  • Przetwarzanie wsadowe: z powodu tak dużych zestawów danych rozwiązanie do obsługi danych big data musi często przetwarzać pliki danych przy użyciu długotrwałych zadań wsadowych, aby filtrować, agregować i przygotowywać w inny sposób dane do analizy. Na ogół zadania te obejmują odczytywanie plików źródłowych, przetwarzanie ich i zapisywanie danych wyjściowych do nowych plików. Opcje obejmują uruchamianie zadań U-SQL w usłudze Azure Data Lake Analytics, używanie programów Hive, Pig, niestandardowych zadań Map/Reduce w klastrze usługi HDInsight Hadoop lub wykorzystanie programów Java, Scala lub Python w klastrze usługi HDInsight Spark.

  • Wprowadzanie komunikatów w czasie rzeczywistym: jeśli rozwiązanie zawiera źródła danych czasu rzeczywistego, architektura musi obejmować sposób na przechwytywanie i przechowywanie komunikatów w czasie rzeczywistym do przetwarzania strumieniowego. Może to być zwykły magazyn danych, gdzie przychodzące komunikaty są umieszczane w folderze w celu przetworzenia. Jednak wiele rozwiązań wymaga, aby magazyn wprowadzający komunikaty pełnił rolę bufora dla komunikatów, a także oferował zwiększanie w poziomie skali przetwarzania, niezawodne dostarczanie i inne elementy semantyki kolejkowania komunikatów. Opcje obejmują usługi Azure Event Hubs, Azure IoT Hubs i Kafka.

  • Przetwarzanie strumienia: po przechwyceniu komunikatów w czasie rzeczywistym rozwiązanie musi je przetworzyć, filtrując, agregując i przygotowując w inny sposób dane do analizy. Przetworzony strumień danych zostaje następnie zapisany do ujścia danych wyjściowych. Usługa Azure Stream Analytics to usługa zarządzanego przetwarzania strumienia w oparciu o stale działające zapytania SQL pracujące na niepowiązanych strumieniach. Można również użyć rozwiązań typu open source opartych o technologie przesyłania strumieniowego Apache, takich jak Storm i Spark Streaming w klastrze usługi HDInsight.

  • Magazyn danych analitycznych: wiele rozwiązań do obsługi danych big data przygotowuje dane do analizy, a następnie przekazuje przetworzone dane w formacie ustrukturyzowanym, który może być odpytywany za pomocą narzędzi analitycznych. Magazynem danych analitycznych używanym do obsługi tych zapytań może być relacyjny magazyn danych w architekturze Kimballa, stosowany w tradycyjnych rozwiązaniach z zakresu analizy biznesowej (BI). Dane mogą być także przedstawiane za pomocą zapewniającej niskie opóźnienia technologii NoSQL, np. HBase, lub interakcyjnej bazy danych Hive zapewniającej abstrakcję metadanych nad plikami danych w rozproszonym magazynie danych. Usługa Azure Synapse Analytics oferuje zarządzaną usługę magazynowania danych na dużą skalę w oparciu o chmurę. Usługa HDInsight obsługuje interakcyjne klastry Hive, HBase i Spark SQL, które można także wykorzystać do obsługi danych do analizy.

  • Analiza i raportowanie: celem większości rozwiązań typu big data jest udostępnienie szczegółowych informacji na temat danych przy użyciu analizy i raportowania. Aby dać użytkownikom możliwość analizowania danych, architektura może obejmować warstwę modelowania danych, np. wielowymiarowy moduł OLAP lub model danych tabelarycznych w usłudze Azure Analysis Services. Może również obsługiwać samoobsługową analizę biznesową, korzystając z technologii wizualizacji i modelowania w usłudze Microsoft Power BI lub Microsoft Excel. Analiza i raportowanie może również przyjmować formę interakcyjnej eksploracji danych przez analityków danych i naukowców pracujących z danymi. Pod kątem takich scenariuszy wiele usług platformy Azure obsługuje notesy analityczne, takie jak Jupyter, pozwalając użytkownikom na wykorzystanie posiadanych umiejętności z użyciem języka Python lub R. W przypadku eksploracji danych na dużą skalę można użyć platformy Microsoft R Server, samodzielnie lub wraz z platformą Spark.

  • Aranżacja: większość rozwiązań typu big data składa się z powtarzanych operacji przetwarzania danych, zhermetyzowanych w ramach przepływów pracy, które przetwarzają dane źródłowe, przenoszą dane między różnymi źródłami i ujściami, ładują przetworzone dane do magazynu danych analitycznych lub wypychają wyniki bezpośrednio do raportu lub pulpitu nawigacyjnego. Aby zautomatyzować te przepływy pracy, można użyć technologii aranżacji, takich Azure Data Factory, Apache Oozie i Sqoop.

Platforma Azure zapewnia wiele usług, których można użyć w ramach architektury danych big data. Zasadniczo można je podzielić na dwie kategorie:

  • Usługi zarządzane, w tym usługi Azure Data Lake Store, Azure Data Lake Analytics, Azure Synapse Analytics, Azure Stream Analytics, Azure Event Hub, Azure IoT Hub i Azure Data Factory.
  • Technologie typu open source oparte na platformie Apache Hadoop, w tym HDFS, HBase, Hive, Pig, Spark, Storm, Oozie, Sqoop i Kafka. Technologie te są dostępne na platformie Azure w usłudze Azure HDInsight.

Te opcje nie wykluczają się wzajemnie i wiele rozwiązań łączy technologie typu open source z usługami platformy Azure.

Kiedy stosować tę architekturę

Weź pod uwagę ten styl architektury, jeśli chcesz:

  • Przechowywać i przetwarzać dane w ilościach zbyt dużych dla tradycyjnych baz danych.
  • Przekształcać dane nieustrukturyzowane na potrzeby analizy i raportowania.
  • Przechwytywać, przetwarzać i analizować niepowiązane strumienie danych w czasie rzeczywistym lub z niewielkim opóźnieniem.
  • Używać usługi Azure Machine Learning lub Microsoft Cognitive Services.

Korzyści

  • Wybór technologii. Możliwość mieszania i dopasowywania usług zarządzanych platformy Azure oraz technologii Apache w klastrach HDInsight, aby wykorzystać posiadane umiejętności lub inwestycje w technologie.
  • Wydajność dzięki równoległości. Rozwiązania typu big data korzystają z zalet równoległości, zapewniając wysokowydajne rozwiązania skalowalne do dużych ilości danych.
  • Elastyczne skalowanie. Wszystkie składniki architektury danych big data obsługują zwiększanie w poziomie skali aprowizowania, co pozwala dopasować rozwiązanie do małych i dużych obciążeń oraz płacić tylko za wykorzystane zasoby.
  • Współdziałanie z istniejącymi rozwiązaniami. Składniki architektury danych big data są również używane w ramach rozwiązań przetwarzania IoT oraz rozwiązań analizy biznesowej dla przedsiębiorstw, pozwalając na tworzenie zintegrowanych rozwiązań obejmujących różne obciążenia w zakresie danych.

Wyzwania

  • Złożoność. Rozwiązania do obsługi danych big data mogą być bardzo skomplikowane, z wieloma składnikami obsługującymi pozyskiwanie danych z wielu źródeł danych. Tworzenie i testowanie procesów dotyczących danych big data oraz rozwiązywanie związanych z nimi problemów może stanowić wyzwanie. Ponadto może istnieć duża liczba ustawień konfiguracji w wielu systemach, które muszą zostać zastosowane w celu zoptymalizowania wydajności.
  • Umiejętności. Wiele technologii danych big data to technologie wysoce specjalistyczne, wykorzystujące platformy i języki, które nie są typowe dla bardziej ogólnych architektur aplikacji. Z drugiej strony technologie danych big data tworzą nowe interfejsy API, które wykorzystują sprawdzone języki. Na przykład język U-SQL w usłudze Azure Data Lake Analytics bazuje na kombinacji języków Transact-SQL i C#. Analogicznie dostępne są interfejsy API oparte na języku SQL dla usług Hive, HBase i Spark.
  • Dojrzałość technologii. Wiele technologii używanych do obsługi danych big data wciąż ewoluuje. Choć podstawowe technologie Hadoop, takie jak Hive i Pig są już stabilne, nowe technologie, takie jak Spark, charakteryzują się rozległymi zmianami i ulepszeniami w kolejnych wersjach. Usługi zarządzane, takie jak Azure Data Lake Analytics i Azure Data Factory, są stosunkowo młode w porównaniu z innymi usługami platformy Azure i z czasem będą się prawdopodobnie zmieniać.
  • Bezpieczeństwo. Rozwiązania do obsługi danych big data działają na ogół w oparciu o przechowywanie wszystkich danych statycznych w scentralizowanym magazynie typu data lake. Zabezpieczanie dostępu do tych danych może być trudne, szczególnie w przypadku, gdy dane muszą być pozyskiwane i używane przez wiele platform i aplikacji.

Najlepsze rozwiązania

  • Wykorzystanie równoległości. Większość technologii przetwarzania danych big data rozkłada obciążenie na wiele jednostek przetwarzających. Wymaga to, aby pliki danych statycznych były tworzone i przechowywane w podzielnym formacie. Systemy plików rozproszonych, np. system plików HDFS, mogą optymalizować wydajność odczytu i zapisu, a faktyczne przetwarzanie jest realizowane przez wiele węzłów klastra równolegle, co zmniejsza całkowity czas zadania.

  • Podziel dane na partycje. Przetwarzanie wsadowe zwykle odbywa się zgodnie z cyklicznym harmonogramem — na przykład co tydzień lub co miesiąc. Partycjonowanie plików danych i struktur danych, takich jak tabele, należy przeprowadzać w oparciu o okresy czasowe zgodne z harmonogramem przetwarzania. Upraszcza to pozyskiwanie danych oraz planowanie zadań i ułatwia usuwanie awarii. Ponadto partycjonowanie tabel, które są wykorzystywane w zapytaniach Hive, U-SQL lub SQL, może znacznie poprawić wydajność zapytań.

  • Stosowanie semantyki schematu przy odczycie. Wykorzystanie magazynu typu data lake pozwala na łączne magazynowanie plików w wielu formatach, zarówno ustrukturyzowanych, częściowo ustrukturyzowanych, jak i nieustrukturyzowanych. Użyj semantyki schematu przy odczycie, która dokonuje projekcji schematu na dane podczas przetwarzania danych, a nie gdy dane są przechowywane. Pozwala to nadać elastyczność rozwiązaniu i zapobiega powstawaniu wąskich gardeł na skutek weryfikacji danych i sprawdzania ich typu podczas pozyskiwania danych.

  • Przetwarzanie danych w miejscu. Tradycyjne rozwiązania analizy biznesowej często używają procesu wyodrębniania, przekształcania i ładowania (ETL) do przenoszenia danych do magazynu danych. W przypadku większych ilości danych i większej różnorodności formatów rozwiązania typu big data używają na ogół odmian ETL, takich jak przekształcanie, wyodrębnianie i ładowanie (TEL). Przy tej metodzie dane są przetwarzane w rozproszonym magazynie danych i przekształcane do wymaganej struktury przed przeniesieniem przekształconych danych do analitycznego magazynu danych.

  • Równoważenie kosztów wykorzystania i czasu. W przypadku zadań przetwarzania wsadowego należy wziąć pod uwagę dwa czynniki: koszt jednostkowy węzłów obliczeniowych i koszt za minutę używania tych węzłów do wykonania zadania. Zadanie wsadowe może na przykład potrwać osiem godzin z użyciem czterech węzłów klastra. Może się jednak okazać, że zadanie wykorzystuje wszystkie cztery węzły tylko podczas pierwszych dwóch godzin, a następnie wymagane są tylko dwa węzły. W takim przypadku uruchomienie całego zadania na dwóch węzłach wydłuży łączny czas zadania, ale nie dwukrotnie, więc całkowity koszt będzie mniejszy. W niektórych scenariuszach biznesowych dłuższy czas przetwarzania może być preferowany niż wyższy koszt używania niedostatecznie możliwych zasobów klastra.

  • Oddzielenie zasobów klastra. Wdrażając klastry usługi HDInsight, można zwykle uzyskać większą wydajność przez aprowizowanie osobnych zasobów klastra dla każdego typu obciążenia. Przykładowo, chociaż klastry Spark obejmują platformę Hive, chcąc przeprowadzić rozległe przetwarzanie z użyciem zarówno platformy Spark, jak i Hive, należy rozważyć wdrożenie oddzielnych dedykowanych klastrów Spark i Hadoop. Podobnie jeśli używasz rozwiązań HBase i Storm do przetwarzania strumieni z niewielkim opóźnieniem i Hive do przetwarzania wsadowego, weź pod uwagę osobne klastry Storm, HBase i Hadoop.

  • Orkiestracja pozyskiwania danych. W niektórych przypadkach istniejące aplikacje biznesowe mogą zapisywać pliki danych do przetwarzania wsadowego bezpośrednio do kontenerów obiektów blob magazynu platformy Azure, gdzie mogą być używane przez usługi HDInsight lub Azure Data Lake Analytics. Jednak często konieczna będzie orkiestracja procesu wprowadzania danych z lokalnych lub zewnętrznych źródeł danych do magazynu typu data lake. Aby tego dokonać w sposób przewidywalny i centralnie zarządzany, należy użyć przepływu pracy lub potoku organizacyjnego, takiego jak te obsługiwane przez usługi Azure Data Factory lub Oozie.

  • Czyszczenie danych poufnych na wczesnym etapie. Przepływ pracy pozyskiwania danych powinien czyścić dane poufne na początkowym etapie procesu, aby uniknąć ich przechowywania w magazynie typu data lake.

Architektura IoT

Internet rzeczy (IoT) to wyspecjalizowany podzbiór rozwiązań do przetwarzania danych big data. Na poniższym diagramie przedstawiono przykładową architekturę logiczną dla IoT. Diagram kładzie nacisk na składniki strumienia zdarzeń architektury.

Diagram architektury IoT

Brama w chmurze pozyskuje zdarzenia urządzenia na granicy chmury, używając niezawodnego systemu obsługi komunikatów o niskich opóźnieniach.

Urządzenia mogą wysyłać zdarzenia bezpośrednio do bramy w chmurze lub za pośrednictwem bramy działającej w terenie. Brama działająca w terenie to wyspecjalizowane urządzenie lub oprogramowanie, zwykle kolokowane z urządzeniami, które odbiera zdarzenia i przekazuje je do bramy w chmurze. Brama działająca w terenie może również wstępnie przetwarzać nieprzetworzone zdarzenia urządzenia, wykonując takie funkcje jak filtrowanie, agregacja lub przekształcanie protokołu.

Po pozyskaniu zdarzenia przechodzą przez co najmniej jeden procesor strumieni, który może kierować dane (na przykład do magazynu) lub wykonywać analizy i inne procesy.

Poniżej przedstawiono niektóre typowe typy przetwarzania. (Ta lista na pewno nie jest wyczerpująca).

  • Zapisywanie danych zdarzeń do zimnego magazynu w celu zarchiwizowania lub przeprowadzenia analizy partii.

  • Analiza ścieżki aktywnej badająca strumień zdarzeń (prawie) w czasie rzeczywistym w celu wykrycia anomalii, rozpoznania wzorców na przestrzeni przedziałów czasu lub wyzwolenia alertów po wystąpieniu w strumieniu określonego warunku.

  • Obsługa specjalnych typów komunikatów nietelemetrycznych z urządzeń, takich jak powiadomienia i alarmy.

  • Uczenie maszynowe.

W wyszarzonych polach przedstawiono składniki systemu IoT, które nie są bezpośrednio związane z przesyłaniem strumieniowym zdarzeń, ale zostały uwzględnione, aby informacje były kompletne.

  • Rejestr urządzenia to baza danych aprowizowanych urządzeń, w tym identyfikatorów urządzeń i zwykle metadanych urządzeń, takich jak lokalizacja.

  • Aprowizujący interfejs API to wspólny interfejs zewnętrzny aprowizujący i rejestrujący nowe urządzenia.

  • Niektóre rozwiązania IoT umożliwiają wysyłanie komunikatów poleceń i komunikatów sterujących do urządzeń.

W tej części przedstawiono bardzo ogólny widok rozwiązania IoT; istnieje jeszcze wiele precyzyjnych kwestii, które należy uwzględnić. Bardziej szczegółowa architektura referencyjna oraz omówienie znajduje się w temacie Architektura referencyjna IoT platformy Microsoft Azure (do pobrania w formacie PDF).

Następne kroki