Другие третьи лица
Структурированные данные
Неструктурированные данные
Машина и звук , сенсорное изображение и
ДанныеВидеоданные
Неструктурированные текстовые данные
Данные о контенте социальных сетей
После того как вы выбрали необходимые вам возможности работы с данными и определили последовательность построения, можно приступать к выбору конкретных технологий работы с данными. Именно здесь важна эталонная архитектура. В целом, основные технологические компоненты будут определяться выбранным архетипом и выбранным поставщиком облачных услуг (CSP). На рисунке 26.3 показан выбор технологии для архитектуры Lakehouse, построенной с использованием Databricks на Azure. В данном конкретном случае дизайн максимально использует возможности Databricks. В качестве альтернативы можно было бы использовать программное обеспечение с открытым исходным кодом, чтобы минимизировать привязку к поставщику, снизить стоимость и/или обеспечить лучшие в своем классе возможности. Аналогичные архитектуры Lakehouse существуют и для других облачных сред.
В общем, не изобретайте колесо, а лучше воспользуйтесь проверенной эталонной архитектурой, чтобы ускорить разработку и минимизировать риски внедрения.
Лучшие практики проектирования архитектуры данных
Начните с малого. Если у вас нет многих возможностей для работы с данными, определите минимально жизнеспособную архитектуру для удовлетворения наиболее приоритетных потребностей и начните с нее. Создайте и разверните минимально жизнеспособную архитектуру, которая обеспечивает конкретные компоненты данных, необходимые для каждого желаемого варианта использования. Например, компания среднего размера, занимающаяся управлением активами, определила облачную платформу данных и создала ее начальную версию, которую можно было использовать для структурирования данных в течение всего нескольких месяцев.
Эталонная архитектура: Lakehouse с использованием Databricks в Azure
Ведение журнала и мониторинг:
Мониторинг Azure
Интеллектуальные приложения и другие операционные системы, основанные на данных
ПРИЛОЖЕНИЯ
ПОТРЕБЛЕНИЕ ДАННЫХ
Среда моделирования лаборатории DS
Azure ML
Azure ML Studio DS Notebooks Kedro ML pipelines
BI и визуализация
Power BI, QlikView, DB Notebooks
SQL Analytics
Блокноты Databricks
РАСШИРЕННАЯ АНАЛИТИКА
АНАЛИТИКА
Конечные точки API данных: Azure API Manage- ment, собственные API
ДАННЫЕ СЕРВИСЫ
Конечные точки SQL:
Databricks SQL
Конечные точки публикации/подписки: Темы Kafka на Azure EventHubs
Аналитические оптимизированные данные: Дельта-таблицы на ADLS
Azure Data Lake Gen 2
(исходные данные)
ОЗЕРО ДАННЫХ DATABRICKS DATA LAKEHOUSE
ХРАНИЛИЩА ДАННЫХ
Озеро Дельта
Песочница (для лаборатории DS)
ПОТОК ДАННЫХ
Хранилище метрик и характеристик: Databricks Feature Store, Tecton
Федерация данных / виртуализация: Denodo, Trino/ Starburst, Dremio
Databricks (pySpark, Spark SQL)
ПАКЕТНАЯ ОБРАБОТКА
Системы обработки данных (потоковая передача данных Spark)
ПОТОКОВАЯ ОБРАБОТКА
Databricks ML Runtime Azure ML
ИИ/МЛ
ПРОЦЕССИНГ
Создание конвейеров данных:
Python, ADF, DB Notebooks
Оркестровка конвейера данных:
Вакансии Databricks, ADF, Airflow
Управление моделями: Каталог данных:
БД mlFlow или Azure Purview, Datahub
Наблюдаемость Линейность инадежность данных: МонтеМетаданные : Данные Маркеса Карло, Datafold и OpenMetadata
OSS, Collibra, Alation
Реестр ML
Управление идентификацией: Azure Active Directory
Управление секретами: Azure Vault
Инфраструктура как код: ARM DevOps: Azure DevOps,
шаблоны, Terraform, Pulumi
Github, GitLab
Золото
Серебро
Бронза
Зона высадки
ИСТОЧНИКИ ДАННЫХ
Структурированные данные
Неструктурированные данные
Транзакционные Структурированные
Другие третьи лица
Машина и Звук,
Неструктурированные
Социальные сети
& Event DataMaster &
Структурированный
SensorImage , и
Текстовые данные
Содержание
Справочные данные
Данные
ДанныеВидеоданные
Данные
Обеспечьте зрелость всего жизненного цикла данных, а не вкладывайте слишком много средств только в один этап потока данных. Архитектура будет настолько сильна, насколько силен самый слабый компонент. Например, если необходим поток и обработка данных в режиме реального времени, то одних инвестиций в обеспечение возможности приема данных в режиме реального времени будет недостаточно - данные будут поступать быстро, а затем их обработке будут мешать пакетные процессы в хранилище или других точках.
