Najlepsze rozwiązania dotyczące korzystania z usługi Azure Data Lake Storage

Ten artykuł zawiera wskazówki dotyczące najlepszych rozwiązań, które ułatwiają optymalizowanie wydajności, obniżanie kosztów i zabezpieczanie konta usługi Azure Storage z obsługą usługi Data Lake Storage.

Znajdź dokumentację

Usługa Azure Data Lake Storage nie jest dedykowaną usługą ani typem konta. Jest to zestaw funkcji, które obsługują obciążenia analityczne o wysokiej przepływności. Dokumentacja usługi Data Lake Storage zawiera najlepsze rozwiązania i wskazówki dotyczące korzystania z tych funkcji. Wszystkie inne aspekty zarządzania kontami, takie jak konfigurowanie zabezpieczeń sieci, projektowanie pod kątem wysokiej dostępności i odzyskiwanie po awarii, można znaleźć w dokumentacji usługi Blob Storage.

Ocena obsługi funkcji i znanych problemów

Użyj poniższego wzorca podczas konfigurowania konta do korzystania z funkcji usługi Blob Storage.

1. Zapoznaj się z artykułem Obsługa funkcji usługi Blob Storage na kontach usługi Azure Storage, aby określić, czy funkcja jest w pełni obsługiwana na twoim koncie. Niektóre funkcje nie są jeszcze obsługiwane lub mają częściową obsługę na kontach z włączoną usługą Data Lake Storage. Obsługa funkcji jest zawsze rozszerzana, dlatego należy okresowo przeglądać ten artykuł pod kątem aktualizacji.

2. Zapoznaj się z artykułem Znane problemy z usługą Azure Data Lake Storage , aby sprawdzić, czy istnieją jakiekolwiek ograniczenia lub specjalne wskazówki dotyczące funkcji, która ma być używana.

3. Przejrzyj artykuły dotyczące funkcji, aby uzyskać wskazówki specyficzne dla kont z obsługą usługi Data Lake Storage.

Omówienie terminów używanych w dokumentacji

Podczas przechodzenia między zestawami zawartości zauważysz niewielkie różnice w terminologii. Na przykład w dokumentacji usługi Blob Storage stosuje się termin blob zamiast plik. Technicznie rzecz biorąc, pliki, które przesyłasz na swoje konto magazynu, stają się blobami na twoim koncie. W związku z tym termin jest poprawny. Jednak termin blob może powodować nieporozumienia, jeśli jesteś przyzwyczajony do terminu plik. Zostanie również wyświetlony termin kontener używany do odwoływania się do systemu plików. Należy wziąć pod uwagę te terminy jako synonimy.

Rozważ premium

Jeśli obciążenia wymagają niezmiennie niskich opóźnień lub dużej liczby operacji wejścia/wyjścia na sekundę (IOPS), rozważ użycie konta magazynu blokowych obiektów blob typu Premium. Ten typ konta udostępnia dane za pośrednictwem sprzętu o wysokiej wydajności. Dane są przechowywane na dyskach półprzewodnikowych (SSD), które są zoptymalizowane pod kątem małych opóźnień. Dyski SSD zapewniają większą przepływność w porównaniu z tradycyjnymi dyskami twardymi. Koszty przechowywania przy wydajności premium są wyższe, ale koszty transakcji są niższe. W związku z tym, jeśli obciążenia wykonują dużą liczbę transakcji, konto blokowych obiektów blob o wydajności premium może okazać się opłacalne.

Jeśli twoje konto magazynu będzie używane do analizy danych, zdecydowanie zalecamy, abyś używał Azure Data Lake Storage wraz z kontem magazynowania blokowych blobów premium. Ta kombinacja użycia kont magazynu blokowych obiektów blob w warstwie Premium wraz z kontem z włączoną usługą Data Lake Storage jest nazywana warstwą Premium dla usługi Azure Data Lake Storage.

Optymalizowanie pod kątem pozyskiwania danych

Podczas pozyskiwania danych z systemu źródłowego sprzęt systemu źródłowego, sprzęt sieciowy systemu źródłowego lub łączność sieciowa z kontem magazynu danych mogą stanowić wąskie gardła.

Sprzęt źródłowy

