Попробую рассказать про поставки данных по дата-контрактам своими словами.

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

Другое дело, что разработчики OLTP-систем могут быть не совсем в курсе, за какими данными и куда к ним в базу лазают дата-инженеры.

Представим, что мы делаем SQL запросы к базе источника, а там вдруг переименовывают какую-то колонку или таблицу, что-то удаляют, где-то меняют тип данных. Если источник не предупредил о своих изменениях, то наши SQL запросы просто сломаются. Причём узнаем мы это скорее всего ночью или утром, когда увидим ошибки в ночном ETL.

Да хотя бы вот живой пример. 1С вообще не разрешает по условиям своей лицухи залезать к ней напрямую в БД. Но многие продолжают писать запросы напрямую ко всем этим таблицам в духе _Document123. Так вот в 1С разработке стали модными "расширения", которые легко накатить и откатить. Только при накатывании такого расширения, таблицы документов, которое оно затронуло, меняют свои названия _Document123 → _Document123X1. Старый запрос обращается в ещё существующую _Document123, но ничего не вытаскивает, т.е. все данные незаметно переехали в таблицу с новым названием.

Теперь рассмотрим ситуацию, когда не мы ходим за данными к системе-источнику, а сама система отправляет новые данные при их появлении. Например, для каждого поставляемого объекта(таблицы) согласуется формат сообщений о событиях INSERT, UPDATE, DELETE. Например, это можно сделать с помощью AVRO-схемы с перечислением всех атрибутов и их типов данных.

С момента заключения дата-контракта в виде AVRO-схемы нам уже не так важна внутренняя структура хранения данных в источнике. Теперь сам источник отвечает за поддержание контракта. Если он что-то меняет в своих таблицах, то он обязан поддержать текущий формат интеграции. Либо должен явно согласовать изменения в контракте с командой DWH.

Таким образом, заключение дата-контракта переносит ответственность за его поддержание на систему источник. Команды со стороны этих систем могут сопротивляться таким предложениям, ведь это на них накладывает много дополнительной работы. Теперь при каждом изменении своих объектов они должны отправлять эти данные в необходимый топик Кафки — стандартный сейчас инструмент для подобных интеграций.

Это может потребовать больших доработок на стороне источника, которые не всегда возможно провести для легаси-систем. К тому же при отправке данных возможны сбои. Если с помощью CDC-инструмента мы видим фактические изменения в данных, то в случае поставок по дата-контрактам мы видим лишь то, что нам отправили. Это дополнительный участок для ошибок, когда могут что-то не отправить или отправить что-то лишнее.

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

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

Data Lineage

Одна из главных болей при работе с данными — понять, откуда они тянутся, размотать всю цепочку преобразований. Как поменяв что-то в одном месте, можно внезапно всё сломать в другом? Речь идёт об управлении зависимостями в данных.

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

Что остаётся делать? Копать вглубь по ветвящемуся дереву зависимостей, где одно поле в таблице складывается из переплетения десятка других таблиц. Это долго, муторно, легко допустить ошибку в ходе расследования.

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

Все преобразования данных осуществляются с помощью специально подготовленных шаблонов SQL-кода для dbt модели, которую можно визуализировать в виде дерева зависимостей таблиц друг от друга.

Почему это ценно? Если мы решим что-то поменять в одной таблице, то мы будем видеть, на какие другие таблицы наша доработка повлияет. Если ошибка происходит на уровень ниже, то она может просочиться на все последующие уровни выше.

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

В некоторых случаях выбирают самописные решения, например в Т-Банке используемся свой инструмент Data Detective, о разработке которого рассказали на хабре. Сам я постоянно им пользуюсь и мне уже трудно себе представить работу с легаси без такого инструмента.

Продолжаю тему управления зависимостями. Кроме зависимостей между объектами DWH мы имеем ещё и зависимости пользователей и BI-отчётов. Что может случиться?

Самый просто пример: необходимо выпилить легаси таблицу с устаревшей логикой. Ну, конечно, необязательно прям сразу DROP TABLE, её можно просто перенести в другое пространство.

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

