Сегодня на Surfalytics мы разбирали интересную задачку по Spark (PySpark), которую прислали в качестве тестового задания на Sr Data Engineer с вилкой для Канады 200к CAD - 220к CAD, что очень неплохо, удаленная работа на проект в консалтинг.

Задание мне понравилось:

Нужно взять 3 файла с данными, сделать трансформацию и сохранить результат. Идеальное упражнение для всех, кто учится на Data Engineer и начинает работать с PySpark. Я потратил где-то 2 часа на это упражнение и рассказывал про каждую строчку кода и приводил примеры как это работает в production и какие вопросы можно будет ожидать на собеседовании, или как тоже самое сделать с помощью SQL. Рассказал про Test Driven Development и многое другое.

Код удалось сохранить, вы можете самостоятельно решить задачку: https://github.com/surfalytics/data-projects/tree/main/de-projects/10_spark_transformations_with_tests_framework.


Вообще это очень хороший пример, как разрабатывать на Spark и как сразу писать тесты ко всем функциям/трансформациям.

Было бы еще классно к решению добавить:
- PySpark Style guide: https://github.com/palantir/pyspark-style-guide
- Использовать GitHub Actions, чтобы у вас тесты выполнялись, когда вы делаете commit (Continuous Integration)
- Попробовать тоже самое на Snowflake и dbt
- Попробовать тоже самое на Databricks (+ Repos, Unity Catalog)

PS это лишь маленький пример, что мы делаем на Surfalytics🏄

The Trimodal Nature of Tech Compensation Revisited - статья про уровни зарплат.

Любая зарплата (total compensation) складывается из 3х частей:

Base salary + cash bonus + Stocks (“акции” или типа того)

Акции компании бывают разные, если компания публичная как Amazon, вы получаете акции RSU и каждый квартал вам их выдают, вы можете их продать.

Так же если компания публичная, вы можете покупать акции на 15% процентов свой зарплаты со скидкой 10% (Например Microsoft и другие).

В статье уже более детально все описано.

Я лишь подумал о другом.

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

Поэтому надо смотреть Tier 2 компании, которые так же вам могут предложить что-то кроме зарплаты. Ведь базовая зарплата у всех +/- будет одинаковая, а все, что выше это бонусы, стоки и тп.

Часто бывает опцион в стартапах, где вам обещают буквально миллионы, если компания станет публичной. Я вам тоже могу обещать миллионы, если вы будете играть в лотерею😅 Ну смысле не будьте наивными.

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

И все это к чему? А к тому, что лучше искать работу, когда у вас все хорошо, и есть возможность подойти к вопросу отбора без спешки, чем когда у вас все горит….

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

Компания специализируется на создании хранилища данных, интеграции данных, построении дашбордов. Условно у вас есть своя компания/стартап и вы слышали про data driven культуру, принятие решений на основе данных и тп, и решили воспользоваться услугами, чтоб наконец получить долгожданные insights и как говорит Гребенюк - “добавить ноль справа” к вашей выручке.

Далее расскажу пример реализации. В данном контексте, я лишь унаследовал, то, чтобы внедрено в течение прошлого года и больше как на позиции adviser по data engineering, чтобы понять как все масштабировать, найти bottle necks, да и просто сделать reverse engineering.

Цена удовольствия такой компании 60k US$ в месяц за 1,5-2 консультанта в месяц (расценки в США, наверно такие жирные). Консультанты не простые, ребята укомплектованы best practices и сертификатами по dbt, snowflake, fivetran, sigma, looker и тп. Я их не застал, но застал все решение и изучил его сверху вниз (от BI дашбордов, до источников данных)

Если кратко суммировать, то было создано много дашбордов, dbt моделей, таблиц, слоев, схем. Сами дашборды похожи на новогодние огоньки, где каждую метрику визуализируют несколько раз (line chart, bar chart, kpi, и тп), сами дашборды как простыня, которую можно долго скролить.

То есть по факту, ребята реально наклепали всего на всю катушку, проблема лишь в том, что кол-во никак не коррелирует с качеством.

Такое впечатление, что им платили за “output”, то есть вроде все крутится вертится, но по факту бесполезно. Чем больше я погружался, тем больше было заметно, что все дашборды и показатели совсем не помогают бизнесу.

Про всякие вещи, типа синхронизации time zones (UTC) такого вообще нет.

Поэтому выводы:
1) Самый лучший способ быстро вкатиться в проект, это его задокументировать сверху вниз (reverse engineering)
2) Самый лучший способ показать бурную деятельность это клипать дашбордики, модели и таблицы, чем больше, тем лучше (особенно если вам плевать на результат)
3) Fivetran вообще топчик для интеграции данных, но вы платите за кол-во строк! Например, в нашем случае, цена Fivetran была выше в 10 раз, чем сам Snowflake.
4) dbt labs после dbt core кажется бесполезным, но помогает экономить силы на расписании (с dbt core, нужно Airflow или типа того)
5) Sigma - прикольный light weight BI инструмент в браузере, но если вам достались дашборды с простынями из графиков, то удачи, а так позволяет очень быстро наклепать дашбордиков и отличная интеграция со Slack или Email.

