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://news.1rj.ru/str/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

Ребята из Телеграм-канала @it_resume хотят создать полноценную открытую платформу для подготовки к техническим собеседованиям IT-специалистам.

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

Ребята собрали большую подборку авторских телеграмм-каналов для 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. Постараюсь не затягивать)

Нашёл неплохой документ от Snowflake, где они приводят 7 примеров архитектур с использованием их продукта с кратким описанием. Здесь есть примеры и serverless-архитектуры, и стриминга, и ML. Посмотреть интересно)

Последний месяц я готовился к сдаче сертификации от Snowflake - SnowPro Core Certification. Сегодня был экзамен, который не обошёлся без приключений😅

Сертификация сдаётся с прокторингом - с включённой веб-камерой, с идентификацией личности и постоянным наблюдением. И где-то на 20 вопросе у меня отключилась камера и заблокировался экран - так что я не мог дальше продолжать экзамен...
Написал в поддержку, они мне заново открыли доступ, но теперь у меня не было активной кнопки, чтобы продолжить экзамен. Пришлось снова писать в поддержку, и на третий раз я всё-таки продолжил экзамен.

К счастью, экзамен я сдал и теперь могу поделиться этим достижением)

P.S. Есть идея сделать отдельный пост и описать свой процесс подготовки и на что стоит обратить внимание. Вынесу это в опрос.

Всем привет!

Как обещал, опишу свой процесс подготовки и дам рекомендации для сдачи экзамена Snowflake - SnowPro Core Certification.

Расскажу сначала немного о самом экзамене и о некоторых организационных моментах.
SnowPro Core Certification - это базовая сертификация Snowflake, которая проверяет знания "ядра" (основ) продукта, включая внутреннюю архитектуру, администрирование аккаунта, безопасность, вычислительные возможности, возможности для загрузки и трансформации данных, хранение данных и др.
Экзамен состоит из 100 вопросов и включает в себя тесты с выбором одного варианта ответа, нескольких вариантов ответа и True/False.
На экзамен отводится ровно 115 мин.
Стоимость экзамена - $175.

Есть 2 опции сдачи: 1) онлайн с прокторингом; 2) в специальных центрах оценивания.
Онлайн с прокторингом подразумевает постоянно включённую веб-камеру, отсутствие гаджетов и дополнительных материалов на столе и тихое место без отвлекающих факторов. Экзамен проходит под наблюдением проктора.
Болше информации здесь.

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

Рекомендации по организационным моментам:
- если у вас нет админских прав на вашем рабочем компьютере, используйте ваш личный компьютер, так как для запуска Sentinel нужны админские права. Плюс вам нужно будет отключить антивирус и firewall на время экзамена;
- отключайте антивирус и firewall перед экзаменом, как описано в рекомендациях, когда вы запустите экзамен. Я проходил экзамен с рабочей машины и у меня не было пароля для отключения антивируса. На 20 вопросе у меня отключилась камера и пришлось 2 раза связываться с поддержкой. Чтобы такого не было - лучше выполняйте все рекомендации.


Теперь перейдём непосредственно к рекомендациям по подготовке:

1) Не полагайтесь только на курсы (например, на Udemy). Их реально не достаточно, чтобы сдать экзамен. В экзамене много вопросов, которые не освещаются в курсах.

2) Документация - основа основ подготовки. Внимательно её читайте со всеми сносками и предупреждениями. В экзамене встречаются вопросы из разряда "Какие типы файлов поддерживаются при выгрузке полу-структурированных данных в stage?" И здесь, в отличие от загрузки данных, например, не поддерживаются AVRO, ORC и XML.

3) Уделите достаточно внимания, на первый взгляд, скучным темам, таким как организация аккаунта, безопасность и data governance. Я набрал меньше всего баллов по вопросам именно из этого блока. Поэтому, хорошенько пройдитесь по таким сущностям, как "role", "privileges", "roles hierarchy", "custom roles", по методам аутентификации, masking policy, row access policy и т.д.

4) Уделите внимание синтаксису DDL и DCL команд при создании объектов Snowflake. В экзамене встречаются вопросы на знание параметров и на значения по умолчанию. Например, был вопрос из разряда "Какие устанавливаются параметры при создании virtual warehouse через SQL?"

5) Уделите внимание структуре и предназначению системных схем и таблиц, таких как ACCOUNT_USAGE и INFORMATION_SCHEMA.

6) В экзамене есть вопросы на процесс внедрения новых релизов, поэтому на эту тему тоже стоит обратить внимание.

7) Создайте trial-аккаунт на 30 дней. В экзамене есть вопросы на знание веб-интерфейса + уже есть готовые таблицы, к которым можно потренироваться писать запросы и "пощупать" остальные возможности продукта. При создании триального аккаунта не нужно привязывать карту. Единственный момент, с которым я столкнулся - при регистрации выдавало ошибку, если заходить не с ip-адреса страны, для которой регистрировал аккаунт. Я выбирал США и включал американский VPN.