Как избежать таких ситуаций? Во-первых, есть разные инструменты профайлинга, которые позволяют логировать все запросы к DWH. Статистика по запросам позволит отслеживать чем вообще в DWH пользуются чаще всего, какого рода запросы пишут. При должном упорстве можно пытаться проанализировать типичные пользовательские запросы, выявить какие-то паттерны и потом предложить новую витрину, которая позволит пользователям не прогонять каждый раз кучу джойнов. Как вариант: скормите запросы какой-нибудь LLM'ке и попросите её проанализировать, вдруг найдёт что интересное.

Во-вторых, неплохо бы иметь централизованный доступ к коду, который пишут ваши пользователи и аналитики. Например, разрешить пользоваться ноутбуками только через сервер JupyterHub и не давать запускать скрипты локально со своих компьютеров. Так можно получить доступ ко всей кодовой базе пользователей и анализировать, к каким именно данным они обращаются. Если какую-то таблицу DWH необходимо удалить, то таким образом можно собрать всех пользователей и оповестить их о необходимости воспользоваться заменой.

В случае BI-разработчиков можно дать им возможность для self-service ETL, чтобы они могли собирать свои собственные витрины и вьюшки под отчёты. Лучше вся бизнес-логика на SQL будет где-то на виду, а не зашита внутрь BI-инструмента.

В общем случае универсальных решений я назвать не смогу. Какую-то статистику по пользователям и Data Lineage умеет собирать OpenMetadata, но скорее всего многие решения по управлению данными (data governance) будут кастомными, всё в ваших руках.

Меня просили рассказать про инкрементное(или инкрементальное?) обновление хранилища, так что я попробую немного обрисовать общую картину и стоящие за ней проблемы.

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

Итак, если объём данных растёт, то не пересчитывать же всё хранилище на полных данных. Чтобы сократить объём вычислений необходимо использовать только свежие и прежде необработанные данные.

Неважно, получаем ли мы данные с помощью CDC или по дата-контрактам от источника, но для инкрементной загрузки нам необходимо поле с таймстемпом попадания данных в хранилище. Пусть это будет processed_dttm или upload_dttm, но каждая строка данных из источника должна иметь таймстемп попадания данных в наш слой загрузки (ODS, Stage — как вам удобнее).

Допустим, мы хотим наладить инкрементное обновление модели данных хранилища. Тогда при очередном обновлении таблиц в хранилище мы будем отбирать сырьё из слоя загрузки данных по этому полю processed_dttm. Например, во время последней ночной загрузки мы зафиксировали максимальный processed_dttm = '2025-05-29 00:05:54'. Тогда для следующей загрузки мы будем отфильтровывать из слоя загрузки только те строки, для которых processed_dttm > '2025-05-29 00:05:54'.

Но инкремент возможен не только для слоя загрузки. Например, с помощью сырья мы обновили таблицу фактов и для каждой обновлённой строки в таблице фактов мы тоже проставим processed_dttm как время отработки соответствующего ETL. Зачем нам продолжать эту логику? Ведь от таблицы фактов могут быть последующие зависимости в виде других корпоративных витрин, которые тоже обновляются по инкременту с использованием только новых строк из таблицы фактов (select ... from dwh.fact.Sales where processed_dttm > ...)

Такой механизм с использованием только "подрезанных" по processed_dttm данных часто так и называется механизмом подрезки. Реализации такого механизма возможны разные, есть своё решение в рамках dbt, можно и руками прописывать все необходимые фильтры, оптимизируя их с помощью партиционирования таблиц в слое загрузки данных.

Как и многие оптимизиации, обновление хранилища по инкременту добавляет мест для ошибки, ведь надо внимательно следить за тем, что бы инкремент правильно "проливался" по всей цепочке ETL-зависимостей.

Какие могут быть подводные камни? Например, решили провести работу над исправлением кривых данных в слое загрузки данных, в результате такой корректировки образуется огромный инкремент, который не может перевариться в рамках ежедневного ETL. Либо где-то что-то поправили ручками и не проставили корректный processed_dttm, в результате данные не пролились далее по цепочке в конечные пользовательские витрины. Вариантов может быть много, поэтому работа с инкрементом требует большой внимательности.

