В 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? А если нет, то кто рулит данными?

⚙️ От Postgres к Data Lake

Интересная статья с верхнеуровневым описанием эволюции внутренностей сервиса.

Notions - крутой органайзер с разнообразным функционалом.
Текстовые заметки, картинки, страницы, ... - представлены в виде "блока" в Postgres.

📶 До 2021 - все блоки хранились в 1 инстансе Postgres.
В 2021 стало 20 млн блоков.
Сейчас их 200 млрд. Как они хранятся?

🔡 Данные разбиты на 480 логических шардов, распределенных на 96 инстанцев Postgres.
БД обслуживала разнообразные запросы:
1) пользовательский траффик онлайн
2) оффлайн аналитику
3) машинное обучение

Было решено вынести от Postgres нагрузку 2), 3).

🔀 Воспользовались ETL:
Postgres -> connector -> Debezium -> Kafka -> S3 <- ...аналитика

⏺ Проффит:
1) Сэкономленный бюджет
2) Быстрая обработка
3) Новые возможности. Решение помогло быстрее внедрять AI функционал.

Подробности в статье:
https://blog.det.life/how-does-notion-handle-200-billion-data-entities-919b238c2846

Мой перевод на хабре:
https://habr.com/ru/articles/845446/

▶️ А у Вас есть проект с ETL? Какие видите в нём преимущества?

У меня давно была идея скопировать Data Learn из YouTube (или правильней запрещенная сеть?) в RUTUBE или VK Video.

Оказывается RUTUBE сделал космическую фичу - полностью копировать канал из YouTube, все видео и описания. Жалко, что обложки не копирует =/

Поэтому, чтобы посмотреть видео Data Learn или просто узнать, что такое аналитика и понять нужно вам это или нет совершенно бесплатно, теперь вам не нужен VPN, можете посмотреть на Rutube https://rutube.ru/channel/46386964/ (обязательно подпишитесь!)

В планах добавлять обзоры вакансий РФ по аналитическим профессиям и продолжать Data Learn. Может еще надо GitHub импорто заменить?

PS вопрос к знатокам, какой VPN самый лучший в РФ и какой аналог GitHub используется?

Как это знакомо…

Все больше встречаю постов от опытных инженеров, что Co-Pilot/ChatGPT не очень то уж и помогают, а часто даже вредят работе.

Как у вас?

Хороших выходных, элита.

Для меня последние несколько лет использование CI/CD в аналитических проектах это must have, хотя до этого во всех компаниях в РФ мы никогда не использовали.

5 лет в Амазоне тоже обходился без CI/CD. В целом можно было использовать внутренний framework для этого, но совсем было непонятно с чего начинать.

А теперь на всех проектах, где я работаю, обычно первые 2 месяца уходят на создание правильного CI/CD framework или улучшения существующего.

С чего начать, если никогда не работали?

1. Понять GitHub на уровне создания branch, Pull request, Code review, Merge. (Module 0 Surfalytics)

2. Понять для каких задач это подойдет, а для каких нет. Например хранить XLS или Tableau Workbooks не самый лучший способ.

3. Внедрить pre-commit, linting для локальной разработки.

4. Добавить автоматические проверки в CI, начиная с linting/pre-commit и заканчиваю unit tests. Вы можете запускать в CI dbt, spark, pytest и использовать dummy данные или реальные.

У разных продуктов, есть разные способы проверки, например у Looker популярен Spectacles, у AWS Glue есть возможность использовать Glue Spark в контейнере, контейнер с Databricks.

5. Если код деплоится, добавить шаг CD и tags/releases.

Так же можно и для инфраструктуры с использованием Terraform, Helm Values и тп. Например, для Terraform часто используется Atlantis.

И все эти истории всегда killer features для собеседования на дата инженера!

Мы тут обсуждали, что chatGPT не всегда помогает с кодом, зато мне вот помог с пельменями!