Наверно уже все и так скачали книгу Fundamentals of Data Engineering, но вот есть легальная ссылка на скачку.

Я сам прочитал только 3 главы. На каждую тему в книге у меня мысли были примерно такие - “ага, знаю”, “так, все правильно”, “точно, согласен” и тп.

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

А вы читали?

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


- Apache Arrow
- Apache Iceberg ( я работал уже с готовыми решениями, но не строил с 0)
- DuckDB
- Polars
- Rust/Golang языки программирования для задач дата инжиниринга
- Ray (spark)
- Protobuf (использую по факту, обычно в связки с event и streams)
- Apache XTable

Из старого но важного:
- Kubernetes
- Apache Kafka
- Apache Flink
- Fast API

У меня список своеобразный конечно. Что еще есть интересного?

Вебинар: ➡️Мигрируем аналитическую отчетность с SAP BW на импортонезависимый стек. Показываем вживую

На вебинаре команда Sapiens solutions поделится техническими деталями реализации проектов миграции.

📅Дата вебинара: 01.10.2024
⌚️Время начала: 11:00 Мск

Регистрация обязательна

❗️Ключевые моменты вебинара:

1️⃣ Загрузка данных из SAP ERP с помощью OData в Greenplum
2️⃣ Фреймворк управления загрузками и расчетами Proplum
3️⃣ Внедрение современного хранилища данных.
4️⃣ Демонстрация процесса доставки данных - от создания документа в ERP до отображения в отчете
5️⃣ Apache Superset как фронт BI: соответствие объектов SAP BW/BO и Superset, разработанный функционал форка

Вебинар будет полезен, даже если вы не используете SAP. Мы рассмотрим технологические аспекты работы с Arena DB и Superset, а также дополнительные компоненты, которые дают возможность ADB быть чуть более "low code". Для Superset покажем расширения для сводных таблиц и другие компоненты.

До встречи на вебинаре!

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

Решение на AWS, куча Kinesis стримов, которые пишут в S3 (json), дальше lambda их обрабатывает и пишет в другой S3. Есть еще DynamoDB с клиентской информации, которая делает ежедневные snapshots в S3. В конце с помощью Athena таблицы и запросы.

Компания продает обезличенные данные на млн долларов для других компаний. И товарищ непосредственно занимается интеграцией и выгрузкой данных для сторонних компаний.

Выгрузка происходит раз в час, когда Glue Python Shell запускает запросы Athena и делает unload в S3. С помощью вспомогательных запросов отслеживается качество данных и результат пишется в Cloud Watch и там всевозможные алерты на отклонения качества данных.

Решение будет переделано на Databricks и Delta.

Иногда кажется чем больше rejection rate, тем лучше для HR и они наверно еще бонусы получают и хвастаются у кого больше rejection и что вообще можно все автоматизировать и оно само будет делать screening и rejection.


Позабыты хлопоты, остановлен бег, Вкалывают роботы, а не человек!

До чего дошел прогресс! Было времени в обрез, А теперь гуляй по свету - хочешь, с песней, хочешь, без!

В Surfalytics мы делаем типичные Data Engineering проекты нетипичным образом. Обычно цель любого end-to-end проекта — это использование стандартных настроек и минимальной конфигурации.

Практически любой проект на Youtube это будет набор команд и шагов. Часто человек может даже не понимать как работает, но с покер фейсом нас учить, как делать Copy-Paste и строить решение. На выходе, у нас много pet проектов и 0 релевантного опыта и главное вообще не понятно как это применять в реальных условиях.

Сегодня Максим проводил проект по созданию end-to-end решения для работы с API (job posting сайт) с использованием стека AWS, включая такие сервисы, как Lambda, Step Functions, Redshift и другие.

Но вместо того, чтобы слепо следовать шагам, мы его мучаем вопросами на каждом этапе. Например:

1. Почему Lambda?
2. Почему Python 3.11?
3. Что такое API rate limit и как его избежать?
4. Какие есть альтернативы Lambda в AWS?
5. В чем разница между IAM role и IAM user? Что лучше и почему?
6. Что такое VPC и subnet, почему используется default VPC?
7. Какие есть соображения по безопасности? Где найти лучшие практики AWS (подсказка: AWS Well-Architected Framework)?
8. Как проверить работу AWS Lambda function?
9. Какова стоимость?
10. Почему Redshift? Почему Serverless? Какие плюсы и минусы у Redshift Serverless?
11. Почему не использовать Glue + Athena вместо Redshift?
12. Какова стоимость за запуск/в день?

И так далее. Некоторые вопросы даже мне сложно ответить.

Другими словами, в Surfalytics мы не гонимся за количеством pet projects. Мы сосредоточены на том, чтобы превратить ваш pet project в реальный проект и по-настоящему понять разницу. Мы не принимаем ничего на веру и считаем, что все может быть неправильно.

В результате, на выполнение 1/3 проекта у нас ушло более 3 часов, хотя при простом копировании и запуске кода это заняло бы всего 60 минут.

В каждом проекте мы детально разберемся, почему так, что стоит за капотом, и убедимся, что вы будете готовы ответить на вопросы hiring manager.

Хотелось бы конечно больше проектов и чаще делать, но пока основное время занимает работа.

