Data System Design Interview
Что это за зверь🤔
Data system design - это подмножество сисдиз интервью, но с упором на data-driven задачу, где кандидат показывает способность построения систем в области хранения, управления и обработки данных.
Пример задачи💁♂️
(Пример подробный, часто кандидат сам формулирует требования через диалог)
Мы компания Х, новая платформа для авторов. У каждого автора есть свое пространство и люди могут подписываться или отписываться от них. Запрос отписки может приходит либо от пользователя из UI интерфейса, отдельного запроса от департамента Customer Success или Legal (может содержать в себе большое число пользователей за один раз)
Нам необходимо разработать решение, у которого будет:
1. Возможность отправлять near real-time событие в уже разработанный UnsubMe сервис для отписки
2. Финальный отчет для сеньор менеджмента для анализа воронки отписок (с возможностью работы на разных уровнях агрегаций и времени)
3. Возможность для аналитиков осуществлять ad-hoc аналитику
Как проходит интервью😅
Формат интервью обычно соответствует тем же временным рамкам, что и сис дизайн интервью (пример для интервью в 90 минут):
1. Интро (5 минут)
• Вы представляетесь друг другу и пара слов о бекграунде каждого. Для больших компаний обычно присутствуют 2 интервьюера.
2. Понимание проблемы и сбор требований (10-15 минут)
• Интервьюер описывает вам проблему и предлагает задавать вопросы
• Ваша задача проговорить функциональные и нефункциональные требования и те ограничения, которые будут приняты в виду ограничения по времени (например, если у вас задача по имплементации GDPR, то вы обсуждаете только часть удаления пользовательских данных)
• Также вы обсуждаете текущую нагрузку на систему и как это изменится в краткосрочной и среднесрочной перспективе
• В какой среде будет задача (клауд/гибрид/on-prem)? Есть ли доп ограничения вида Cloud Agnostic?
3. Высокоуровневый дизайн (15-20 минут)
• Вы совместно рисуете и обсуждает общую схему решения на уровне компонетов / сервисов / технологий. Тут часто бывают общие обсуждения уровня нужен ли нам дополнительной слой DWH, выбора синхронного или асинхронного метода передачи сообщения, необходимости какой-то шины данных и т.п.
4. Детальное обсуждения какого-то компонента (20-35 минут)
• Идет углубленное обсуждение какого-то компонента. В виду дата ориентированности, обычно это завязано на какой-то компонент стриминга, етл, дата модели и т.п.
5. (Опционально) Обсуждение оптимизаций, масштабирования или каких-то адаптаций для решения (10-15 минут)
• Такие обсуждения часто бывают в процессе предыдущих этапов или кандидат инициирует их
• Интервьюер может предложить изменение требований и спросить, какие адаптации надо сделать под них (например, подключение 3rd party vendor в примере компании X, который может работать с отписками)
6. Q&A и Вопросы Кандидата
• Обычная Q&A сессия, которая позволяет кандидату спросить про работу в компании
Примеры детальных обсуждений👨🦳
Неполный список тем, который может быть в детальном обсуждении
• CDC. Как организовать, зачем, какой тип выбрать
• Message Broker, какой выбрать, какой критерий выбор, формат сообщений, какая модель обработки
• DWH. Нужен? Какая модель данных? Какие основные сущности будут?
• Качество данных. на каком этапе, какие тулзы, что покрыть
• Мониторинг. Что мониторить, как мониторить?
• Batch Processing. Как будет организована загрузка? Как выглядит инициализирующая / инкрементальная загрузка? Как ускорить загрузку?
• Оркестрация, как организовать, на каком этапе?
Как готовиться😺
Курс/книги по системному дизайну (educative / карпов / System Design Interview от Alex Xu), общие книги по дата инженерии (Fundamentals of Data Engineering / DDIA) и более глубокое погружение в конкретные темы, которые могут всплыть.
Если времени не много, попробовать поделать мок интервью и по фидбеку пытаться что-то доизучить, но мок-интервьюеры смотрят на то, что интересно им, и могут упустить часть вещей. Я также провожу их в рамках моих менторинг сессий =)
Что это за зверь
Data system design - это подмножество сисдиз интервью, но с упором на data-driven задачу, где кандидат показывает способность построения систем в области хранения, управления и обработки данных.
Пример задачи
(Пример подробный, часто кандидат сам формулирует требования через диалог)
Мы компания Х, новая платформа для авторов. У каждого автора есть свое пространство и люди могут подписываться или отписываться от них. Запрос отписки может приходит либо от пользователя из UI интерфейса, отдельного запроса от департамента Customer Success или Legal (может содержать в себе большое число пользователей за один раз)
Нам необходимо разработать решение, у которого будет:
1. Возможность отправлять near real-time событие в уже разработанный UnsubMe сервис для отписки
2. Финальный отчет для сеньор менеджмента для анализа воронки отписок (с возможностью работы на разных уровнях агрегаций и времени)
3. Возможность для аналитиков осуществлять ad-hoc аналитику
Как проходит интервью
Формат интервью обычно соответствует тем же временным рамкам, что и сис дизайн интервью (пример для интервью в 90 минут):
1. Интро (5 минут)
• Вы представляетесь друг другу и пара слов о бекграунде каждого. Для больших компаний обычно присутствуют 2 интервьюера.
2. Понимание проблемы и сбор требований (10-15 минут)
• Интервьюер описывает вам проблему и предлагает задавать вопросы
• Ваша задача проговорить функциональные и нефункциональные требования и те ограничения, которые будут приняты в виду ограничения по времени (например, если у вас задача по имплементации GDPR, то вы обсуждаете только часть удаления пользовательских данных)
• Также вы обсуждаете текущую нагрузку на систему и как это изменится в краткосрочной и среднесрочной перспективе
• В какой среде будет задача (клауд/гибрид/on-prem)? Есть ли доп ограничения вида Cloud Agnostic?
3. Высокоуровневый дизайн (15-20 минут)
• Вы совместно рисуете и обсуждает общую схему решения на уровне компонетов / сервисов / технологий. Тут часто бывают общие обсуждения уровня нужен ли нам дополнительной слой DWH, выбора синхронного или асинхронного метода передачи сообщения, необходимости какой-то шины данных и т.п.
4. Детальное обсуждения какого-то компонента (20-35 минут)
• Идет углубленное обсуждение какого-то компонента. В виду дата ориентированности, обычно это завязано на какой-то компонент стриминга, етл, дата модели и т.п.
5. (Опционально) Обсуждение оптимизаций, масштабирования или каких-то адаптаций для решения (10-15 минут)
• Такие обсуждения часто бывают в процессе предыдущих этапов или кандидат инициирует их
• Интервьюер может предложить изменение требований и спросить, какие адаптации надо сделать под них (например, подключение 3rd party vendor в примере компании X, который может работать с отписками)
6. Q&A и Вопросы Кандидата
• Обычная Q&A сессия, которая позволяет кандидату спросить про работу в компании
Примеры детальных обсуждений
Неполный список тем, который может быть в детальном обсуждении
• CDC. Как организовать, зачем, какой тип выбрать
• Message Broker, какой выбрать, какой критерий выбор, формат сообщений, какая модель обработки
• DWH. Нужен? Какая модель данных? Какие основные сущности будут?
• Качество данных. на каком этапе, какие тулзы, что покрыть
• Мониторинг. Что мониторить, как мониторить?
• Batch Processing. Как будет организована загрузка? Как выглядит инициализирующая / инкрементальная загрузка? Как ускорить загрузку?
• Оркестрация, как организовать, на каком этапе?
Как готовиться
Курс/книги по системному дизайну (educative / карпов / System Design Interview от Alex Xu), общие книги по дата инженерии (Fundamentals of Data Engineering / DDIA) и более глубокое погружение в конкретные темы, которые могут всплыть.
Если времени не много, попробовать поделать мок интервью и по фидбеку пытаться что-то доизучить, но мок-интервьюеры смотрят на то, что интересно им, и могут упустить часть вещей. Я также провожу их в рамках моих менторинг сессий =)
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥25👍5
Опыт собеседования на позицию Senior Staff Data Engineer 🤔
Недавно я принял участие в собеседовании на должность Senior Staff Data Engineer (Data Architecture) в компанию из сферы foodtech. Хотя я и не ищу совсем работу, мне было интересно пощупать немецкий рынок и попробовать себя в интервью на позицию Staff DE и роль была связана с дата моделированием.
Первоначальный контакт с рекрутером ☎️
Рекрутер нашёл меня в LinkedIn был краткий 10-15 минутный звонок. Обсуждали вакансию, мои ожидания, текущее состояние компании, мои интересы к роли и следующие шаги.
Собеседование с hiring manager😃
Следующим этапом было интервью с непосредственным менеджером, которое было смесью проектного и подходящего интервью. Обсуждали весь скоуп по дата инженерии, особое внимание уделили end-to-end и CI/CD процессам, где у меня меньше опыта и я часто работаю с нестандартными решениями. На Q&A довольно откровенно отвечали о текущих болячках и что нужно улучшать.
Coding👩💻
Техническое интервью по программированию было нестандартным и ориентированным на Data Engineering. За 90 минут предполагалось решить 2-3 задачи (batch, SQL, streaming). Собесил Staff DE.
Batch-задача - написать ETL на псевдо-Spark, включая базовые вопросы о partition pruning, partitioning и обработке dataframe.
SQL-задача - классика около-FAANG – создание модели данных и написание инкрементного заполнения. Как SQL-гик я постоянно докидывал corner case :D.
Streaming решили не делать поскольку оставалось 25 минут, и была расширенная Q&A сессия, где я поспрашивал про работу стаффом, организацию внутри команды, компании, и процессам.
СисДиз😵
Интервью по системному дизайну было довольно стандартным. Было 2 интервьюера - Senior Staff DE и Staff SWE (или наоборот :D). Задача была связана с данными, но не требовала серьёзного масштабирования после анализа входных параметров.
На детальной части обсуждали Kafka, топики и схемы. А затем мы похоливарили с интервьюерам, так как они вели к одному решению, но оно мне не нравилось :D. Q&A было 5 минутным, так что просто спросил про работу стаффом в компании.
Обратная связь №1 👍
Рекрутер сделал фидбек по интервью.
По кодингу был strong go😂 , но был сделан акцент на то, что я усложнил SQL-часть, постоянно увеличивая сложность задачи.
По системному дизайну дали фидбек как улучшить процесс в целом.
По менеджерскому интервью было отмечено отсутствие глубины знаний CI/CD, частично из-за использования DBT Cloud, а не DBT Core.
Поведенческое интервью👋
Финальный этап - интервью с VP of Data. Сначала он 20 минут рассказывал о компании, затем задавал поведенческие вопросы и обсуждал мои вопросы о работе в компании, практиках и сочетании data vault и data mesh. Почти не было bullshit, а были довольно четкие ответы с неплохой глубиной, но послевкусие было как будто бы не случилось фита.
Обратная связь №2 🚩
Перед второй сессией обратной связи мне уже сообщили об отказе, так что я был готов👨🦳
В качестве фидбека сказали, что решение принято уже на совместном обсуждении
Как плюсы - сильная ориентация на данные и аналитический подход, ориентация на клиента, предпочтение долгосрочного и стратегического подхода.
Отказ был обусловлен рядом факторов: неясные цели в отношении роли IC, не показал Learning never stops принцип, сомнения в том что буду адаптировн к быстроизменчивым средам.
Выводы⚡️
Оценка рекрутеру - 5, компании и процессу интервью - 4, себе - 3+.
Что надо улучшить: начать уже готовиться к behaivoral interview, улучшить знания по сис дизу и английский с точки зрения коммуникации
А что по деньгам💰
Компания была тир2 и была ожидаемой для вилки стаффа. Сам вилка, по моим ощущениям, это 105-130k EUR base + 10-50k EUR bonus/RSU.
Недавно я принял участие в собеседовании на должность Senior Staff Data Engineer (Data Architecture) в компанию из сферы foodtech. Хотя я и не ищу совсем работу, мне было интересно пощупать немецкий рынок и попробовать себя в интервью на позицию Staff DE и роль была связана с дата моделированием.
Первоначальный контакт с рекрутером ☎️
Рекрутер нашёл меня в LinkedIn был краткий 10-15 минутный звонок. Обсуждали вакансию, мои ожидания, текущее состояние компании, мои интересы к роли и следующие шаги.
Собеседование с hiring manager
Следующим этапом было интервью с непосредственным менеджером, которое было смесью проектного и подходящего интервью. Обсуждали весь скоуп по дата инженерии, особое внимание уделили end-to-end и CI/CD процессам, где у меня меньше опыта и я часто работаю с нестандартными решениями. На Q&A довольно откровенно отвечали о текущих болячках и что нужно улучшать.
Coding
Техническое интервью по программированию было нестандартным и ориентированным на Data Engineering. За 90 минут предполагалось решить 2-3 задачи (batch, SQL, streaming). Собесил Staff DE.
Batch-задача - написать ETL на псевдо-Spark, включая базовые вопросы о partition pruning, partitioning и обработке dataframe.
SQL-задача - классика около-FAANG – создание модели данных и написание инкрементного заполнения. Как SQL-гик я постоянно докидывал corner case :D.
Streaming решили не делать поскольку оставалось 25 минут, и была расширенная Q&A сессия, где я поспрашивал про работу стаффом, организацию внутри команды, компании, и процессам.
СисДиз
Интервью по системному дизайну было довольно стандартным. Было 2 интервьюера - Senior Staff DE и Staff SWE (или наоборот :D). Задача была связана с данными, но не требовала серьёзного масштабирования после анализа входных параметров.
На детальной части обсуждали Kafka, топики и схемы. А затем мы похоливарили с интервьюерам, так как они вели к одному решению, но оно мне не нравилось :D. Q&A было 5 минутным, так что просто спросил про работу стаффом в компании.
Обратная связь №1 👍
Рекрутер сделал фидбек по интервью.
По кодингу был strong go
По системному дизайну дали фидбек как улучшить процесс в целом.
По менеджерскому интервью было отмечено отсутствие глубины знаний CI/CD, частично из-за использования DBT Cloud, а не DBT Core.
Поведенческое интервью
Финальный этап - интервью с VP of Data. Сначала он 20 минут рассказывал о компании, затем задавал поведенческие вопросы и обсуждал мои вопросы о работе в компании, практиках и сочетании data vault и data mesh. Почти не было bullshit, а были довольно четкие ответы с неплохой глубиной, но послевкусие было как будто бы не случилось фита.
Обратная связь №2 🚩
Перед второй сессией обратной связи мне уже сообщили об отказе, так что я был готов
В качестве фидбека сказали, что решение принято уже на совместном обсуждении
Как плюсы - сильная ориентация на данные и аналитический подход, ориентация на клиента, предпочтение долгосрочного и стратегического подхода.
Отказ был обусловлен рядом факторов: неясные цели в отношении роли IC, не показал Learning never stops принцип, сомнения в том что буду адаптировн к быстроизменчивым средам.
Выводы
Оценка рекрутеру - 5, компании и процессу интервью - 4, себе - 3+.
Что надо улучшить: начать уже готовиться к behaivoral interview, улучшить знания по сис дизу и английский с точки зрения коммуникации
А что по деньгам
Компания была тир2 и была ожидаемой для вилки стаффа. Сам вилка, по моим ощущениям, это 105-130k EUR base + 10-50k EUR bonus/RSU.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥31👍8
SQL и CASE WHEN
CASE - знакомое многим выражение SQL для условий. Я хотел бы показать варианты использования CASE WHEN, о которых может быть не известно
Все примеры из public datasets в Bigquery. В основном будем использовать таблицу заказов для примеров. То, что можно так сделать с точки зрения синтаксиса не значит, что так стоит делать, всегда думайте о поддерживаемости и читабельности
CASE в агрегатной функции
Нужно вывести для каждого пользователя последние даты отмененного, возвращенного и завершенного заказов.
CASE в Order by оконной функции
Для каждого пользователя вывести последнюю дату отменненого заказа, а если у него не было отменненых заказов, последнюю дату возвращенного заказа
CASE в джоинах
Убедиться что дата активности заказа не произошла на выходной день
CASE в QUALIFY
Последний пример более искусственный, но показывает пример применения в QUALIFY
CASE - знакомое многим выражение SQL для условий. Я хотел бы показать варианты использования CASE WHEN, о которых может быть не известно
Все примеры из public datasets в Bigquery. В основном будем использовать таблицу заказов для примеров. То, что можно так сделать с точки зрения синтаксиса не значит, что так стоит делать, всегда думайте о поддерживаемости и читабельности
CASE в агрегатной функции
Нужно вывести для каждого пользователя последние даты отмененного, возвращенного и завершенного заказов.
SELECT user_id,
MAX(case when status = 'Cancelled' THEN created_at END)
AS last_cancelled_dt,
MAX(case when status = 'Returned' THEN returned_at END)
AS last_returned_dt,
MAX(case when status = 'Complete' THEN delivered_at END)
AS last_complted_at
FROM bigquery-public-data.thelook_ecommerce.orders
GROUP BY user_id
CASE в Order by оконной функции
Для каждого пользователя вывести последнюю дату отменненого заказа, а если у него не было отменненых заказов, последнюю дату возвращенного заказа
SELECT distinct user_id,
LAST_VALUE(CASE WHEN status = 'Cancelled' THEN created_at
WHEN Status = 'Returned' THEN returned_at END)
OVER
(PARTITION BY user_id
ORDER BY
CASE WHEN status = 'Cancelled' THEN 2
WHEN status = 'Returned' THEN 1
ELSE 0 END,
CASE WHEN status = 'Cancelled' THEN created_at
WHEN Status = 'Returned' THEN returned_at
END
ROWS BETWEEN UNBOUNDED PRECEDING
AND UNBOUNDED FOLLOWING )
FROM bigquery-public-data.thelook_ecommerce.orders
CASE в джоинах
Убедиться что дата активности заказа не произошла на выходной день
SELECT ord.user_id, count(distinct ord.order_id)
FROM `bigquery-public-data.thelook_ecommerce.orders` ord
LEFT JOIN `bigquery-public-data.ml_datasets.holidays_and_events_for_forecasting` h
ON h.region = 'DE'
AND CASE WHEN status = 'Cancelled' THEN DATE(created_at)
WHEN status = 'Returned' THEN DATE(returned_at)
WHEN status = 'Complete' THEN DATE(delivered_at)
END = h.primary_date
WHERE h.primary_date IS NOT NULL
GROUP by ord.user_i
CASE в QUALIFY
Последний пример более искусственный, но показывает пример применения в QUALIFY
SELECT distinct user_id
FROM `bigquery-public-data.thelook_ecommerce.orders`
QUALIFY
CASE WHEN user_id > 100
THEN
SUM(num_of_item *
CASE WHEN status = 'Complete' THEN 1
WHEN status = 'Returned' THEN -1
ELSE 0
END)
OVER (PARTITION BY user_id
ORDER BY created_at
ROWS BETWEEN UNBOUNDED PRECEDING
AND UNBOUNDED FOLLOWING)
ELSE
SUM(num_of_item *
CASE WHEN status = 'Complete' THEN 2
WHEN status = 'Returned' THEN -0.5
ELSE 0
END)
OVER (PARTITION BY user_id
ORDER BY created_at
ROWS BETWEEN UNBOUNDED PRECEDING
AND UNBOUNDED FOLLOWING)
END > 2
👍16🤯2
Вышла книга Grokking Concurrency.
Автор книги - Senior Data Engineer в Spotify и ведет https://luminousmen.com (думаю, многие видели этот блог)
Я просмотрел содержание книги (благо есть manning подписочка) и однозначно добавлю ее в reading list на этот год, так как планирую подтянуть свой теорикрафт по concurrency и distributed системам.
Книга кажется неплохим введением для этого, чтобы потом вернуться к зубодробительным томам по CS. Примеры на питоне, и покрываются такие темы как процессы, треды, тред пулы, multitasking, semaphores, non-blocking i/o, coroutines, ...
Для суровых дата инженеров может быть повторением того, что знают, а нам, склщикамголовного мозга, будет введением в тематику.
Автор книги - Senior Data Engineer в Spotify и ведет https://luminousmen.com (думаю, многие видели этот блог)
Я просмотрел содержание книги (благо есть manning подписочка) и однозначно добавлю ее в reading list на этот год, так как планирую подтянуть свой теорикрафт по concurrency и distributed системам.
Книга кажется неплохим введением для этого, чтобы потом вернуться к зубодробительным томам по CS. Примеры на питоне, и покрываются такие темы как процессы, треды, тред пулы, multitasking, semaphores, non-blocking i/o, coroutines, ...
Для суровых дата инженеров может быть повторением того, что знают, а нам, склщикам
Blog | iamluminousmen
Blog | luminousmen — Python, Data Engineering & ML
helping robots conquer the earth and trying not to increase entropy using Python, Data Engineering, Machine Learning
👍20
Forwarded from L̶u̵m̶i̵n̷o̴u̶s̶m̶e̵n̵B̶l̵o̵g̵
Hello wonderful people!
I’m thrilled to announce that my new book, “Grokking Concurrency,” has officially hit the shelves!
This book dives deep into the concept of concurrency, making it accessible and practical for software engineers, computer science enthusiasts and data engineers, I believe this book can be valuable to many. It's packed with insights, real-world examples, and practical tips. And, most importantly, with cool visualizations. You can find it here: https://www.manning.com/books/grokking-concurrency
I could really use your support in spreading the word! You can support me by:
1. spreading the news on social media
2. writing reviews (on amazon, goodreads or whatever people use nowadays)
3. mentioning to your colleagues, neighbors, and pets
Thank you so much for your support!
I’m thrilled to announce that my new book, “Grokking Concurrency,” has officially hit the shelves!
This book dives deep into the concept of concurrency, making it accessible and practical for software engineers, computer science enthusiasts and data engineers, I believe this book can be valuable to many. It's packed with insights, real-world examples, and practical tips. And, most importantly, with cool visualizations. You can find it here: https://www.manning.com/books/grokking-concurrency
I could really use your support in spreading the word! You can support me by:
1. spreading the news on social media
2. writing reviews (on amazon, goodreads or whatever people use nowadays)
3. mentioning to your colleagues, neighbors, and pets
Thank you so much for your support!
👍6
Database in 2023 A Year in Review
Обзор 2023 от Andy Pavlo. https://ottertune.com/blog/2023-databases-retrospective
- Векторные базы данных (ну или векторные поисковые движки) сильно в тренде в DS кругах. Я лично о них услышал в декабре, но в 2024 потрачу время на изучение. В статье сравнивают vector database и relational databases - https://www.youtube.com/watch?v=jDhVEjgCHGk&t=3s
- Обзор SQL: 2023 стандарта и SQL/PGQ. Property Graph Queries (SQL/PGQ): выглядят офигенно. Надо бы сделать еще 1 попытку прочитать современный стандарт 🙂
- Проблемы MariaDB. Мы только недавно добавили интеграцию с MariaDB на проекте, но до корпоратов это докатится года через 3-4, если будет поворо обратно к MySQL
- Рынок VS-финансирования СУБД проектов уменьшился, но есть интересные проекты в списке. Также Andy написал, что большему числу студентов потребовалась помощь в поиске internship.
- В конце обсуждается американская специфика о Larry Ellison, Elon Musk, и их взаимотношения. Рад, что Oracle снова на коне. Oracle как СУБД для меня точно в топ-3 по удобству и широты использования.
Обзор 2023 от Andy Pavlo. https://ottertune.com/blog/2023-databases-retrospective
- Векторные базы данных (ну или векторные поисковые движки) сильно в тренде в DS кругах. Я лично о них услышал в декабре, но в 2024 потрачу время на изучение. В статье сравнивают vector database и relational databases - https://www.youtube.com/watch?v=jDhVEjgCHGk&t=3s
- Обзор SQL: 2023 стандарта и SQL/PGQ. Property Graph Queries (SQL/PGQ): выглядят офигенно. Надо бы сделать еще 1 попытку прочитать современный стандарт 🙂
- Проблемы MariaDB. Мы только недавно добавили интеграцию с MariaDB на проекте, но до корпоратов это докатится года через 3-4, если будет поворо обратно к MySQL
- Рынок VS-финансирования СУБД проектов уменьшился, но есть интересные проекты в списке. Также Andy написал, что большему числу студентов потребовалась помощь в поиске internship.
- В конце обсуждается американская специфика о Larry Ellison, Elon Musk, и их взаимотношения. Рад, что Oracle снова на коне. Oracle как СУБД для меня точно в топ-3 по удобству и широты использования.
Andy Pavlo - Carnegie Mellon University
Databases in 2023: A Year in Review
Andy recounts the rise of vector databases to SQL:2023 to MariaDB troubles and the FAA outage in 2023.
👍10
#никчитает
Обзор на Analytics Engineering with SQL and dbt
Сегодня узнал о выходе книги Analytics Engineering в O'Reilly with SQL and dbt - https://www.oreilly.com/library/view/analytics-engineering-with/9781098142377/
Автор был бы не автором, если бы ее уже не прочитал =)
Пройдемся по главам
1. Analytics Engineering. Обзорная глава про историю, появление и кто такие эти analytics engineers. Корни AE, откуда взялся BI, как в Cloud Era появились решения, демократизирующие инструментарий. Рассказ про жизненный цикл дата аналитики (-> Определение проблемы -> Моделирование данных -> Внедрение данных и трансформация -> Хранение данных и структурирование -> Визуализация данных -> DQ, мониторинг, тестированик и документировние ).
Обсуждают роль и ответственность AE, базовое обсуждение Data mesh и Data product, переход от легаси BI/ETL систем (с visual-coding etl и процедурными расширениями) в modern data stack (с visual-coding etl и процедурными расширениями, прим. Nik🙂 )
2. Data Modeling. Глава про моделирование данных. КМД, ЛМД и ФМД, нормализацию (да-да, нормальные формы в 2к24😂 ), базовое ведение в схему звезда/снежинка с упоминанием Кимбала и Инмона, и невнятный параграф про Data Vault 😡 . Обсуждается переход от монолитного дата моделирования к модульному дата моделировани. В конце вводят Medallion Architecture Pattern. Последнее, это просто Bronze-Silver-Gold layers - https://www.databricks.com/glossary/medallion-architecture
3. SQL For Analytics.🔥 Рассказывают про основы SQL с оконками, join как обычно через диграммы Венна 😺 . Вторая часть - про SQL for Distributed Data Processing, используя DuckDB, Polaris, и FugueSQL 🤯 (новое для меня).
4. Data Transformation with dbt.😃 Основы dbt, причем показывают как запускать только для dbt cloud (никакой core настройки не описано).
5. Dbt Advanced Topics😃 . Кратко обсуждают такие понятия, как материализация, jinja шаблоны, макросы, пакеты и semantic layer.
6. Building An End-to-End Analytics Engineering Use Case👍 . Показывают полноценное "end-to-end" решение от заливки сырых данных в BigQuery из MySQL до финальной витрины данных и ad-hoc аналитики. 😎 Треть главы уделена тому, как делать архитектуру дата решения (как определяем бизнес-процесс, понимаем, какие данные нужны, моделируем). Сначала проектируем - потом кодим. 🔥
⚡️ Книга оставила смешанное впечатление. В плюс занесу 1 и 6 главу. В главе 2 про дата моделирование получилась какая-то каша терминов, и я не увидел какой-то раскрытости. 3 глава представляет собой базовое введение в SQL, и добавление про DuckDB, которое дальше вообще никак не используется 4 и 5 главы про dbt, уступают dbt мануалам.
Из минусов таже отмечу отсутствие Further Reading или доп материалов.
Читая книгу, я словил дежавю, как будто это мини-курс Analytics Engineer (Аналитик DWH) на ОТУС времен 2022 годов. Разрозненный материал, с разными доменными примерами и технологиями от главы к главе, который надо собрать как-то у себя в голове.
🙆 Оценка 3/5. Подойдет, как доп. материал к dbt курсам, если у вас есть подписка O'Reilly.
Обзор на Analytics Engineering with SQL and dbt
Сегодня узнал о выходе книги Analytics Engineering в O'Reilly with SQL and dbt - https://www.oreilly.com/library/view/analytics-engineering-with/9781098142377/
Автор был бы не автором, если бы ее уже не прочитал =)
Пройдемся по главам
1. Analytics Engineering. Обзорная глава про историю, появление и кто такие эти analytics engineers. Корни AE, откуда взялся BI, как в Cloud Era появились решения, демократизирующие инструментарий. Рассказ про жизненный цикл дата аналитики (-> Определение проблемы -> Моделирование данных -> Внедрение данных и трансформация -> Хранение данных и структурирование -> Визуализация данных -> DQ, мониторинг, тестированик и документировние ).
Обсуждают роль и ответственность AE, базовое обсуждение Data mesh и Data product, переход от легаси BI/ETL систем (с visual-coding etl и процедурными расширениями) в modern data stack (с visual-coding etl и процедурными расширениями, прим. Nik
2. Data Modeling. Глава про моделирование данных. КМД, ЛМД и ФМД, нормализацию (да-да, нормальные формы в 2к24
3. SQL For Analytics.
4. Data Transformation with dbt.
5. Dbt Advanced Topics
6. Building An End-to-End Analytics Engineering Use Case
Из минусов таже отмечу отсутствие Further Reading или доп материалов.
Читая книгу, я словил дежавю, как будто это мини-курс Analytics Engineer (Аналитик DWH) на ОТУС времен 2022 годов. Разрозненный материал, с разными доменными примерами и технологиями от главы к главе, который надо собрать как-то у себя в голове.
Please open Telegram to view this post
VIEW IN TELEGRAM
O’Reilly Online Learning
Analytics Engineering with SQL and dbt
With the shift from data warehouses to data lakes, data now lands in repositories before it's been transformed, enabling engineers to model raw data into clean, well-defined... - Selection from Analytics Engineering with SQL and dbt [Book]
✍12🔥4👍3❤1
#datadesign
WAP Pattern
Знаете ли вы, что такое WAP (Write - Audit - Publish. ) паттерн в дата инженерии? Скорее всего, многие из вас им уже пользуются!🤔
Я объясню это на коленке, желающим детальных кишочек -> в ссылки снизу. 📌
Представим, я инженер в компании Colt👍 , и мы занимаемся доставкой еды. Моя зона ответственности - end-to-end решение для ежедневной отчетности в разрезе городов (прибыль, количество доставок, средний чек, среднее время доставки, ...).
У меня есть проблема с источником данных по возвратам денег (допустим кому-то что-то не доставили, и вам возвращают денег на счет). Он обновляется непостоянно, так еще и иногда там часто бывают ошибки в данных.🆗
Когда менеджеры смотрят мой отчет, они недовольны тем, что цифры, которые они видели вчера резко меняются после обновлений. Они не верят нашим данным, поэтому продолжают использовать свои проверенные эксели. А я не получаю свой заслуженный promotion.😂
Что же делать? Мы можем добавить тесты!👍 Но возникает дилемма - скорость доставки vs качество. Если взять dbt как инструмент, то базовая имплементация тестов выглядит следующим образом -> прогнали модель, запустили тест над моделью, если тест упал, анализируем. Но если это уже презентационный слой, то конечные пользователи уже увидят эти данные. Мы можем настроить алертинг, но кто будет в него смотреть.👨🦳
Поэтому в случае критичных отчетов / дата продуктов, можно применить подход WAP.
- Write. Записываем данные в stage таблицу / объект
- Audit. Проверяем качество и полноту данных на уровне stage таблицы. Есть проблема -> автоматический алерт команде и on-call инженер с радостью разбирается😮 (можно еще больше автоматизировать в случае повторяемых случаев, например сразу с ноги выбивать дверь к коллегам с источника писать письмо / заводить инцидент ).
- Publish. Если все тесты успешно прошли, кладем в Publish слой. Это можно делать как логически (синонимы, линки на файловой системы, переопределение view, alter/modify partition, ...) или физически (ETL).
Есть еще один use-case применения WAP паттерна. Далеко не все системы поддерживают ACID транзакции, а те, которые поддерживают, не всегда готовы часами ждать тяжелых расчетов. Для организации консистентности (ну или чаще уменьшения неконсистентного промежутка по времени) вы можете подготовить свои 20+ таблиц в стейдже, а потом переключить их одновременно в презентационном слое.🍷
Недостатки? Данные будут устаревшие, поэтому нам надо быстро сообщить об этом пользователям, чтобы они не сообщили об этом нам!🙂
Кроме этого, далеко не всегда причина может быть устранена быстро, но что с этим делать, обсудим в следующих постах.😵
Cсылочки 💻
- Верхнеуровневое обсуждение - https://lakefs.io/blog/data-engineering-patterns-write-audit-publish/
- Пример имплементации - https://lakefs.io/blog/write-audit-publish-with-lakefs/ , продолжение - https://lakefs.io/blog/write-audit-publish-with-lakefs/ и https://dagster.io/blog/python-write-audit-publish
- Видео - https://www.youtube.com/watch?v=fXHdeBnpXrg (в целом хорошее видео, сам WAP pattern с 16 минуты)
- Презентация для Iceberg - https://www.dremio.com/wp-content/uploads/2022/05/Sam-Redai-The-Write-Audit-Publish-Pattern-via-Apache-Iceberg.pdf
WAP Pattern
Знаете ли вы, что такое WAP (Write - Audit - Publish. ) паттерн в дата инженерии? Скорее всего, многие из вас им уже пользуются!
Я объясню это на коленке, желающим детальных кишочек -> в ссылки снизу. 📌
Представим, я инженер в компании Colt
У меня есть проблема с источником данных по возвратам денег (допустим кому-то что-то не доставили, и вам возвращают денег на счет). Он обновляется непостоянно, так еще и иногда там часто бывают ошибки в данных.
Когда менеджеры смотрят мой отчет, они недовольны тем, что цифры, которые они видели вчера резко меняются после обновлений. Они не верят нашим данным, поэтому продолжают использовать свои проверенные эксели. А я не получаю свой заслуженный promotion.
Что же делать? Мы можем добавить тесты!
Поэтому в случае критичных отчетов / дата продуктов, можно применить подход WAP.
- Write. Записываем данные в stage таблицу / объект
- Audit. Проверяем качество и полноту данных на уровне stage таблицы. Есть проблема -> автоматический алерт команде и on-call инженер с радостью разбирается
- Publish. Если все тесты успешно прошли, кладем в Publish слой. Это можно делать как логически (синонимы, линки на файловой системы, переопределение view, alter/modify partition, ...) или физически (ETL).
Есть еще один use-case применения WAP паттерна. Далеко не все системы поддерживают ACID транзакции, а те, которые поддерживают, не всегда готовы часами ждать тяжелых расчетов. Для организации консистентности (ну или чаще уменьшения неконсистентного промежутка по времени) вы можете подготовить свои 20+ таблиц в стейдже, а потом переключить их одновременно в презентационном слое.
Недостатки? Данные будут устаревшие, поэтому нам надо быстро сообщить об этом пользователям, чтобы они не сообщили об этом нам!
Кроме этого, далеко не всегда причина может быть устранена быстро, но что с этим делать, обсудим в следующих постах.
Cсылочки 💻
- Верхнеуровневое обсуждение - https://lakefs.io/blog/data-engineering-patterns-write-audit-publish/
- Пример имплементации - https://lakefs.io/blog/write-audit-publish-with-lakefs/ , продолжение - https://lakefs.io/blog/write-audit-publish-with-lakefs/ и https://dagster.io/blog/python-write-audit-publish
- Видео - https://www.youtube.com/watch?v=fXHdeBnpXrg (в целом хорошее видео, сам WAP pattern с 16 минуты)
- Презентация для Iceberg - https://www.dremio.com/wp-content/uploads/2022/05/Sam-Redai-The-Write-Audit-Publish-Pattern-via-Apache-Iceberg.pdf
Please open Telegram to view this post
VIEW IN TELEGRAM
lakeFS
Data Engineering Patterns: Write-Audit-Publish (WAP)
This blog explains the concept of Write-Audit-Publish, which is a pattern in data engineering to enforce data quality in data pipelines.
🔥9👍3❤2
Залетел на подкаст / разговоры в FAANGTalk кекспертом эскпертом по DE 😂 на выпуск про дата инженерию.
Главным спикером был Vladimir Elfimov и видео стоит послушать ради него и презентации.
Я врывался пару раз с крайне важными вопросами, по типу мертв ли Hadoop👋 и является ли Excel Reverse-ETL или ML системой 🤯
Обсудили такие темы:
- История развития Data Engineering
- «Большие данные» и его отличие от «средних данных».
- Инструменты Data Engineering, и отличия от Data Science и Data Analytics
- C-level в сфере Data Engineering (CDO, CIO, CAO).
Немного затронули:
- Обработка данных. Отличия между pull и push системами, batch и streaming обработкой данных
- Data Warehouse, Data Marts, Data Lake, Data Platform, Data Mesh и Data LakeHouse
- Планирование дата-архитектуры и сложности, связанные с этим процессом
Само видео: https://www.youtube.com/watch?v=VyUqrYfj_yY
Главным спикером был Vladimir Elfimov и видео стоит послушать ради него и презентации.
Я врывался пару раз с крайне важными вопросами, по типу мертв ли Hadoop
Обсудили такие темы:
- История развития Data Engineering
- «Большие данные» и его отличие от «средних данных».
- Инструменты Data Engineering, и отличия от Data Science и Data Analytics
- C-level в сфере Data Engineering (CDO, CIO, CAO).
Немного затронули:
- Обработка данных. Отличия между pull и push системами, batch и streaming обработкой данных
- Data Warehouse, Data Marts, Data Lake, Data Platform, Data Mesh и Data LakeHouse
- Планирование дата-архитектуры и сложности, связанные с этим процессом
Само видео: https://www.youtube.com/watch?v=VyUqrYfj_yY
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
#FaangTalk 51 - Data Engineering
Канал с анонсами https://news.1rj.ru/str/faangtalk_news
Чат по подготовке к интервью: https://news.1rj.ru/str/faangtalk
В выпуске обсудим что такое Data Engineering
- История развития Data Engineering
- «Большие данные» и его отличие от «средних данных».
- Инструменты Data Engineering…
Чат по подготовке к интервью: https://news.1rj.ru/str/faangtalk
В выпуске обсудим что такое Data Engineering
- История развития Data Engineering
- «Большие данные» и его отличие от «средних данных».
- Инструменты Data Engineering…
🔥28❤3👍2❤🔥1
Forwarded from FaangTalk Channel (Dima V)
Во вторник, 12 марта в 19:00 GMT+0 разбираем как устроены интервью для Дата инженеров
В гостях - Ник, автор канала @analytics_engineer
Кликайте Notify me чтобы не пропустить 😎 и приходите задавать вопросы в комменты!
Ссылка на стрим
https://youtube.com/live/vWYbsbnJphI?feature=share
В гостях - Ник, автор канала @analytics_engineer
Кликайте Notify me чтобы не пропустить 😎 и приходите задавать вопросы в комменты!
Ссылка на стрим
https://youtube.com/live/vWYbsbnJphI?feature=share
YouTube
#FaangTalk 54 Как устроены Data engineering интервью
Канал с анонсами https://news.1rj.ru/str/faangtalk_news
Чат по подготовке к интервью: https://news.1rj.ru/str/faangtalk
В гостях Ник
https://news.1rj.ru/str/analytics_engineer
Чат по подготовке к интервью: https://news.1rj.ru/str/faangtalk
В гостях Ник
https://news.1rj.ru/str/analytics_engineer
🔥20👍9❤3
Запись прошедшего разговора - https://www.youtube.com/watch?v=sqLCAjc9DYQ
Получилось по ощущениям интересно, но микрофон немного подкачал (Я зафейлил с настройкого основного)
Слайды - https://link.excalidraw.com/p/readonly/JZ3p956Nz1zqNdJ0hmFg ( В Safari у меня почему-то не ренедерятся, в Google Chrome норм)
Получилось по ощущениям интересно, но микрофон немного подкачал (Я зафейлил с настройкого основного)
Слайды - https://link.excalidraw.com/p/readonly/JZ3p956Nz1zqNdJ0hmFg ( В Safari у меня почему-то не ренедерятся, в Google Chrome норм)
YouTube
#FaangTalk 54 Как устроены Data engineering интервью
Канал с анонсами https://news.1rj.ru/str/faangtalk_news
Чат по подготовке к интервью: https://news.1rj.ru/str/faangtalk
В гостях Ник
https://news.1rj.ru/str/analytics_engineer
Chapters
00:00 Вступление
00:56 Введение в дата инжиниринг интервью
09:10 Различия между BI Engineer и Software…
Чат по подготовке к интервью: https://news.1rj.ru/str/faangtalk
В гостях Ник
https://news.1rj.ru/str/analytics_engineer
Chapters
00:00 Вступление
00:56 Введение в дата инжиниринг интервью
09:10 Различия между BI Engineer и Software…
👍19🔥11❤3
15 ноября старт DE буткемпа от американского инфлюенсера Zach Wilson
https://www.youtube.com/watch?v=myhe0LXpCeo
Будет интересно сравнить с DE Zoomcamp
https://www.youtube.com/watch?v=myhe0LXpCeo
Будет интересно сравнить с DE Zoomcamp
YouTube
6-week Free Data Engineering Boot Camp Launch Video | DataExpert.io
This data engineering boot camp will be amazing!
We'll be publishing a new video almost every day from November 15th, 2024 to December 31st, 2024!
Learn actual cloud stuff directly here: https://www.dataexpert.io/LAUNCH20
Join the Discord community! …
We'll be publishing a new video almost every day from November 15th, 2024 to December 31st, 2024!
Learn actual cloud stuff directly here: https://www.dataexpert.io/LAUNCH20
Join the Discord community! …
👍4🔥4
Обнаружил интересный пост - https://javisantana.com/2024/11/30/learnings-after-4-years-data-eng.html
90% утверждений резонируют с моим опытом
Перейти с одного решения на другое для 99% задач потребует неделю знакомства с инструментом и изучения архитектуры нового решения😎 . Есть небольшое число задач, требуемое максимальной оптимизации и знания кишков, но такая оптимизация является внутренним решением с структурой данных, придуманной под него и разрабатывается итерационно
Загрузка данных в базу данных / файловую систему - то место, которое часто можно ускорить за небольшие усилия. Особенно, если у вас какое-то самописное решение по вставке данных.✨
Как фанат WAP паттерна, полностью поддерживаю такое. У меня были разговоры с принципал инженерами, почему у нас нет покрытия юнит тестами, и зачем нам runtime проверки. Считаю, что технические проверки должны быть у каждого ETL при загрузке (а в идеале и бизнес-проверки в том числе). На паре проектов у меня было, что косты dq были почти такие же, как косты ETL загрузок.
Ну это прямо база. Один раз я решал задачу переписывания загрузки сотен мегабайт в неделю (!!!) через Apache Spark и Hadoop. Задача оптимизации заключалась сделать так, чтобы нетворк и shuffle был минимален и все считалось на одной ноде😂 А выбрать другую архитектуру нельзя было, так как архитекторы банка решили, что все витрины должны считаться в хадупе 👋
В экстремальном случае уже на уровне дата продукта / витрины появляется схема и разбор полустуктурированных данных произойдет на этапе подготовки данных. Так что парсинг JSON потребуется все равно =)
90% утверждений резонируют с моим опытом
People focus on learning the tools, which is good, but they forget about principles.
Перейти с одного решения на другое для 99% задач потребует неделю знакомства с инструментом и изучения архитектуры нового решения
Ingestion is 80% of the job but usually it’s not even monitored.
Загрузка данных в базу данных / файловую систему - то место, которое часто можно ускорить за небольшие усилия. Особенно, если у вас какое-то самописное решение по вставке данных.
Data quality is like unit testing but in production.
Как фанат WAP паттерна, полностью поддерживаю такое. У меня были разговоры с принципал инженерами, почему у нас нет покрытия юнит тестами, и зачем нам runtime проверки. Считаю, что технические проверки должны быть у каждого ETL при загрузке (а в идеале и бизнес-проверки в том числе). На паре проектов у меня было, что косты dq были почти такие же, как косты ETL загрузок.
Most companies just need basic bash / make knowledge, a single instance SQL processing engine (DuckDB, CHDB or a few python noscripts), a distributed file system, git and a developer workflow (CI/CD).
Ну это прямо база. Один раз я решал задачу переписывания загрузки сотен мегабайт в неделю (!!!) через Apache Spark и Hadoop. Задача оптимизации заключалась сделать так, чтобы нетворк и shuffle был минимален и все считалось на одной ноде
There is always a schema. You decide on it when you write the data or later when you read it, but at some point, you need to decide attributes and data types for your data
В экстремальном случае уже на уровне дата продукта / витрины появляется схема и разбор полустуктурированных данных произойдет на этапе подготовки данных. Так что парсинг JSON потребуется все равно =)
Please open Telegram to view this post
VIEW IN TELEGRAM
👍19🔥11❤1
Ищем спикеров на наш февральский онлайн митап от modern data stack чатика @dbt_users
Если есть чем поделиться, напишите мне
Если есть чем поделиться, напишите мне
👍1
Forwarded from Nik B
Привет, чатик! 👋
Мы готовим возвращение наших онлайн митапов и планируем первый из них уже в феврале (предварительно).
Ищем спикеров с темами из нашего modern (а иногда уже и не modern) дата-стека!
Особенно будем рады докладам о:
Новинках и трендах в индустрии.
Опыт с SQLMesh, DLT и др в проде.
Инсайтах и практиках в области DataOps, DQ
.
Если у вас есть, чем поделиться, и вы хотите выступить — напишите мне! @nikbeesti
Мы готовим возвращение наших онлайн митапов и планируем первый из них уже в феврале (предварительно).
Ищем спикеров с темами из нашего modern (а иногда уже и не modern) дата-стека!
Особенно будем рады докладам о:
Новинках и трендах в индустрии.
Опыт с SQLMesh, DLT и др в проде.
Инсайтах и практиках в области DataOps, DQ
.
Если у вас есть, чем поделиться, и вы хотите выступить — напишите мне! @nikbeesti
🔥14👍2
Сделаю мини-апдейт.
Безработный с 31 декабря😩
Сегодня мой крайний вечер в Берлине и Германии🇩🇪
Полтора года в Германии были забавные, но разгребать еще долго (привет налоговая декларация 2024, abmeldung и все остальное!).
Через 3 года около-менеджмента (все-таки я даже код на скале писал иногда👨⚕️ ) возвращаюсь в IC и уезжаю из ЕС через пару дней (так то не покидал границы ес почти 3 года 😃 ).
Рефлексию по Германии и Энтерпрайзах думаю сделаю в течение недели-другой
Stay tuned.🙆
Безработный с 31 декабря
Сегодня мой крайний вечер в Берлине и Германии🇩🇪
Полтора года в Германии были забавные, но разгребать еще долго (привет налоговая декларация 2024, abmeldung и все остальное!).
Через 3 года около-менеджмента (все-таки я даже код на скале писал иногда
Рефлексию по Германии и Энтерпрайзах думаю сделаю в течение недели-другой
Stay tuned.
Please open Telegram to view this post
VIEW IN TELEGRAM
🎉25🔥15😱15👍7🫡2🤝1
Сегодня первый день на работе, так что можно и не держать интригу ( и так почти все знают кек 😃 ).
Переехал я в Лондон🇬🇧 по skilled worker визе и сегодня вышел SQL дата инженером в один из биг техов 😺 ( начинается с m, заканчивается на a)
Первое впечатление от Лондона пока более позитивное, чем я ожидал, но посмотрим, что будет, как только я отъеду подальше и будет более долгий коммьют.
Если вы вдруг в Лондоне, пингуйте, попьем кофе 🍺!
Переехал я в Лондон
Первое впечатление от Лондона пока более позитивное, чем я ожидал, но посмотрим, что будет, как только я отъеду подальше и будет более долгий коммьют.
Если вы вдруг в Лондоне, пингуйте, попьем кофе 🍺!
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥60👍17🎉10🤝3❤2👏1
Всем привет! 👋
В январе мы объявляли планы об онлайн-митапе в нашем dbt сообществе!🧐
Я как обычно продолбался со всеми сроками, но мы собрали спикеров и рады объявить, что наш митап пройдет 27 марта
Начало в 19:00 (GMT+3) 🗓
Ссылка на регистрацию - https://inzhenerka.tech/dbt_meetup
Запись будет, как и трансляция на ютуб! 📹
В январе мы объявляли планы об онлайн-митапе в нашем dbt сообществе!
Я как обычно продолбался со всеми сроками, но мы собрали спикеров и рады объявить, что наш митап пройдет 27 марта
Начало в 19:00 (GMT+3) 🗓
Ссылка на регистрацию - https://inzhenerka.tech/dbt_meetup
Запись будет, как и трансляция на ютуб! 📹
Please open Telegram to view this post
VIEW IN TELEGRAM
inzhenerka.tech
dbt & modern data stack Meetup 25 сентября в 19:00 (+3GMT)
25 сентября в 19:00 (+3 GMT) приглашаем на митап, где опытные data-инженеры поделятся инсайтами, реальными кейсами и лучшими практиками работы с dbt и современным data stack.
🔥19❤5👍1
Первые месяцы в бигтехе 🙂
Прошло чуть больше двух месяцев, и можно подвести первые мини-итоги.
Лондон в целом 🇬🇧
Про Лондон сложно сказать что-то особенное. Главное преимущество города — английский язык. Транспорт средний, примерно такой же, как и по остальной Европе. Случаются неожиданные поломки, поездки бывают не всегда комфортными как из-за социального фактора (странные личности), так и физически (жарко, душно, поездки затягиваются).
Дом нашли быстро, но дорого. Однако добираться до офиса оказалось неожиданно быстрее по сравнению с Таллином, Берлином и старой Москвой: 15 минут на метро плюс около 30 минут пешком. Если удаётся поймать маршрутку, общее время сокращается до 30 минут.
Работа👩💻
Первые три недели обычно уходят на онбординг, но у меня этот этап занял две. Онбординговой задачей оказалась продуктовая задача с написанием рекурсивного обхода данных в SQL, где нет поддержки рекурсивных запросов. Помню, пару лет назад в Data Jobs меня уверяли, что таких задач никогда не бывает😃 , а я встречаю уже на третьем месте.
После онбординга я работаю сразу в двух проектах:
Первое — классическая дата-инженерия: загрузка данных, включая spreadsheets😂 , построение модели данных и создание dashboard.
Второе — задачи, сильно связанные с ML и LLM, что для меня новое и имеет значительно более высокий порог входа. Предстоит изучить множество новых вещей: от оценки эффективности моделей до prompt engineering и fine-tuning.
В целом, такой микс активностей оказался оптимальным. Мой прошлый менеджерский опыт научил держать в голове большой контекст и быстро переключаться между задачами. В результате получается одновременно разбираться в внутренней дата-инженерии и осваивать новые, неизвестные направления.
Технологии в бигтехе🧑💻
Это действительно впечатляет. Настолько оптимизированной и масштабно интегрированной экосистемы я ранее не встречал. 80% всех задач закрываются внутренними инструментами сразу, для оставшихся 20% обычно достаточно внутренней гибкости даже с учётом некоторых ограничений.
Главный недостаток состоит в том, что если есть привычка копаться в кишках и разрабатывать платформы, то лучше сразу идти на роль Software Engineer, а не на Data Engineer.
Стек полностью кастомный, но почти всегда можно найти аналог в open-source — иногда близкий, иногда довольно отдалённый.
Не могу не отметить как бустится продуктивность от внутренных LLM с контекстом, который предоставляет ссылки и информацию по запросу, и конечно же пишет готовый код🙂
Внерабочие активности😎
Удалось организовать онлайн-митап по dbt & modern stack, хоть и с некоторыми накладками. Кажется, получилось довольно неплохо. Если ещё не видели, можно посмотреть записи по ссылке на плейлист на YouTube - https://www.youtube.com/watch?v=iLxdRPUWS8k&list=PLC92034l7MRx3NwchXQhKEy82kU7S7FKW&index=1.
Иногда удается выбираться на ODS бранчи и Вастрик Клуб тусовки
Планы на будущее🙆
Основная задача — продержаться как можно дольше👋 , успешно пройти испытательный срок, а затем performance review. Одновременно с этим максимально глубоко изучить внутряк.
Главные направления для улучшения — это коммуникация и планирование. Моя раздолбайская натура не всегда позволяет держать commitment, а это один из ключевых факторов успеха в команде. Коммуникация также требует значительного улучшения, в том числе за счёт развития моего английского языка.
Прошло чуть больше двух месяцев, и можно подвести первые мини-итоги.
Лондон в целом 🇬🇧
Про Лондон сложно сказать что-то особенное. Главное преимущество города — английский язык. Транспорт средний, примерно такой же, как и по остальной Европе. Случаются неожиданные поломки, поездки бывают не всегда комфортными как из-за социального фактора (странные личности), так и физически (жарко, душно, поездки затягиваются).
Дом нашли быстро, но дорого. Однако добираться до офиса оказалось неожиданно быстрее по сравнению с Таллином, Берлином и старой Москвой: 15 минут на метро плюс около 30 минут пешком. Если удаётся поймать маршрутку, общее время сокращается до 30 минут.
Работа
Первые три недели обычно уходят на онбординг, но у меня этот этап занял две. Онбординговой задачей оказалась продуктовая задача с написанием рекурсивного обхода данных в SQL, где нет поддержки рекурсивных запросов. Помню, пару лет назад в Data Jobs меня уверяли, что таких задач никогда не бывает
После онбординга я работаю сразу в двух проектах:
Первое — классическая дата-инженерия: загрузка данных, включая spreadsheets
Второе — задачи, сильно связанные с ML и LLM, что для меня новое и имеет значительно более высокий порог входа. Предстоит изучить множество новых вещей: от оценки эффективности моделей до prompt engineering и fine-tuning.
В целом, такой микс активностей оказался оптимальным. Мой прошлый менеджерский опыт научил держать в голове большой контекст и быстро переключаться между задачами. В результате получается одновременно разбираться в внутренней дата-инженерии и осваивать новые, неизвестные направления.
Технологии в бигтехе🧑💻
Это действительно впечатляет. Настолько оптимизированной и масштабно интегрированной экосистемы я ранее не встречал. 80% всех задач закрываются внутренними инструментами сразу, для оставшихся 20% обычно достаточно внутренней гибкости даже с учётом некоторых ограничений.
Главный недостаток состоит в том, что если есть привычка копаться в кишках и разрабатывать платформы, то лучше сразу идти на роль Software Engineer, а не на Data Engineer.
Стек полностью кастомный, но почти всегда можно найти аналог в open-source — иногда близкий, иногда довольно отдалённый.
Не могу не отметить как бустится продуктивность от внутренных LLM с контекстом, который предоставляет ссылки и информацию по запросу, и конечно же пишет готовый код
Внерабочие активности
Удалось организовать онлайн-митап по dbt & modern stack, хоть и с некоторыми накладками. Кажется, получилось довольно неплохо. Если ещё не видели, можно посмотреть записи по ссылке на плейлист на YouTube - https://www.youtube.com/watch?v=iLxdRPUWS8k&list=PLC92034l7MRx3NwchXQhKEy82kU7S7FKW&index=1.
Иногда удается выбираться на ODS бранчи и Вастрик Клуб тусовки
Планы на будущее
Основная задача — продержаться как можно дольше
Главные направления для улучшения — это коммуникация и планирование. Моя раздолбайская натура не всегда позволяет держать commitment, а это один из ключевых факторов успеха в команде. Коммуникация также требует значительного улучшения, в том числе за счёт развития моего английского языка.
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Данные на максималках: инкрементальные загрузки и partition replacing | Nik B
#dbt #dataanalytics #dataengineering
Автор канала Analytics Engineer в мире данных – https://news.1rj.ru/str/analytics_engineer
Автор канала Analytics Engineer в мире данных – https://news.1rj.ru/str/analytics_engineer
🔥32👍12❤9🥰6