Как дата-инженеру почувствовать пользу от своей работы?

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

И тут на помощь могут прийти аналитики! Обратная связь от них может не только направить работу инженеров в нужное русло, но и дать им повод для гордости. Для этого аналитикам нужно чаще делиться результатами своей работы с конкретными примерами, как на основе данных, они смогли повлиять на работу целой компании.

Дата-инженер помог собрать данные для новой витрины, на основе которой получены инсайты, проведены эксперименты и сэкономлены миллиарды? Отличный повод собраться всем вместе и пойти в караоке!

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

Работу дата-инженеров и аналитиков можно обернуть метриками, которые бы могли в денежном эквиваленте измерять их успехи и неудачи. Главное, чтобы это не превратилось в выполнение KPI ради KPI, а преследовало общую цель — проводить аналитику и оптимизировать управление ресурсами фирмы.

Немного холиварный вопрос. Что важнее: понимание общих принципов или владение конкретными технологиями?

Мне кажется, что важнее понимание общих принципов, ведь общие принципы применимы при работе с разными технологиями.

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

Работали на доисторической Терадате? С Гринпламом справитесь без проблем, между ними найдётся немало общего. Поэтому я против дискриминации людей по признаку работы на устаревшем стеке. Если у человека нет опыта в модном modern data stack, то не попадать же ему в замкнутый круг нет опыта => нет работы => нет опыта.

Бывают вакансии, на которые нужен эксперт с конкретными хард скиллами, потому что в команде этих скиллов прям не достаёт. Но это речь о серьёзных экспертных позициях, а если речь о джунах или миддлах, то тут важнее не конкретные технологии, а понимание сферы в целом.

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

В приступе ретроностальгии решил глянуть древние номера Игромании за 2001 год. Годы шли, Nvidia не менялась

Месяц назад я давал не самую сложную задачку на SQL, с которой не справлялись многие кандидаты на позицию дата-инженера.

И тут я решил на своём ноуте со скромной видеокартой RTX 2050 развернуть небольшую гугловскую модель Gemma 3 4B-IT. Для этого я просто скачал LM Studio под винду, никаких танцев с бубнами в консоли.

Мне было интересно протестировать генерацию SQL силами маленькой модельки. Для контекста я задал табличную схему, попросил написать несколько простеньких запросов.

И наконец я даю нейросетке ту самую задачу. Проходит несколько секунд (и это с дохлой мобильной видеокартой!) и... она мне выдаёт практически правильное решение через ROW_NUMBER().

Внимательный читатель заметит, что не на всякой СУБД сработает сортировка по выражению SUM(s.amount) внутри оконной функции, но у нас всего лишь маленькая моделька! Её можно поправить, и она исправит запрос.

Так, блин, какие тут выводы?

Не секрет, что в некоторых фирмах менеджеры используют аналитиков как SQL-роботов. Периодически аналитик слышит "БЫСТРО ОТГРУЗИ МНЕ МАРЖУ ЗА ТРЕТИЙ КВАРТАЛ!!" и идёт в DWH за нужным цифрами, упаковывает их в эксель и отправляет менеджеру на почту. В итоге менеджер доволен (или нет). Я рад, если вы работаете не в такой компании и не с такими менеджерами, но ситуация в целом не редкая.

Умение современных моделек переводить человеческий вопрос в SQL-запрос уже начинает впечатлять. Если даже глупенькая модель на не самом мощном ноутбуке справляется с задачкой для собеседования, то что уже сможет сделать более умная и тонко настроенная модель на серьёзном железе? Я бы сначала сказал, что она заменит людей и лишит их работы, но скорее всего она освободит аналитиков от рутинных задачек по собиранию адхоков под хотелки менеджеров и позволит им заняться чем-то более интересным.

Ждём корпоративных ботов-аналитиков?

