W tym artykule opisano, jak fikcyjne biuro planowania miasta może korzystać z tego rozwiązania. Rozwiązanie udostępnia kompleksowe potok danych, który jest zgodny ze wzorcem architektury MDW wraz z odpowiednimi procesami DevOps i DataOps, w celu oceny użycia parkingu i podejmowania bardziej świadomych decyzji biznesowych.
Architektura
Na poniższym diagramie przedstawiono ogólną architekturę rozwiązania.
Pobierz plik programu Visio z tą architekturą.
Przepływ danych
Usługa Azure Data Factory organizuje i usługa Azure Data Lake Storage Gen2 przechowuje dane:
Interfejs API usługi internetowej parkingu miejskiego firmy Contoso jest dostępny do przesyłania danych z miejsc parkingowych.
Istnieje zadanie kopiowania fabryki danych, które przesyła dane do schematu docelowej.
Następnie usługa Azure Databricks czyści i standandaryzuje dane. Pobiera ona nieprzetworzone dane i warunki, aby analitycy danych mogli z nich korzystać.
Jeśli walidacja ujawni jakiekolwiek nieprawidłowe dane, zostanie ona porzucona do schematu Źle sformułowanego.
Ważne
Osoby zapytały, dlaczego dane nie są weryfikowane przed ich zapisaniem w usłudze Data Lake Storage. Przyczyną jest to, że walidacja może spowodować wprowadzenie usterki, która może uszkodzić zestaw danych. Jeśli w tym kroku wprowadzisz usterkę, możesz naprawić usterkę i odtworzyć potok. W przypadku porzucania nieprawidłowych danych przed dodaniu ich do usługi Data Lake Storage uszkodzone dane są bezużyteczne, ponieważ nie można odtworzyć potoku.
Istnieje drugi krok przekształcania usługi Azure Databricks, który konwertuje dane na format, który można przechowywać w magazynie danych.
Na koniec potok obsługuje dane na dwa różne sposoby:
Usługa Databricks udostępnia dane analitykowi danych, aby mogły trenować modele.
Program Polybase przenosi dane z usługi Data Lake do usługi Azure Synapse Analytics, a usługa Power BI uzyskuje dostęp do danych i prezentuje je użytkownikowi biznesowemu.
Składniki
Rozwiązanie korzysta z następujących składników:
Szczegóły scenariusza
Nowoczesny magazyn danych (MDW) umożliwia łatwe łączenie wszystkich danych w dowolnej skali. Nie ma znaczenia, czy są to dane ustrukturyzowane, nieustrukturyzowane lub częściowo ustrukturyzowane. Szczegółowe informacje dotyczące rozwiązania MDW można uzyskać za pomocą analitycznych pulpitów nawigacyjnych, raportów operacyjnych lub zaawansowanych analiz dla wszystkich użytkowników.
Konfigurowanie środowiska MDW dla środowisk deweloperskich (deweloperskich) i produkcyjnych (prod) jest złożone. Automatyzacja procesu jest kluczem. Pomaga zwiększyć produktywność przy jednoczesnym zminimalizowaniu ryzyka błędów.
W tym artykule opisano, jak fikcyjne biuro planowania miasta może korzystać z tego rozwiązania. Rozwiązanie udostępnia kompleksowe potok danych, który jest zgodny ze wzorcem architektury MDW wraz z odpowiednimi procesami DevOps i DataOps, w celu oceny użycia parkingu i podejmowania bardziej świadomych decyzji biznesowych.
Wymagania dotyczące rozwiązania
Możliwość zbierania danych z różnych źródeł lub systemów.
Infrastruktura jako kod: wdrażaj nowe środowiska deweloperskie i przejściowe (stg) w zautomatyzowany sposób.
Wdróż zmiany aplikacji w różnych środowiskach w zautomatyzowany sposób:
Implementowanie potoków ciągłej integracji i ciągłego dostarczania (CI/CD).
Użyj bram wdrożenia do zatwierdzania ręcznego.
Potok jako kod: upewnij się, że definicje potoku ciągłej integracji/ciągłego wdrażania są w kontroli źródła.
Przetestuj testy integracji dotyczące zmian przy użyciu przykładowego zestawu danych.
Uruchamianie potoków zgodnie z harmonogramem.
Obsługa przyszłego tworzenia zwinnego, w tym dodawanie obciążeń nauki o danych.
Obsługa zabezpieczeń na poziomie wiersza i na poziomie obiektu:
Funkcja zabezpieczeń jest dostępna w usłudze SQL Database.
Można je również znaleźć w usługach Azure Synapse Analytics, Azure Analysis Services i Power BI.
Obsługa 10 współbieżnych użytkowników pulpitu nawigacyjnego i 20 współbieżnych użytkowników zasilania.
Potok danych powinien przeprowadzać walidację danych i filtrować źle sformułowane rekordy do określonego magazynu.
Obsługa monitorowania.
Scentralizowana konfiguracja w bezpiecznym magazynie, na przykład Azure Key Vault.
Potencjalne przypadki użycia
W tym artykule użyto fikcyjnego miasta Contoso do opisania scenariusza przypadku użycia. W narracji firma Contoso jest właścicielem czujników parkingowych dla miasta i zarządza nimi. Jest również właścicielem interfejsów API, które łączą się z czujnikami i pobierają dane z tych czujników. Potrzebują platformy, która będzie zbierać dane z wielu różnych źródeł. Następnie dane muszą zostać zweryfikowane, oczyszczone i przekształcone w znany schemat. Planiści miast firmy Contoso mogą następnie eksplorować i oceniać dane raportów dotyczące korzystania z parkingu za pomocą narzędzi do wizualizacji danych, takich jak usługa Power BI, aby określić, czy potrzebują więcej zasobów parkingowych, czy powiązanych.
Kwestie wymagające rozważenia
Te zagadnienia implementują filary struktury Azure Well-Architected Framework, która jest zestawem wytycznych, które mogą służyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Microsoft Azure Well-Architected Framework.
Zagadnienia przedstawione w tej sekcji podsumowują kluczowe informacje i najlepsze rozwiązania przedstawione w tym rozwiązaniu:
Uwaga
Każda kwestia w tej sekcji zawiera linki do powiązanej sekcji Key Learnings w dokumentacji przykładu rozwiązania czujnika parkowania w witrynie GitHub.
Zabezpieczenia
Zabezpieczenia zapewniają ochronę przed celowymi atakami i nadużyciami cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca zabezpieczeń.
Sprawność operacyjna
Doskonałość operacyjna obejmuje procesy operacyjne, które wdrażają aplikację i działają w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Lista kontrolna projektu dotycząca doskonałości operacyjnej.
Wdrażanie tego scenariusza
Poniższa lista zawiera ogólne kroki wymagane do skonfigurowania rozwiązania Czujników parkowania przy użyciu odpowiednich potoków kompilacji i wydania. Szczegółowe kroki konfiguracji i wymagania wstępne można znaleźć w tym repozytorium przykładów platformy Azure.
Konfigurowanie i wdrażanie
Konfiguracja początkowa: zainstaluj wszelkie wymagania wstępne, zaimportuj repozytorium GitHub przykłady platformy Azure do własnego repozytorium i ustaw wymagane zmienne środowiskowe.
Wdrażanie zasobów platformy Azure: rozwiązanie jest dostarczane ze skryptem zautomatyzowanego wdrażania. Wdraża wszystkie niezbędne zasoby platformy Azure i jednostki usługi Microsoft Entra na środowisko. Skrypt wdraża również usługi Azure Pipelines, grupy zmiennych i połączenia usług.
Konfigurowanie integracji z usługą Git w usłudze Dev Data Factory: konfigurowanie integracji z usługą Git w celu pracy z zaimportowanymi repozytorium GitHub.
Przeprowadź początkową kompilację i wydanie: utwórz przykładową zmianę w usłudze Data Factory, na przykład włączenie wyzwalacza harmonogramu, a następnie obejrzyj zmianę automatycznie wdrażaną w różnych środowiskach.
Wdrożone zasoby
Jeśli wdrożenie zakończy się pomyślnie, na platformie Azure powinny znajdować się trzy grupy zasobów reprezentujące trzy środowiska: dev, stg i prod. W usłudze Azure DevOps powinny być również kompleksowe potoki kompilacji i wydania, które mogą automatycznie wdrażać zmiany w tych trzech środowiskach.
Aby uzyskać szczegółową listę wszystkich zasobów, zobacz sekcję Deployed Resources (Wdrożone zasoby ) w artykule DataOps - Parking Sensor Demo README (Pokaz czujnika parkowania).
Ciągła integracja i ciągłe dostarczanie (CI/CD)
Na poniższym diagramie przedstawiono proces ciągłej integracji/ciągłego wdrażania oraz sekwencję potoków kompilacji i wydania.
Pobierz plik programu Visio z tą architekturą.
Deweloperzy opracowują własne środowiska piaskownicy w grupie zasobów deweloperskich i zatwierdzają zmiany we własnych krótkotrwałych gałęziach usługi Git. Na przykład
<developer_name>/<branch_name>
.Po zakończeniu wprowadzania zmian deweloperzy zgłaszają żądanie ściągnięcia do głównej gałęzi do przeglądu. Spowoduje to automatyczne uruchomienie potoku weryfikacji żądania ściągnięcia, który uruchamia testy jednostkowe, linting i kompilacje pakietu aplikacji warstwy danych (DACPAC).
Po zakończeniu weryfikacji żądania ściągnięcia zatwierdzenie na serwerze głównym spowoduje wyzwolenie potoku kompilacji, który publikuje wszystkie niezbędne artefakty kompilacji.
Ukończenie pomyślnego potoku kompilacji spowoduje wyzwolenie pierwszego etapu potoku wydania. Spowoduje to wdrożenie artefaktów kompilacji publikowania w środowisku deweloperskim, z wyjątkiem usługi Data Factory.
Deweloperzy ręcznie publikują w usłudze Dev Data Factory z gałęzi współpracy (głównej). Ręczne publikowanie aktualizuje szablony usługi Azure Resource Manager w
adf_publish
gałęzi .Pomyślne ukończenie pierwszego etapu wyzwala bramę ręcznego zatwierdzania.
Po zatwierdzeniu potok wydania będzie kontynuowany z drugim etapem, wdrażając zmiany w środowisku stg.
Uruchom testy integracji, aby przetestować zmiany w środowisku stg.
Po pomyślnym zakończeniu drugiego etapu potok wyzwala drugą bramę ręcznego zatwierdzania.
Po zatwierdzeniu potok wydania będzie kontynuowany z trzecim etapem, wdrażając zmiany w środowisku prod.
Aby uzyskać więcej informacji, przeczytaj sekcję Build and Release Pipeline (Potok kompilacji i wydania) w pliku README.
Testowanie
Rozwiązanie obejmuje obsługę testowania jednostkowego i testowania integracji. Korzysta z narzędzia pytest-Data Factory i platformy testowania Nutter. Aby uzyskać więcej informacji, zobacz sekcję Testowanie pliku README.
Obserwowanie i monitorowanie
Rozwiązanie obsługuje obserwację i monitorowanie usług Databricks i Data Factory. Aby uzyskać więcej informacji, zobacz sekcję Obserwacja/Monitorowanie pliku README.
Następne kroki
Jeśli chcesz wdrożyć rozwiązanie, wykonaj kroki opisane w sekcji How to use the sample (Jak używać przykładowej sekcji DataOps — Parking Sensor Demo README).
Przykłady kodu rozwiązania w witrynie GitHub
Obserwowanie/monitorowanie
Azure Databricks
- Monitorowanie usługi Azure Databricks za pomocą usługi Azure Monitor
- Monitorowanie zadań usługi Azure Databricks za pomocą usługi Application Insights
Data Factory
- Monitorowanie usługi Azure Data Factory za pomocą usługi Azure Monitor
- Tworzenie alertów w celu proaktywnego monitorowania potoków fabryki danych
Azure Synapse Analytics
- Monitorowanie wykorzystania zasobów i działania zapytań w usłudze Azure Synapse Analytics
- Monitorowanie obciążenia puli SQL usługi Azure Synapse Analytics przy użyciu widoków DMV
Azure Storage
Odporność i odzyskiwanie po awarii
Azure Databricks
Data Factory
Azure Synapse Analytics
Azure Storage
- Odzyskiwanie po awarii i tryb failover konta magazynu
- Najlepsze rozwiązania dotyczące korzystania z usługi Azure Data Lake Storage Gen2 — wysoka dostępność i odzyskiwanie po awarii
- Nadmiarowość usługi Azure Storage
Szczegółowy przewodnik
Aby uzyskać szczegółowy przewodnik po rozwiązaniu i kluczowych pojęciach, obejrzyj następujące nagranie wideo: DataDevOps dla nowoczesnego magazynu danych na platformie Microsoft Azure