Niezależnie od tego, czy używasz maszyn lokalnych, czy maszyn wirtualnych w Azure, dokładnie wybierz odpowiedni sprzęt. W przypadku sprzętu dyskowego rozważ użycie dysków półprzewodnikowych (SSD) i wybierz sprzęt dyskowy, który ma szybsze wrzeciona. W przypadku sprzętu sieciowego można użyć najszybszych kontrolerów interfejsu sieciowego (NIC). W Azure należy użyć maszyn wirtualnych Azure D14, które mają odpowiednio zaawansowany sprzęt dyskowy i sieciowy.

Łączność sieciowa z kontem pamięci masowej

Łączność sieciowa między danymi źródłowymi a kontem magazynu danych może czasami stanowić wąskie gardło. Jeśli dane źródłowe są lokalne, rozważ użycie dedykowanego linku z Azure ExpressRoute. Jeśli dane źródłowe są na platformie Azure, wydajność jest najlepsza, gdy dane są w tym samym regionie świadczenia usługi Azure co konto z włączoną usługą Data Lake Storage.

Skonfigurować narzędzia do pozyskiwania danych do maksymalnej paralelizacji.

Aby uzyskać najlepszą wydajność, użyj całej dostępnej przepływności, wykonując jak najwięcej operacji odczytu i zapisu równolegle.

W poniższej tabeli przedstawiono kluczowe ustawienia kilku popularnych narzędzi do importowania danych.

Aby uzyskać pełniejszą listę narzędzi do pozyskiwania danych, zobacz Wybieranie narzędzi do migracji.

Twoje konto skaluje się tak, aby zapewnić niezbędną przepływność dla wszystkich scenariuszy analitycznych. Domyślnie konto z włączoną usługą Data Lake Storage zapewnia wystarczającą przepływność w domyślnej konfiguracji, aby zaspokoić potrzeby szerokiej kategorii przypadków użycia. Jeśli napotkasz domyślny limit, skontaktuj się z pomocą techniczną Azure, aby skonfigurować konto w celu zapewnienia większej przepływności.

Strukturyzuj zestawy danych

Rozważ wstępneplanowanie struktury danych. Format pliku, rozmiar pliku i struktura katalogu mogą mieć wpływ na wydajność i koszty.

Formaty plików

Dane można pozyskiwać w różnych formatach. Dane mogą być wyświetlane w formatach czytelnych dla człowieka, takich jak JSON, CSV lub XML, albo jako skompresowane formaty binarne, takie jak .tar.gz. Dane mogą być dostępne w różnych rozmiarach. Dane mogą składać się z dużych plików (kilka terabajtów), takich jak dane z eksportu tabeli SQL z systemów lokalnych. Dane mogą również pochodzić z dużej liczby małych plików (kilka kilobajtów), takich jak dane ze zdarzeń w czasie rzeczywistym z rozwiązania Internetu rzeczy (IoT). Wydajność i koszty można zoptymalizować, wybierając odpowiedni format pliku i rozmiar pliku.

Usługa Hadoop obsługuje zestaw formatów plików zoptymalizowanych pod kątem przechowywania i przetwarzania danych strukturalnych. Niektóre typowe formaty to Format Avro, Parquet i Optimized Row Columnar (ORC). Wszystkie te formaty to formaty plików binarnych z możliwością odczytu maszynowego. Są one kompresowane, aby ułatwić zarządzanie rozmiarem pliku. Mają one schemat osadzony w każdym pliku, co sprawia, że są one samoopisujące. Różnica między tymi formatami polega na sposobie przechowywania danych. Avro przechowuje dane w formacie opartym na wierszach, a formaty Parquet i ORC przechowują dane w formacie kolumnowym.

Użyj formatu pliku Avro, gdy operacje wejścia/wyjścia są bardziej zorientowane na zapis lub gdy zapytania częściej wymagają pobierania wielu wierszy w całości. Na przykład format Avro działa dobrze z magistralą komunikatów, taką jak Event Hubs lub Kafka, która zapisuje wiele zdarzeń lub komunikatów z rzędu.

Używaj formatów plików Parquet i ORC, gdy wzorce we/wy są bardziej czytelne lub gdy wzorce zapytań koncentrują się na podzestawie kolumn w rekordach. Transakcje odczytu można zoptymalizować w celu pobrania określonych kolumn zamiast odczytywania całego rekordu.

