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