В комментариях не раз звучала мысль, что нам бы в пору бояться LLM, т.к. они отнимут у нас работу. В 2021 году на эту тему (это ещё до выхода Chat GPT) вышла книга оксфордского профессора Дэниела Сасскинда "Будущее без работы".

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

Одной из запоминающихся идей книги было то, что автоматизации стоит бояться людям "средней" интеллектуальной работы. На нашем примере что-то типа аналитиков собирающих простые отчёты. Но вот кому бояться нечего, так это действительно серьёзным профессионалам и... людям ручного труда. То есть людей тех профессий, которые требуют какого-то чутья, наития, когда руки сами знают как делать. Это те профессии, мастерство в которых нельзя полностью объяснить словами (или алгоритмами), но которым можно обучить на живом примере. Поэтому, вряд ли нам стоит ждать роботов по ремонту автомобилей или квартир, что требует мелкой моторики рук и некой бытовой смекалки.

Когда-то я сам работал руками в 19 лет будучи лаборантом в научном институте. Меня взяли на помощь в пару к одному аспиранту собирать EUV-установку, чтобы у него освободилось время под написание кандидатской диссертации. Речь о том самом EUV-излучении, которое сейчас используется в литографах для производства современных чипов. Но тогда 10 лет назад это был экспериментальный проект по заказу от компании ASML, мы должны были собрать EUV-установку для калибровки многослойной оптики, которая бы потом использовалась в промышленных литографах.

В создании этой установки участвовали сварщики и токари такой квалификации, что их приглашали работать в Швейцарию и Францию. Мне самому доверяли вещи попроще типа пайки проводов, сверлильного станка, бесчисленного закручивания гаек.

Если у вас в руках современный смартфон, то скорее всего процессор в нём сделан с помощью технологий литографии от нидерландской компании ASML, маленький вклад в развитие которой я внёс в далёком 2015!

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

Я пока не собирался превращать свой канал в новостную ленту по ИИ, но уж очень увлёкся локальными LLM-ками. Когда я только начал знакомиться с темой, то создалось впечатление, что маленькие дистиллированные модельки ещё бесполезны. Но я ошибался.

Этой весной произошло два важных события, которые для меня затмевают хайп вокруг DeepSeek.

1. В марте Google представляет свою Gemma 3, которая умеет работать с анализом изображений и разумно отвечать прямо на домашних машинах.

2. В апреле Alibaba Group выпускают Qwen 3, который требует ещё меньше ресурсов, умеет "рассуждать вслух" и ещё сильнее в математике и программировании чем Gemma 3.

Как и в случае с Gemma 3-4b китайский Qwen 3 на 4 млрд параметров без проблем запускается на видеокарте в 4 гигабайта, хотя есть и варианты поумней на большее число параметров.

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

Я протестировал его на написание SQL и заметил, что эта модель куда шустрее понимает указания, где у неё ошибка и как её исправить. С задачей из предыдущего примера Qwen 3 справился после одного маленького замечания и затем без проблем продолжил решать аналогичные задачи.

Но затем стало интересно протестировать модели на примерах из письменных экзаменов по математике в МФТИ.

Явным преимуществом Gemma 3 стала способность сразу распознать условие задачи по скриншоту самого файла. Но со сложными задачами моделька начинала немного путаться и допускать ошибки. Не исключаю, что аналогичная модель с большим числом параметров справилась лучше.

Но другое дело Qwen 3. Ему, конечно, необходимо было разжевать условие задачи и перевести в текстовый вид, что для многоэтажных формул было не так удобно. Но у ленивых свой путь: условие задачи в виде картинки передаём Gemma 3, а затем она готовит текстовый промт для Qwen 3.

И дальше становится страшно. Qwen 3 на мобильной видеокарте за 1-2 минуты начинал раскидывать задачи с экзамена по матану одна за другой. Причём не просто выдавать готовый ответ, а расписывать подробное решение, которое студент без проблем мог бы переписать и получить хорошую оценку за обоснованно полученный ответ.

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