Apache Parquet to format plików typu open source zoptymalizowany pod kątem potoków analizy z dużą liczbą odczytów. Struktura przechowywania kolumnowego Parquet umożliwia pomijanie nieistotnych danych. Zapytania są znacznie bardziej wydajne, ponieważ mogą precyzyjnie określać zakres danych wysyłanych z magazynu do silnika analitycznego. Ponadto, ponieważ podobne typy danych (dla kolumny) są przechowywane razem, Parquet obsługuje wydajne schematy kompresji i kodowania danych, które mogą obniżyć koszty magazynowania danych. Usługi takie jak Azure Synapse Analytics, Azure Databricks i Azure Data Factory mają natywne funkcje, które korzystają z formatów plików Parquet.

Rozmiar pliku

Większe pliki prowadzą do lepszej wydajności i obniżenia kosztów.

Zazwyczaj silniki analityczne, takie jak usługa HDInsight, mają operacyjne obciążenie związane z zadaniami, takimi jak wyświetlanie listy, sprawdzanie dostępu i wykonywanie różnych operacji związanych z metadanymi. Jeśli przechowujesz dane w postaci wielu małych plików, ten wybór może negatywnie wpłynąć na wydajność. Ogólnie rzecz biorąc, pogrupuj dane w większe pliki, aby uzyskać lepszą wydajność (od 256 MB do 100 GB rozmiaru). Niektóre aparaty i aplikacje mogą mieć problemy z wydajnym przetwarzaniem plików o rozmiarze większym niż 100 GB.

Zwiększenie rozmiaru pliku może również zmniejszyć koszty transakcji. Operacje odczytu i zapisu są rozliczane w przyrostach 4 megabajtów, więc opłaty są naliczane za operację niezależnie od tego, czy plik zawiera 4 megabajty, czy tylko kilka kilobajtów. Aby uzyskać informacje o cenach, zobacz Cennik usługi Azure Data Lake Storage.

Czasami potoki danych mają ograniczoną kontrolę nad danymi nieprzetworzonymi, które mają wiele małych plików. Ogólnie rzecz biorąc, system powinien mieć jakiś proces agregowania małych plików w większe do użytku przez aplikacje podrzędne. Jeśli przetwarzasz dane w czasie rzeczywistym, możesz użyć aparatu przesyłania strumieniowego w czasie rzeczywistym (takiego jak Azure Stream Analytics lub Spark Streaming) wraz z brokerem komunikatów (takim jak Event Hubs lub Apache Kafka), aby przechowywać dane jako większe pliki. W miarę agregowania małych plików do większych rozważ zapisanie ich w formacie zoptymalizowanym pod kątem odczytu, takim jak Apache Parquet na potrzeby przetwarzania podrzędnego.

Struktura katalogów

Każde obciążenie ma inne wymagania dotyczące sposobu korzystania z danych. Jednak podczas pracy z Internetem rzeczy (IoT), scenariuszami wsadowymi lub optymalizacją danych szeregów czasowych należy wziąć pod uwagę te typowe układy.

Struktura IoT

W przypadku obciążeń IoT można pozyskiwać dużą ilość danych obejmujących wiele produktów, urządzeń, organizacji i klientów. Zaplanuj z wyprzedzeniem układ katalogów z myślą o organizacji, bezpieczeństwie i wydajnym przetwarzaniu danych przez systemy podrzędne. Ogólny szablon do rozważenia może mieć następujący układ:

• {Region}/{SubjectMatter(s)}/{rrrr}/{mm}/{dd}/{hh}/

Na przykład telemetria dotycząca lądowania silnika samolotu w Wielkiej Brytanii może wyglądać podobnie do następującej struktury:

• UK/Planes/BA1293/Engine1/2017/08/11/12/

W tym przykładzie, umieszczając datę na końcu struktury katalogów, można użyć list ACL, aby łatwiej zabezpieczyć regiony i kwestie dotyczące określonych użytkowników i grup. Jeśli na początku umieścisz strukturę dat, znacznie trudniej byłoby zabezpieczyć te regiony i kwestie. Jeśli na przykład chcesz udzielić dostępu tylko do danych dotyczących Wielkiej Brytanii lub niektórych samolotów, musisz zastosować osobne uprawnienie dla wielu katalogów w ramach każdego katalogu godzin. Ta struktura również wykładniczo zwiększyłaby liczbę katalogów w miarę upływu czasu.

Struktura zadań wsadowych

