Мы посвятили значительное количество времени изучению возможностей Azure по обработке данных и созданию надежной инфраструктуры данных, которая обрабатывает необработанное видео, очищенное видео и соответствующий контекст, необходимый для сопоставления данных и подачи их в модель ИИ. Поскольку каждый дизайн уникален и не может быть продублирован, этот процесс включал в себя множество экспериментов и усовершенствований. Опираясь на наш опыт, мы собрали ряд ценных идей.

Учетная запись Azure Data Lake Storage 2-го поколения создается поверх хранилища BLOB-объектов Azure, которое было первой итерацией этой технологии. Он предлагает множество преимуществ для хранения, включая низкую стоимость и различные уровни. Новая учетная запись Gen2 сочетает в себе функции Azure Blob Storage и Azure Data Lake Storage Gen1, предоставляя дополнительные возможности, такие как семантика файловой системы, безопасность на уровне файлов и масштабируемость. Это значительно улучшает аналитику, особенно с точки зрения производительности, поскольку данные не нужно копировать или преобразовывать перед анализом, в отличие от плоского пространства имен хранилища BLOB-объектов. Иерархическое пространство имен Gen2 также улучшает управление, позволяя легко организовывать файлы в каталоги и подкаталоги. Кроме того, он повышает безопасность за счет включения разрешений POSIX для каталогов или отдельных файлов. В конечном счете, иерархическое пространство имен отличает Gen2 от других и делает его идеальным решением для аналитики.

Все типы данных поступают к нам из различных источников, включая журналы, медиафайлы и структурированные/неструктурированные данные из реляционных баз данных. Для приема этих данных мы используем Фабрику данных Azure. Впоследствии мы храним эти данные в Azure Data Lake Storage 2-го поколения — уникальном репозитории для нашего аналитического решения. Оттуда он становится фокусом, с которого начинается все действие. Azure Databricks можно использовать для подготовки и обучения, а нижестоящие службы, такие как Azure Synapse Analytics, Azure Analysis Services или Power BI, могут быть включены в модель и этап обслуживания. Однако все эти службы зависят от Azure Data Lake Storage 2-го поколения. Информация может быть извлечена из озера данных, подготовлена ​​и обучена в Databricks и передана в Synapse. Кроме того, Synapse может извлекать данные непосредственно из нашего озера данных. Независимо от того, какие сервисы вы добавляете в свое аналитическое решение, например Cosmos DB или Stream Analytics, центром данных, связывающим все вместе, является озеро данных Azure.

Зоны

«Зона» относится к папке, обычно от трех до пяти, хотя конкретное количество и расположение могут различаться в зависимости от реализации. Хотя некоторые зоны могут быть необязательными, большинство представлений включают зону приземления, где исходные данные изначально хранятся в неизменном состоянии. Хотя данные не всегда могут быть пригодны для использования, их можно организовать в соответствии с источником в отдельных папках. Однако эта зона может стать дорогой из-за полного набора данных из разных источников. Таким образом, рекомендуется периодически перемещать данные на более высокий уровень доступа с помощью программного процесса.

Далее идет поэтапная зона, которая знаменует собой первый шаг к уточнению данных путем предоставления базовой структуры. Как правило, необработанные данные автоматически обрабатываются, чтобы предложить улучшенную форму для подготовки к курированию. Даже на этом этапе данные представляют большую ценность, чем необработанные данные. Далее следует курируемая зона, где данные преобразуются в расходуемые наборы данных, такие как таблицы или файлы. Хотя эта зона может наполнять хранилище данных, она не может заменить его, поскольку не подходит для информационных панелей или отчетов конечных пользователей из-за более низкой скорости. Вместо этого эта зона идеально подходит для внутренней аналитики, не требующей времени, например для специальных запросов. Однако он отличается от промежуточной зоны тем, что содержит только проверенное качество потребительских данных и объединенное с аналогичными источниками. Затем отобранные данные используются для подачи в производственную зону.

Зона относится к каталогу в озере данных, содержащему определенные данные на определенном этапе. Обычно существует 3–5 зон, но их наименование и порядок могут различаться в разных организациях. Первая — это зона приземления, где необработанные и неизменяемые данные попадают в исходное состояние. Эта зона может стать дорогостоящей из-за большого объема собираемых данных, поэтому данные следует программно перемещать на холодный уровень доступа с заданными интервалами. Следующий этап — поэтапная зона, где к данным добавляются базовые структуры, чтобы подготовить их к курированию. После этого идет курируемая зона, где данные преобразуются в расходуемые наборы данных, а качество данных проверяется перед подачей в производственную зону. Рабочая зона обеспечивает легкий доступ к потребителям данных и включает в себя бизнес-логику, такую ​​как суррогатные ключи для конкретных приложений. Экспериментальная локация представляет собой песочницу, с которой исследователи данных могут экспериментировать, объединяя несколько наборов данных внутри и за пределами озера данных. Важно понимать философию каждой зоны, даже несмотря на то, что организации могут различаться своими конкретными зонами и тем, как они называются. Самые распространенные зоны — лендинг, кураторская и продакшн, которые есть почти у каждого аналитического решения. Другие зоны могут добавлять дополнительные функции к этим основным зонам.

