Масштабирование облачной аналитики в Azure
Масштабируемая платформа данных имеет решающее значение для обеспечения быстрого роста данных. Огромные объемы данных создаются каждые секунды по всему миру. Ожидается, что объем доступных данных будет продолжать расти экспоненциально в течение следующих нескольких лет. По мере увеличения скорости создания данных скорость перемещения данных также увеличивается.
Независимо от того, сколько данных у вас есть, пользователи требуют быстрых ответов на запросы. Они ожидают, чтобы ждать минуты, а не часы, для результатов. В этой статье объясняется, как масштабировать решение аналитики в облаке Azure и продолжать отвечать требованиям пользователей к скорости.
Введение
Многие предприятия имеют большие монолиты платформы данных. Эти монолиты создаются вокруг одной учетной записи Azure Data Lake 2-го поколения, а иногда и одного контейнера хранилища. Одна подписка Azure часто используется для всех связанных задач платформы данных. Масштабирование на уровне подписки отсутствует на большинстве архитектурных платформ, что может препятствовать продолжению внедрения Azure, если пользователи могут столкнуться с любым из ограничений на уровне обслуживания или подписки Azure. Несмотря на то, что некоторые из ограничений являются мягкими ограничениями, они по-прежнему могут оказать значительное негативное влияние на платформу данных.
При структуре платформы данных рассмотрите структуру организации. Обратите внимание на ответственность за владение данными и функциональные обязанности вашей команды. Если ваша организация предоставляет командам большую степень автономии и распределенного владения, архитектура сетки данных является лучшим вариантом.
Избегайте ситуаций, ответственных за различные задачи решения, такие как прием, очистка, агрегирование и обслуживание. В зависимости от нескольких команд может привести к резкой потере скорости. Например, если потребители данных на уровне обслуживания должны подключить новые ресурсы данных или реализовать функциональные изменения для определенного ресурса данных, они должны пройти многоэтапный процесс. В этом примере ниже приведены действия.
- Потребитель данных отправляет запрос каждой команде, ответственной за этап конвейера данных.
- Команды должны работать вместе в синхронизации, так как уровни связаны друг с другом. Новые службы требуют изменения уровня очистки данных, что приводит к изменениям в уровне агрегирования данных, что приводит к изменениям в уровне обслуживания. Изменения могут повлиять на каждый этап конвейера.
- Командам трудно увидеть потенциальные последствия изменений обработки, так как у них нет обзора всего комплексного жизненного цикла. Они должны работать вместе для разработки четко определенного плана выпуска, который сводит к минимуму влияние на существующих потребителей и конвейеров. Это управление зависимостями увеличивает затраты на управление.
- Как правило, команды не являются экспертами по ресурсу данных, который запрашивает потребитель данных. Чтобы понять новые функции набора данных или значения параметров, необходимо обратиться к эксперту.
- После реализации всех изменений потребитель данных уведомляется о том, что новый ресурс данных готов к использованию.
Каждая крупная организация имеет тысячи потребителей данных. Сложный процесс, как описано, сильно снижает скорость в крупных архитектурах, так как централизованные команды становятся узким местом для бизнес-подразделений. Результатом является меньше инноваций и ограниченной эффективности. Возможно, подразделения могут решить выйти из службы и создать собственную платформу данных.
Методы масштабирования
Аналитика в масштабе облака решает проблемы масштабирования с помощью двух основных понятий:
- Использование целевых зон данных для масштабирования
- Использование продуктов данных или интеграции данных для масштабирования для обеспечения возможности распределенного и децентрализованного владения данными
Вы можете развернуть одну целевую зону данных или несколько. Целевые зоны данных позволяют обнаруживать данные и управлять ими, подключаясь к целевой зоне управления данными. Каждая целевая зона управления данными находится в одной подписке Azure.
Подписки — это единицы управления, выставления счетов и масштабирования Azure. Они играют важную роль в крупномасштабном плане внедрения Azure.
Масштабирование с помощью целевых зон данных
Основными понятиями облачной аналитики являются целевая зона управления данными и целевая зона данных. Каждое из них должно размещаться в собственной подписке Azure. Разделяя их, вы можете четко отделять обязанности, следовать принципу наименьших привилегий и частично устранять проблемы масштабирования подписки, которые были упоминание ранее. Минимальная настройка облачной аналитики включает отдельную целевую зону для управления данными и целевую зону управления данными.
Однако минимальной настройки недостаточно для крупномасштабных развертываний платформы данных. Компании создают крупномасштабные платформы и делают инвестиции в последовательное и эффективное масштабирование своих данных и аналитических усилий с течением времени. Для преодоления ограничений уровня подписки аналитика в облаке использует подписки в качестве единицы масштабирования, как описано в целевых зонах Azure. Этот метод позволяет увеличить объем пространства платформы данных, добавив в архитектуру дополнительные целевые зоны данных. Внедрение этого метода также устраняет проблему одного azure Data Lake 2-го поколения, используемого для всей организации, так как каждая целевая зона данных включает три озера данных. Проекты и действия из нескольких доменов могут быть распределены по нескольким подпискам Azure, что обеспечивает большую масштабируемость.
Определите, сколько целевых зон данных требуется вашей организации перед реализацией архитектуры облачной аналитики. Правильное решение лежит в основе эффективной и эффективной платформы данных.
Количество целевых зон данных, необходимых для многих факторов, особенно:
- Выравнивание организации, например, сколько подразделений нуждается в собственной целевой зоне данных
- Операционные рекомендации, такие как выравнивание ресурсов операций и ресурсов организации, относящихся к бизнес-единице.
Использование правильной модели целевой зоны данных сводит к минимуму будущие усилия по перемещению продуктов данных и ресурсов данных из одной целевой зоны в другую. Она также помогает эффективно и согласованно масштабировать большие данные и аналитические усилия в будущем.
При принятии решения о количестве целевых зон данных следует учитывать следующие факторы.
| Множитель | Description |
|---|---|
| Структура организации и владение данными | Рассмотрим структуру организации и способ владения данными в вашей организации. |
| Регион и расположение | При развертывании в нескольких регионах определите, какой регион или регионы должны размещать зоны данных. Обязательно соблюдайте все требования к месту размещения данных. |
| Планы продаж | Квоты подписки не являются гарантиями емкости и применяются на основе каждого региона. |
| Независимость данных | Из-за нормативных требований о суверенитете данных данные должны храниться в определенном регионе и следовать политикам конкретного региона. |
| Политики Azure | Целевые зоны данных должны соответствовать требованиям различных политик Azure. |
| Граница управления | Подписки предоставляют границу управления для управления и изоляции, которая четко разделяет проблемы. |
| Сеть | Каждая целевая зона имеет виртуальную сеть. Так как виртуальная сеть находится в одном регионе, для каждого нового региона требуется новая целевая зона. Виртуальные сети должны быть одноранговых виртуальных сетей, чтобы обеспечить междоменный обмен данными. |
| Ограничения | Подписка имеет ограничения. Имея несколько подписок, вы можете снизить опасность попадания этих ограничений. |
| Распределение затрат | Рассмотрите, должны ли общие службы, такие как учетные записи хранения, оплачиваемые централизованно, разделиться по бизнес-единицам или домену. Использование отдельной подписки создает границу для распределения затрат. Вы можете достичь той же функциональности с помощью тегов. |
| Классификации данных и конфиденциальные данные | Механизмы безопасности могут повлиять на разработку продуктов данных и удобство использования платформы данных. Рассмотрите классификации данных и определите, требуются ли строго конфиденциальные наборы данных, например JIT-доступ, управляемые клиентом ключи (CMK), точные сетевые элементы управления или многое другое шифрование. |
| Другие юридические или связанные с безопасностью последствия | Рассмотрите, существуют ли другие юридические или требования к безопасности, требующие логического или физического разделения данных. |
Если вы реализуете архитектуру сетки данных, рассмотрите следующие факторы, как решить, как распределить целевые зоны данных и домены данных.
| Множитель | Description |
|---|---|
| Предметные области | Рассмотрим домены данных, которые использует ваша организация, и определите, какие будут находиться на платформе данных. Рассмотрим размер отдельных доменов данных. Дополнительные сведения см. в разделе "Что такое домены данных"? |
| Задержка | Домены, которые совместно работают над большими объемами данных, могут передавать большое количество данных в целевых зонах. Рассмотрите возможность выделения доменов в одной целевой зоне или регионе. Разделение их увеличивает задержку и может увеличить затраты в межрегионных доменах. |
| Безопасность | Для некоторых развертываний или конфигураций служб требуются повышенные привилегии в подписке. Предоставление этим привилегиям пользователю в одном домене неявно дает этому пользователю те же привилегии в других доменах в той же подписке. |
Дополнительные сведения см. в руководстве по платформе внедрения облака для подписок.
Многие организации хотят эффективного масштабирования своей корпоративной платформы данных. Бизнес-подразделения должны иметь возможность создавать собственные решения и приложения для обработки данных в соответствии с их уникальными требованиями. Предоставление этой возможности может быть проблемой, так как многие существующие платформы данных не создаются на основе концепций масштабируемости и децентрализованной собственности. Этот недостаток четко рассматривается в архитектуре, структуре команды и модели ops этих платформ данных.
Целевые зоны данных не создают подсистемы данных в вашей организации. Рекомендуемая настройка сети для облачной аналитики обеспечивает безопасный и общий доступ к данным на месте в целевых зонах, что, в свою очередь, обеспечивает инновации в доменах данных и бизнес-подразделениях. Дополнительные сведения см . в рекомендациях по архитектуре сети.
То же самое относится к уровню удостоверений. При использовании одного клиента Microsoft Entra можно предоставить удостоверениям доступ к ресурсам данных в нескольких целевых зонах данных. Дополнительные сведения о процессе авторизации пользователей и удостоверений см. в разделе "Управление доступом к данным".
Примечание.
Если у вас несколько целевых зон данных, каждая зона может подключаться к данным, размещенным в других зонах. Это позволяет группам сотрудничать в бизнесе.
Аналитика в масштабе облака использует общую архитектуру для защиты согласованного управления. Архитектура определяет базовые возможности и политики. Все целевые зоны данных соответствуют одному и тому же аудиту и элементам управления. Команды могут создавать конвейеры данных, прием источников и создавать такие продукты данных, как отчеты и панели мониторинга. Teams также может выполнять анализ Spark/SQL по мере необходимости. Вы можете расширить возможности целевой зоны для данных, добавив службы к предусмотренной политикой функции. Например, команда может добавить сторонний обработчик графов для решения бизнес-требований.
Аналитика в масштабе облака уделяет особое внимание централизованному каталогизации и классификации для защиты данных и позволяет различным группам обнаруживать продукты данных.
Внимание
Рекомендуется запрашивать данные в разных регионах. Вместо этого убедитесь, что данные близки к вычислительным ресурсам, использующим его, соблюдая региональные границы.
Архитектура облачной аналитики и концепция целевых зон данных позволяют вашей организации легко увеличивать размер платформы данных с течением времени. Вы можете добавить дополнительные целевые зоны данных в поэтапном подходе. Клиенты не должны сначала иметь несколько целевых зон. При внедрении этой архитектуры определите приоритет нескольких целевых зон данных и продуктов данных, содержащихся в них. Правильная приоритетность помогает обеспечить успешное развертывание облачной аналитики.
Масштабирование с помощью продуктов данных или интеграции данных
В каждой целевой зоне ваша организация может масштабироваться с помощью приложений данных. Приложения данных — это единицы или компоненты архитектуры данных, которые инкапсулируют функциональные возможности, обеспечивающие продукты данных, оптимизированные для чтения, для использования другими приложениями данных. В Azure приложения данных — это среды в виде групп ресурсов, которые позволяют кроссфункциональным командам реализовать решения и рабочие нагрузки данных. Связанная команда заботится о комплексном жизненном цикле решения данных, который включает прием, очистку, агрегирование и обслуживание задач.
Аналитика в масштабе облака решает проблемы интеграции данных и ответственности, которые были рассмотрены ранее. Вместо монолитных функциональных обязанностей по приему таблиц и интеграции исходной системы эталонная архитектура обеспечивает распределенную архитектуру, которая управляется доменами данных. Кроссфункциональный отдел берет на себя сквозную функциональную ответственность и ответственность за данные область.
Вместо централизованного технического стека и команды, ответственной за все задачи рабочего процесса обработки данных, можно распределить сквозную ответственность между несколькими автономными кроссфункциональными группами интеграции данных. Каждая команда владеет возможностью домена или поддомена и рекомендуется обслуживать наборы данных в соответствии с требованиями потребителей данных.
Эти архитектурные различия приводят к увеличению скорости на платформе данных. Потребители данных больше не должны полагаться на набор централизованных команд или бороться за их запрошенные изменения, чтобы быть приоритетными. Так как небольшие команды берут на себя ответственность за комплексный рабочий процесс интеграции, цикл обратной связи между поставщиком данных и потребителем данных гораздо короче. Такой подход приводит к более быстрой приоритетности, более быстрым циклам разработки и более гибкому процессу разработки. Ваши команды больше не должны синхронизировать процессы и планы выпуска между собой, так как кроссфункциональную группу интеграции данных имеет полное представление о сквозном техническом стеке и последствиях изменений. Он может использовать методики проектирования программного обеспечения для выполнения модульных и интеграции тестов, чтобы свести к минимуму общий эффект на потребителей.
В идеале команда, которая владеет системами интеграции данных, также владеет исходными системами. Эта команда должна состоять из инженеров данных, работающих над исходными системами, экспертами по темам (SMEs) для наборов данных, облачных инженеров и владельцев продуктов данных. Создание такой кроссфункциональную команды сокращает объем взаимодействия, необходимого для внешних команд, и важно при разработке полного стека от инфраструктуры к фактическим конвейерам данных.
Основой платформы данных является наборы данных, интегрированные из исходных систем. Эти наборы данных позволяют группам продуктов данных внедрять инновации в таблицы бизнес-фактов и улучшать принятие решений и бизнес-процессы. Команды интеграции с данными и группы продуктов данных должны предлагать соглашения об уровне обслуживания потребителям и обеспечить соблюдение всех соглашений. Предлагаемые соглашения об уровне обслуживания могут быть связаны с качеством данных, временная шкала ss, скоростью ошибок, временем простоя и другими задачами.
Итоги
Используя механизмы масштабирования архитектуры облачной аналитики, ваша организация увеличивает объем ресурсов данных в Azure с течением времени, избегая известных технических ограничений. Оба метода масштабирования, описанные в этой статье, помогают преодолеть различные технические сложности и использовать их простым и эффективным способом.