Какими ресурсами для подготовки я пользовался:

1) Бесплатный гайд для подготовки от Snowflake - основной и самый полезный ресурс. Здесь есть ссылки на документацию, статьи на блоге, community, вебинары и короткие видео. Очень рекомендую пройтись по всем ссылкам и внимательно со всем ознакомиться. Особенное внимание уделите документации.

2) Курс для подготовки к экзамену от Snowflake (платный) - хорошо разбавлял меня от постоянного чтива. Но мне повезло,что у компании был к нему доступ, и я смотрел его бесплатно. Откровенно говоря, большого смысла, чтобы платить за него $375 я не увидел, так как все темы есть в гайде. Но если вам очень тяжело постоянно только читать и вам не жалко денег, то курс неплохой.

3) Курс на Udemy с 5 наборами тестов, которые очень похожи на те, которые были на экзамене. Хорошо их пройти в конце, когда вы изучите все необходимые темы. В результатах теста указано, в каких областях вы допустили больше всего ошибок, поэтому можно потом вернуться к этим темам в документации и восполнить пробелы в знаниях.

Т.е. я бы процесс подготовки построил так:
Прошёлся бы по всем ссылкам в гайде -> Прошёл пробные тесты -> Вернулся к темам, в которых допустил ошибки -> Снова через пару дней прошёл бы пробный тест


Думаю, этого достаточно, чтобы успешно подготовиться)

P.S. После публикации предыдущего поста мне посоветовали ещё 2 ресурса:

1) Телеграм-канал с новостями Snowflake - @snowflake_daily - очень прикольная штука, если вы работаете или планируете плотно работать с этим продуктом.

2) Чат специалистов, кто работает со Snowflake - @snowflakedbchat.

Если будет нужна дополнительная помощь или будут дополнительные вопросы - можете написать мне в личку.

Всем привет.

Сегодня хочу, наконец, закончить большую рубрику построения аналитических архитектур.

Мы с вами уже разобрали концептуальные блоки, на которых строится любая архитектура, разобрались, что такое lambda и kappa архитектуры и рассмотрели различные примеры. И сегодня я хочу закрыть рубрику примером построения архитектуры с использованием AWS и Databricks. В частности, я хочу вкратце затронуть такую сущность как Delta Lake. Подробно останавливаться не буду, так как хочу в будущем посвятить Databricks серию отдельных постов. А пока придерживаемся подхода "от общего к частному".

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

Разбираем по слоям:

1. Слой источников. Для стриминга здесь могут выступать IoT-сервисы (AWS IoT Events), очереди сообщений и различные API. Для батч-обработки, по классике, - различные файлы и транзакционные базы данных.

2. Слой процессинга данных. На схеме процессинг разделён на 2 этапа: 1) извлечение данных (ingestion); 2) непосредственная их обработка и подготовка для конечных пользователей и ML-движков. Первый этап предполагает, что при стриминге данные изначально складываются в Amazon Kinesis (брокер сообщений), а при батче - "сырые" данные пачками загружаются в AWS S3. На втором этапе подключается Databricks.
Хочу написать несколько слов о Databricks. Я бы рассматривал Databricks с 2 сторон:
1) как инструмент процессинга данных; 2) как платформу данных.
Как инструмент процессинга данных - это fully-managed Spark. Т.е. вам не нужно самостоятельно устаналивать Spark, настраивать "железо" и т.д. Всё это за вас делает Databricks. Вам достаточно сделать несколько настроек при создании кластера в интерфейсе и сразу писать код на Spark.
Как платформа данных - это набор инструментов и технологий, которые позволяют централизовать хранение всех данных (как структурированных, так и неструктурированных) в одном месте и централизовать все активности при работе с данными (ETL, BI и Data Science). Чтобы создать полноценную централизованную платформу данных, Databricks дополнительно создали Delta Lake и MLflow.
Возвращаемся непосредственно к процессингу: при стриминге данные, которые уже находятся в Amazon Kinesis, обрабатываются через Spark Streaming на Databricks и могут складываться в Delta Lake (о нём ниже) для real-time аналитики. При батче данные читаются из S3 бакета, обрабатываются на Spark и так же складываются в Delta Lake для аналитики или дальнейших ML-операций.

