Рекомендации по использованию Azure Data Lake Storage
В этой статье приведены рекомендации по оптимизации производительности, сокращению затрат и защите учетной записи служба хранилища Azure data Lake Storage.
Общие рекомендации по структуре озера данных см. в указанных здесь статьях.
- Общие сведения об Azure Data Lake Storage для сценария управления данными и анализа
- Подготовка трех учетных записей Azure Data Lake Storage для каждой целевой зоны данных
Ищите документацию
Azure Data Lake Storage не является выделенной службой или типом учетной записи. Это набор возможностей, которые поддерживают аналитическую рабочую нагрузку с высокой пропускной способностью. Документация по Data Lake Storage предоставляет рекомендации и рекомендации по использованию этих возможностей. Все остальные аспекты управления учетными записями, такие как настройка сетевой безопасности, проектирование для обеспечения высокой доступности и аварийного восстановления, см. в документации по хранилищу BLOB-объектов.
Оценка поддержки функций и известные проблемы
При настройке учетной записи для использования функций хранилища BLOB-объектов используйте следующий шаблон.
Чтобы определить, полностью ли поддерживается функция в вашей учетной записи, см. раздел Поддержка функций Хранилища BLOB-объектов в учетных записях службы хранилища Azure. Некоторые функции пока не поддерживаются или частично поддерживаются в учетных записях с поддержкой Data Lake Storage. Поддержка функций постоянно расширяется, поэтому периодически просматривайте эту статью.
Просмотрите известные проблемы с Azure Data Lake Storage , чтобы узнать, существуют ли ограничения или специальные рекомендации по использованию функции.
Статьи функций сканирования для всех рекомендаций, относящихся к учетным записям с поддержкой Data Lake Storage.
Понимание терминов, используемых в документации
При перемещении между наборами содержимого вы заметите некоторые незначительные различия в терминологии. Например, в документации по хранилищу BLOB-объектов используется термин BLOB-объект вместо термина файл. Технически файлы, которые вы принимаете в учетную запись хранения, становятся BLOB-объектами в вашей учетной записи. Так что это корректный термин. Тем не менее, большой двоичный объект может вызвать путаницу, если вы используете для файла терминов. Вы также увидите термин контейнер, обозначающий файловую систему. Эти термины можно считать синонимами.
Уровень "Премиум"
Если для рабочих нагрузок требуется стабильно низкая задержка и/или большое количество операций ввода в секунду, рассмотрите возможность использования учетной записи хранения блочных BLOB-объектов уровня "Премиум". Этот тип учетной записи использует высокопроизводительное оборудование. Данные хранятся на твердотельных накопителях (SSD), оптимизированных для низкой задержки. SSD обеспечивают более высокую пропускную способность по сравнению с традиционными жесткими дисками. Затраты на хранение производительности уровня "Премиум" выше, но затраты на транзакции ниже. Таким образом, если рабочие нагрузки выполняют большое количество транзакций, учетная запись BLOB-объекта блока производительности класса Premium может быть экономичной.
Если ваша учетная запись хранения будет использоваться для аналитики, настоятельно рекомендуется использовать Azure Data Lake Storage вместе с учетной записью хранения BLOB-объектов класса Premium. Сочетание учетных записей хранилища блочных BLOB-объектов уровня "Премиум" с учетной записью с поддержкой Data Lake Storage называется Azure Data Lake Storage категории "Премиум".
Оптимизация для приема данных
При приеме данных из исходных систем оборудование источника, оборудование сети источника или сетевое подключение к учетной записи хранения могут стать узким местом.
Исходное оборудование
Независимо от того, используете ли вы локальные компьютеры или Виртуальные машины (виртуальные машины) в Azure, тщательно выберите соответствующее оборудование. Для оборудования диска рекомендуем выбрать твердотельный накопитель (SSD) с более быстрыми шпинделями. Для сетевого оборудования используйте наиболее быстрые контроллеры сетевого интерфейса (NIC). В Azure мы советуем выбрать виртуальные машины Azure D14 с соответствующим мощным диском и сетевым оборудованием.
Сетевое подключение к учетной записи хранения
Сетевое подключение между исходными данными и учетной записью хранения иногда может быть узким местом. Если исходные данные находятся в локальной среде, попробуйте использовать выделенный канал с Azure ExpressRoute. Если исходные данные находится в Azure, производительность лучше всего подходит, если данные будут в том же регионе Azure, что и учетная запись Data Lake Storage.
Настройка средств приема данных для обеспечения максимальной параллелизации
Чтобы добиться максимальной производительности, используйте доступную пропускную способность, выполняя как можно больше операций чтения и записи параллельно.
В следующей таблице приводятся параметры ключей для нескольких популярных инструментов для приема данных.
| Средство | Настройки |
|---|---|
| DistCp | -m (mapper) |
| Фабрика данных Azure | parallelCopies |
| Sqoop | fs.azure.block.size, -m (mapper) |
Примечание.
Общая производительность операций приема данных зависит от других факторов, которые, в свою очередь, зависят от используемого инструмента приема данных. Чтобы получить актуальные рекомендации, см. документацию для выбранного инструмента.
Учетную запись можно масштабировать, чтобы предоставить необходимую пропускную способность для всех сценариев аналитики. По умолчанию включенная учетная запись Data Lake Storage обеспечивает достаточную пропускную способность в конфигурации по умолчанию для удовлетворения потребностей широкой категории вариантов использования. Если вы достигаете лимита по умолчанию, учетную запись можно настроить для предоставления большей пропускной способности, связавшись с поддержкой Azure.
Структурирование наборов данных
Рекомендуется предварительно спланировать структуру данных. Формат файла, размер файла и структура каталогов могут повлиять на производительность и стоимость.
Форматы файлов
Данные могут быть в разных форматах. Данные могут отображаться в удобочитаемых форматах, таких как JSON, CSV или XML, или в виде сжатых двоичных форматов, таких как .tar.gz. Кроме того, данные могут быть разного размера. Данные могут состоять из больших файлов (размером несколько терабайт), например, данные экспорта таблицы SQL из локальных систем. Данные также могут поступать в виде большого количества маленьких файлов (по несколько килобайт), например данные по событиям реального времени из решения Интернета вещей. Вы можете оптимизировать эффективность и затраты, выбрав нужный формат и размер файла.
Hadoop поддерживает набор форматов файлов, оптимизированных для хранения и обработки структурированных данных. Часто используются форматы Avro, Parquet и Optimized Row Columnar (ORC). Все эти форматы являются машиночитаемыми двоичными файлами. Они сжимаются для управления размером файла. В каждый файл внедрена схема, которая позволяет им описывать себя. Разница между этими форматами заключается в том, как хранятся данные. В Avro данные хранятся в строках, а в Parquet и ORC — в столбцах.
Используйте формат Avro в том случае, если вы выполняете больше операций записи или запросы обычно извлекают несколько строк записей целиком. Например, формат Avro хорошо работает с шиной сообщений, например Центрами событий или Kafka, которая записывает несколько событий или сообщений в последовательности.
Форматы Parquet и ORC лучше использовать, если вы чаще выполняете операции чтения или запросы извлекают наборы столбцов в записях. Транзакции чтения можно оптимизировать для извлечения определенных столбцов вместо чтения всей записи.
Apache Parquet — это формат файлов с открытым кодом, оптимизированный для конвейеров аналитики с большим числом операций чтения. В структуре хранения в виде столбцов в Parquet можно игнорировать нерелевантные данные. Запросы будут гораздо эффективнее, так как они могут сужать объем данных, которые нужно отправить из хранилища в подсистему аналитики. Кроме того, так как похожие типы данных (для столбца) хранятся вместе, Parquet поддерживает эффективные схемы сжатия и кодирования данных, которые могут снизить затраты на хранение. Такие службы, как Azure Synapse Analytics, Azure Databricks и Фабрика данных Azure, имеют функциональные возможности, которые могут использовать преимущества формата файлов Parquet.
Размер файла
Чем крупнее файлы, тем выше производительность и ниже расходы.
Как правило, у таких подсистем аналитики, как HDInsight, есть накладные расходы для каждого файла, которые связаны с такими задачами, как перечисление, проверка доступа и выполнение различных операций с метаданными. Если вы храните данные в большом количестве небольших файлов, это может отрицательно сказаться на производительности. Упорядочивайте свои данные в файлы большего размера для лучшей производительности (от 256 МБ до 100 ГБ). В некоторых подсистемах и приложениях могут возникнуть проблемы с эффективной обработкой файлов размером более 100 ГБ.
Увеличение размера файла также может снизить затраты на транзакции. Плата за операции чтения и записи взимается за каждые 4 МБ, поэтому вы платите за операцию, даже если размер файла меньше 4 МБ или и вовсе составляет несколько килобайт. Дополнительные сведения см. на странице Цены на Azure Data Lake Storage.
В некоторых случаях конвейеры данных имеют ограниченный контроль над необработанными данными, которые содержат множество небольших файлов. Как правило, мы рекомендуем обеспечить в системе некоторый процесс объединения мелких файлов в более крупные приложения для использования в подчиненных приложениях. Если вы обрабатываете данные в режиме реального времени, вы можете использовать подсистему потоковой передачи в реальном времени (например , Azure Stream Analytics или Spark Streaming) вместе с брокером сообщений (например , Центрами событий или Apache Kafka) для хранения данных в виде больших файлов. При объединении небольших файлов в более крупные можно сохранить их в формате, оптимизированном для чтения, например Apache Parquet, для последующей обработки.
Структура каталогов
Каждая рабочая нагрузка имеет свои требования к потреблению данных, но существуют некоторые распространенные макеты, которые следует учитывать при работе с Интернетом вещей (IoT), пакетной обработке или оптимизации для данных временных рядов.
Структура Центра Интернета вещей
В рабочих нагрузках Интернета вещей может поступать большое количество данных, которое охватывает множество продуктов, устройств, организаций и клиентов. Важно заранее спланировать структуру каталога для организации, обеспечения безопасности и эффективной обработки данных для нисходящих потребителей. Ниже приведен общий шаблон, который стоит рассмотреть.
- {Region}/{SubjectMatter(s)}/{yyyy}/{mm}/{dd}/{hh}/
Например, каталог размещения телеметрии для авиационного двигателя в Великобритании может выглядеть так:
- UK/Planes/BA1293/Engine1/2017/08/11/12/
В этом примере, разместив данные в конце структуры каталогов, вы можете использовать ACL, чтобы упросить защиту регионов и областей для определенных пользователей и групп. Если вы положили структуру дат в начале, было бы гораздо сложнее защитить эти регионы и темы. Например, если вы хотите предоставить доступ только к данным Великобритании или определенным самолетам, вам потребуется применить отдельное разрешение для множества каталогов в каждом каталоге за час. Эта структура также будет экспоненциально увеличивать количество каталогов с течением времени.
Структура пакетных заданий
Обычный подход к пакетной обработке — размещение данных внутри каталога. Как только данные будут обработаны, поместите новые данные во внешний каталог для использования нисходящими процессами. Эта структура каталогов иногда используется в случае заданий, требующих обработки отдельных файлов и не требующих массовой параллельной обработки больших наборов данных. Как и рекомендованная выше структура Центра Интернета вещей, оптимальная структура каталога использует каталоги родительского уровня для региона и предметной области (например, организации, продукта или производителя). Рассмотрите дату и время в структуре, чтобы обеспечить лучшую организацию, отфильтрованные поисковые запросы, безопасность и автоматизацию в процессе обработки. Уровень детализации структуры даты определяется интервалом, с которым данные загружаются или обрабатываются, например ежечасно, ежедневно или даже ежемесячно.
Иногда обработка файлов завершается сбоем из-за повреждения данных или непредвиденных форматов. В таких случаях в структуре каталога целесообразно использовать папку /bad, чтобы перемещать в нее файлы для дальнейшей проверки. Пакетное задание также может обрабатывать отчет или уведомление об этих недопустимых файлах для устранения проблем вручную. Рассмотрите следующую структуру:
- {Region}/{SubjectMatter(s)}/In/{yyyy}/{mm}/{dd}/{hh}/
- {Region}/{SubjectMatter(s)}/Out/{yyyy}/{mm}/{dd}/{hh}/
- {Region}/{SubjectMatter(s)}/Bad/{yyyy}/{mm}/{dd}/{hh}/
Например, маркетинговая фирма ежедневно получает извлечения данных клиентских обновлений от своих клиентов в Северной Америке. Она может выглядеть, как приведенный ниже фрагмент кода, перед обработкой и после нее:
- NA/Extracts/ACMEPaperCo/In/2017/08/14/updates_08142017.csv
- NA/Extracts/ACMEPaperCo/Out/2017/08/14/processed_updates_08142017.csv
В общем случае пакетных данных, обрабатываемых непосредственно в таких базах данных, как Hive или традиционных базах данных SQL, нет необходимости в каталоге /in или /out, так как результаты уже выводятся в отдельную папку для таблицы Hive или внешней базы данных. Например, ежедневно извлекаемые данные о клиентах будут направляться в соответствующие каталоги. Затем такая служба, как Фабрика данных Azure, Apache Oozie или Apache Airflow, активирует ежедневное задание Hive или Spark для обработки и записи данных в таблицу Hive.
Структура данных временных рядов
Для рабочих нагрузок Hive удаление секций данных временных рядов может помочь некоторым запросам считывать только подмножество данных, что улучшает производительность.
Конвейеры, принимающие данные временных рядов, часто используют для размещения своих файлов структурированную систему именования файлов и папок. Ниже приведен обычный пример для данных, структурированных по дате:
/DataSet/ГГГГ/ММ/ДД/datafile_YYYY_MM_DD.tsv
Обратите внимание, что данные времени и даты отображаются и как папки, и в имени файла.
Ниже приведен распространенный шаблон для даты и времени:
/DataSet/YYYY/MM/DD/HH/mm/datafile_YYYY_MM_DD_HH_mm.tsv
Выбор, который вы делаете с помощью упорядочения папки и файлов, должен быть оптимизирован для больших размеров файлов и разумного количества файлов в каждой папке.
Настройка безопасности
Для начала просмотрите рекомендации в статье Рекомендации по безопасности для хранилища BLOB-объектов. Вы найдете рекомендации по защите данных от случайного или вредоносного удаления, защиты данных за брандмауэром и использования идентификатора Microsoft Entra в качестве основы управления удостоверениями.
Затем ознакомьтесь с моделью управления доступом в статье Azure Data Lake Storage , чтобы получить рекомендации, относящиеся к учетным записям с поддержкой Data Lake Storage. Из этой статьи вы узнаете, как использовать роли управления доступом на основе ролей Azure (Azure RBAC) вместе со списками управления доступом (ACL) для применения разрешений системы безопасности для каталогов и файлов в иерархической файловой системе.
Прием, обработка и анализ
Существует множество различных источников данных и различных способов приема данных в учетную запись Data Lake Storage.
Например, можно принимать большие наборы данных из кластеров HDInsight и Hadoop или небольшие наборы для специфических данных для создания прототипов приложений. Вы можете принимать потоковую передачу данных их различных источников, таких как приложения, устройства и датчики. Для этого типа данных можно использовать инструменты для захвата и обработки данных по конкретным событиям в реальном времени, а затем записывать события пакетами в учетную запись. Вы также можете принимать журналы веб-серверов, содержащие сведения, например историю запросов страниц. Для данных журнала можно написать пользовательские скрипты или приложения для отправки, чтобы включить компонент отправки данных в более крупное приложение для передачи данных.
Когда данные будут доступны в вашей учетной записи, вы можете выполнить их анализ, создать визуализации и даже скачать данные на локальный компьютер или в другие репозитории, например в Базу данных Azure SQL или экземпляр SQL Server.
В следующей таблице приводятся рекомендуемые инструменты для анализа, визуализации и скачивания данных. Ссылки в этой таблице ведут на инструкции по настройке и использованию каждого инструмента.
| Характер использования | Руководство по средствам и средствам |
|---|---|
| Прием специальных данных | Портал Azure, Azure PowerShell, Azure CLI, REST, Azure Storage Explorer, Apache DistCp, AzCopy |
| Прием реляционных данных | Фабрика данных Azure |
| Прием журналов веб-сервера | Azure PowerShell, Azure CLI, REST, Azure SDK (.NET, Java, Python и Node.js), Фабрика данных Azure |
| Прием из кластеров HDInsight | Фабрика данных Azure, Apache DistCp, AzCopy |
| Прием из кластеров Hadoop | Фабрика данных Azure, Apache DistCp, WANdisco LiveData Migrator for Azure, Azure Data Box |
| Прием больших наборов данных (несколько терабайт) | Azure ExpressRoute |
| Обработка и анализ данных | Azure Synapse Analytics, Azure HDInsight, Databricks |
| Визуализация данных | Power BI, Ускорение запросов Azure Data Lake Storage |
| Загрузка данных | Портал Azure, PowerShell, Azure CLI, REST, Azure SDK (.NET, Java, Python и Node.js), Обозреватель службы хранилища Azure, AzCopy, Фабрика данных Azure, Apache DistCp |
Примечание.
Эта таблица не отражает полный список служб Azure, поддерживающих Data Lake Storage. Чтобы просмотреть список поддерживаемых служб Azure, их уровень поддержки, см . в службах Azure, поддерживающих Azure Data Lake Storage.
Мониторинг телеметрии
Мониторинг использования и производительности является важной частью эксплуатации службы. Примеры: частые операции, операции с высокой задержкой или операции, которые приводят к регулированию на стороне службы.
Вся телеметрия для вашей учетной записи хранения доступна с помощью журналов службы хранилища Azure в Azure Monitor. Эта функция интегрирует учетную запись хранения с Log Analytics и Центрами событий, а также позволяет архивировать журналы в другой учетной записи хранения. Полный список метрик и журналов ресурсов и связанную с ними схему см. в справочнике по данным мониторинга службы хранилища Azure.
Выбор места хранения журналов зависит от того, как вы планируете получать к ним доступ. Например, если вы хотите получать доступ к журналам в реальном времени и соотносить события в журналах с другими метриками из Azure Monitor, вы можете хранить журналы в рабочей области Log Analytics. Затем запросите журналы с помощью KQL и запросов авторов, которые перечисляют таблицу StorageBlobLogs в рабочей области.
Если вы хотите хранить журналы как для запросов почти в реальном времени, так и для долгосрочного хранения, вы можете настроить параметры диагностики для отправки журналов в рабочую область Log Analytics и учетную запись хранения.
Если вы хотите получить доступ к журналам через другой обработчик запросов, например Splunk, можно настроить параметры диагностики для отправки журналов в концентратор событий и приема журналов из концентратора событий в выбранное место назначения.
Журналы службы хранилища Azure в Azure Monitor можно включить с помощью портала Azure, в PowerShell, в Azure CLI и шаблонах Azure Resource Manager. Для масштабных развертываний можно использовать Политику Azure с полной поддержкой задач по исправлению. Дополнительные сведения см. в разделе ciphertxt/AzureStoragePolicy.