Всем привет. Думаю, предыдущую рубрику можно закрывать. Я постарался охватить все основные направления работы с данными и дать пошаговый план развития с полезными ссылками для каждой позиции.
Теперь я хочу начать следующую рубрику, которая будет посвящена архитектуре аналитических решений. Думаю, что более эффективно изучать материал, двигаясь от общего к частному, от абстракции к конкретике. Такой подход позволяет наиболее быстро и эффективно разобраться в любом предмете. Поэтому, я предлагаю сначала взглянуть на архитектуру решений в целом, а затем подробно разобрать каждый из её элементов.
Сегодня я хочу коснуться базовых вещей - концепций, на которых строится любая аналитическая архитектура. В последующих постах для закрепления я буду брать примеры реальных решений и разбирать их, рассказывая какие инструменты за какую задачу отвечают.
Итак, поговорим о концепциях.
Если абстрагироваться, то любую аналитическую архитектуру можно разделить на 5 слоев:
1) Source Layer (слой источников данных);
2) Data Processing Layer (слой обработки данных);
3) Storage Layer (слой хранения данных);
4) Access Layer (слой доступа к данным);
5) Service Layer (сервисный слой).
Разберём каждый слой подробнее:
Source Layer. Этот слой отвечает за все наши источники данных. Это могут быть OLTP базы данных, которые отвечают за обслуживание операционной деятельности компании, различные файлы, в которых хранятся операционные данные (файлы могут быть различных форматов: csv, xlsx, txt, json, xml и т.д.), API внешних систем, IoT (интернет вещей) и др.
Примеры сервисов и инструментов на этом уровне: MySQL СУБД, Google Analytics, Facebook Ads, FTP/SFTP сервер, Salesforce, Kafka.
Data Processing Layer. Этот слой отвечает за обработку данных. Как раз здесь встречаются такие понятия, как ETL/ELT и data pipelines. Т.е., благодаря этому слою, осуществляется извлечение данных из источников, трансформация данных, движение данных и загрузка их в централизованный слой хранения данных.
Примеры сервисов и инструментов на этом уровне: Python и SQL, Apache Airflow, dbt, Pentaho Data Integration, Matillion ETL, Spark, AWS Glue, Azure Data Factory и др.
Storage Layer. Этот слой отвечает за централизованное хранение данных. Здесь появляются такие понятия как Data Warehouse (DWH), Data Lake и новомодное слово Lakehouse. Какое решение использует компания зависит от её задач. Например, если компании аналитическое решение нужно для конечной визуализации данных в BI-инструменте и для написания SQL-запросов к обработанным данным для поиска инсайтов, то достаточно будет использовать хранилище данных. Если у компании есть Data Science департамент, который строит ML-модели на основе данных для задач бизнеса, то разумным решением будет также использование Data Lake или Lakehouse, так как построение моделей требует обработки большого количества данных и для таких целей используется более сложный non-SQL код; Data Lake в таком случае является более гибким решением, так как обеспечивает быстрый прямой доступ к файлам.
Большим компаниям обычно нужен микс хранилища данных и озера данных, т.е., так называемая, Data Platform. Платформа данных как раз заточена на то, чтобы обслуживать и уровень BI-приложений и Data Science.
Примеры сервисов и инструментов на этом уровне: AWS S3, Azure Data Lake, Google Cloud Storage, AWS Redshift, Azure Synapse, Google BigQuery, HDFS (Hadoop), Vertica, Clickhouse и др.
Access Layer. Слой доступа к данным. Здесь в игру вступают BI-приложения, data-аналитики и data-сайнтисты, которые используют данные (уже находящиеся в Data Lake или DWH) для своих целей. В качестве приёмщика данных может также выступать база данных, которая обслуживает back-end интернет-магазина и позволяет показывать рекомендуемые товары на основе ML-моделей. В общем, этот слой является верхушкой айсберга, ради которой собственно и затевается построение всей системы.
Примеры сервисов и инструментов на этом уровне: Power BI, Tableau, AWS SageMaker, GCP AI Platform и др.
Теперь я хочу начать следующую рубрику, которая будет посвящена архитектуре аналитических решений. Думаю, что более эффективно изучать материал, двигаясь от общего к частному, от абстракции к конкретике. Такой подход позволяет наиболее быстро и эффективно разобраться в любом предмете. Поэтому, я предлагаю сначала взглянуть на архитектуру решений в целом, а затем подробно разобрать каждый из её элементов.
Сегодня я хочу коснуться базовых вещей - концепций, на которых строится любая аналитическая архитектура. В последующих постах для закрепления я буду брать примеры реальных решений и разбирать их, рассказывая какие инструменты за какую задачу отвечают.
Итак, поговорим о концепциях.
Если абстрагироваться, то любую аналитическую архитектуру можно разделить на 5 слоев:
1) Source Layer (слой источников данных);
2) Data Processing Layer (слой обработки данных);
3) Storage Layer (слой хранения данных);
4) Access Layer (слой доступа к данным);
5) Service Layer (сервисный слой).
Разберём каждый слой подробнее:
Source Layer. Этот слой отвечает за все наши источники данных. Это могут быть OLTP базы данных, которые отвечают за обслуживание операционной деятельности компании, различные файлы, в которых хранятся операционные данные (файлы могут быть различных форматов: csv, xlsx, txt, json, xml и т.д.), API внешних систем, IoT (интернет вещей) и др.
Примеры сервисов и инструментов на этом уровне: MySQL СУБД, Google Analytics, Facebook Ads, FTP/SFTP сервер, Salesforce, Kafka.
Data Processing Layer. Этот слой отвечает за обработку данных. Как раз здесь встречаются такие понятия, как ETL/ELT и data pipelines. Т.е., благодаря этому слою, осуществляется извлечение данных из источников, трансформация данных, движение данных и загрузка их в централизованный слой хранения данных.
Примеры сервисов и инструментов на этом уровне: Python и SQL, Apache Airflow, dbt, Pentaho Data Integration, Matillion ETL, Spark, AWS Glue, Azure Data Factory и др.
Storage Layer. Этот слой отвечает за централизованное хранение данных. Здесь появляются такие понятия как Data Warehouse (DWH), Data Lake и новомодное слово Lakehouse. Какое решение использует компания зависит от её задач. Например, если компании аналитическое решение нужно для конечной визуализации данных в BI-инструменте и для написания SQL-запросов к обработанным данным для поиска инсайтов, то достаточно будет использовать хранилище данных. Если у компании есть Data Science департамент, который строит ML-модели на основе данных для задач бизнеса, то разумным решением будет также использование Data Lake или Lakehouse, так как построение моделей требует обработки большого количества данных и для таких целей используется более сложный non-SQL код; Data Lake в таком случае является более гибким решением, так как обеспечивает быстрый прямой доступ к файлам.
Большим компаниям обычно нужен микс хранилища данных и озера данных, т.е., так называемая, Data Platform. Платформа данных как раз заточена на то, чтобы обслуживать и уровень BI-приложений и Data Science.
Примеры сервисов и инструментов на этом уровне: AWS S3, Azure Data Lake, Google Cloud Storage, AWS Redshift, Azure Synapse, Google BigQuery, HDFS (Hadoop), Vertica, Clickhouse и др.
Access Layer. Слой доступа к данным. Здесь в игру вступают BI-приложения, data-аналитики и data-сайнтисты, которые используют данные (уже находящиеся в Data Lake или DWH) для своих целей. В качестве приёмщика данных может также выступать база данных, которая обслуживает back-end интернет-магазина и позволяет показывать рекомендуемые товары на основе ML-моделей. В общем, этот слой является верхушкой айсберга, ради которой собственно и затевается построение всей системы.
Примеры сервисов и инструментов на этом уровне: Power BI, Tableau, AWS SageMaker, GCP AI Platform и др.
Service Layer. Обслуживающий слой, который включает в себя технологии и инструменты, обеспечивающие безопасность решения, отправку уведомлений об ошибках в логах, поддержку кода, автоматизацию деплоймента приложений (CI/CD) и т.д.
Примеры сервисов и инструментов на этом уровне: GitHub, Jenkins, Google Cloud Build, AWS SNS, AWS Cloud Formation, Terraform и др.
Этой информации достаточно, чтобы на фундаментальном уровне понять, на чём основана любая аналитическая архитектура и как она работает.
Прилагаю базовую схему, которая отображает все слои системы. Костяк системы позаимствовал у Димы Аношина в одной из его презентаций и немного изменил её, чтобы адаптировать под сегодняшний пост.
Примеры сервисов и инструментов на этом уровне: GitHub, Jenkins, Google Cloud Build, AWS SNS, AWS Cloud Formation, Terraform и др.
Этой информации достаточно, чтобы на фундаментальном уровне понять, на чём основана любая аналитическая архитектура и как она работает.
Прилагаю базовую схему, которая отображает все слои системы. Костяк системы позаимствовал у Димы Аношина в одной из его презентаций и немного изменил её, чтобы адаптировать под сегодняшний пост.
Продолжаем нашу тему построения аналитической архитектуры.
Вчера я рассказал о базовых концепциях, на которых строится любое аналитическое решение. Сегодня же я приведу реальный пример аналитической инфраструктуры и разберу его.
Это кейс с архитектурой на Google Cloud, которую я выстраивал на протяжении полугода. Кейс, которым я горжусь и которым не стыдно хвастаться)
Цель проекта - построить end-to-end решение для маркетинга для принятия бизнес-решений на основе данных.
Задачи проекта:
- настроить корректный сбор данных на уровне источников;
- построить централизованное хранилище данных;
- построить автоматизированный процесс регулярного извлечения данных из источников, загрузки данных в хранилище и преобразования данных (ETL);
- построить автоматизированную сквозную отчётность об эффективности источников и каналов трафика, рекламных кампаний и другую бизнес-отчётность в BI-инструменте.
Вчера я рассказал о базовых концепциях, на которых строится любое аналитическое решение. Сегодня же я приведу реальный пример аналитической инфраструктуры и разберу его.
Это кейс с архитектурой на Google Cloud, которую я выстраивал на протяжении полугода. Кейс, которым я горжусь и которым не стыдно хвастаться)
Цель проекта - построить end-to-end решение для маркетинга для принятия бизнес-решений на основе данных.
Задачи проекта:
- настроить корректный сбор данных на уровне источников;
- построить централизованное хранилище данных;
- построить автоматизированный процесс регулярного извлечения данных из источников, загрузки данных в хранилище и преобразования данных (ETL);
- построить автоматизированную сквозную отчётность об эффективности источников и каналов трафика, рекламных кампаний и другую бизнес-отчётность в BI-инструменте.
Давайте разложим эту архитектуру на слои, о которых я рассказывал в предыдущем посте, и распишем, какую задачу решает определённый инструмент:
Source Layer. Этот слой включает в себя следующие источники:
1) API Firebase Analytics. Firebase Analytics собирает данные об эффективности привлечения трафика в мобильное приложение и данные о поведении пользователей внутри приложения;
2) API Google Ads. В Google Ads хранятся данные о расходах на рекламу в сети Google и данные о об эффективности рекламных активностей;
3) Binotel. Сервис позволяет получать данные о звонках на сайте и заказах обратного звонка через виджет;
4) API Google Analytics. GA собирает данные об эффективности привлечения трафика на сайт и данные о поведении пользователей на сайте;
5) API Facebook Ads. Facebook Ads хранит данные о расходах на рекламу в сети Facebook и данные о об эффективности рекламных активностей;
6) API Criteo. Criteo - это ремаркетинговая платформа, которая позволяет настраивать рекламу на пользователей, которые уже знакомы с брендом;
7) API Currency Layer. Позволяет получать данные о курсах валют для конвертации;
8) Google Sheets. Хранит данные о расходах на неплатные источники трафика;
9) FTP-сервер. На FTP-сервере хранятся csv-файлы с данными о конечных сделках за каждый день.
Data Processing Layer. Инструменты, которые я использовал для задач ETL и стриминга:
1) BigQuery Data Transfer. Инструмент, который позволяет в несколько кликов настроить поток данных в Google BigQuery из различных источников данных. Использовал для загрузки данных из Firebase Analytics и Google Ads.
2) Связку Cloud Functions + Cloud Pub/Sub + Cloud Scheduler для регулярной загрузки данных из Google Analytics, Facebook Ads, Criteo, Currency Layer и FTP-сервера.
Cloud Functions - это serverless-среда, где вы можете запускать ваш код в виде функций, направленных на решение одной задачи. Триггерами для запуска функции выступают различные события (http-запросы, отправка сообщения в Pub/Sub и др.). Все мои функции были реализованы на Python (но сервис поддерживает и другие языки).
Cloud Pub/Sub - это сервис для приёма и отправки сообщений. По факту это буфер, в который вы можете писать какие-то данные и читать данные из него. On-premise аналогом Pub/Sub является Kafka.
Cloud Scheduler - облачный cron-менеджер, который позволяет запускать задачи по заданному расписанию.
Полная логика работы этой связки такая: Cloud Scheduler каждые сутки по расписанию отправляет сообщение в Pub/Sub. При появлении сообщения в Pub/Sub запускается функция, которая извлекает данные из источника и загружает их в Google BigQuery.
Если посмотреть на схему, то можно увидеть, что процесс извлечения и загрузки данных из ftp-сервера включает в себя дополнительные компоненты. Дело в том, что сервер принимает обращения только с указанных в wish-листе ip-адресов. Поэтому, передо мной стояла задача привязать статический ip-адрес к облачной функции, чтобы функция могла делать запросы на сервер и получать данные. Для привязки статического ip-адреса необходимо было создать виртуальную сеть (VPC), создать Serverless VPC Accessor для доступа функции к виртуальной сети, создать NAT-сервер и Router (через Cloud NAT и Cloud Router), чтобы функция могла выходить в интернет и получать данные из FTP-сервера.
3) Data Build Tool (dbt), который был развёрнут в Cloud Run.
dbt - это сервис для создания трансформаций данных внутри хранилища, используя всем знакомый нам SQL. dbt также позволяет перенести все лучшие практики из разработки программного обеспечения на построение хранилища данных. К таким бест практисам относятся: версионность кода (используя Git), рзделение сред разработки на dev и prod, автоматизация тестирования, документация и др. Также dbt использует Directed acyclic graph (DAG), так что ваши трансформация всегда будут запускаться в нужном порядке. У этого инструмента ещё очень много фишек, описать которые одного поста точно не хватит)
Source Layer. Этот слой включает в себя следующие источники:
1) API Firebase Analytics. Firebase Analytics собирает данные об эффективности привлечения трафика в мобильное приложение и данные о поведении пользователей внутри приложения;
2) API Google Ads. В Google Ads хранятся данные о расходах на рекламу в сети Google и данные о об эффективности рекламных активностей;
3) Binotel. Сервис позволяет получать данные о звонках на сайте и заказах обратного звонка через виджет;
4) API Google Analytics. GA собирает данные об эффективности привлечения трафика на сайт и данные о поведении пользователей на сайте;
5) API Facebook Ads. Facebook Ads хранит данные о расходах на рекламу в сети Facebook и данные о об эффективности рекламных активностей;
6) API Criteo. Criteo - это ремаркетинговая платформа, которая позволяет настраивать рекламу на пользователей, которые уже знакомы с брендом;
7) API Currency Layer. Позволяет получать данные о курсах валют для конвертации;
8) Google Sheets. Хранит данные о расходах на неплатные источники трафика;
9) FTP-сервер. На FTP-сервере хранятся csv-файлы с данными о конечных сделках за каждый день.
Data Processing Layer. Инструменты, которые я использовал для задач ETL и стриминга:
1) BigQuery Data Transfer. Инструмент, который позволяет в несколько кликов настроить поток данных в Google BigQuery из различных источников данных. Использовал для загрузки данных из Firebase Analytics и Google Ads.
2) Связку Cloud Functions + Cloud Pub/Sub + Cloud Scheduler для регулярной загрузки данных из Google Analytics, Facebook Ads, Criteo, Currency Layer и FTP-сервера.
Cloud Functions - это serverless-среда, где вы можете запускать ваш код в виде функций, направленных на решение одной задачи. Триггерами для запуска функции выступают различные события (http-запросы, отправка сообщения в Pub/Sub и др.). Все мои функции были реализованы на Python (но сервис поддерживает и другие языки).
Cloud Pub/Sub - это сервис для приёма и отправки сообщений. По факту это буфер, в который вы можете писать какие-то данные и читать данные из него. On-premise аналогом Pub/Sub является Kafka.
Cloud Scheduler - облачный cron-менеджер, который позволяет запускать задачи по заданному расписанию.
Полная логика работы этой связки такая: Cloud Scheduler каждые сутки по расписанию отправляет сообщение в Pub/Sub. При появлении сообщения в Pub/Sub запускается функция, которая извлекает данные из источника и загружает их в Google BigQuery.
Если посмотреть на схему, то можно увидеть, что процесс извлечения и загрузки данных из ftp-сервера включает в себя дополнительные компоненты. Дело в том, что сервер принимает обращения только с указанных в wish-листе ip-адресов. Поэтому, передо мной стояла задача привязать статический ip-адрес к облачной функции, чтобы функция могла делать запросы на сервер и получать данные. Для привязки статического ip-адреса необходимо было создать виртуальную сеть (VPC), создать Serverless VPC Accessor для доступа функции к виртуальной сети, создать NAT-сервер и Router (через Cloud NAT и Cloud Router), чтобы функция могла выходить в интернет и получать данные из FTP-сервера.
3) Data Build Tool (dbt), который был развёрнут в Cloud Run.
dbt - это сервис для создания трансформаций данных внутри хранилища, используя всем знакомый нам SQL. dbt также позволяет перенести все лучшие практики из разработки программного обеспечения на построение хранилища данных. К таким бест практисам относятся: версионность кода (используя Git), рзделение сред разработки на dev и prod, автоматизация тестирования, документация и др. Также dbt использует Directed acyclic graph (DAG), так что ваши трансформация всегда будут запускаться в нужном порядке. У этого инструмента ещё очень много фишек, описать которые одного поста точно не хватит)
👍1
Cloud Run - это serverless-среда для запуска Docker-контейнеров. Удобство Cloud Run в том, что вам не нужно самостоятельно разворачивать виртуальную машину и устанавливать там Docker. Более того, приложение, которое развёрнуто в контейнере будет запускаться только при отправке http-запроса на endpoint этого контейнера. Поэтому, вы не будете платить за мощности виртуальной машины, если приложение по факту не работает.
Storage Layer. В качестве хранилища данных, как уже стало понятно выше, был выбран Google BigQuery. О построении хранилища хочу сделать отдельный пост, поэтому здесь подробно останавливаться не буду.
Access Layer. В качестве приёмщика данных на этой схеме выступает Power BI, который читает данные из BigQuery и обновляет дашборды с отчётами.
Service Layer. Для построения и обслуживания архитектуры здесь я использую такие инструменты:
1) PyCharm - IDE для локальной работы с Python-кодом;
2) Visual Studio Code - использовал при работе с dbt core;
3) Cloud Source Repositories - удалённый репозиторий для хранения кода. По типу GitHub только внутри Google Cloud;
4) Cloud Build - сервис для построения CI/CD пайплайнов. Использовал для автоматического деплоймента Python-кода в Cloud Functions и Docker-контейнера в Cloud Run.
Логика CI/CD следующая: при внесении изменений в код у себя на компьютере я делаю commit через git и отправляю код в Cloud Source Repositories. При создании коммита на ветке master запускается Cloud Build и автоматически деплоит изменения. В случае с Cloud Run он сначала добавляет новый образ Docker в Container Registry и затем разворачивает контейнер непосредственно в Cloud Run.
5) Cloud Container Registry - для хранения образов Docker-контейнеров;
6) Cloud Logging - для мониторинга логов. Планирую также, используя Cloud Logging API, настроить отправку уведомлений об ошибках в мессенджерах для быстрого реагирования на сбои.
Ну вот и всё. Должно было получиться интересно. Очень интересна обратная связь по поводу такого формата разборов архитектур. Что скажете?
Storage Layer. В качестве хранилища данных, как уже стало понятно выше, был выбран Google BigQuery. О построении хранилища хочу сделать отдельный пост, поэтому здесь подробно останавливаться не буду.
Access Layer. В качестве приёмщика данных на этой схеме выступает Power BI, который читает данные из BigQuery и обновляет дашборды с отчётами.
Service Layer. Для построения и обслуживания архитектуры здесь я использую такие инструменты:
1) PyCharm - IDE для локальной работы с Python-кодом;
2) Visual Studio Code - использовал при работе с dbt core;
3) Cloud Source Repositories - удалённый репозиторий для хранения кода. По типу GitHub только внутри Google Cloud;
4) Cloud Build - сервис для построения CI/CD пайплайнов. Использовал для автоматического деплоймента Python-кода в Cloud Functions и Docker-контейнера в Cloud Run.
Логика CI/CD следующая: при внесении изменений в код у себя на компьютере я делаю commit через git и отправляю код в Cloud Source Repositories. При создании коммита на ветке master запускается Cloud Build и автоматически деплоит изменения. В случае с Cloud Run он сначала добавляет новый образ Docker в Container Registry и затем разворачивает контейнер непосредственно в Cloud Run.
5) Cloud Container Registry - для хранения образов Docker-контейнеров;
6) Cloud Logging - для мониторинга логов. Планирую также, используя Cloud Logging API, настроить отправку уведомлений об ошибках в мессенджерах для быстрого реагирования на сбои.
Ну вот и всё. Должно было получиться интересно. Очень интересна обратная связь по поводу такого формата разборов архитектур. Что скажете?
В продолжение темы построения архитектуры аналитических решений.
https://www.youtube.com/watch?v=slfDKyMxZsU
https://www.youtube.com/watch?v=slfDKyMxZsU
YouTube
DATALEARN | DE - 101 | МОДУЛЬ 5-6 АРХИТЕКТУРА ОБЛАЧНЫХ РЕШЕНИЙ
Прежде чем строить дом, нам нужно нарисовать архитектуру дома и сделать много других подготовительных работ. Тоже самое и в облаке и ИТ решениях. А если мы еще вспомним про принципы Амазон и их подход к созданию новых продуктов - Working Backwards, то самый…
Хочу теперь затронуть тему построения архитектуры для Big Data. И для начала предлагаю рассмотреть концепции Lambda- и Kappa-архитектур.
Нашёл полезное видео с докладом на эту тему от сообщества DE or DIE.
Нашёл полезное видео с докладом на эту тему от сообщества DE or DIE.
YouTube
DE or DIE #2. Егор Матешук – Обзор Lambda- и Kappa-архитектур
Материалы всех наших митапов доступны на GitHub: https://github.com/deordie/deordie-meetups
Наш чат в Telegram: https://news.1rj.ru/str/deordie_chat
Новые события сообщества DE or DIE: https://deordie.timepad.ru/events/
Автор доклада: Егор Матешук, Chief Data Officer…
Наш чат в Telegram: https://news.1rj.ru/str/deordie_chat
Новые события сообщества DE or DIE: https://deordie.timepad.ru/events/
Автор доклада: Егор Матешук, Chief Data Officer…
Digital-агентство Adventum приглашает на бесплатный вебинар «Как управлять большим бюджетом с помощью сквозной аналитики»
Когда: 29 июня в 14:00 МСК
Что расскажут на вебинаре:
✅ Как оптимизировать бюджеты от 1 млн рублей в месяц
✅ Как находить узкие места в воронке продаж
✅ Как создать единый центр медиапланирования
Узнать больше и зарегистрироваться можно на странице вебинара:
👉 https://talks.adventum.ru/skvoznaya-analitika-dlya-upravleniya-byudzhetom
Когда: 29 июня в 14:00 МСК
Что расскажут на вебинаре:
✅ Как оптимизировать бюджеты от 1 млн рублей в месяц
✅ Как находить узкие места в воронке продаж
✅ Как создать единый центр медиапланирования
Узнать больше и зарегистрироваться можно на странице вебинара:
👉 https://talks.adventum.ru/skvoznaya-analitika-dlya-upravleniya-byudzhetom
Всем привет.
Продолжая тему построения Big Data архитектур, сегодня на верхнем уровне хочу разобрать пример lambda-архитектуры. Хочу сделать 2 поста на эту тему: сначала привести пример построения на основе open source сервисов, а затем объяснить то же самое на примере самых известных облачных провайдеров (AWS, Azure и GCP). Схемы архитектур взял из этой статьи.
Давайте сначала кратко опишем, что такое lambda-архитектура и на чём она строится. Выше я публиковал хороший доклад на эту тему, поэтому супер-подробно останавливаться не буду.
Итак, простыми словами, lambda-архитектура - архитектура, которая объединяет в себе преимущества batch-обработки данных и стриминга. Batch обеспечивает более высокое качество данных и простой репроцессинг, стриминг - возможность получать и анализировать данные в режиме близком к реальному времени, а также избежание пиковых нагрузок на сервера.
Концептуально, lambda-архитектура состоит из 3-х уровней:
Batch Layer - слой, где происходит batch-обработка данных;
Streaming Layer (или Speed Layer) - слой, где происходит потоковый процессинг данных;
Serving Layer - слой, где объединяются данные 2-х предыдущих слоёв. По факту происходит так: сначала на этот слой поступают данные со Streaming Layer, а после того, как запускается batch job по определённому расписанию, стриминговые данные перезаписываются, так как batch обеспечивает более высокое качество + не все агрегации можно сделать, используя стриминг.
Ок, с этим разобрались, теперь давайте разберём схему с open source продуктами и посмотрим, как они ложатся на lambda-архитектуру.
На схеме у нас есть несколько блоков архитектуры: Collection, Ingestion, Preparation and Computation, Presentation. Разберём каждый:
Collection: ничего нового - здесь у нас происходит первичный сбор данных на уровне источников. Источниками могут выступать мобильные приложения, сайты, веб-приложения, микросервисы, IoT-девайсы, 3rd Party (Google Analytics, Facebook Ads и т.д.).
Ingestion: этот блок отвечает за извлечение данных из источников. Здесь у нас есть какая-то среда для приёма данных (например, REST API, который принимает входящие запросы), сервис, который выступает буфером для приёма и отправки данных (Kafka) и data lake для хранения "сырых" данных для дальнейшей batch-обработки (на схеме это Hadoop HDFS). Пример движения данных: данные о событиях мобильного приложения приходят на ваш API endpoint. Этот API принимает запрос и отправляет данные в Kafka. Из Kafka данные копируются в HDFS для дальнейшего батча.
Preparation и Computation: как раз здесь включаются в работу условные Batch Layer, Streaming Layer и Serving Layer. Начнём со Streaming. Здесь, когда данные переданы в Kafka, подключается какой-то стриминговый движок для потоковой обработки. На схеме это Apache Flink, но может использоваться любой другой движок в зависимости от проекта и задачи: Apache Spark (его стриминговый API), Apache Beam или Apache Storm. Если есть ML-задача, то могут использоваться соответствующие движки (на схеме это TensorFlow). После того, как данные обработаны, они складываются в хранилище данных для real-time аналитики, которое уже находится на Serving Layer. Если есть сервисы, которым необходимо потреблять данные в режиме реального времени (сервисы push-уведомлений, SMS-рассылок и т.д.), данные снова могут складываться в Kafka для дальнейшего потребления.
Теперь, что касается batch-обработки: у нас данные уже лежат в HDFS и, например, мы делаем пакетную обработку раз в сутки. Здесь мы также используем какой-то движок для процессинга больших данных, такой как Apache Spark или Apache Beam, и складываем данные в DWH, перезаписуя стриминговые данные. Выбор СУБД для DWH зависит от задачи. Обычно это какая-то колоночная БД по типу Vertica, Greenplum или Clickhouse, но могут использоваться и БД других типов. Например, для графовых задач я слышал хорошо подходит Cassandra.
Presentation: здесь тоже всё достаточно прозрачно. Здесь мы подключаем наш BI-инструмент к нашему DWH, а микросервисы потребляют данные для определённых бизнес-задач.
Продолжая тему построения Big Data архитектур, сегодня на верхнем уровне хочу разобрать пример lambda-архитектуры. Хочу сделать 2 поста на эту тему: сначала привести пример построения на основе open source сервисов, а затем объяснить то же самое на примере самых известных облачных провайдеров (AWS, Azure и GCP). Схемы архитектур взял из этой статьи.
Давайте сначала кратко опишем, что такое lambda-архитектура и на чём она строится. Выше я публиковал хороший доклад на эту тему, поэтому супер-подробно останавливаться не буду.
Итак, простыми словами, lambda-архитектура - архитектура, которая объединяет в себе преимущества batch-обработки данных и стриминга. Batch обеспечивает более высокое качество данных и простой репроцессинг, стриминг - возможность получать и анализировать данные в режиме близком к реальному времени, а также избежание пиковых нагрузок на сервера.
Концептуально, lambda-архитектура состоит из 3-х уровней:
Batch Layer - слой, где происходит batch-обработка данных;
Streaming Layer (или Speed Layer) - слой, где происходит потоковый процессинг данных;
Serving Layer - слой, где объединяются данные 2-х предыдущих слоёв. По факту происходит так: сначала на этот слой поступают данные со Streaming Layer, а после того, как запускается batch job по определённому расписанию, стриминговые данные перезаписываются, так как batch обеспечивает более высокое качество + не все агрегации можно сделать, используя стриминг.
Ок, с этим разобрались, теперь давайте разберём схему с open source продуктами и посмотрим, как они ложатся на lambda-архитектуру.
На схеме у нас есть несколько блоков архитектуры: Collection, Ingestion, Preparation and Computation, Presentation. Разберём каждый:
Collection: ничего нового - здесь у нас происходит первичный сбор данных на уровне источников. Источниками могут выступать мобильные приложения, сайты, веб-приложения, микросервисы, IoT-девайсы, 3rd Party (Google Analytics, Facebook Ads и т.д.).
Ingestion: этот блок отвечает за извлечение данных из источников. Здесь у нас есть какая-то среда для приёма данных (например, REST API, который принимает входящие запросы), сервис, который выступает буфером для приёма и отправки данных (Kafka) и data lake для хранения "сырых" данных для дальнейшей batch-обработки (на схеме это Hadoop HDFS). Пример движения данных: данные о событиях мобильного приложения приходят на ваш API endpoint. Этот API принимает запрос и отправляет данные в Kafka. Из Kafka данные копируются в HDFS для дальнейшего батча.
Preparation и Computation: как раз здесь включаются в работу условные Batch Layer, Streaming Layer и Serving Layer. Начнём со Streaming. Здесь, когда данные переданы в Kafka, подключается какой-то стриминговый движок для потоковой обработки. На схеме это Apache Flink, но может использоваться любой другой движок в зависимости от проекта и задачи: Apache Spark (его стриминговый API), Apache Beam или Apache Storm. Если есть ML-задача, то могут использоваться соответствующие движки (на схеме это TensorFlow). После того, как данные обработаны, они складываются в хранилище данных для real-time аналитики, которое уже находится на Serving Layer. Если есть сервисы, которым необходимо потреблять данные в режиме реального времени (сервисы push-уведомлений, SMS-рассылок и т.д.), данные снова могут складываться в Kafka для дальнейшего потребления.
Теперь, что касается batch-обработки: у нас данные уже лежат в HDFS и, например, мы делаем пакетную обработку раз в сутки. Здесь мы также используем какой-то движок для процессинга больших данных, такой как Apache Spark или Apache Beam, и складываем данные в DWH, перезаписуя стриминговые данные. Выбор СУБД для DWH зависит от задачи. Обычно это какая-то колоночная БД по типу Vertica, Greenplum или Clickhouse, но могут использоваться и БД других типов. Например, для графовых задач я слышал хорошо подходит Cassandra.
Presentation: здесь тоже всё достаточно прозрачно. Здесь мы подключаем наш BI-инструмент к нашему DWH, а микросервисы потребляют данные для определённых бизнес-задач.
Medium
Architecture for High-Throughput Low-Latency Big Data Pipeline on Cloud
Scalable and efficient data pipelines are as important for the success of analytics and ML as reliable supply lines are for winning a war.
Крутой доклад про построение хардкорной Big Data архитектуры для Почты России.
YouTube
BigПочта: как мы строили DataLake в Почте России / Алексей Вовченко (Luxoft)
Приглашаем на конференцию HighLoad++ 2024, которая пройдет 2 и 3 декабря в Москве!
Программа, подробности и билеты по ссылке: https://clck.ru/3DD4yb
--------
HighLoad++ 2017
Тезисы:
http://www.highload.ru/2017/abstracts/3014.html
Мы планируем поделиться…
Программа, подробности и билеты по ссылке: https://clck.ru/3DD4yb
--------
HighLoad++ 2017
Тезисы:
http://www.highload.ru/2017/abstracts/3014.html
Мы планируем поделиться…
Forwarded from Инжиниринг Данных (Dmitry Anoshin)
15 июля новый вебинар от Денис Соловьев - Разбор сервисов Google Cloud для построения аналитических решений
📌 Разберём/вспомним Cloud Service Models
📌 Разберём группу сервисов Compute
📌 Разберём группу Storage и Databases
📌 Рассмотрим сервисы для Big Data решений
📌 Рассмотрим сервисы для CI/CD
📌 Рассмотрим другие полезные сервисы Google Cloud
📌 Посмотрим на примеры аналитических архитектур на Google Cloud
🔥 У Дениса есть свой канал, где он рассказывает очень крутые штуки, описывает кейсы и дает крутые материалы по инжнирингу данных...
🔗 Ссылка на его ТГ: https://news.1rj.ru/str/smart_data_channel
📌 Разберём/вспомним Cloud Service Models
📌 Разберём группу сервисов Compute
📌 Разберём группу Storage и Databases
📌 Рассмотрим сервисы для Big Data решений
📌 Рассмотрим сервисы для CI/CD
📌 Рассмотрим другие полезные сервисы Google Cloud
📌 Посмотрим на примеры аналитических архитектур на Google Cloud
🔥 У Дениса есть свой канал, где он рассказывает очень крутые штуки, описывает кейсы и дает крутые материалы по инжнирингу данных...
🔗 Ссылка на его ТГ: https://news.1rj.ru/str/smart_data_channel
YouTube
Разбор сервисов Google Cloud для построения аналитических решений / Денис Соловьев
🔔 План:
📌 Разберём/вспомним Cloud Service Models
📌 Разберём группу сервисов Compute
📌 Разберём группу Storage и Databases
📌 Рассмотрим сервисы для Big Data решений
📌 Рассмотрим сервисы для CI/CD
📌 Рассмотрим другие полезные сервисы Google Cloud
📌 Посмотрим…
📌 Разберём/вспомним Cloud Service Models
📌 Разберём группу сервисов Compute
📌 Разберём группу Storage и Databases
📌 Рассмотрим сервисы для Big Data решений
📌 Рассмотрим сервисы для CI/CD
📌 Рассмотрим другие полезные сервисы Google Cloud
📌 Посмотрим…
Вчера провёл вебинар для Data Learn, где подробно разобрали сервисы Google Cloud и в каких кейсах их можно применять. Получилась целая лекция о Cloud Computing)
Презентация с выступления: https://docs.google.com/presentation/d/141TXFvCSl7tYaw1ODzYdlDxcWLJsHMM0roCj0YbbfYc/edit?usp=sharing
Полезные ссылки, которыми просили поделиться после вебинара:
Решение на GitHub для стриминга данных Google Analytics на базе App Engine и Google BigQuery (решение опубликовано давно и использует Python 2, поэтому при использовании его нужно будет обновить и причесать)
Пример того, как захостить ваш R-скрипт на Cloud Run
Презентация с выступления: https://docs.google.com/presentation/d/141TXFvCSl7tYaw1ODzYdlDxcWLJsHMM0roCj0YbbfYc/edit?usp=sharing
Полезные ссылки, которыми просили поделиться после вебинара:
Решение на GitHub для стриминга данных Google Analytics на базе App Engine и Google BigQuery (решение опубликовано давно и использует Python 2, поэтому при использовании его нужно будет обновить и причесать)
Пример того, как захостить ваш R-скрипт на Cloud Run
YouTube
Разбор сервисов Google Cloud для построения аналитических решений / Денис Соловьев
🔔 План:
📌 Разберём/вспомним Cloud Service Models
📌 Разберём группу сервисов Compute
📌 Разберём группу Storage и Databases
📌 Рассмотрим сервисы для Big Data решений
📌 Рассмотрим сервисы для CI/CD
📌 Рассмотрим другие полезные сервисы Google Cloud
📌 Посмотрим…
📌 Разберём/вспомним Cloud Service Models
📌 Разберём группу сервисов Compute
📌 Разберём группу Storage и Databases
📌 Рассмотрим сервисы для Big Data решений
📌 Рассмотрим сервисы для CI/CD
📌 Рассмотрим другие полезные сервисы Google Cloud
📌 Посмотрим…
Ребята из Телеграм-канала @it_resume хотят создать полноценную открытую платформу для подготовки к техническим собеседованиям IT-специалистам.
Считаю это очень классной задумкой, так как это в разы повышает шансы для всех специалистов проходить собеседования в хорошие компании, получать боевой опыт и растить экспертизу внутри индустрии.
Ребята собрали большую подборку авторских телеграмм-каналов для data-инженеров и аналитиков. Там более 20 каналов на любой вкус - анализ данных, программирование, data engineering, data science и многое другое 👍
Подробнее - в статье
P.S. Сам подписан на их Телеграм-канал, много прикольных интерактивных задачек, которые проверяют ваши технические знания.
Считаю это очень классной задумкой, так как это в разы повышает шансы для всех специалистов проходить собеседования в хорошие компании, получать боевой опыт и растить экспертизу внутри индустрии.
Ребята собрали большую подборку авторских телеграмм-каналов для data-инженеров и аналитиков. Там более 20 каналов на любой вкус - анализ данных, программирование, data engineering, data science и многое другое 👍
Подробнее - в статье
P.S. Сам подписан на их Телеграм-канал, много прикольных интерактивных задачек, которые проверяют ваши технические знания.
Хабр
Большая подборка телеграмм-каналов для аналитиков
Работа аналитика требует постоянного пополнения своих знаний - новые инструменты, обновления и методы создаются, как горячие пирожочки. Но перерабатывать такие объемы информации просто нереально, а...
Всем привет! Со сменой места работы немного выбился из своего привычного графика, поэтому давненько ничего не писал)
Мы с вами разбирали рубрику аналитических архитектур, и в последнем посте, посвящённом этой рубрике, я показал и разобрал пример lambda-архитектуры на основе open source сервисов.
В этом же посте я хочу разобрать такой же пример с lambda-архитектурой, но уже с использованием сервисов 3-х главных облачных провайдеров (AWS, Azure и GCP). Примеры архитектур приведены выше на картинке.
Снова-таки, у нас есть несколько блоков архитектуры: Ingestion, Data Lake, Preparation and Computation, Data Warehouse и Presentation. Разбираем каждый:
Ingestion (извлечение данных из источников): здесь мы можем иметь облачные IoT-сервисы, которые помогают извлекать данные из различных девайсов, подключенных к сети, свои API для приёма и обработки данных, а также брокер сообщений в качестве буфера для дальнейшей работы с данными. Примеры сервисов для этого блока на разных облаках:
AWS: AWS IoT, Lambda Function, Kinesis Streams / Firehose
Azure: Azure IoT Hub, Azure Function, Event Hub
GCP: Cloud IoT, Cloud Function, Cloud Pub/Sub
Пример движения данных на AWS: данные о событиях мобильного приложения приходят на endpoint Lambda Function. Функция принимает запрос и сразу отправляет данные в Kinesis Streams / Firehose.
Data Lake (файловое хранилище данных): после отправки данных в брокер сообщений данные копируются в озеро данных для дальнейшей batch-обработки. Сервисы для озера данных:
AWS: AWS S3
Azure: Azure Data Lake Store
GCP: Cloud Storage
Preparation and Computation (обработка и процессинг данных): вспоминаем наши Batch Layer, Streaming Layer и Serving Layer в lambda-архитектуре.
На Streaming Layer, когда данные переданы в брокер сообщений, подключается стриминговый движок для обработки данных. Примеры сервисов для стриминга:
AWS: Kinesis Analytics
Azure: Stream Analytics
GCP: Cloud Dataflow
Для ML-задач при потоковой обработке данных может использоваться AWS SageMaker или Azure ML.
При batch-обработке у нас данные уже лежат в data lake и мы можем делать обработку, например, раз в сутки. Здесь мы используем сервисы для обработки больших объёмов данных. Например:
AWS: AWS Glue, AWS EMR
Azure: Azure Data Factory, Azure Synapse
GCP: Cloud Dataproc, Claud Dataflow, Cloud Dataprep
Data Warehouse: после обработки данных, мы складываем их в какое-то хранилище или буфер для дальнейшей аналитики или потребления другими сервисами. Примеры сервисов на этом уровне:
AWS: AWS Redshift, AWS RDS, AWS Elasticsearch, Dynamo DB, Kinesis Streams
Azure: Azure SQL, Cosmos DB, Azure Redis Cache, Event Hub
GCP: Google BigQuery, Cloud Bigtable, Cloud SQL, Cloud Pub/Sub
Presentation: здесь подключаются BI-инструменты, данные используются для ML-задач, а также подключаются сервисы, потребляющие эти данные. Сервисы:
AWS: QuickSight, Lambda Function
Azure: Power BI, Azure Function
GCP: Data Studio, Looker, Cloud Datalab, Cloud Function
Вот мы и закончили рассматривать lambda-архитектуру на базе облачных сервисов.
P.S. Я сейчас плотно изучаю Snowflake и потом хочу рассказать о примерах решений с использованием этого облачного хранилища. + разобрать какой-то пример с использованием Databricks и Delta Lake. Постараюсь не затягивать)
Мы с вами разбирали рубрику аналитических архитектур, и в последнем посте, посвящённом этой рубрике, я показал и разобрал пример lambda-архитектуры на основе open source сервисов.
В этом же посте я хочу разобрать такой же пример с lambda-архитектурой, но уже с использованием сервисов 3-х главных облачных провайдеров (AWS, Azure и GCP). Примеры архитектур приведены выше на картинке.
Снова-таки, у нас есть несколько блоков архитектуры: Ingestion, Data Lake, Preparation and Computation, Data Warehouse и Presentation. Разбираем каждый:
Ingestion (извлечение данных из источников): здесь мы можем иметь облачные IoT-сервисы, которые помогают извлекать данные из различных девайсов, подключенных к сети, свои API для приёма и обработки данных, а также брокер сообщений в качестве буфера для дальнейшей работы с данными. Примеры сервисов для этого блока на разных облаках:
AWS: AWS IoT, Lambda Function, Kinesis Streams / Firehose
Azure: Azure IoT Hub, Azure Function, Event Hub
GCP: Cloud IoT, Cloud Function, Cloud Pub/Sub
Пример движения данных на AWS: данные о событиях мобильного приложения приходят на endpoint Lambda Function. Функция принимает запрос и сразу отправляет данные в Kinesis Streams / Firehose.
Data Lake (файловое хранилище данных): после отправки данных в брокер сообщений данные копируются в озеро данных для дальнейшей batch-обработки. Сервисы для озера данных:
AWS: AWS S3
Azure: Azure Data Lake Store
GCP: Cloud Storage
Preparation and Computation (обработка и процессинг данных): вспоминаем наши Batch Layer, Streaming Layer и Serving Layer в lambda-архитектуре.
На Streaming Layer, когда данные переданы в брокер сообщений, подключается стриминговый движок для обработки данных. Примеры сервисов для стриминга:
AWS: Kinesis Analytics
Azure: Stream Analytics
GCP: Cloud Dataflow
Для ML-задач при потоковой обработке данных может использоваться AWS SageMaker или Azure ML.
При batch-обработке у нас данные уже лежат в data lake и мы можем делать обработку, например, раз в сутки. Здесь мы используем сервисы для обработки больших объёмов данных. Например:
AWS: AWS Glue, AWS EMR
Azure: Azure Data Factory, Azure Synapse
GCP: Cloud Dataproc, Claud Dataflow, Cloud Dataprep
Data Warehouse: после обработки данных, мы складываем их в какое-то хранилище или буфер для дальнейшей аналитики или потребления другими сервисами. Примеры сервисов на этом уровне:
AWS: AWS Redshift, AWS RDS, AWS Elasticsearch, Dynamo DB, Kinesis Streams
Azure: Azure SQL, Cosmos DB, Azure Redis Cache, Event Hub
GCP: Google BigQuery, Cloud Bigtable, Cloud SQL, Cloud Pub/Sub
Presentation: здесь подключаются BI-инструменты, данные используются для ML-задач, а также подключаются сервисы, потребляющие эти данные. Сервисы:
AWS: QuickSight, Lambda Function
Azure: Power BI, Azure Function
GCP: Data Studio, Looker, Cloud Datalab, Cloud Function
Вот мы и закончили рассматривать lambda-архитектуру на базе облачных сервисов.
P.S. Я сейчас плотно изучаю Snowflake и потом хочу рассказать о примерах решений с использованием этого облачного хранилища. + разобрать какой-то пример с использованием Databricks и Delta Lake. Постараюсь не затягивать)
Telegram
Smart Data
Всем привет.
Продолжая тему построения Big Data архитектур, сегодня на верхнем уровне хочу разобрать пример lambda-архитектуры. Хочу сделать 2 поста на эту тему: сначала привести пример построения на основе open source сервисов, а затем объяснить то же самое…
Продолжая тему построения Big Data архитектур, сегодня на верхнем уровне хочу разобрать пример lambda-архитектуры. Хочу сделать 2 поста на эту тему: сначала привести пример построения на основе open source сервисов, а затем объяснить то же самое…
7-snowflake-reference-architectures-for-application-builders.pdf
9.1 MB
Нашёл неплохой документ от Snowflake, где они приводят 7 примеров архитектур с использованием их продукта с кратким описанием. Здесь есть примеры и serverless-архитектуры, и стриминга, и ML. Посмотреть интересно)
Forwarded from Лена Янссон
С 6 по 17 сентября приглашаем DS- и BI-разработчиков Middle+ принять участие в EPAM Hiring Weeks и получить welcome-бонус в размере одного оклада.
Заполните регистрационную форму, пройдите интервью и получите оффер в течение 48 часов. Плюсом к быстрому офферу вы получите welcome-бонус в размере одного оклада!
Кого мы ждём в Data Science:
• Data Scientist – Computer Vision
• Data Scientist - NLP
• Data Scientist - Time Series
• Machine Learning Engineer
Кого мы ждём в Business Intelligence:
• BI Reporting Engineer
• Database Expert and Cloud
• Data Integration
Подробнее об открытых позициях, требованиях и примерах проектов вы можете узнать на сайте: https://epa.ms/HW-DS-BI-sept
Участвуйте в EPAM Data Science & Business Intelligence Hiring Weeks и получите быстрый оффер с welcome-бонусом!
Заполните регистрационную форму, пройдите интервью и получите оффер в течение 48 часов. Плюсом к быстрому офферу вы получите welcome-бонус в размере одного оклада!
Кого мы ждём в Data Science:
• Data Scientist – Computer Vision
• Data Scientist - NLP
• Data Scientist - Time Series
• Machine Learning Engineer
Кого мы ждём в Business Intelligence:
• BI Reporting Engineer
• Database Expert and Cloud
• Data Integration
Подробнее об открытых позициях, требованиях и примерах проектов вы можете узнать на сайте: https://epa.ms/HW-DS-BI-sept
Участвуйте в EPAM Data Science & Business Intelligence Hiring Weeks и получите быстрый оффер с welcome-бонусом!
Последний месяц я готовился к сдаче сертификации от Snowflake - SnowPro Core Certification. Сегодня был экзамен, который не обошёлся без приключений😅
Сертификация сдаётся с прокторингом - с включённой веб-камерой, с идентификацией личности и постоянным наблюдением. И где-то на 20 вопросе у меня отключилась камера и заблокировался экран - так что я не мог дальше продолжать экзамен...
Написал в поддержку, они мне заново открыли доступ, но теперь у меня не было активной кнопки, чтобы продолжить экзамен. Пришлось снова писать в поддержку, и на третий раз я всё-таки продолжил экзамен.
К счастью, экзамен я сдал и теперь могу поделиться этим достижением)
P.S. Есть идея сделать отдельный пост и описать свой процесс подготовки и на что стоит обратить внимание. Вынесу это в опрос.
Сертификация сдаётся с прокторингом - с включённой веб-камерой, с идентификацией личности и постоянным наблюдением. И где-то на 20 вопросе у меня отключилась камера и заблокировался экран - так что я не мог дальше продолжать экзамен...
Написал в поддержку, они мне заново открыли доступ, но теперь у меня не было активной кнопки, чтобы продолжить экзамен. Пришлось снова писать в поддержку, и на третий раз я всё-таки продолжил экзамен.
К счастью, экзамен я сдал и теперь могу поделиться этим достижением)
P.S. Есть идея сделать отдельный пост и описать свой процесс подготовки и на что стоит обратить внимание. Вынесу это в опрос.