PS картинка просто с похожим стеком, современней уже быть не может!

Я же вам говорил, что CLI знать надо, чтобы вот такие вот шутки понимать😅

Ответил еще на два вопроса:

1) заменит ли нас AI? 🤖
2) Что делать с опытом IBM DataStage 🦖

Leading Effective Engineering Teams - новая книжка по управлению инженерными командами!

The essential traits for engineering effectiveness and the pitfalls to avoid
How to cultivate trust, commitment, and accountability within your team
Strategies to minimize friction, optimize career growth, and deliver maximum value
The dynamics of highly successful engineering teams and how to replicate their achievements
How to implement a systems thinking approach for everyday problem-solving and decision-making
Self-advocacy techniques to enhance your team's visibility and recognition within the organization

Судя по отзывам в Linkedin, отлчная книга, у автора свой большой блог https://addyosmani.com/ и он уже успел написать много книг.

Apache Iceberg - What Is It - статья про Apache Iceberg, с картинками и объяснением

Кстати в Yandex и VK, как дела c Lakehouse обстоят да и в целом в РФ интересно куда сместился акцент. Раньше это было Clickhouse/Greenplum и обычно on-premise, а теперь?

Классная история про Clickhouse - The Fast and the Furious: How ClickHouse, the World’s Fastest Open-Source Database, is Creating the First Real-Time Data Warehouse

Мой самый популярный пост в Linkedin оказался не про айти и аналитику….


Ведь реально получается:
1) Лучшая инвестиция это в семью и детей
2) Пословица про свой самовар самая правильная
3) Там еще добавил бы ликбез про ипотеку
4) Подход я работаю, жена тратит деньги работает отлично, чем больше жена потратила, тем больше я заработал, или наоборот

Так хорошо отдохнул, что забыл ноутбук за 500км, забыл его в пятницу, а вспомнил в понедельник вечером! Повезло, что он отмечен в Find My Device.

Основных компоненты системы для аналитики (System Designed for OLAP Workloads)

В данном контексте OLAP подразумевает аналитические запросы (сложные запросы на исторических данных).

Хранилище (Storage)
Для анализа исторических данных из различных источников необходимо иметь систему, позволяющую хранить большие объемы данных. Хранилище — это первый компонент системы, способной обрабатывать аналитические запросы к большим наборам данных. Варианты хранилища включают локальную файловую систему (DAS), распределенную файловую систему (HDFS) и объектное хранилище от облачных провайдеров (Amazon S3).

Типы хранилищ могут быть строковыми (row) или поколоночными (columnar) базами данных, или их комбинацией. Columnar уже является стандартом.

Формат файлов (File format) Для хранения, данные должны быть организованы в определенном формате файла. Выбор формата файла влияет на сжатие данных, их структуру и производительность работы.

Форматы файлов делятся на три категории: структурированные (CSV), полуструктурированные (JSON) и неструктурированные (текстовые файлы). В структурированных и полуструктурированных форматах данные могут быть организованы построчно или поколоночно. Примеры построчных форматов — CSV и Apache Avro, поколоночных — Apache Parquet и Apache ORC.

Формат таблицы (Table Format)
Важный компонент для системы, поддерживающей аналитические запросы к большим объемам данных. Формат таблицы действует как слой метанных над форматом файла и отвечает за расположение данных в хранилище.

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


Движок хранения (Storage engine)
Отвечает за размещение данных в заданном формате таблицы и поддержание всех файлов и структур данных в актуальном состоянии.

Движок хранения выполняет такие задачи, как оптимизация данных, поддержание индексов и удаление старых данных.

Каталог (Catalog)
При работе с данными из разных источников важно быстро находить нужные данные. Каталог решает эту задачу, используя метаданные для идентификации наборов данных.

Каталог — это центральное место, где можно найти информацию о таблицах, их схеме и расположении данных. Некоторые каталоги являются внутренними для системы (например, Postgres и Snowflake), другие, такие как Hive и Project Nessie, могут использоваться любыми системами.

Вычислительный движок (Compute Engine)
Последний компонент, необходимый для обработки больших объемов данных, выполняет пользовательские запросы по обработке данных. В зависимости от объема данных и типа нагрузки можно использовать один или несколько вычислительных движков. Для работы с большими объемами данных часто требуется распределенный вычислительный движок (MPP), такие как Apache Spark, Snowflake и Dremio.

PS надеюсь теперь вы поймете разницу между Parquet (file format) и Iceberg/Delta (table format)

Сегодня посмотрим на компоненты хранилища данных.

