Инжиниринг Данных

11 October 2024 18:25

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

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

Как у вас?

Инжиниринг Данных

10 October 2024 07:37

⚙️ От 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? Какие видите в нём преимущества?

Инжиниринг Данных

08 October 2024 17:47

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

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

Инжиниринг Данных

07 October 2024 03:39

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

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

Инжиниринг Данных

04 October 2024 07:50

Как у вас получается бороться с 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.”

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

Инжиниринг Данных

02 October 2024 17:25

Amazon Hybrid work policy 😛

Инжиниринг Данных

01 October 2024 15:42

В интересное время живем🔫🙌

Инжиниринг Данных

29 September 2024 21:42

В 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 и тп)
Проект Максима: kazarmax/from-api-to-dashboard-building-an-end-to-end-etl-pipeline-with-aws-3c1f4048676d">From API to Dashboard: Building an End-to-End ETL Pipeline with AWS

Инжиниринг Данных

28 September 2024 09:13

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

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

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

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

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

Инжиниринг Данных

27 September 2024 17:51

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


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

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

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

Инжиниринг Данных

27 September 2024 05:45

Тут возможно самый полный сборник всего, что есть по DE или около того. https://github.com/DataExpert-io/data-engineer-handbook

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

Инжиниринг Данных

26 September 2024 07:41

Сегодня был интересный опыт - Vancouver Career Fair, поделился инсайтами🍿

Инжиниринг Данных

24 September 2024 16:45

Как работать с SQL запросами 🛠

Сделали небольшой коллаб с Димой Аношиным (Surfalytics) про работы с SQL. Дима как супер эксперт по дата инжинирингу рассказал про более правильную работу с SQL с точки зрения хранения и обработки кода. Так что много про версионирование, гит и качество данных. А от меня немного про форматирование SQL запросов для лучшей читабельности.

- Часть 1: версионирование, гит и первый pull request
- Часть 2: документация, code review и sql стайлгайд

Инжиниринг Данных

22 September 2024 00:28

Сегодня первый раз побывал в общественном разряде бани.

Баня — это заебись! И вот почему:
♨️ Контекст максимально располагает к открытому и прямолинейному общению. Вместе с одеждой и аксессуарами спадает напускной флер, остается, так сказать, фактура. Это очень меняет ракурс восприятия себя самого и других людей;

♨️ Методичный алгоритм действий помогает переключиться и сосредоточиться на ощущениях, тело становится первостепенным, разум и рефлексия отходят на второй план;

♨️ Вокруг — разные, непохожие друг на друга люди, которым абсолютно все равно, кто ты за пределами этих стен.

💡Outcome на будущее: если хочешь получше узнать человека, сходи с ним в баню.

Инжиниринг Данных

19 September 2024 19:35

Книга Kubernetes in Action (2nd edition by Marko Lukša, Kevin Conner) — отличный старт для знакомства с Kubernetes

Когда я начал читать книгу Kubernetes in Action, сразу понял — это не просто теория. Автор делает акцент на понятном объяснении того, что такое Kubernetes, как он работает и почему его популярность так стремительно выросла. Честно говоря, я был впечатлен уже с первых страниц.

Что мне особенно понравилось

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

Теперь давайте разберем основные идеи первых глав (1.1 Introducing Kubernetes - 1.2 Understanding Kubernetes), которые привлекли мое внимание.

---

Введение в Kubernetes: Зачем это нужно?

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

Причем, как отмечает автор, имя Kubernetes символично. Как штурман направляет корабль, так Kubernetes направляет ваше приложение, оставляя за вами только ключевые решения.

---

Почему Kubernetes стал таким популярным?

Развитие микросервисов и контейнеров изменило весь подход к разработке ПО. Если раньше приложения представляли собой большие монолитные системы, которые было сложно масштабировать и управлять, то теперь мы работаем с десятками и сотнями микросервисов. Kubernetes автоматизирует их управление, делая развертывание и масштабирование микросервисов тривиальной задачей. Автор книги подчеркивает: то, что раньше было сложно, с Kubernetes стало простым и очевидным.