3. Слой хранения данных. Используя Databricks как платформу данных, слой хранения можно организовать с помощью такой технологии как Delta Lake. Немного о нём:
Delta Lake - это open source технология, которая представляет из себя логический слой хранения данных на базе существующего data lake (файлового хранилища). Т.е. это не хранилище само по себе, а надстройка над уже существующим хранилищем, на схеме это AWS S3. В этом хранилище данные хранятся в так называемых delta-таблицах. Сама технология предполагает поддержку ACID-транзакций, масштабируемую поддержку метаданных, батчевые и стриминговые операции и т.д. Databricks создал Delta Lake, чтобы объединить преимущества традиционных хранилищ данных и data lake, назвав этот концепт Lakehouse и успешно продвигая его в массы:)Т.е. с Lakehouse вы получаете преимущества относительной простоты использования DWH с поддержкой ACID и преимущества дешёвого хранения файлов в data lake.
Если этого требует задача, данные можно дополнительно скопировать в классическое хранилище данных и делать нужные активности с данными там. На схеме в качестве DWH выступает Amazon Redshift.

4. Слой доступа к данным. Слой, на котором конечные пользователи получают доступ к данным и анализируют их. Также здесь могут подключаться различные ML-движки и сервисы.

На схеме для написания запросов к данным, которые лежат в delta-таблицах, могут использоваться 2 пути: 1) скопировать нужные данные в Amazon Redshift и писать запросы там; 2) Использовать Amazon Athena и читать delta-таблицы напрямую из S3 бакета.
Для второго варианта мы используем AWS Glue Catalog и Glue Crawler. Glue Catalog - это fully-managed Hive metastore, который позволяет собрать метаданные о файлах, хранящихся в data lake. В данном случае Glue Catalog используется как хранилище метаданных для delta-таблиц, к которым пишутся запросы через Athena.
В качестве BI-инструмента на схеме используется Amazon QuickSight. Он таким же образом может подключаться как к скопированным данным в Redshift, так и напрямую к delta-таблицам.


P.S. На этом закрываем нашу рубрику построения аналитических архитектур. Дальше я собираюсь переходить к более частным вещам. Например, следующую рубрику я хочу посвятить SQL и теории баз данных, где постараюсь осветить все ключевые моменты.

Всем привет!

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

Так как я учил SQL на платном курсе и потом закреплял знания на рабочих задачах и на таких платформах, как Leetcode и Hacker Rank, предлагаю поступить следующим образом:

Не хочу просто гуглить любые курсы и вставлять ссылки на них в пост. Убеждён, что многие из вас проходили какие-то конкретные бесплатные базовые курсы по SQL и нашли их для себя очень полезными. Поэтому:

Напишите, пожалуйста, в комментариях, какие курсы (и ссылки на них) вам помогли получить базовые знания и улучшить свои навыки в написании SQL-запросов. Позже я из них и сделаю подборку.

Спасибо!

Всем привет.

В прошлом посте я просил вас написать, какие курсы по SQL вы проходили и какие принесли максимальную пользу в совершенствовании этого навыка. После сбора рекомендаций публикую результаты)Для каждого курса буду цитировать рекомендацию. Итак:

ТОП 10 бесплатных и бюджетных курсов и материалов по SQL по версии подписчиков:

1. sql-ex.ru - классика для многих специалистов.

2. Udemy SQL для Анализа Данных Глеба Михайлова (платный, но бюджетный). Многие советуют.

3. Курс по SQL от Анатолия Балакирева на Data Learn (бесплатный). - Подробный и очень структурированный курс.

3. Анализ данных на языке SQL в "Специалист". Платный и самый дорогой из списка. Но есть возможность учиться очно. Цитирую рекомендацию: "Препод очень толковый. На ходу разбираются практические задачки. Даёт базу с 0 вплоть до уровня курсоров, транзакций и т.д."

4. Основы SQL на Stepik (платный, но бюджетный). Рекомендация: "Просто добавлю про один неочевидный, но очень большой плюс - выработка автоматизма. После окончания курса стоит только подумать о каком-то запросе, руки его уже сами печатают."

5. Интерактивный тренажер по SQL (бесплатный). Рекомендация: "Пушечный стартовый курс
Если прям никогда не открывали SQL, то это то, что нужно: задачки, задачки, задачки."

6. Learn DB (подписочная модель). Рекомендация: "Очень годный курс. Сейчас у них подписочная модель, но не очень дорогая. Всем советую🙂"

7. Stepik SQLite для аналитики Антона Жиянова (платный, но бюджетный).

8. SQL Developer Анализ данных на языке SQL (бесплатный).

9. Udemy: SQL для начинающих: с нуля до сертификата Oracle (платный, но бюджетный).

10. Хабр: Вопросы по SQL на собеседовании


P.S. Спасибо Sergey Novik, @Graffeev, @ruslanadv, @Artem_ne_Artem, @MrSparkline, @Krakatau27, @Garry_S, @dmi_inod, @BaburovNik, @Alexander_Zlenko, @user2764, @AnalystAM, @ashakhverdyan за рекомендации и вовлечённость!