Powszechnie stosowane podejście do przetwarzania wsadowego polega na umieszczaniu danych w folderze "in". Następnie, po przetworzeniu danych, umieść nowe dane w katalogu "out" do wykorzystania przez procesy dalsze. Ta struktura katalogów jest czasami używana w przypadku zadań wymagających przetwarzania poszczególnych plików i może nie wymagać masowego przetwarzania równoległego w dużych zestawach danych. Podobnie jak zalecana powyżej struktura IoT, dobra struktura katalogów zawiera katalogi na poziomie nadrzędnym dla takich rzeczy jak region i zagadnienia (na przykład organizacja, produkt lub producent). Rozważ datę i godzinę w strukturze, aby umożliwić lepszą organizację, przefiltrowane wyszukiwania, zabezpieczenia i automatyzację w przetwarzaniu. Poziom szczegółowości struktury daty zależy od interwału, w którym dane są przekazywane lub przetwarzane, na przykład co godzinę, codziennie, a nawet co miesiąc.

Czasami przetwarzanie plików kończy się niepowodzeniem z powodu uszkodzenia danych lub nieoczekiwanych formatów. W takich przypadkach struktura katalogów może skorzystać z folderu /bad , aby przenieść pliki do w celu dalszej inspekcji. Zadanie wsadowe może również obsługiwać raportowanie lub powiadamianie o tych nieprawidłowych plikach w celu ręcznej interwencji. Rozważ następującą strukturę szablonu:

• {Region}/{SubjectMatter(s)}/In/{rrrr}/{mm}/{dd}/{hh}/
• {Region}/{Tematyka(i)}/Out/{rrrr}/{mm}/{dd}/{hh}/
• {Region}/{SubjectMatter(s)}/Bad/{yyyy}/{mm}/{dd}/{hh}/

Na przykład firma marketingowa otrzymuje codzienne wyciągi danych dotyczących aktualizacji klientów od swoich klientów z Ameryki Północnej. Może to wyglądać podobnie do poniższego fragmentu kodu przed przetworzeniem i po jego przetworzeniu:

• NA/Extracts/ACMEPaperCo/In/2017/08/14/updates_08142017.csv
• NA/Extracts/ACMEPaperCo/Out/2017/08/14/processed_updates_08142017.csv

W typowym przypadku przetwarzania danych wsadowych bezpośrednio w bazach danych, takich jak Hive lub tradycyjne bazy danych SQL, nie ma potrzeby korzystania z katalogu in lub out , ponieważ dane wyjściowe są już przekazywane do oddzielnego folderu dla tabeli Hive lub zewnętrznej bazy danych. Na przykład codziennie wyodrębnione dane od klientów trafiają do przypisanych im katalogów. Następnie usługa, taka jak Azure Data Factory, Apache Oozie lub Apache Airflow wyzwala codzienne zadanie Hive lub Spark w celu przetwarzania i zapisywania danych w tabeli Hive.

Struktura danych szeregów czasowych

W przypadku obciążeń Hive oczyszczanie partycji danych szeregów czasowych może pomóc niektórym zapytaniom w odczytywaniu tylko podzestawu danych, co zwiększa wydajność.

Potoki przetwarzające dane szeregów czasowych często zapisują pliki zgodnie z uporządkowanym schematem nazewnictwa plików i folderów. Poniżej przedstawiono typowy przykład danych ustrukturyzowanych według daty:

/DataSet/RRRR/MM/DD/datafile_YYYY_MM_DD.tsv

Zwróć uwagę, że informacje o dacie/godziny są wyświetlane zarówno jako foldery, jak i nazwa pliku.

W przypadku daty i godziny następujący wzorzec jest typowy

/DataSet/RRRR/MM/DD/HH/mm/datafile_YYYY_MM_DD_HH_mm.tsv

Ponownie wybór w organizacji folderów i plików powinien być zoptymalizowany pod kątem większych rozmiarów plików i rozsądnej liczby plików w każdym folderze.

Konfigurowanie zabezpieczeń

Zacznij od zapoznania się z zaleceniami w artykule Zalecenia dotyczące zabezpieczeń dla usługi Blob Storage . Znajdziesz wskazówki dotyczące najlepszych rozwiązań dotyczących ochrony danych przed przypadkowym lub złośliwym usunięciem, zabezpieczaniem danych za zaporą i używaniem Microsoft Entra ID jako podstawy zarządzania tożsamościami.

Następnie zapoznaj się z artykułem Model kontroli dostępu w usłudze Azure Data Lake Storage , aby uzyskać wskazówki specyficzne dla kont z obsługą usługi Data Lake Storage. Ten artykuł pomaga zrozumieć, jak używać ról dostępu opartych na rolach (Azure RBAC) wraz z listami kontroli dostępu (ACL) w celu ustanawiania uprawnień zabezpieczeń do katalogów i plików w hierarchicznym systemie plików.