---

Как Kubernetes решает повседневные задачи?

Читая книгу, я понял: Kubernetes — это не просто система для развертывания приложений. Это целая экосистема, которая позволяет автоматически управлять масштабированием, следить за здоровьем приложения и даже восстанавливаться после сбоев. Если ваше приложение упало — Kubernetes сам перезапустит его. А если произошел сбой оборудования, Kubernetes перенесет работу на здоровые узлы. Все это экономит время и нервы.

---

Основные компоненты Kubernetes

Автор подробно объясняет архитектуру Kubernetes, разделяя её на две главные плоскости: Control Plane и Workload Plane. Control Plane управляет состоянием всего кластера, а Workload Plane — это место, где запускаются приложения. Все выглядит логично, и благодаря иллюстрациям с каждым компонентом становится легче разобраться.

---

Личный опыт

Для меня этот материал стал отличным введением в тему. Книга Kubernetes in Action помогает понять не только теоретические основы, но и показывает, как Kubernetes действительно работает на практике. А самое главное — автор делает это легко и доступно, с примерами и наглядными пояснениями. Если вы хотите погрузиться в мир Kubernetes — это идеальная отправная точка.

От себя же я составил Mind Map первых двух частей, которым хотел бы поделиться в этом посте (пока что ссылкой на dropbox)

- https://www.dropbox.com/scl/fi/9fv5og1cchp44kofi9h0p/Kubernetes-in-Action-till-1.3.pdf?rlkey=vus4tw7vsrqf15naerns2x12v&amp;st=6miusxfn&amp;dl=0

Обзор следующих частей опубликую очень скоро🛥

Инжиниринг Данных

10 October 2024 20:30

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

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

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

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

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

Инжиниринг Данных

09 October 2024 22:51

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

Инжиниринг Данных

08 October 2024 01:26

Новая книга - Building Medallion Architectures

In today's data-driven world, organizations must manage and analyze vast amounts of information to deliver the insights that give them a competitive advantage. Many turn to the medallion architecture because it's a proven and well-known design. Yet implementing a robust data pipeline can be difficult, particularly when it comes to using the medallion architecture's bronze, silver, and gold layers—done wrong, it can hamper your ability to make data-driven decisions. This practical guide helps you build a medallion architecture the right way with Azure Databricks and Microsoft Fabric.

Drawing on hands-on experience from the field, Piethein Strengholt demystifies common assumptions and complex problems you'll face when embarking on a new data architecture. Architects and engineers of all stripes will find answers to the most typical questions along with insights from real organizations about what's worked, what hasn't, and why.

Согласно описанию, книга будет посвящена примерам на базе Azure Databricks и Microsoft Fabric.

Я могу сказать, как это работает в Databricks. По факту, если вы строите озеро данных (data lake) или его улучшенную версию lake house (используете формат таблиц Delta, Iceberg), то вы разделяете хранение по уровням хранения данных:

- raw/bronze - может быть просто папка с blob storage, в которую вы грузите/копируете сырые данные и создаете таблицы, то есть абстракции в каталоге (Hive, Unity).

В случае dbt, это будет dbt source. Но dbt и databricks это какое-то modern data извращение.

- staging/silver - вы используете уже таблички из bronze, и делаете трансформации, но все еще данные raw (без агрегации), можете еще добавить joins.

- business/fact/dw/gold слой - там где у вас уже таблицы фактов/витрины/метрики, вы агрегируете данные и используете аналитические функции.

На второй картинке я привел свое решение на основе Microsoft Gaming. Я еще делал решение на Trino/dbt/Iceberg.

То есть medallion architecture просто подразумевает, что у вас есть несколько слоев в хранилище данных, и 30 лет назад когда делали хранилище даже и не догадывались, что они использовали архитектуру миньенчиков.

Инжиниринг Данных

04 October 2024 21:01

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

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

Как правило, аналитическое решение (хранилище данных) это не 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

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

