Наткнулся на довольно интересный Data Engineering Study Guide. Его подготовили люди, которые проходили собеседование в FAANG и другие крупные технологические компании и успешно его прошли. Много внимания уделено SQL и решению задач на применение алгоритмов (использовать алгоритмы можно на любом языке программирования). Условно, если вы знаете Python или приняли решение его изучать, то, следуя этому гайду, вы будете решать много задачек на SQL и алгоритмы с использованием Python. В принципе, как я уже писал, SQL и Python - 2 основных навыка для data-инженера.
Я просмотрел задачки в этом гайде и, действительно, нужно будет напрячься:)Очень хорошая встряска для мозгов.

Но ещё меня этот гайд натолкнул на то, чтобы написать своё мнение по поводу "нужно ли знать алгоритмы или можно обойтись без них?"

Вот несколько моих мыслей:

- С одной стороны, большую часть бизнес-задач можно спокойно решить без знаний алгоритмов. Мне, например, не особо нужны знания алгоритмов, когда я пишу ETL-скрипты. Сейчас есть огромное множество готовых встроенных функций языка, пакетов, классов и методов, которые при знаниях синтаксиса и должном уровне смекалки можно успешно использовать и строить программы. Есть также много примеров кода в интернете, который можно брать за основу и адаптировать под себя. Главное, понимать, что хранится в переменных, что делают конкретные функции и т.д.
Поэтому, спрашивать алгоритмы у человека, который собеседуется на позицию Junior или Middle, как по мне, глупо. Главное - решить бизнес-задачу.

- С другой стороны, хочется постоянно растить свои знания и навыки и бесполезно учить новые готовые функции и классы, если вы не применяете их на практике. В таких случаях будет, наоборот, полезно углубиться в основы программирования, понять, на чём основаны эти наши функции и классы. Это даёт более глубокое понимание процессов и развивает логическое мышление при решении задачек на алгоритмы.
Буквально неделю назад я решил тоже копнуть глубже и разобраться с программированием на более низком уровне. Начал читать книгу "Структура и интерпретация компьютерных программ". Классика в сфере программирования. Всё очень фундаментально и детально описано. Книга базируется на языке lisp, а точнее на его диалекте scheme. Я сначала выполнял упражнения на scheme, но потом решил, что для меня будет полезнее эти же задачки решать с помощью Python. Поэтому всё переложил на его синтаксис.
Также считаю, что без знаний алгоритмов и структур данных намного сложнее (если вообще возможно) создавать какие-то крутые инновации в программном мире. Сложно создавать инновации, если не знаешь фундаментальной сути того, что уже есть.


В общем, я сделал такой вывод: если вы хотите быстрее войти в сферу data-инжиниринга и программирования в целом, то алгоритмы - не то, что вам нужно учить в первую очередь. А вот когда вы уже вольётесь, начнёте решать бизнес-задачи и захотите выйти на кардинально новый уровень - можно копать глубже и учить алгоритмы.

А вы как считаете?

Хочу всем порекомендовать курс по SQL от Анатолия Балакирева в рамках Data Learn. Наверное, самый подробный и полный бесплатный русскоязычный курс по SQL, который я видел.

Всегда уважаю и ценю такой большой труд.

Всем привет.

Сегодня хочу возобновить серию постов о том, что учить и в каком порядке в зависимости от выбранного направления работы с данными. Напомню, что прошлые посты были посвящены тому, что учить в первую очередь всем вне зависимости от направления, что учить инженеру данных и что учить data-аналитику.

Сегодня же я хочу затронуть направление web/app и продуктовой аналитики. Я специально не выделяю web/app аналитику как отдельное направление, так как обычно люди, которые начинают с веба, чаще всего затем занимаются продуктовой аналитикой, добавляя в свой арсенал SQL, BI-инструменты, сервисы для A/B-тестирования и языки программирования (Python или R). Для меня продуктовый аналитик - это тот же data-аналитик, но с фокусом на конкретный продукт (сайт или мобильное приложение) и с фундаментальными знаниями сервисов web/app аналитики и A/B тестирования.

Т.е. в моей картине мира есть 2 отправные точки, из которых можно стать продуктовым аналитиком:

1) Начать с классической веб-аналитики и дальше добавлять в свой арсенал сервисы мобильной аналитики, SQL, BI-инструменты и сервисы для проведения A/B-тестов на сайте и в приложении. Ну и, конечно же, не забываем читать продуктовые кейсы и изучать метрики продуктовой аналитики.

2) Начать работать BI-разработчиком и, уже имея знания SQL и BI-инструментов, дальше изучать и пробовать работать с сервисами web/app аналитики и проводить
A/B-тесты.