Мы уже в двух шагах от ситуации, когда телефон даже без доступа к сети сможет расправляться с письменными экзаменами. Тут никакие глушилки связи не помогут, только жёстко шмонать студентов и грозиться страшными карами за списывание с телефона.

А домашние задания? Теперь не надо искать решебник или списывать у одногруппников — моделька сама всё разложит по полочкам. Эпоха сайтов с ГДЗ закончилась, ведь ИИ приготовит любое домашнее задание даже лучше решебника.

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

Заметил, что посты про LLM вызывают интерес в виде обсуждения и репостов, что очень приятно! Спасибо большое всем, кто задаёт вопросы и пересылает мои посты своим друзьям.

Но я бы хотел рассказать, почему сам не стал специалистом по машинному обучению в своё время.

В 2017 году были очень популярны курсы по машинному обучению от Яндекса + МФТИ на Курсере. Сейчас там этих курсов уже не найти, но в текстовом виде материалы всё ещё есть на Гитхабе. Ссылка прилагается.

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

Можно разобраться с математикой под капотом моделей, с их сильными и слабыми сторонами, но всё равно всё чаще сводилось к ставшему мемом fit() → predict()

Признаем честно, но большинство дата-сайентистов не так глубоко сами понимают устройство моделей под капотом. Чаще всего они заняты подготовкой и тестированием новых фич, которые дадут лучший результат на выходе. Мне показалось, что эта работа ближе не в инженерии, а к кулинарии, когда чутьё повара Data Scientist'а помогает приготовить правильный набор фич. Как будто само слово Science тут ближе не к современной физике, а к средневековой алхимии с поиском философского камня.

Я не хочу обесценивать работы DS! Ни в коем случае! Ведь вы тоже даёте мне работу.

Сейчас я понимаю, что меня смущали проблемы интерпретируемости моделей чуть сложнее регрессии. Если я не могу понять, как одна модель работает лучше другой, или как вообще был получен результат, то это и есть проблема с интерпретацией модели.

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

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

Неважно, что модели сами «ничего не понимают», и мы уже не понимаем, что у них внутри. Но если мы просим у них аргументов, то чаще всего они довольно вменяемы.

Интерпретируемость моделей вещь очень важная, тот же ЦБ стремится требовать, чтобы кредитные модели банков были более прозрачны. Принимать важные решения на основе непонятно откуда взявшихся цифр довольно страшно, не так ли?

Хватит пока об ИИ, вернусь к своей профессиональной теме, к архитектуре DWH.

В моделировании данных встречаются проблемы чем-то напоминающие притчу о слепых и слоне.

Рассмотрим моделирование такого "слона" как счёт в банке (account). Cчета могут быть самые разные: расчётные, ипотечные, страховые, брокерские, для дебетовых и кредитных карточек.

Со стороны разных доменов бизнеса (кредитные карты, ипотеки, страхование) одна и та же сущность как счёт будет выглядеть по-разному, обладая разным набором атрибутов.

Нашим слоном будет широкая таблица Аccount со множеством атрибутов для описания всевозможных видов счетов. Поскольку часть атрибутов свойственна только определённым видам счетов, то у нас проблема, что многие атрибуты почти не заполняются (много NULL) или заполняются некорректно. Сюда может входить флаг квалифицированного инвестора только для брокерских счетов, кредитный лимит для кредиток, инфо о внесении залога и так далее.

Колоночные СУБД позволяют достаточно безболезненно увеличивать количество колонок у таблицы, что нередко ведёт к (анти)паттерну One Big Table (OBT). Получается такой "слон" из большого множества колонок (даже пары сотен), которого с разных сторон изучают "слепые" аналитики из разных бизнес-доменов.

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

Проблема не ограничивается денормализацией, когда от вида счёта (account_type) зависит заполняемость других атрибутов. Проблема ещё и в том, что чаще всего одновременно анализируется ограниченное подмножество строк.

Вряд ли часто в одном отчёте будет фигурировать аналитика по кредитным картам и брокерским счетам. Только вот таблица Account у нас одна общая на все отчёты.