Инжиниринг Данных

03 October 2024 15:57

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

Инжиниринг Данных

02 October 2024 02:03

Точно интересное время☀️

Инжиниринг Данных

29 September 2024 21:43

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

Инжиниринг Данных

28 September 2024 22:28

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


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

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

Инжиниринг Данных

27 September 2024 20:55

Вебинар: ➡️Мигрируем аналитическую отчетность с 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 покажем расширения для сводных таблиц и другие компоненты.

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

Инжиниринг Данных

27 September 2024 15:02

True Tech Champ

Всероссийский чемпионат по алгоритмическому и робототехническому программированию от МТС.

Регистрация: до 12 октября
Доступ к онлайн-заданиям: с 1 октября
Финал в офлайне: 8 ноября

Регистрируйся на алгоритмический трек и решай задачи в классическом олимпиадном формате.

Участникам в ходе отборочных испытаний предстоит решить алгоритмические задачи онлайн и посоревноваться в индивидуальном зачете. 150 участников с лучшим рейтингом будут приглашены на очный шоу-финал чемпионата. Призовой фонд трека — 2 750 000 руб.

Смотри подробности и регистрируйся на сайте.

Инжиниринг Данных

26 September 2024 17:45

Конференция для ИТ-архитекторов от МТС

3 октября | 16:00
Офлайн в Санкт-Петербурге | Онлайн

Присоединяйся к конференции для ИТ-архитекторов True Tech Arch#6, которая пройдет 3 октября в Санкт-Петербурге. Тебя ждут доклады от ведущих экспертов МТС и приглашенных экспертов.

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

Для участия нужно зарегистрироваться по ссылке

Инжиниринг Данных

25 September 2024 00:23

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

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

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

А вы читали?

Инжиниринг Данных

22 September 2024 19:39

Еще один отзыв на Surfalytics/менторство.

Товарищ реально справился и смог себя мотивировать и как он правильно отметил - это «марафон», нужно терпение.

Впереди еще много работы, потому что на одну работу в Канаде особо не разгуляешься🤑

Как я искал работу в Канаде
Всем привет! Хочу поделиться историей сначала неуспеха, а потом успеха, к которому я шел почти год. Сейчас будет большое интро для контекста, но если это неинтересно, то можно сразу переходить к части про дата инженера.

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

Я стал искать работу дата аналитиком, откликнулся на 220 вакансий, прошел 16 интервью, но везде получал отказы. Потом я уволился из московской компании и решил искать работу в рисках.

Статистика стала намного лучше.

Откликнулся на 35 вакансий, прошел 7 интервью, в двух компаниях дошел до последнего этапа, но все равно везде получил отказы. Вообще работа в банковской сфере и особенно в рисках сильно отличается от рынка в России, так как крупных банков всего 5 и все главные офисы в Торонто.

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

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

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

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

В итоге за 3 месяца я откликнулся на 45 вакансий, прошел 8 интервью и наконец-то получил заветный оффер. Получилась статистика по поиску как в рисках, но деньги и перспективы гораздо выше, т.к. уровень зарплат у Дата инженеров примерно как у менеджеров и директоров в рисках, а количество таких вакансий очень ограничено по сравнению с инженерными позициями.

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

Главное не опускать руки, все отказы превращать в преимущество на следующем собеседовании, анализировать ошибки (в этом очень помогает запись интервью) и постоянно улучшать свои навыки.

Инжиниринг Данных

22 September 2024 00:28

Собеседования тоже можно в бане проводить! Баня топчик!

Инжиниринг Данных

19 September 2024 06:29

Все чаще мелькает информация про YAML инженера.

Вот несколько статей:
YAML developers and the declarative data platforms

The rise of the YAML engineer

From Data Engineer to YAML Engineer

Data Orchestration Trends: The Shift From Data Pipelines to Data Products

Dbt модели у меня безусловно лидируют, так же использовал для Mock тестов в Pytest и Helm Charts и Kubernetes.