Data Quality и забавные истории
В процессе подготовки лекции по DQ, пересматриваю DAMA-DMBOK и есть там пункт Issues Caused by Data Entry Processes
Field overloading: Some organizations re-use fields over time for different business purposes rather than making changes to the data model and user interface. This practice results in inconsistent and confusing population of the fields.
Вспомнился прям хрестоматийный пример:
В одном из банков, в которых я работал, доработка источника данных занимала от 3 до 6 месяцев для добавления одного поля, а бизнесу надо было здесь и сейчас. И было принято типичное решение. В поле коммент, помимо самого коммента, класть некую метрику, которая влияет на бизнес. Затем, потребовалось добавить еще пару метрик, и поле коммент стало представлять собой полуструктурированный JSON, вида:
{
“measure_1”: “value_1”,
“measure_2”: “value_2”,
“measure_3”: “value_3”
}
Собственно, все это подавалось под соусом, что это workaround, а потом мы заделиверим другое решение с полями, но как-то все откладывалось.
Спустя пару лет мне интересно, не превратилось ли поле comment в еще более древовидную структуру 🙂
В процессе подготовки лекции по DQ, пересматриваю DAMA-DMBOK и есть там пункт Issues Caused by Data Entry Processes
Field overloading: Some organizations re-use fields over time for different business purposes rather than making changes to the data model and user interface. This practice results in inconsistent and confusing population of the fields.
Вспомнился прям хрестоматийный пример:
В одном из банков, в которых я работал, доработка источника данных занимала от 3 до 6 месяцев для добавления одного поля, а бизнесу надо было здесь и сейчас. И было принято типичное решение. В поле коммент, помимо самого коммента, класть некую метрику, которая влияет на бизнес. Затем, потребовалось добавить еще пару метрик, и поле коммент стало представлять собой полуструктурированный JSON, вида:
{
“measure_1”: “value_1”,
“measure_2”: “value_2”,
“measure_3”: “value_3”
}
Собственно, все это подавалось под соусом, что это workaround, а потом мы заделиверим другое решение с полями, но как-то все откладывалось.
Спустя пару лет мне интересно, не превратилось ли поле comment в еще более древовидную структуру 🙂
Тренды 2022 в Modern Data Stack
Посмотрел статью - https://towardsdatascience.com/the-future-of-the-modern-data-stack-in-2022-4f4c91bb778f
Далее сугубо ИМХО:
1. Data Mesh сейчас несомненно на хайпе, но буду надеяться, что все-таки большинство small и medium sized компаний не пойдут на поводу и не будут усложнять инфру для этого. Хотя архитектурный подход отличный и консалтинг сможет продавать еще больше часов и иногда дороже 🙂
2. Metrics layer. Очень заинтересован в этой теме, уже видел два доклада про это - один на coalesce, второй на нашем митапе dbt meet-up. Попробую погрузиться посильнее и написать отдельный пост.
3. Reverse-ETL. Вот тут я не до конца понимаю, в чем новшества. Возврат расчитанных данных в системы-источники был уже очень долгое время, правда история была больше батчевая (хотя и стриминг решения тоже довольно давно существуют). Попробую более детально изучить статьи, на которые ссылается автор.
4. Active Metadata & 3rd Gen Data Driven Catalogs. Как сторонник metadata-driven approach с 2016 года, двумя руками за данный подход. Также очень интересно, к чему приведет Open Metadata инициатива.
5. Data Teams as Product Teams. Да-да и еще раз да. К счастью (а для каких-то DE, наоборот, к сожалению) все более видна демократизация данных и подход Data/DWH as a product все более чаще виден (Это не до конца связанные процессы, но это влияет в том числе и на размер команды). Можно еще раз пересмотреть неплохой доклад от Авито на Смартдате по этой тематике или несколько докладов с Coalesce.
6. Data Observability. Данный пункт выглядит, как возвращение к идеям старого доброго ACID, но на стероидах (Вводим бизнес-транзакционость над более высокой абстракцией). Вместо того, чтобы показывать пользователю частично обновлённую информацию, через метаданные и их управление будем контролировать возможность выдачи данных конечным пользователям. Кажется, что в классических DWH это было решено уже лет 6-10 назад 🙂
Посмотрел статью - https://towardsdatascience.com/the-future-of-the-modern-data-stack-in-2022-4f4c91bb778f
Далее сугубо ИМХО:
1. Data Mesh сейчас несомненно на хайпе, но буду надеяться, что все-таки большинство small и medium sized компаний не пойдут на поводу и не будут усложнять инфру для этого. Хотя архитектурный подход отличный и консалтинг сможет продавать еще больше часов и иногда дороже 🙂
2. Metrics layer. Очень заинтересован в этой теме, уже видел два доклада про это - один на coalesce, второй на нашем митапе dbt meet-up. Попробую погрузиться посильнее и написать отдельный пост.
3. Reverse-ETL. Вот тут я не до конца понимаю, в чем новшества. Возврат расчитанных данных в системы-источники был уже очень долгое время, правда история была больше батчевая (хотя и стриминг решения тоже довольно давно существуют). Попробую более детально изучить статьи, на которые ссылается автор.
4. Active Metadata & 3rd Gen Data Driven Catalogs. Как сторонник metadata-driven approach с 2016 года, двумя руками за данный подход. Также очень интересно, к чему приведет Open Metadata инициатива.
5. Data Teams as Product Teams. Да-да и еще раз да. К счастью (а для каких-то DE, наоборот, к сожалению) все более видна демократизация данных и подход Data/DWH as a product все более чаще виден (Это не до конца связанные процессы, но это влияет в том числе и на размер команды). Можно еще раз пересмотреть неплохой доклад от Авито на Смартдате по этой тематике или несколько докладов с Coalesce.
6. Data Observability. Данный пункт выглядит, как возвращение к идеям старого доброго ACID, но на стероидах (Вводим бизнес-транзакционость над более высокой абстракцией). Вместо того, чтобы показывать пользователю частично обновлённую информацию, через метаданные и их управление будем контролировать возможность выдачи данных конечным пользователям. Кажется, что в классических DWH это было решено уже лет 6-10 назад 🙂
Medium
The Future of the Modern Data Stack in 2022
Featuring the 6 big ideas you should know from 2021
Прочитано. Building the Data Lakehouse
Одно из первых дел, что я сделал, переехав в Эстонию, это заказал кучу книг по дата тематике на английском языке на амазоне (причем, сделав это через американский, а не немецкий, попав на пошлину 🤦♂️)
И вот первая (еле-еле) дочитанная книга это Building the Data Lakehouse - https://www.amazon.com/Building-Data-Lakehouse-Bill-Inmon-ebook/dp/B09GRZ9KP3
Повелся я на автора Билла Инмона, известного всем в сфере DWH. Но есть ощущение, что от него в этой книге только предисловие. Книга представляет собой (фразу спер у Simon Osipov) булшит бинго. 220 страниц про то, как умными словами будучи менеджером дата команды, продать свою важность.
Она может быть полезна джунам и миддл аналитикам или инженерам, чтобы понимать широкую картину дата области и тренды современного рынка. Но для людей, работающих в этой области долгое время, практически ничего нового. Мне понравилась только первая часть, описывающая разницу между обычными пользователями аналитических приложений и дата сайнтистами. Из книги можно понабрать buzzwords, чтобы потом продавать себя на собесах 😄
Также мне не повезло с печатью (книга явно рассчитана на цветной принт)
Полностью подпишусь под словами ниже:
- Grey scale pictures described with colours in the text
- 20+ pages falling out of binding
- Numerous spelling and grammatical errors
- Content is very verbose, could be slimmed down to about 50 pages.
- Lots of rambling about what data can go into a Lake House but very light on Lake House best practices etc
P.S. Если кому-то нужна копия, то я буду в мск ориентировочно в Феврале и могу отдать свою
Одно из первых дел, что я сделал, переехав в Эстонию, это заказал кучу книг по дата тематике на английском языке на амазоне (причем, сделав это через американский, а не немецкий, попав на пошлину 🤦♂️)
И вот первая (еле-еле) дочитанная книга это Building the Data Lakehouse - https://www.amazon.com/Building-Data-Lakehouse-Bill-Inmon-ebook/dp/B09GRZ9KP3
Повелся я на автора Билла Инмона, известного всем в сфере DWH. Но есть ощущение, что от него в этой книге только предисловие. Книга представляет собой (фразу спер у Simon Osipov) булшит бинго. 220 страниц про то, как умными словами будучи менеджером дата команды, продать свою важность.
Она может быть полезна джунам и миддл аналитикам или инженерам, чтобы понимать широкую картину дата области и тренды современного рынка. Но для людей, работающих в этой области долгое время, практически ничего нового. Мне понравилась только первая часть, описывающая разницу между обычными пользователями аналитических приложений и дата сайнтистами. Из книги можно понабрать buzzwords, чтобы потом продавать себя на собесах 😄
Также мне не повезло с печатью (книга явно рассчитана на цветной принт)
Полностью подпишусь под словами ниже:
- Grey scale pictures described with colours in the text
- 20+ pages falling out of binding
- Numerous spelling and grammatical errors
- Content is very verbose, could be slimmed down to about 50 pages.
- Lots of rambling about what data can go into a Lake House but very light on Lake House best practices etc
P.S. Если кому-то нужна копия, то я буду в мск ориентировочно в Феврале и могу отдать свою
Data Engineer.
Недавно в дата Джобс было обсуждение, кто есть труЪ дата инженер, а кто так мимо проходил 🙂
Подумал можно чуть-чуть порефлексировать по этому поводу.
А так ли важен тайтл, которым тебя назовут? Многие дата-инженеры, пишущие на хардкорной скале с кетсами и спарком, (или даже на питоне) часто не довольны, что адептов SQL-based решений (К коим я также отношусь) также относят к ДЕ.
Недавно собесился в одну большую шведскую контору на ДЕ и меня спросили, на чем будешь делать задание: на SQL или на Python. А следующие этапы были больше про качество данных, моделирование данных, выбор компонент и т.д. То есть сейчас даже кодинг интервью часто пропускает проверку реального знания ЯП.
Мне больше нравится разделение на Data Platform Engineer и Data Product Engineer/Analyst в больших компаниях. Первые занимаются платформой, обвязками, иногда централизированным дата-каталогом и другими DG приблудами, а вторые деливерят бизнес-логику в дата продукт, который использует конечный потребитель.
И если для первых выбор инструментария бывает критичен, то во втором случае мне кажется, в разы важнее ориентированность на продукт и контроль бизнес-корректности, чем выбор корректного инструментария и прочее. Также стоит учитывать порог входа и вообще состав команды. Довольно редко удается найти специалиста со знанием доменной области, который еще и в SWE умеет. А вот то, что человек сможет в SQL, вероятность уже большая.
Тут понятно, что я немного biased, и для меня решение в виде drag-and-drop или набросанного SQL или python-кода выглядит часто лучше, так как оно может быстро решить нужды бизнеса. Можно сказать про накапливаемый тех долг, но практика показывает, что довольно часто бизнес-логика решения успеет поменяться несколько раз, что приведет к тому, что текущее решение просто исчезнет.
P.S. Благо мы теперь можем звать себя Analytics Engineer 😄
Недавно в дата Джобс было обсуждение, кто есть труЪ дата инженер, а кто так мимо проходил 🙂
Подумал можно чуть-чуть порефлексировать по этому поводу.
А так ли важен тайтл, которым тебя назовут? Многие дата-инженеры, пишущие на хардкорной скале с кетсами и спарком, (или даже на питоне) часто не довольны, что адептов SQL-based решений (К коим я также отношусь) также относят к ДЕ.
Недавно собесился в одну большую шведскую контору на ДЕ и меня спросили, на чем будешь делать задание: на SQL или на Python. А следующие этапы были больше про качество данных, моделирование данных, выбор компонент и т.д. То есть сейчас даже кодинг интервью часто пропускает проверку реального знания ЯП.
Мне больше нравится разделение на Data Platform Engineer и Data Product Engineer/Analyst в больших компаниях. Первые занимаются платформой, обвязками, иногда централизированным дата-каталогом и другими DG приблудами, а вторые деливерят бизнес-логику в дата продукт, который использует конечный потребитель.
И если для первых выбор инструментария бывает критичен, то во втором случае мне кажется, в разы важнее ориентированность на продукт и контроль бизнес-корректности, чем выбор корректного инструментария и прочее. Также стоит учитывать порог входа и вообще состав команды. Довольно редко удается найти специалиста со знанием доменной области, который еще и в SWE умеет. А вот то, что человек сможет в SQL, вероятность уже большая.
Тут понятно, что я немного biased, и для меня решение в виде drag-and-drop или набросанного SQL или python-кода выглядит часто лучше, так как оно может быстро решить нужды бизнеса. Можно сказать про накапливаемый тех долг, но практика показывает, что довольно часто бизнес-логика решения успеет поменяться несколько раз, что приведет к тому, что текущее решение просто исчезнет.
P.S. Благо мы теперь можем звать себя Analytics Engineer 😄
👍3
Open data
Огромное количество датасетов по Европе можно найти на https://data.europa.eu/en
Кто планирует переезжать в ЕС, можно покопаться, много довольно интересных датасетов
Вот, например, датасет геоточек деревьев в Швеции с дополнительнымы атрибутами - https://data.europa.eu/data/datasets/https-opendata-umea-se-api-v2-catalog-datasets-trad-som-forvaltas-av-gator-och-parker?locale=en
Огромное количество датасетов по Европе можно найти на https://data.europa.eu/en
Кто планирует переезжать в ЕС, можно покопаться, много довольно интересных датасетов
Вот, например, датасет геоточек деревьев в Швеции с дополнительнымы атрибутами - https://data.europa.eu/data/datasets/https-opendata-umea-se-api-v2-catalog-datasets-trad-som-forvaltas-av-gator-och-parker?locale=en
Интересно ли послушать про опыт прохождения собесов в FAANG-like компанию на позицию DE/Analytics Engineer?
Anonymous Poll
84%
Да
2%
Нет
14%
А я мимо проходил
Klarna
Работу я сейчас активно не ищу, но все же мне было интересно пообщаться с FAANG-like компаниями в случае чего. В итоге я получил опыт всех этапов собеседований в одной компании с собесом в стиле FAANG, а также с реальной компанией из MANGA.
Первая компания были шведский финтех Klarna. (Детали могу описать, NDA я не подписывал 🙂 ). Интервью процесс было на позицию Data Engineer.
Первым этапом был классический созвон с HR, уже на этом этапе выяснилось, что мои зп ожидания не совпадают с их базовыми вилками, но, если я покажу себя хорошо, то можем пообсуждать.
Вторым этапом был логический тест 🤦♂️. В последний раз мне кажется я делал логический тест в бородатом 2013 году на стажировку в Билайн. Пример теста - https://www.jobtestprep.co.uk/media/31941/klarna-logic-test-prep.webp). Не сказал, что данный этап сложный - у меня было 18/18 и еще пара минут в запасе. В том же ODS я читал, что люди отказывались от дальнейших этапов, узнав о наличии данного теста :).
Третьим этапом был домашний тест на SQL (можно было выбрать Python или SQL). Вспомнил я про него вечером в вск, выпив уже пару бутылочек пива. Так как в будни мне было бы лень его делать, решил сделать в тот же день. Задачки были уровня easy, medium и одна на оконки с хитрым партиционированием. Плюс была задача на оптимизацию, которую я не очень понимаю, как честно делать, с учетом что в онлайн-платформа для кодинга даже Explain Plan не работает и вроде бы нет доступа к системным таблицам. Поэтому я просто расписал варианты с учетом наличия индексов и прочее.
Тут стоить сказать про факапы, которые начались у HR. Проинформировав, что я закончил тест, я стал ждать. Через неделю не было ни ответа, ни привета. В итоге пинганув еще раз, оказалось, что решение автоматическо не распределилось на проверяющего 🤦♂️
Четвертым этапом мне назначили техническое интервью. Мы обсудили SQL задание с предыдущего этапа, а дальше был сис дизайн наоборот. То есть интервьюер принимал роль джуна, задающего вопросы, как технического, так и продуктового характера по системе. А я должен был описывать ее. В качестве системы (аналитической платформы) можно было взять либо что-нибудь из реального опыта, или придумать самому. Сам формат мне крайне зашел и мы покрыли практически все аспекты end-to-end дата решения с точки зрения DE.
Пятым этапом был бихейв. В первый раз человек тупо не пришел, не сообщив заранее. Во второй раз он пришел, но это было наверное худшее интервью за весь процесс в плане коммуникации. Вопросы были типичнейшие: Расскажите об вашем не успешном опыте, или расскажите, как вы разрешали конфликты. Готовился я к этому интервью примерно 5 минут, открыв местные leadership principles, и уже во время ответа на вопросы, адаптировал свои истории под описанные Кларной. (Если кому-то интересно, они описаны здесь - (https://www.klarna.com/careers/our-culture/)). Потом я позадавал вопросы, но чего-то прям запоминающегося у меня в голове не осталось.
Потому был перерыв где-то недели на 3, но мне в итоге назначили еще одно техническое интервью и встречу с командой.
Шестым этапом было техническое интервью и оно стоило того, чтобы пройти все этапы. Сначала обсуждался классический Data Modelling (а-ля есть raw дата, сделайте мне star schema, выделив основные dimensions и facts). Но потом осталось порядка 20-30 минуты и мы долго обсуждали data quality, data mesh и data governance, и как это все устроено в Klarna. (Правда в итоге оказалось, что меня сматчили с командой, которая не относилась к дата платформе, построение которой мы обсуждали)
Работу я сейчас активно не ищу, но все же мне было интересно пообщаться с FAANG-like компаниями в случае чего. В итоге я получил опыт всех этапов собеседований в одной компании с собесом в стиле FAANG, а также с реальной компанией из MANGA.
Первая компания были шведский финтех Klarna. (Детали могу описать, NDA я не подписывал 🙂 ). Интервью процесс было на позицию Data Engineer.
Первым этапом был классический созвон с HR, уже на этом этапе выяснилось, что мои зп ожидания не совпадают с их базовыми вилками, но, если я покажу себя хорошо, то можем пообсуждать.
Вторым этапом был логический тест 🤦♂️. В последний раз мне кажется я делал логический тест в бородатом 2013 году на стажировку в Билайн. Пример теста - https://www.jobtestprep.co.uk/media/31941/klarna-logic-test-prep.webp). Не сказал, что данный этап сложный - у меня было 18/18 и еще пара минут в запасе. В том же ODS я читал, что люди отказывались от дальнейших этапов, узнав о наличии данного теста :).
Третьим этапом был домашний тест на SQL (можно было выбрать Python или SQL). Вспомнил я про него вечером в вск, выпив уже пару бутылочек пива. Так как в будни мне было бы лень его делать, решил сделать в тот же день. Задачки были уровня easy, medium и одна на оконки с хитрым партиционированием. Плюс была задача на оптимизацию, которую я не очень понимаю, как честно делать, с учетом что в онлайн-платформа для кодинга даже Explain Plan не работает и вроде бы нет доступа к системным таблицам. Поэтому я просто расписал варианты с учетом наличия индексов и прочее.
Тут стоить сказать про факапы, которые начались у HR. Проинформировав, что я закончил тест, я стал ждать. Через неделю не было ни ответа, ни привета. В итоге пинганув еще раз, оказалось, что решение автоматическо не распределилось на проверяющего 🤦♂️
Четвертым этапом мне назначили техническое интервью. Мы обсудили SQL задание с предыдущего этапа, а дальше был сис дизайн наоборот. То есть интервьюер принимал роль джуна, задающего вопросы, как технического, так и продуктового характера по системе. А я должен был описывать ее. В качестве системы (аналитической платформы) можно было взять либо что-нибудь из реального опыта, или придумать самому. Сам формат мне крайне зашел и мы покрыли практически все аспекты end-to-end дата решения с точки зрения DE.
Пятым этапом был бихейв. В первый раз человек тупо не пришел, не сообщив заранее. Во второй раз он пришел, но это было наверное худшее интервью за весь процесс в плане коммуникации. Вопросы были типичнейшие: Расскажите об вашем не успешном опыте, или расскажите, как вы разрешали конфликты. Готовился я к этому интервью примерно 5 минут, открыв местные leadership principles, и уже во время ответа на вопросы, адаптировал свои истории под описанные Кларной. (Если кому-то интересно, они описаны здесь - (https://www.klarna.com/careers/our-culture/)). Потом я позадавал вопросы, но чего-то прям запоминающегося у меня в голове не осталось.
Потому был перерыв где-то недели на 3, но мне в итоге назначили еще одно техническое интервью и встречу с командой.
Шестым этапом было техническое интервью и оно стоило того, чтобы пройти все этапы. Сначала обсуждался классический Data Modelling (а-ля есть raw дата, сделайте мне star schema, выделив основные dimensions и facts). Но потом осталось порядка 20-30 минуты и мы долго обсуждали data quality, data mesh и data governance, и как это все устроено в Klarna. (Правда в итоге оказалось, что меня сматчили с командой, которая не относилась к дата платформе, построение которой мы обсуждали)
👍3
Седьмым этапом был тим матч, и было 2 интервью - с менеджерами и с командой. С менеджерам мы обсудили, что вообще происходит, что за сфера и команда. Если кратко, есть 5 фин. аналитиков, но очень много ручника даже для регуляторной отчетности, и ищут ДЕ, который сделает обновляемый бек-офис (условно витрину) для подготовки данных. Я озвучил подход, когда работа с данными демократизируется и сам аналитик может писать базовые загрузки, чтобы ДЕ не был “узким горлышком”. С командой это был скорее неформальный чат в обе стороны, чтобы понять, подходим ли мы друг другу.
В итоге после недели ожидания я решил уточнить, есть ли какой-то фидбек и получил следующее:
I have synced with all the interviewers and as the feedback has been mixed, I'm afraid we decided not to proceed with an offer this time.
To shed some understanding:
You did really great in both technical interviews, the interviewers found you a strong technical profile.
For the team fit interview, they were not able to gather enough evidence towards our leadership principles and stakeholder management skills. They would have also wished to see more interest in Klarna.
Делаю вывод, что я не правильно готовился и понимал последний этап, так как я думал, что лидершип уже не нужен 🙂
В итоге весь процесс занял около 2-3 месяцев. Из выводов делаю, что нужно больше времени уделять бихейву и анализу самой компании, по сравнению с РФ компаниями.
Себе за техническую часть ставлю 4, за продуктовую/бихейв - 3-. Местным HR ставлю 3-.
Суммарное потраченное время - около 8-10 часов.
P.S. Про MANGA компанию в след. серии (но там деталей сильно не будет, так как NDA 🙁 )
В итоге после недели ожидания я решил уточнить, есть ли какой-то фидбек и получил следующее:
I have synced with all the interviewers and as the feedback has been mixed, I'm afraid we decided not to proceed with an offer this time.
To shed some understanding:
You did really great in both technical interviews, the interviewers found you a strong technical profile.
For the team fit interview, they were not able to gather enough evidence towards our leadership principles and stakeholder management skills. They would have also wished to see more interest in Klarna.
Делаю вывод, что я не правильно готовился и понимал последний этап, так как я думал, что лидершип уже не нужен 🙂
В итоге весь процесс занял около 2-3 месяцев. Из выводов делаю, что нужно больше времени уделять бихейву и анализу самой компании, по сравнению с РФ компаниями.
Себе за техническую часть ставлю 4, за продуктовую/бихейв - 3-. Местным HR ставлю 3-.
Суммарное потраченное время - около 8-10 часов.
P.S. Про MANGA компанию в след. серии (но там деталей сильно не будет, так как NDA 🙁 )
👍6
Forwarded from Stanislav Lysikov
Всем привет.
В рамках развития сообщества @dbt_users мы проводим второй митап, затрагивающий уже более технические подробности инструмента.
14 июня в 19-00 в онлайне ребята из Wheely, ADV/web-engineering co., Space307 и NabuMinds расскажут:
- надежанная дружба clickhouse и dbt
- data quality в modern data stack
- куда расти в зрелых dbt-проектах
- dbt для байтовозов с маленьким t в elt
Слоты фиксированы по времени, можно подключаться на любой канал. Ссылка на ютуб придет как обычно перед началом митапа.
До встречи :)
https://space307.team/dbtmeetup
В рамках развития сообщества @dbt_users мы проводим второй митап, затрагивающий уже более технические подробности инструмента.
14 июня в 19-00 в онлайне ребята из Wheely, ADV/web-engineering co., Space307 и NabuMinds расскажут:
- надежанная дружба clickhouse и dbt
- data quality в modern data stack
- куда расти в зрелых dbt-проектах
- dbt для байтовозов с маленьким t в elt
Слоты фиксированы по времени, можно подключаться на любой канал. Ссылка на ютуб придет как обычно перед началом митапа.
До встречи :)
https://space307.team/dbtmeetup
Если вдруг кто не видел, то у гитлаба часть репозитория в открытом доступе - https://gitlab.com/gitlab-data/analytics/-/tree/master/transform/snowflake-dbt
GitLab
transform/snowflake-dbt · master · GitLab Data / GitLab Data Team · GitLab
This is the primary project for the GitLab Data team.
Две статьи от CTO https://www.selfr.io/ про modern data stack и вообще построение дата команд/подходов в компании
https://medium.com/alexandre-beauvois/modern-data-stack-as-a-service-1-3-1a1813c38633
https://medium.com/@abeauvois/modern-data-stack-as-a-service-2-3-9a15fd8dfb31
Автор подсвечивает довольно классические проблемы всех хранилищ, и показывает современный дата стак. Статьи, как обзорные, мне понравились
Для себя также открыл https://www.castordoc.com/, возможно запрошу демо и попробую осветить в канале
https://medium.com/alexandre-beauvois/modern-data-stack-as-a-service-1-3-1a1813c38633
https://medium.com/@abeauvois/modern-data-stack-as-a-service-2-3-9a15fd8dfb31
Автор подсвечивает довольно классические проблемы всех хранилищ, и показывает современный дата стак. Статьи, как обзорные, мне понравились
Для себя также открыл https://www.castordoc.com/, возможно запрошу демо и попробую осветить в канале
👍3
Рефлексии пост (отметим 2 юбилея! год в Эстонии и 100+ подписчиков 🙂 )
Год назад я переехал в Эстонию. Уходить из Deutsche Bank было тяжко, в виду очень крутой команды, но нерабочие причины побудили к переезду. Выбирал я между Германией (New Yorker) и Nabuminds (Эстония). По совокупности причин была выбрана Эстония. Получилось так, что я попал в совершенно другой бизнес, другой стек (cloud vs on-premise), и в другую парадигму работы (неуправляемый хаос кек).
На момент переезда в компании был BI департамент с классическим подходом дата инженеры + bi analyst. В команде дата инжей было 2 человека + 1 джун на аутстаффе. Процесс был выстроен довольно лайтово.
За год произошло следующее:
⁃ Поменяли парадигму на Core Data Team + Analytics Team (и отчетность как доп команда в ней)
⁃ Core Data Team выросла с 2 дата инжей до Data Architect + Lead DE + 3 DE + 2 Data QA Engineer
⁃ Ввели Code Review и практику написания дата тестов дата инжами
⁃ Мы стали не бек-офисом для BI, а самостоятельным бизнес-юнитом с разными стейкхолдерами
⁃ Организовали Reverse-ETL
Как обычно, планов в разы больше, чем реализованного
Что хочется
⁃ Организовать полноценный CI/CD. Сейчас это в начальном состоянии
⁃ Сейчас выбираем ELT инструмент для новых источников. До это у нас была связка Pure Python + Kafka -> BigQuery, но сейчас требуется более масштабируемый инструмент. Смотрим на Fivetran, Hevo, StitchData
⁃ Организация End-to-End column data lineage. Как инструментарий у нас dbt + airflow + elt тул + Tableau. Главная проблема тут Tableau, но планируем изучить доступные решения и в случае чего, допилить свою интеграцию
⁃ Кросс-клауд. Сейчас у нас GCP + BigQuery, но ожидается вторым проектом AWS + Snowflake и, скорее всего, потребуется кросс-клауд интеграция
⁃ Демократизация работы с данными. Планируем отдать часть витрин под продукт команды с нашим высокоуровневым контролем + предоставление полноценной документации
⁃ Мониторинг - тоже пока относительно сырая часть, опираемся на слак алерты, но для более детализированной картины будем добавлять мониторинг
⁃ Адаптация команды под рост. У нас открыты 3 дата инженерных позиции + DataOps. С учетом такого бурного роста требуется адаптация процессов
Год назад я переехал в Эстонию. Уходить из Deutsche Bank было тяжко, в виду очень крутой команды, но нерабочие причины побудили к переезду. Выбирал я между Германией (New Yorker) и Nabuminds (Эстония). По совокупности причин была выбрана Эстония. Получилось так, что я попал в совершенно другой бизнес, другой стек (cloud vs on-premise), и в другую парадигму работы (неуправляемый хаос кек).
На момент переезда в компании был BI департамент с классическим подходом дата инженеры + bi analyst. В команде дата инжей было 2 человека + 1 джун на аутстаффе. Процесс был выстроен довольно лайтово.
За год произошло следующее:
⁃ Поменяли парадигму на Core Data Team + Analytics Team (и отчетность как доп команда в ней)
⁃ Core Data Team выросла с 2 дата инжей до Data Architect + Lead DE + 3 DE + 2 Data QA Engineer
⁃ Ввели Code Review и практику написания дата тестов дата инжами
⁃ Мы стали не бек-офисом для BI, а самостоятельным бизнес-юнитом с разными стейкхолдерами
⁃ Организовали Reverse-ETL
Как обычно, планов в разы больше, чем реализованного
Что хочется
⁃ Организовать полноценный CI/CD. Сейчас это в начальном состоянии
⁃ Сейчас выбираем ELT инструмент для новых источников. До это у нас была связка Pure Python + Kafka -> BigQuery, но сейчас требуется более масштабируемый инструмент. Смотрим на Fivetran, Hevo, StitchData
⁃ Организация End-to-End column data lineage. Как инструментарий у нас dbt + airflow + elt тул + Tableau. Главная проблема тут Tableau, но планируем изучить доступные решения и в случае чего, допилить свою интеграцию
⁃ Кросс-клауд. Сейчас у нас GCP + BigQuery, но ожидается вторым проектом AWS + Snowflake и, скорее всего, потребуется кросс-клауд интеграция
⁃ Демократизация работы с данными. Планируем отдать часть витрин под продукт команды с нашим высокоуровневым контролем + предоставление полноценной документации
⁃ Мониторинг - тоже пока относительно сырая часть, опираемся на слак алерты, но для более детализированной картины будем добавлять мониторинг
⁃ Адаптация команды под рост. У нас открыты 3 дата инженерных позиции + DataOps. С учетом такого бурного роста требуется адаптация процессов
👍7
Forwarded from Data Coffee
Наконец-то это случилось, и мы поговорили про dbt! К нам в гости заходил Никита Баканчев, Lead Data Engineer из NabuMinds (LinkedIn, Telegram)
Никита рассказал нам что же за инструмент такой dbt и зачем он нужен на data-проектах, чем отличается open source версия dbt core от закрытой dbt cloud, про возможности тестирования и data quality, документацию и lineage, а также про community.
Кроме того, мы не могли обойти стороной расширяемость dbt и попросили гостя назвать те пакеты, на которые точно стоит обратить внимание, и сделали для вас подборочку:
- dbt_utils
- dbtvault
- snowflake_utils
- dbt_expectations
- dbt_date
#datacoffee #podcast #data
Где слушать🎧:
— Anchor.FM
— YouTube
— Бот (последний эпизод)
— Остальные площадки
Канал в Telegram: https://news.1rj.ru/str/datacoffee
Профиль в Twitter: https://twitter.com/_DataCoffee_
Чат подкаста: https://news.1rj.ru/str/datacoffee_chat
Поддержать нас чашечкой кофе и даже присоединиться онлайн во время записи можно с помощью сервиса Buy me a coffee
Никита рассказал нам что же за инструмент такой dbt и зачем он нужен на data-проектах, чем отличается open source версия dbt core от закрытой dbt cloud, про возможности тестирования и data quality, документацию и lineage, а также про community.
Кроме того, мы не могли обойти стороной расширяемость dbt и попросили гостя назвать те пакеты, на которые точно стоит обратить внимание, и сделали для вас подборочку:
- dbt_utils
- dbtvault
- snowflake_utils
- dbt_expectations
- dbt_date
#datacoffee #podcast #data
Где слушать🎧:
— Anchor.FM
— YouTube
— Бот (последний эпизод)
— Остальные площадки
Канал в Telegram: https://news.1rj.ru/str/datacoffee
Профиль в Twitter: https://twitter.com/_DataCoffee_
Чат подкаста: https://news.1rj.ru/str/datacoffee_chat
Поддержать нас чашечкой кофе и даже присоединиться онлайн во время записи можно с помощью сервиса Buy me a coffee
🔥6👍5
https://habr.com/ru/company/lamoda/blog/684658/
довольно интересный пост по вкату в DE
довольно интересный пост по вкату в DE
Хабр
Что должен знать дата-инженер. Роадмап для джуниора
Привет, username! Меня зовут Иван Васенков и я джуниор дата-инженер в дирекции данных и аналитики Lamoda. Но к этой профессии я пришел не сразу: окончив университет, я начал работать аналитиком...
👍7🔥1