Первый вариант - это больше про тех людей, кто вообще начинал с performance-маркетинга (PPC, SEO и т.д.), они каждый день соприкасались с веб-аналитикой и затем решили полностью уйти в это направление. На моей практике я как раз встречаю больше таких людей, чем тех, кто начинал работать веб-аналитиками с чистого листа. Поэтому, если у вас нет опыта в performance-маркетинге, для вас логичным будет либо начать свой пусть с BI и находить возможности, чтобы дополнительно поработать с сервисами web/app аналитики, либо пройти специализированные курсы по веб-аналитике, получить хоть какой-то сертификат (кстати, можно пройти профессиональную сертификацию по Google Analytics от Google) и пробовать стучаться в крупные агентства интернет-маркетинга на позицию Junior веб-аналитика. Самому разобраться в веб-аналитике без боевого опыта будет крайне сложно.

Ок, теперь о том, что нужно учить и какой порядок изучения выбрать. Предположим, вы начали свой путь как BI-разработчик и теперь хотите работать с продуктом как аналитик. Вы уже знаете Excel, теорию баз данных, SQL и владеете одним или несколькими BI-инструментами. Как двигаться дальше?

1. Изучить основные концепции и метрики продуктовой аналитики. Здесь я бы рекомендовал пройти вот этот базовый курс. Он основан на игровой аналитике, но все принципы можно спокойно перекладывать на другие сферы.

2. Научиться работать с Google Analytics. Google Analytics - бесспорно является самым популярным сервисом веб-аналитики в мире. Его задача - собирать и представлять данные об источниках трафика, через которые пользователи попадают на сайт, и собирать данные об их поведении при его посещении.

Полезные ресурсы:
Курс по Google Analytics для начинающих (Google)
Книга по Google Analytics (Universal Analytics)
Курс "Анализ данных в Google Analytics"
Статьи по Google Analytics 4

4. Научиться работать с Google Tag Manager. Google Tag Manager - это инструмент, который позволяет размещать различные теги на сайте без прямого доступа к его коду. Это ключевой инструмент для настройки сбора данных на сайте и отправки их в различные системы аналитики и рекламные сервисы. Здесь я бы просто советовал прочитать вот эту книгу и много-много практиковаться.

Дополнительно хочу дать список блогов, которые я читал и читаю на тему веб-аналитики:
Блог Якова Осипенкова
Блог Андрея Осипова
Блог Макса Гапчука
Блог Симо Ахавы
Блог "Analytics mania"
Блог "BurgerData"
Блог Дмитрия Осиюка
Блог компании OWOX


5. После того, как вы немного освоились с сервисами веб-аналитики, я бы рекомендовал разобраться c сервисами мобильной аналитики. Сервисов мобильной аналитики довольно много. Примеры: Firebase Analytics, AppsFlyer, Adjust, Amplitude и др. Лично я сначала разбирался с Firebase Analytics.
Также очень важная тема при работе с мобильной аналитикой - это настройка и использование deep links.

Полезные ресурсы:
Плейлист по Firebase Analytics
Документация Firebase Analytics
Плейлист по dynamic links (deep links) в Firebase
Статья про работу с deep links

6. Научиться работать с сервисами для A/B тестирования. Здесь раскрыть тему вряд ли смогу, так как работал только с A/B тестами на сайте через Google Optimize. Есть ещё специализированные сервисы для A/B-тестов в мобильных приложениях, но с ними я никогда не работал.

Дальнейший путь изучения практически идентичен тому, который я описывал в предыдущем посте для аналитика данных.


Если вы, наоборот, начали не с BI, а сразу начали выполнять задачи по веб-аналитике и уже неплохо знакомы с Google Analytics и Google Tag Manager, то я бы рекомендовал построить дальнейшее обучение в таком порядке:

1) Изучить основные концепции и метрики продуктовой аналитики
2) Разобраться c сервисами мобильной аналитики
3) Научиться работать с сервисами для A/B тестирования
4) Изучить SQL. Очень рекомендую курс из моего предыдущего поста
5) Научиться работать с одним BI-инструментом
6) Подтянуть знания статистики
7) Python/R как advanced навык

Конечно, в боевых условиях вы вряд ли строго будете соблюдать какой-то определённый порядок, так как задачи прилетают постоянно разные и вы постепенно будете учиться всему по чуть-чуть. Моя последовательность - это больше попытка помочь людям структурировать мысли и дать примерное направление, в котором можно двигаться.

Поэтому строго соблюдать порядок абсолютно необязательно, главное продолжать идти:)

