Data Їнженер

описание

Про дані, інженерію, та все що їх повʼязує 👨‍💻

← к каналу @data_engineer_ua

611

подписчиков

Охват к подписчикам

136,2%

ERR

Реакции к просмотрам

1,72%

286 на 20 постов

Пересылки к просмотрам

0,88%

147

Постов в день

0,0

всего 20

Где отзываются чаще

доля реакций к просмотрам

3 мар.Data modeling починається з кінця ⏪ Моя помилка, коли я був джуном і моделював дані для аналітики — я починав із SQL. Виглядає продуктивно: код пишеться, таблиці зʼявляються, ніби є прогрес. Але часто це закінчується кривою структурою або глухим кутом. Бо моделювання треба будувати у зворотному напрямку. Є три рівні: conceptual → logical → physical. І працюють вони саме в такому порядку. 1️⃣ Conceptual — визначаємо фінальну картину Тут без коду. Ви описуєте: • бізнес-сутності • метрики • виміри • звʼязки Зазвичай це whiteboard і розмова з бізнесом. І головне — не думати, чи є у вас ці дані. Уявіть ідеальний стан. Що ви хочете бачити? Які рішення приймати? Обмеження — це вже наступний крок. 2️⃣ Logical — надаємо форму Коду все ще немає, але зʼявляється структура. Тут допомагають Event (bus) matrix та ERD діаграми. Event matrix показує процеси та виміри — і дає розуміння пріоритетів. ERD допомагає визначити fact/dimension таблиці, grain, ключі та знайти дірки в даних. 3️⃣ Physical — тепер можна писати SQL Тільки зараз — SQL або dbt. Але ви вже: • розумієте бізнес-контекст • знаєте обмеження • бачите use cases Тому цей етап стає майже механічним: код, тести, документація. 💥 І от тоді ви реально будуєте дата моделі, а не просто “пишете SQL”.3,69%
31 дек.Ось і ще один рік променув. Для мене він був значно кращий за минулий. Мені допомогло кілька речей. 1. Я спілкувався із вами. За рік я проконсультував порядка 10 людей з цього каналу, які зверталися з питаннями зросту, кар'єри, дата-інжинірингу та тому подібне. Багато із цих розмов я потім перетворив у пости в LinkedIn, які набули дуже класного фідбеку. 2. Я мав прописані цілі і вів журнал. Я не зробив всіх цілей, і не вів журнал досконально, але це давало мені натхнення рухатися і щось робити. 3. Цілі як процес. Це моє відкриття року. Всі цілі, які я зробив у вигляді процесу, були досягнені. Наприклад, замість «хочу 10К підписників в LinkedIn» була ціль «робити один пост на тиждень». Я пропустив лише один тиждень у квітні, всі інші тижні по 1+ постів. Взагалі послухайте подкаст із James Clear про цілі та їх досягнення — там дуже багато корисного. 4. Consistency > Quality. Це до минулого пункту. Краще сходити в зал на 10 хвилин, аніж пропустити взагалі. І ще одне схоже: Done > Perfect. Треба таку татуху набити 😅 Це про те, що краще зробити хоч якось, а потім покращити, аніж не зробити, тому що «не відповідає моїм вимогам якості». 5. Робота — не головне. Постійно про це собі нагадую. А потім приходять рахунки і знову за старе 😅 Коротше, не забуваємо про стосунки, родину, здоров'я і всі інші важливі речі. Якось так. А який у вас був рік?3,11%
8 янв.🔥 Як швидко зробити dummy-таблицю в чистому SQL? Використовуйте VALUES. Памʼятаєте момент, коли потрібно швидко перевірити якусь ідею або зробити маленьку «словникову» таблицю? Раніше я для цього або писав CREATE TABLE, або зʼєднував купу SELECT ... UNION ALL. Виглядало це завжди… так собі 😅 Але є простіший варіант — VALUES. По суті, він дозволяє: - створити dummy-таблицю - і одразу зробити з неї SELECT. А ще, найприємніше, VALUES можна покласти в CTE і використовувати разом із реальними таблицями ⭐️ Дуже зручно для швидких перевірок, прототипів і маленьких хаків у SQL.2,96%
16 маяЯ написав книгу про співбесіди на позицію Analytics Engineer 🙌 Я постійно отримую питання по тому як пройти технічний етап, як має виглядати сильне take-home завдання, та шо hiring managers насправді оцінюють. Зазвичай я просто відповідав в приватних повідомленнях. Але вирішив зібрати все це в одному місці і зробити книгу. Вона називається “Cracking the Analytics Engineering Interview”. 7 модулів. 22 уроки. Покриваю всі етапи: 🔹 Дзвінок з рекрутером — як презентувати себе, говорити про зарплату та які red flags можуть вас відсіяти 🔹 Технічний раунд — SQL, data modeling, dbt, debugging, дизайн-рішення 🔹 Домашній проєкт — покрокова система та деталі, які реально виділяють вас серед інших 🔹 Раунд зі стейкхолдерами — що нетехнічні інтервʼюери насправді оцінюють 🔹 Фінальна підготовка — тижневий ритм підготовки, щоб залишатися в тонусі до самого оферу Також у кінці кожного розділу я намагався зробити практичні завдання, щоб студенти не просто читали, а реально тренували навички. Зараз книга на англійській, але можу спробувати перекласти із Клодом, якщо є бажання. Даю всім підписникам каналу 50% знижки за посиланням нижче 😊 https://olegagapov.gumroad.com/l/cracking-the-analytics-engineering-interview/DATA-ENGINEER-TG2,77%
13 сент. 2025 г.Безкоштовно (за імейл) роздають електронну версію книги "Data Engineering Patterns" від Бартоша Конєчного. Книга цікава — описується багато кейсів у дата інженерії, способи їх вирішення та потенційні підводні камені. Багато патернів дуже просунуті, особливо ті, які пов'язані зі стрімінгом. Я, до речі, десь чотири роки тому вчився у Бартоша — у нього був відеокурс по дата інженерії. Він дуже шарить у темі. https://buf.build/resources/data-engineering-design-patterns2,27%
3 янв.Починаю новий рік з корисної справи. Я розробив свій CLI-застосунок tablediff для розрахунку різниці між двома таблицями в сховищі. Працює так: спочатку встановлюємо в Python-середовище pip install "tablediff-cli[duckdb]" # або pip install "tablediff-cli[snowflake]" А потім використовуємо як CLI: tablediff table_a table_b --pk id --conn "snowflake://..." Насправді я не писав свій алгоритм для пошуку різниці, а взяв готовий пакет reladiff. А потім натягнув на нього свій UI та додав кілька корисних для себе речей. Буду потроху розвивати цей застосунок, тому що по роботі я роблю багато data diffing. І завжди мені чогось не вистачає. Ось тепер буде варіант реалізувати все, що я задумав. Код доступний також на GitHub: https://github.com/oleg-agapov/tablediff2,19%
2 июн.Вийшов dbt Core v2. І я дуже радий тому, куди все рухається 🤩 На мою думку, dbt Labs ухвалили дуже важливе рішення, яке вплине на багато компаній та інженерів у дата-сфері. Перша велика зміна — це обʼєднання dbt Core та dbt Fusion в один engine, написаний на Rust. Це прям дуже круто, тому що Rust значно швидший і дає набагато кращий developer experience при розробці дата-моделей у dbt. Друга велика зміна — ліцензія. Тепер це Apache 2. А це означає, що ще більше компаній зможуть спокійно використовувати dbt у себе. Із технічних покращень: 🔹 Новий dbt працюватиме без Python virtual environments, тому що це буде один binary-файл. 🔹 dbt artifacts тепер будуть у Parquet замість JSON. Цей формат менший і швидший, а отже можна буде мати ще більші проєкти без просідання продуктивності. Ну і їх буде дуже зручно читати через DuckDB. 🔹 Зʼявляться такі штуки, як language spec та підтримка LSP. Developer experience у Fusion був дуже класний, тому приємно бачити, що це приходить у dbt Core. 🔹 Адаптери будуть використовувати ADBC driver, що теж має покращити продуктивність завдяки Arrow technology. Поки що це alpha, тому я б не переносив production-проєкт прямо зараз. Але точно варто уважно стежити.2,14%
13 янв.Новий рік — і традиційно багато людей замислюються про зміну роботи 🎯 Якщо ви зараз у пошуку ролі Analytics Engineer, я написав невеликий newsletter про те, як зазвичай виглядає процес найму AE. У пості розбираю 4 типові етапи співбесіди: - скрінінг із рекрутером - технічний раунд - тестове завдання - фінальний раунд зі стейкхолдерами Готуватися до невідомого завжди непросто, тому я постарався зібрати все в одному місці й пояснити, чого очікувати на кожному етапі. Сподіваюся, цей гайд допоможе вам почуватися впевненіше й успішно пройти інтерв’ю 💪 Якщо ви зараз у пошуку — тримаю за вас кулаки 🤞 https://dbtips.substack.com/p/how-to-prepare-for-an-analytics-engineering1,82%
19 февр.Поговорили із Нікітою про аналітикс-інженерів та проходження співбесід. Нікіта нещодавно пройшов на позицію Analytics Engineer. Я проходив рік тому, а зараз працюю над курсом «Як проходити співбесіди на аналітикс-інженерів». Якщо є питання — задавайте в коментарях! https://www.youtube.com/watch?v=8V5jU7R2ez81,82%
10 февр.Створив інфографіку про перехід із Data Analytics в Analytics Engineering. Тільки після публікації в LinkedIn зрозумів, що не згадав жодного слова про dbt. Тепер сиджу й думаю — це помилка чи dbt справді не такий важливий для зміни професії? Це ж hard skill, який можна вивчити за кілька місяців. Головне — знати основи професії.1,75%
5 мар.22 правила тестування, які ми додали в AGENTS(.md) Більшість dbt-проєктів провалюються з дуже простої причини — ніхто не визначив чіткі правила тестування. Якщо у вашому проєкті немає задокументованих стандартів тестування, у вас немає надійності даних. Ми зафіксували такі правила в AGENTS(.md), щоб і люди, і AI-агенти працювали за однаковими стандартами. 👇 1. Усі моделі повинні мати тест первинного ключа (not_null + unique). 2. Якщо у моделі немає природного первинного ключа — створюємо surrogate key через dbt_utils.generate_surrogate_key і тестуємо його. 3. Staging-моделі тестуємо максимально ретельно, бо вони є фундаментом для всього проєкту. 4. Якщо колонка не змінює значення між шарами (staging → intermediate → mart), тестуємо її в staging і не дублюємо тести далі. 5. Mart-моделі завжди повинні мати тест первинного ключа. Якщо його немає — модель не готова до продакшну. 6. У marts можна повторно тестувати критичні бізнес-поля. Краще перестрахуватися. 7. Колонки, які ніколи не повинні бути NULL, повинні мати тест not_null. Upstream-джерела можуть змінити свої обмеження будь-якої миті. 8. Колонки, які повинні бути унікальними, мають мати тест unique. 9. Для boolean колонок додаємо accepted_values з TRUE і FALSE, щоб уникнути значень 0/1 або "TRUE"/"FALSE". 10. Якщо boolean ніколи не може бути NULL, додаємо також not_null. 11. Для категоріальних значень (status, state, category) завжди додаємо accepted_values. 12. Якщо категорія створена через CASE WHEN, також додаємо accepted_values, щоб уникнути неочікуваних змін у логіці. 13. Колонки з CASE WHEN зазвичай повинні мати not_null (якщо тільки NULL не очікується). 14. Для складних CASE-виразів варто писати unit-тести, щоб зміни не ламали логіку. 15. Relationship-тести можуть бути дорогими (часто роблять full scan). Використовуйте їх обережно, бажано на staging. 16. Для великих таблиць використовуйте WHERE-обмеження, щоб зменшити час виконання тестів. 17. Custom (singular) тести — для специфічної бізнес-логіки. Але спочатку перевірnt готові dbt пакети, там є багато корисного. 18. dbt_utils.expression_is_true — для перевірки SQL-виразів, наприклад: net_amount + tax_amount = gross_amount. 19. dbt_utils.not_empty_string — для перевірки, що рядок не порожній. 20. dbt_utils.accepted_range — для перевірки числового діапазону. 21. dbt_utils.recency — для перевірки актуальності даних. 22. dbt_utils.not_null_proportion — якщо допускається невеликий відсоток NULL.1,66%
15 янв.Працюємо з semi-structured даними в Snowflake як профі 🔥 Іноді мені потрібно писати SQL-запити до semi-structured датасетів. Наприклад, коли в колонці лежить масив JSON-обʼєктів. 🤨 Старий підхід: LATERAL FLATTEN або UDF-функції. 😎 Новий підхід: вбудовані lambda-функції прямо в SQL. Кілька корисних прикладів 👇 👉 FILTER Фільтрує масив за умовою. Наприклад, повернути лише елементи, де поле value ≥ 50: FILTER(items, i -> i:value >= 50) 👉 REDUCE Агрегація «на місці». Наприклад, порахувати суму цін позицій у замовленні: REDUCE(order_items, 0, (acc, val) -> acc + val:price) 👉 TRANSFORM (мій улюблений 😍) Проходиться по масиву та трансформує кожен елемент. Наприклад, отримати всі id з масиву JSON-ів: TRANSFORM(items, v -> v:id) Я вже давно так не радів новим фішкам в SQL.1,50%