Хранилище данных это у нас просто большая база данных, часто это может быть распределенная (кластер из нескольких машин, чтобы они вместе все параллельно обрабатывали данные, ведь так быстрей и можно больше данных обработать - ну или просто Massive Parallel Processing)

Хранилище данных объединяет все технические компоненты в одной системе.

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


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

Это приводило к множеству проблем. Масштабирование становилось большой проблемой, так как объемы данных быстро росли, а количество и интенсивность нагрузок росло.

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

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

Хранилище данных до сих пор является отличным решением для построения аналитического решения.

Минису все известны:
- Поддержка только SQL
- Вы платите за compute и storage вместе (Snowflake и тп это lakehouse и о нем будет позже)
- Сложно использовать для ML, так как данные нужно выгружать
- У вас schema on write (то есть у вас таблица создана и вы в нее уже пишите как есть)
- Не очень удобно для streaming/real time аналитики, обычно это batch - раз в час, раз в сутки
- Это Vendor Lock

В след посте рассмотрим озеро данных.

Источник: https://www.oreilly.com/library/view/apache-iceberg-the/9781098148614/ch01.html

PS Судя по прошлым комментариям, я рад что ребята в Авито Тех тоже прочитали книгу и поделились знаниями со своей аудиторией🙃

В Surfalytics я попросил всех прочитать 1ю главу и понять, так как очень важно понимать разницу между DW/Data Lake/Lake House и знать их особенности.

А вот и книжка!

Мы рассмотрели компоненты хранилища данных, теперь озеро данных. К нему можно применить термин decoupled.

Изначально использовался Hadoop — открытая распределенная вычислительная платформа и компонент файловой системы HDFS для хранения и обработки больших объемов структурированных и неструктурированных данных на кластерах недорогих компьютеров. Для аналитики использовался MapReduce, но написание задач было сложным, поэтому был создан Hive для преобразования SQL-запросов в задачи MapReduce.

Со временем перешли от кластеров Hadoop к облачным объектным хранилищам (Amazon S3, Minio, Azure Blob Storage) из-за удобства и дешевизны. MapReduce заменили другие распределенные движки, такие как Apache Spark, Presto и Dremio. Однако формат таблиц Hive остался стандартом для распознавания файлов как таблиц для аналитики.

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

Преимущества:
- Низкая стоимость: Хранение данных и выполнение запросов дешевле, чем в хранилище данных.
- Открытые форматы хранения: Можно использовать любые форматы файлов.
- Обработка неструктурированных данных: Озера данных могут обрабатывать данные, такие как данные сенсоров, вложения электронной почты и журналы.

Недостатки:
- Производительность: Отсутствие встроенных оптимизаций, таких как индексы и гарантии ACID, приводит к необходимости значительных усилий для достижения производительности, сравнимой с хранилищем данных.
- Сложная конфигурация: Необходимость значительных инженерных усилий для настройки и оптимизации компонентов.
- Отсутствие гарантий ACID: Нет встроенных транзакционных гарантий, что усложняет задачи, требующие строгой целостности данных.

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

Для выполнения запросов на озере данных можно использовать движки, такие как Dremio, Presto/Trino, Apache Spark и другие, но они сталкиваются с трудностями при обновлении данных из-за ограничений формата таблиц Hive.

Таким образом, озера данных и хранилища данных имеют свои уникальные преимущества и недостатки, что привело к появлению новой архитектуры, сочетающей их плюсы и минимизирующей минусы, — Data Lakehouse.


Как я первый раз познакомился с Lakehouse?
Был 2021 год, я был в Amazon Alexa, у нас было много данных и централизованный Redshift на 128 нод (максимальное кол-во нод) использовался для BI use cases. Redshift (хранилище данных) был единственный вариант для BI (отчетность), так как подключаться к озеру данных через Athena, Hive, Spark было не очень удобно из-за объема и особенности BI.

Тем не менее у Alexa было и озеро данных (upstream) на S3 и EMR (managed Hadoop). И там не было проблем с производительностью или хранением большого объема данных. Главная проблема была подружить это с BI и поэтому приходилось выгружать из озера и грузить в хранилище, а потом еще раз выгружать из хранилища обратно в S3 для ML.

Как раз в это время вступил в силу закон про data privacy (GDPR), для нас это простая задача - удалить CUSTOMER_ID(s) по запросу клиента раз в неделю. Это очень просто в реляционном хранилище данных, но очень сложно в озере данных (так как у вас просто куча файлов)

Поэтому мы стали смотреть в сторону Lakehouse, и первый open source был Delta для Spark.

Я как разу перешел в Xbox, и у меня была идея построить Delta Lake на Databricks, что я и сделал. Тогда Delta Lake был топ формат таблицы (теперь то мы знаем, что это не формат файлов). А вот сейчас походу надо уже строить на Iceberg. Хотя в Databricks все еще по умолчанию используется Delta.

А как было у вас?