Я рассказывал о Data Lineage, но представьте себе, как выглядит дерево зависимости от таблицы Account для абсолютно всех видов счетов для всех банковских продуктов. Это могут быть сотни и тысячи зависимых связей!

В таком случае ценность Data Lineage начинает просто теряться, ведь из одной таблицы счетов тысяча зависимостей, при этом конкретно счета для ипотек могут использоваться лишь в нескольких зависимых витринах.

То есть мы слили всё вместе в один котёл, а потом с трудом различаем, куда и что растекается дальше. Это большая проблема, с которой трудно работать. Свои идеи я попробую набросать в следующем посте.

Как нам съесть слона из поста выше?

Можно, нарезать по кусочкам, а именно выделять отдельные группы атрибутов в таблицы-расширения. Например, атрибуты для брокерских счетов выделить в отдельную таблицу-расширение account_invest_ext.

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

Слишком сложные объекты с кучей зависимостей характерны только для ОЧЕНЬ больших DWH в ОЧЕНЬ больших компаниях. Здесь речь о компаниях, где работают тысячи программистов и аналитиков, а от одной таблицы ветвятся тысячи зависимых витрин и отчётов.

Ещё Билл Инмон писал, что со временем от основного DWH отпочковывается аналитика внутри отдельных департаментов, где выделены свои команды под разработку витрин.

Когда я предлагаю выделять атрибуты в отдельную таблицу, я ещё предлагаю закрепить за новой таблицей команду-владельца. Выделили account_invest_ext? Теперь за неё отвечают дата-инженеры из департамента инвестиций. А все отчеты и витрины связанные с инвестициями будут завязаны на эту таблицу-расширение, что делает Data Lineage проще.

Да, закрепление владельца за таблицей в DWH вещь очень важная. Представьте, что в хранилище тысячи таблиц и с десяток разных команд, но непонятно, кто и за что отвечает? Мои соболезнования тем, у кого с этим на работе такой бардак.

MIPT Alumni, Ex. T-Bank (Tinkoff), AI Enthusiast, DE Mentor, Lost In Data™ Founder etc.

Не знаю как вы, а я с такой саморекламы в социальных сетях (линк, телега) то ли смеюсь, то ли кринжую.

Ex. Yandex, Ex. OZON, Ex. McKinsey & Company и так далее...

Что говорит о человеке то, что он просто работал в Яндексе или Т-Банке? В первую очередь, что он прошёл многоэтапный отбор, который просто вытерпит не каждый (либо хорошо себя показал на one day offer). Но пара слов не говорит о конкретной команде и проекте, с которыми человек работал.

Мне повезло (или нет😁) работать в сильнейшей команде DWH Т-Банка, которая задавала общие подходы для других команд, но я не могу похвастаться большими достижениями кроме того, что участвовал в проектах нескольких миграций, рефакторил архитектуру и выпиливал застарелое легаси.

В опыте работы важно именно то, чем можно похвастаться. Например, я очень горжусь опытом работы в Дикси, где своими руками написал аналитического тг-бота, которым пользовались сотни менеджеров от среднего звена до CEO, куда я даже запилил сканер штрихкодов для получения отчёта по товару. Но писать в своём тг-био, что я Ex. Dixy DWH Analyst уже не так солидно, не правда ли?

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

Да, в среднем выпускники топовых вузов умнее выпускников ПТУ, но иногда легко забыть о том, что это лишь усреднённая статистика, а не железное правило. Иногда меня пугают вакансии с требованиями "Строго топовое образование: МФТИ, МГТУ им. Баумана, ИТМО, МГУ, ВШЭ, РЭШ", ведь в такой компании проще всем внушить чувство исключительности (мы интеллектуальная элита!) и начать манипулировать на этом чувстве.

Не клейте ярлыков, пожалуйста.

Мои экс-коллеги выложили на Хабр подробное описание дата-платформы Т-Банка.

Очень удобно, кстати. Писать в паблик о внутренней кухне всегда как-то стрёмно, ведь такие материалы должны согласовываться с СБ банка. Теперь есть публичный материал, на который можно ссылаться, говоря о большом числе внутренних самописных решений.

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

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

