Комментарии 4
НЛО прилетело и опубликовало эту надпись здесь
Читаю, и прямо сам чувствую боль автора, хотя и приходилось сталкиваться с подобными проблемами в намного более лайтовом варианте. Если я правильно уловил смысл статьи, то идея в том, чтобы данные лежали в некой витрине, и любой аналитик мог зайти, пощупать схему, почитать описания, и решить свою проблему вообще без коммуникаций с теми, кто за созданием данных стоит.
Но почему мне это кажется утопическим, — как правило, потоки данны для аналитики в сложных системах
а) Имеют много неочевидных нюансов, вроде «вот тут надо дубли прибить перед джойном, чтобы не умножить все показатели», «а… и да, при формировании отчета по поставкам на указанный месяц надо еще найти для них коррекции с датами за следующие три месяца», «по контрактам с беларусами в их валюте во всем софте строящем отчеты, есть магический case when, учитывающий дату деноминации». И проблема не в их существовании, а в том, что простой доступ к данным дает иллюзию их (нюансов) отсутствии. Соответственно, можно напринимать горы управленческих решений, вообще не понимая, где подвох.
б) Структура и качество данных часто продиктовано требованиями их владельца. Условно, в системе управления складом, может быть поле «цена» для наглядности, но вот, его актуальность вообще никому не интересна, ведь система делалась для оптимизации хранения товара на складах и загрузки грузчиков. И когда, кто-то напишет владельцу данных, мол, у вас курс валют не обновляется 5 лет, и лишние ноли в ценах проскакивают, то реакцией будет не «спасибо, друг, что сказал, — бросим все и наведем порядок!», а «да вроде я сам не знаю, — ты это, сам лучше курс где-то найди за пять лет, и реши вопрос, а не отвлекай людей»
Интересно, что делаете с этим. И да, а как в итоге решаете задачу
Но почему мне это кажется утопическим, — как правило, потоки данны для аналитики в сложных системах
а) Имеют много неочевидных нюансов, вроде «вот тут надо дубли прибить перед джойном, чтобы не умножить все показатели», «а… и да, при формировании отчета по поставкам на указанный месяц надо еще найти для них коррекции с датами за следующие три месяца», «по контрактам с беларусами в их валюте во всем софте строящем отчеты, есть магический case when, учитывающий дату деноминации». И проблема не в их существовании, а в том, что простой доступ к данным дает иллюзию их (нюансов) отсутствии. Соответственно, можно напринимать горы управленческих решений, вообще не понимая, где подвох.
б) Структура и качество данных часто продиктовано требованиями их владельца. Условно, в системе управления складом, может быть поле «цена» для наглядности, но вот, его актуальность вообще никому не интересна, ведь система делалась для оптимизации хранения товара на складах и загрузки грузчиков. И когда, кто-то напишет владельцу данных, мол, у вас курс валют не обновляется 5 лет, и лишние ноли в ценах проскакивают, то реакцией будет не «спасибо, друг, что сказал, — бросим все и наведем порядок!», а «да вроде я сам не знаю, — ты это, сам лучше курс где-то найди за пять лет, и реши вопрос, а не отвлекай людей»
Интересно, что делаете с этим. И да, а как в итоге решаете задачу
как мотивировать архитекторов, сопровождающих уже существующие информационные системы, описывать данные и поддерживать их в актуальном состоянии
Да, все так. Мы интегрируем данные из операционных систем, складываем в хранилище, собираем описания и предоставляем данные как сервис.
Для поиска нюансов из вашего примера в Управлении корпоративными данными есть отдельные команды бизнес- и системных аналитиков, которые исследуют систему и готовят почву для работы дата-инженеров. Они общаются с заказчиком, прототипируют прогнозные модели и дашборды в Tableau. Работу таких команд мы описывали на примере данных функции Маркетинг и Продажи.
Для описания сложных и неочевидных (и очевидных тоже!) кейсов на данных мы используем глоссарий. В нашем понимании он чуть шире, чем просто набор терминов. Сюда также вписываются алгоритмы расчетов, методология и хранится история изменений подходов для вопросов из серии «А почему сейчас так, раньше ведь все было иначе?». Каждая запись из глоссария связывается с задействованными в ней элементами логической модели. В наших планах сделать живую систему, когда задачу на разработку можно было бы генерить напрямую через указания терминов логической модели.
За корректностью описаний в глоссарии следят Кураторы и Ответственные — люди от бизнеса, знакомые со всей спецификой. Поддерживая такие описания, они решают сразу несколько задач: не тратят время на объяснения показателей аналитикам смежных подразделений, снижают время на погружение новичков и консультантов, снижают затраты на аналитическую проработку новых IT-решений. А мы получаем еще один кусочек знаний в каталог.
Качество и структура данных. Все верно. Такие кейсы также встречаются в процессе прединтеграционной проработки системы. В этом случае мы либо не затягиваем атрибут вообще (например, когда функционал предусмотрен базовым набором атрибутов системы, но конкретно у нас не востребован сейчас и в будущем), либо об этом делается отдельная пометка в Каталоге о недопустимости использования конкретно этого атрибута.
Насчет мотивации описывать модели данных систем. Совместно с корпоративной архитектурой мы выстраиваем новый процесс управления изменениями. Описание данных встроено в новые архитектурные стандарты и принципы. Со своей стороны мы подготовили чеклисты для контроля заполняемости.
Каждое новое решение должно быть смоделировано в Sparx Enterprise architect, в том числе и потоки данных. Это невозможно сделать, если данные не описаны. Со своей стороны мы доносим до всех архитекторов компании пользу и кейсы применимости описанных данных
Архитекторы понимают, что большие трудозатраты на описание сейчас в целевом видении компенсируются сокращением времени на поиск нужных данных. Основная задача сейчас — выдержать большой поток работ по описанию некоторой критической массы данных, на которой уже можно показать эффекты от трудозатрат. После чего у аналитиков и архитекторов появится стимул поддерживать данные в актуальном состоянии, ведь это будет полезно им, прежде всего.
Для поиска нюансов из вашего примера в Управлении корпоративными данными есть отдельные команды бизнес- и системных аналитиков, которые исследуют систему и готовят почву для работы дата-инженеров. Они общаются с заказчиком, прототипируют прогнозные модели и дашборды в Tableau. Работу таких команд мы описывали на примере данных функции Маркетинг и Продажи.
Для описания сложных и неочевидных (и очевидных тоже!) кейсов на данных мы используем глоссарий. В нашем понимании он чуть шире, чем просто набор терминов. Сюда также вписываются алгоритмы расчетов, методология и хранится история изменений подходов для вопросов из серии «А почему сейчас так, раньше ведь все было иначе?». Каждая запись из глоссария связывается с задействованными в ней элементами логической модели. В наших планах сделать живую систему, когда задачу на разработку можно было бы генерить напрямую через указания терминов логической модели.
За корректностью описаний в глоссарии следят Кураторы и Ответственные — люди от бизнеса, знакомые со всей спецификой. Поддерживая такие описания, они решают сразу несколько задач: не тратят время на объяснения показателей аналитикам смежных подразделений, снижают время на погружение новичков и консультантов, снижают затраты на аналитическую проработку новых IT-решений. А мы получаем еще один кусочек знаний в каталог.
Качество и структура данных. Все верно. Такие кейсы также встречаются в процессе прединтеграционной проработки системы. В этом случае мы либо не затягиваем атрибут вообще (например, когда функционал предусмотрен базовым набором атрибутов системы, но конкретно у нас не востребован сейчас и в будущем), либо об этом делается отдельная пометка в Каталоге о недопустимости использования конкретно этого атрибута.
Насчет мотивации описывать модели данных систем. Совместно с корпоративной архитектурой мы выстраиваем новый процесс управления изменениями. Описание данных встроено в новые архитектурные стандарты и принципы. Со своей стороны мы подготовили чеклисты для контроля заполняемости.
Каждое новое решение должно быть смоделировано в Sparx Enterprise architect, в том числе и потоки данных. Это невозможно сделать, если данные не описаны. Со своей стороны мы доносим до всех архитекторов компании пользу и кейсы применимости описанных данных
Архитекторы понимают, что большие трудозатраты на описание сейчас в целевом видении компенсируются сокращением времени на поиск нужных данных. Основная задача сейчас — выдержать большой поток работ по описанию некоторой критической массы данных, на которой уже можно показать эффекты от трудозатрат. После чего у аналитиков и архитекторов появится стимул поддерживать данные в актуальном состоянии, ведь это будет полезно им, прежде всего.
Хранение данных: PostgreSQLВот это поворот… И ни слова о Vertica. Год назад на конфе пользователей Вертики доклад СИБУРа от ребят, перешедших из Авито, был потрясающим. Укушенность Anchor-modelling вроде на месте) Неужели команда поменялась или бюджеты порезали?
А вообще, круто, когда старые монструозные компании поворачиваются лицом к IT. Прямо по всем статьям последних 2 лет прослеживается — молодцы.
UPD: чтение по диагонали порок) конечно же Вы описывали решение для реализации баянов DAMA — вопрос снят.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Особенности data-driven в нефтехимии