Топ ресурсы по Data Engineering и Analytics:
- Телеграм канал Инжиниринг Данных 🕺
- Курсы Data Learn 💃
- KDnuggets https://www.kdnuggets.com/news/index.html
- Cloudera | Data Engineering https://blog.cloudera.com/product/data-engineering/
- Silectis https://www.silect.is/blog/
- The RudderStack Blog https://rudderstack.com/blog/
- Facebook Engineering https://engineering.fb.com/
- Snowflake | Inside the Data Cloud https://www.snowflake.com/blog/
- Precisely Blog https://www.precisely.com/blog
- Data Engineering in Towards Data Science https://towardsdatascience.com/tagged/data-engineering
- SmartData Collective https://www.smartdatacollective.com/
- WeCloudData https://weclouddata.com/blog/
- Uber Engineering Blog https://eng.uber.com/
- Team Data Science Blog https://www.teamdatascience.com/blog
- Secoda Data Discovery Blog https://www.secoda.co/blog
- AWS Big Data Blog https://aws.amazon.com/blogs/big-data/
- Data Mechanics Blog https://www.datamechanics.co/blog
- ActiveWizards | Data Science and Engineering Lab https://activewizards.com/blog/
- Data Wow Blog https://datawow.io/blogs
- Pinterest Engineering https://medium.com/@Pinterest_Engineering
- Yelp Engineering and Product Blog https://engineeringblog.yelp.com/
- Netflix TechBlog https://netflixtechblog.com/
- LinkedIn Engineering Blog https://engineering.linkedin.com/blog
- Databricks Blog https://databricks.com/blog
- Knoldus » ML, AI and Data Engineering https://blog.knoldus.com/category/tech-blogs/machine-learning/
- XenonStack » Big Data Engineering https://www.xenonstack.com/blog/category/big-data-engineering/
- Dataquest » Data Engineering https://www.dataquest.io/blog/tag/data-engineering/
- Scribd Technology Blog https://tech.scribd.com/blog/
- Learn Data Engineering https://learndataengineering.com/blog
- data.world Blog https://data.world/blog/
- Ripple Engineering » Data https://engineering.ripple.com/tag/data/
- Jesse Anderson Blog https://www.jesse-anderson.com/category/blog/

В продолжение темы о том, как развиваться в выбранной области работы с данными (DE, DA, DS и т.д.) нашёл интересную серию статей на Хабре.

Автор описывает "что учить" и "как учиться", чтобы стать классным Data Scientist.
Так как у меня ещё не было поста для потенциальных дата-сайнтистов (да и я непосредственно в Data Science не силён), думаю, эта серия постов - как раз то, что нужно.

Очень симпатизирует видение автора в принципах обучения, так как оно пересекается с моим. + его личная история может многих вдохновить.

Всем привет. Думаю, предыдущую рубрику можно закрывать. Я постарался охватить все основные направления работы с данными и дать пошаговый план развития с полезными ссылками для каждой позиции.

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

Сегодня я хочу коснуться базовых вещей - концепций, на которых строится любая аналитическая архитектура. В последующих постах для закрепления я буду брать примеры реальных решений и разбирать их, рассказывая какие инструменты за какую задачу отвечают.

Итак, поговорим о концепциях.

Если абстрагироваться, то любую аналитическую архитектуру можно разделить на 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 и др.


Этой информации достаточно, чтобы на фундаментальном уровне понять, на чём основана любая аналитическая архитектура и как она работает.

Прилагаю базовую схему, которая отображает все слои системы. Костяк системы позаимствовал у Димы Аношина в одной из его презентаций и немного изменил её, чтобы адаптировать под сегодняшний пост.

Продолжаем нашу тему построения аналитической архитектуры.

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

Это кейс с архитектурой на 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), так что ваши трансформация всегда будут запускаться в нужном порядке. У этого инструмента ещё очень много фишек, описать которые одного поста точно не хватит)

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, настроить отправку уведомлений об ошибках в мессенджерах для быстрого реагирования на сбои.

Ну вот и всё. Должно было получиться интересно. Очень интересна обратная связь по поводу такого формата разборов архитектур. Что скажете?

Коллеги поздравили с Днём рождения и подарили эту настольную книгу data-инженера)Давно хотел прочитать, как раз будет повод)

В продолжение темы построения архитектуры аналитических решений.

https://www.youtube.com/watch?v=slfDKyMxZsU

Хочу теперь затронуть тему построения архитектуры для Big Data. И для начала предлагаю рассмотреть концепции Lambda- и Kappa-архитектур.

Нашёл полезное видео с докладом на эту тему от сообщества DE or DIE.

Digital-агентство Adventum приглашает на бесплатный вебинар «Как управлять большим бюджетом с помощью сквозной аналитики»

Когда: 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 архитектуры для Почты России.

15 июля новый вебинар от Денис Соловьев - Разбор сервисов Google Cloud для построения аналитических решений

📌 Разберём/вспомним Cloud Service Models
📌 Разберём группу сервисов Compute
📌 Разберём группу Storage и Databases
📌 Рассмотрим сервисы для Big Data решений
📌 Рассмотрим сервисы для CI/CD
📌 Рассмотрим другие полезные сервисы Google Cloud
📌 Посмотрим на примеры аналитических архитектур на Google Cloud

🔥 У Дениса есть свой канал, где он рассказывает очень крутые штуки, описывает кейсы и дает крутые материалы по инжнирингу данных...

🔗 Ссылка на его ТГ: https://www.tgoop.com/smart_data_channel

Вчера провёл вебинар для 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