После создания структуры зоны следующим шагом будет разработка структуры папок. Вот несколько стратегий для рассмотрения:

  1. Соглашение об именах должно быть удобочитаемым и самодокументируемым. Пожалуйста, сделайте это простым и понятным. Избегайте чрезмерного усложнения структуры папок, что затрудняет масштабирование и управление.
  2. Обеспечьте эффективные разрешения, не создавая ненужных накладных расходов на обслуживание. Избегайте создания слишком большого количества подкаталогов, требующих управления слишком большим количеством разрешений.
  3. Разделяйте вдумчиво. Согласуйте стратегию разделения с назначением зоны, в которой вы работаете. Например, стремитесь к оптимальному поиску в курируемой области и не стесняйтесь использовать разные стратегии для всех зон.
  4. Проектируйте намеренно.
  5. Сгруппируйте похожие предметы вместе. Папки должны содержать файлы одинаковой схемы и формата, чтобы с ними было проще работать последовательно.

Преимущество иерархического пространства имен

Очень важно начать представлять себе, как создать наше озеро данных Azure, хранить наши файлы и настроить его в качестве центрального узла нашего аналитического решения. Преимущества наличия иерархического пространства имен и эффективного управления различными зонами и файлами в этих зонах огромны. С Azure Data Lake Storage мы можем управлять контролем доступа и списками управления доступом для каждой папки и файла, что является значительным улучшением по сравнению с традиционным хранилищем BLOB-объектов. Кроме того, мы можем содержать сеть, подписи общего доступа и другие функции безопасности, которые мы подробно обсудим в следующем уроке.

Azure Data Lake Storage 2-го поколения — отличное решение для аналитических рабочих нагрузок или когда необходима удобочитаемая иерархия. Он сочетает в себе преимущества хранилища BLOB-объектов Azure и ADL Gen1 и является основным компонентом почти каждого решения для аналитики Azure. Таким образом, вы будете часто возвращаться к этому, независимо от того, как вы строите свой ответ. Наконец, помните, что безопасность имеет решающее значение, поэтому рекомендуется включить брандмауэр и ограничить доступ к другим службам Azure. Однако мы углубимся в безопасность позже.

Пример, стратегия структуры папок

Мы можем структурировать наше озеро данных на основе различных критериев, таких как исходная система, отделы или проекты, в зависимости от того, что больше всего подходит для нужд нашего бизнеса. Например, мы можем создать папки для каждого источника данных в фильтре исходной системы в нашей необработанной зоне. Это позволяет предоставлять разрешения на запись исходным системам на уровне источника данных, при этом списки управления доступом по умолчанию наследуются новыми папками, созданными в них. В производственной зоне мы можем создавать папки для разных отделов, таких как продажи, маркетинг или внутренние ИТ, и связывать с этими папками различные системы с другой логикой приложения. Мы также можем использовать фильтрацию на основе даты, разделив папки на годы, месяцы и дни, причем день будет последней папкой, в которой хранятся фактические файлы. Комбинируя эти стратегии фильтрации, наша структура папок может выглядеть так:

Давайте рассмотрим, как мы можем структурировать наши папки, фильтруя их по исходным системам, отделам, проектам или любым другим объектам, которые имеют смысл для вашего бизнеса. Например, в нашей необработанной зоне у нас может быть папка для каждого источника данных. Это позволяет нам предоставлять разрешения на запись на уровне источника данных с ACL по умолчанию, которые будут унаследованы всеми новыми папками ниже. Точно так же мы можем разделить нашу производственную зону на отделы продаж, маркетинга или внутренние ИТ-отделы с различной логикой приложений для каждой структуры папок. Даты также можно использовать для организации файлов со структурой года, месяца и дня в конце иерархии папок. Установка уровня источника данных для наследования разрешений необходима для упрощения обслуживания.

Кроме того, уровни конфиденциальности могут отделять общие данные от конфиденциальных данных в разных зонах. Структура папок может повлиять на производительность запросов, безопасность, сокращение данных и административное обслуживание. Таким образом, заранее продуманные решения по структуре папок могут оказаться полезными в будущем. Помните, что у каждого бизнеса есть уникальные аналитические потребности, поэтому решение должно быть адаптировано соответствующим образом.