Pobieranie, przetwarzanie i analiza

Dane można ładować do konta z włączoną usługą Data Lake Storage z wielu różnych źródeł i na wiele różnych sposobów.

Na przykład można pozyskiwać duże zestawy danych z klastrów hdInsight i Hadoop lub mniejszych zestawów danych ad hoc na potrzeby tworzenia prototypów aplikacji. Można pozyskiwać strumieniowo dane generowane przez różne źródła, takie jak aplikacje, urządzenia i czujniki. W przypadku tego typu danych używaj narzędzi do przechwytywania i przetwarzania danych w czasie rzeczywistym dla każdego zdarzenia osobno, a następnie zapisuj zdarzenia partiami na swoim koncie. Można również pozyskiwać dzienniki serwera internetowego, które zawierają informacje, takie jak historia żądań stron. W przypadku danych dziennika rozważ napisanie niestandardowych skryptów lub aplikacji w celu ich przesyłania, tak aby można było elastycznie uwzględnić komponent do przesyłania danych jako część większej aplikacji do przetwarzania dużych zbiorów danych.

Gdy dane będą dostępne na twoim koncie, możesz uruchomić analizę tych danych, utworzyć wizualizacje, a nawet pobrać dane na komputer lokalny lub do innych repozytoriów, takich jak baza danych Azure SQL Database lub wystąpienie programu SQL Server.

W poniższej tabeli przedstawiono narzędzia, których można użyć do pozyskiwania, analizowania, wizualizowania i pobierania danych. Skorzystaj z linków w tej tabeli, aby znaleźć wskazówki dotyczące konfigurowania i używania poszczególnych narzędzi.

Monitorowanie telemetrii

Monitorowanie użycia i wydajności usługi jest ważną częścią operacjonalizacji usługi. Przykłady telemetrii obejmują częste operacje, operacje z dużym opóźnieniem lub operacje, które powodują ograniczanie przepustowości po stronie usługi.

Możesz uzyskać dostęp do wszystkich danych telemetrycznych swojego konta magazynu za pomocą dzienników usługi Azure Storage w usłudze Azure Monitor. Ta funkcja umożliwia zintegrowanie konta magazynu z usług Log Analytics i Event Hubs, a jednocześnie umożliwia archiwizowanie dzienników na dowolnym innym koncie magazynu. Aby wyświetlić pełną listę metryk i dzienników zasobów oraz skojarzony ze nimi schemat, zobacz Azure Storage dokumentację danych monitorowania.

Miejsce, w którym chcesz przechowywać dzienniki, zależy od tego, jak planujesz uzyskać do nich dostęp. Jeśli na przykład chcesz uzyskać dostęp do dzienników niemal w czasie rzeczywistym i mieć możliwość korelowania zdarzeń w dziennikach z innymi metrykami z Azure Monitor, zapisz dzienniki w obszarze roboczym Log Analytics. Następnie wykonaj zapytania dotyczące dzienników przy użyciu języka KQL i zapytań autorów, które wyliczają tabelę StorageBlobLogs w obszarze roboczym.

Jeśli chcesz przechowywać dzienniki na potrzeby zapytań niemal w czasie rzeczywistym oraz długoterminowego przechowywania, skonfiguruj ustawienia diagnostyczne tak, aby wysyłały dzienniki zarówno do obszaru roboczego usługi Log Analytics, jak i do konta magazynu.

Jeśli chcesz uzyskać dostęp do dzienników za pośrednictwem innego aparatu zapytań, takiego jak Splunk, skonfiguruj ustawienia diagnostyczne, aby wysyłać dzienniki do centrum zdarzeń i pozyskiwać dzienniki z centrum zdarzeń do wybranego miejsca docelowego.

Dzienniki Azure Storage można włączyć w Azure Monitor za pomocą portalu Azure, programu PowerShell, Azure CLI i szablonów Azure Resource Manager. W przypadku wdrożeń na dużą skalę należy użyć Azure Policy z pełną obsługą zadań korygowania. Aby uzyskać więcej informacji, zobacz ciphertxt/AzureStoragePolicy.

Zobacz też

• Strategia wykonawcza dotycząca ujednolicania danych
• Model kontroli dostępu w usłudze Azure Data Lake Storage
• Autostopem przez Data Lake
• Omówienie usługi Azure Data Lake Storage