PS другой интересный аспект - это персональный бренд. Этот пунктик очень важен в Surfalytics. Например, пост Максима набрал 162 лайка про этот проект! Это дает уверенность и Максиму и нанимающему менеджеру и вообще делать свой бренд в Linkedin прежде всего это про выйти из зоны комфорта.

PPS Ссылки:
Все проекты Surfalytics: https://github.com/surfalytics/data-projects (у нас еще много проетов в разработке включая Kubernetes, Open Source stack и тп)
Проект Максима: From API to Dashboard: Building an End-to-End ETL Pipeline with AWS

Так это выглядит на практике. Осталось в Twitch стримить. Заодно практика английского.

Amazon Hybrid work policy 😛

Реально работа с датами и часовыми поясами всегда боль. Кто как решает для себя эту проблему?

А какой стандарт по timestamp?

Как у вас получается бороться с tech debt?

Замечательная статья - Paying down tech debt
И еще одна - Tech Debt and the Pragmatic Middle Ground

“What is tech debt?

I define tech debt as any problem in the codebase that affects programmers by making it harder to make necessary changes. As a programmer, I wanted to fix such issues because they slowed me down. But as a manager, I had to ensure the team delivered value to stakeholders.”

“Я определяю технический долг как любую проблему в кодовой базе, которая мешает программистам вносить необходимые изменения. Как программист, я хотел исправить такие проблемы, потому что они замедляли мою работу. Но будучи менеджером, я должен был убедиться, что команда приносит ценность заинтересованным сторонам.”

В маленьких компаниях (командах) все просто, если что-то сломалось - взяли и починили. Авось никто и не заметит.

А вот в больших командах и организациях все по-другому.

Как правило, аналитическое решение (хранилище данных) это не business critical и может не работать целый день, пользователи потерпят.

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

Обычно используют уже готовое решение от back-end/devops, такие как PagerDuty и другие, сразу появляется новая обязанность - on-call, нужно писать сообщение бизнес пользователям о поломках и обещать, что однажды все будет лучше.

Можно все автоматизировать, и примерно будет так работать:
1. Alert о падение data pipelines или отклонении показателя (качество данных)
2. Заводится новый инцидент, создается Slack канал с номер инцидента и туда добавляются инженеры
3. Обсуждается проблема и решение
4. Ответственный пишет в другой slack канал пользователям (бизнес) о проблеме и estimation когда ее починят
5. Команда все чинит, деплоит фикс, перезапускает data pipelines и вроде к обеду уже можно открывать BI дашборды.

Это уже зрелая организация. У всех компаний есть с этим проблемы, кто-то раньше, кто-то позже к этому приходит, а потом еще SLA внедрят для надежности (спокойствия бизнес пользователей).

Главное отличие от backend/devops - вы все это делаете в рабочие часы, а не ночью (хотя помню в Lamoda мне в 4 утра могли звонить, что отчет поверх backend Postgres для склада в SAP BO не показывает свежие данные).

Одна из причин, почему DevOps, SRE позиции не очень полезны для здоровья long term, и обычно никто не компенсирует ночные часы.



Картинку взял из The Madness of Data Incident Management

А как в РФ с этим? Какие сервисы используются для коммуникации, инцидентов и тп?

Data Engineering tool box выходного дня.

Сегодня будет выступление - Richard Dawkins, чтобы лучше информация воспринималась))

Должна быть интересная дискуссия - Beyond Lakehouse Table Formats
The original creators of Delta Lake and Apache Iceberg™ take on interoperability formats

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

Кто такой CDO и что он делает?

Chief Data Officer (CDO) — это руководитель, который отвечает за управление и использование данных в организации. Основная роль CDO заключается в том, чтобы создавать и реализовывать стратегию работы с данными, помогая компании эффективно собирать, анализировать, хранить и использовать данные для принятия бизнес-решений.

Основные обязанности CDO:

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

Управление данными: CDO отвечает за качество, безопасность и управление данными, включая защиту данных и обеспечение соответствия регуляторным требованиям.

Инновации с данными: CDO исследует, как организация может использовать данные для создания новых продуктов или услуг, улучшения процессов или получения конкурентного преимущества.

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

Координация с другими отделами: CDO тесно сотрудничает с IT, маркетингом, финансами и другими департаментами, чтобы обеспечить единое понимание и использование данных.

Обеспечение соблюдения законов: CDO следит за соблюдением требований в области конфиденциальности данных и защиты персональной информации.

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

Одно время CDO было очень популярно, потом сошло на нет.

В каждой компании свой подход. Где-то можно встретить CDO (обычно в более традиционных индустриях как финансы), а где-то их нет. Вместо них VP по аналитике, директора по инжинирингу (Software Engineering), CPO (chief product officer).

Мне нравится, что картинка передает суть, что есть два мира и их нужно кем-то соединить, а как роль называется не важно. Главное, чтобы к данным и аналитике был продуктовый подход, и цели для команд аналитики ставились в зависимости от целей организации. В этом плане отлично работают OKR (Objective Key Results).

Как лучше наладить согласованность и сотрудничество между бизнесом и миром данных? И решение не в покупке новых инструментов или программного обеспечения. Необходимо сочетать 50% технических навыков и 50% навыков донесения информации на уровне C-suite.

У кого есть в компании CDO? А если нет, то кто рулит данными?