0. Одного Greenplum целых 15 отдельных кластеров для масштабирования нагрузки со стороны пользователей (Monthly Active Users (MAU) > 17k). Да, масштабирование возможно не только увеличением нод в кластере, но и размножением реплик кластеров.

1. За модным Data Lake House (DLH) кроется в общем-то простая идея переносить часть storage с самого GP на S3. Это полезно для того, чтобы не засорять GP малоиспользуемыми архивными данными и слишком громоздким сырьём.

2. У компании есть свой собственный оркестратор для работы с взаимозависимыми потоками данных внутри DWH. Нужно ли вам писать такой свой? Я думаю, что связки Airflow + dbt многим хватит с избытком.

P.S. Наконец-то начал работать с dbt — это прекрасно!

Знаете, из-за обилия непроверенной инфы (кстати, давно ли вы слышали выражение фейк ньюз?) начинаешь к любой новости относиться с недоверием.

Несколько дней назад вышла новость о том, что работа сети алкомаркетов Винлаб (более 2000 точек) парализована работой хакеров, которые потребовали выкуп за восстановление систем. Вчера вечером я не поленился и решил ногами проверить, а может ли реально целая сеть магазинов не работать почти неделю. Дошёл и убедился, что да, правда.

Удивлён, что бизнес оказалось возможным так наглухо парализовать, но не удивлён, что это произошло с ритейлом. Ритейл, к сожалению, имеет свойство экономить на IT, как и на всём остальном. Это разве что не касается X5, которая известна своими инвестициями в технологии и работу с данными.

Экономия на инфобезе приводит к таким миллиардным материальным потерям и неизвестно каким ещё репутационным. Мне особенно обидно как акционеру материнской компании Novabev, которая владеет этой сетью магазинов.

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

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

Разбор ситуации выше от эксперта по ИБ, спасибо за наводку подписчику и просто хорошему товарищу 😎
Нового немного: отдельной службы ИБ нет, всем занимается скромная ИТ-служба. К чести скажу, что на моих глазах в некоем другом ритейле ИБ как раз таки появлялась и начинала заниматься делом.

Тут стоит вспомнить одну идею из риск-менеджмента по Талебу: необходимо бороться с толстыми хвостами распределений. Если есть какой-то маловероятный, но крайне опасный для жизнедеятельности (компании, человека) риск, то нужно его всеми силами минимизировать. Остановка операционной деятельности, особенно для таких компаний как ритейл, смерти подобно. Остановка работы аналитического хранилища уже не так критична, но всё равно наносит ущерб компании, так что совсем расслабляться нельзя.

Другой вопрос, что в некоторых компаниях на DWH завязаны операционные процессы — какие-то расчёты, которые потом отдаются в третьи системы. Это тонкий лёд, на который уже опасно ступать. Да, можно говорить о reverse ETL, когда DWH отправляет какие-то данные в другие системы, или когда операционная отчётность (например, отчёты в госорганы) завязана на хранилище и живёт в опермартах. Но всё это накладывает дополнительные риски, что по дороге где-то что-то в DWH сломается во время очередных преобразований, поэтому лучше использовать аналитическое хранилище как аналитическое, а для операционной отчётности и межсистемных интеграций разрабатывать отдельные сервисы со своим SLA.

Я заметил, что в телеграме пользуются спросом вдохновляющие истории, например, про вкатывание в айти из другой профессии и быстрый рост до мемных 300к/нс

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

Опыта в ML у меня, честно говоря, немного, но то было уже во времена ChatGPT 3.5, и я не боялся новых вызовов. Тем более мне льстило, что такой проект вообще предложили.

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

Проблема была в самих данных, их было тупо недостаточно. Как известно garbage in => garbage out. Каким бы крутым Data Scientist ни был, но сделать из ничего прогнозную модель не получится. Проблема была не только в малом объёме данных, но и их малой вариативности, что не давало возможности выделить значимых факторов.

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

А что бы в такой ситуации делали опытные дата-сайентисты?