Комментарии 33
Спасибо за описание! Доступ пользователей к созданию отчетов - как на практике решаете проблему возможной несходимости данных? Я считаю продажи так, а в другом отделе - совершенно другим способом. При этом на совещаниях мы можем показывать разные отчеты, и спорить, хотя построены на одних данных и те, и другие. Но математика/логика могут быть разными.
В системах отчетности SAP BusinessObjects и PowerBI все формулы прописаны для метрик (продажи, себестоимость, коэффициенты возврата, продаж и др), которые используют пользователи, им не приходится заново рассчитывать их. И также мы делаем описания в confluence в спейсе, к которому есть доступ у всей компании.
Если происходят моменты несходимости данных в отчетах, то обсуждаем с отделами, что и как они используют, анализируем их отчеты, стараемся прийти к единой логике, и если есть необходимость в создании новых метрик, то добавляем их в SAP BO и Power BI. Это помогает избежать ошибок в дальнейшем.
Пробовали ClickHouse для ваших задач? Чем не подошел?
Мы давно используем Oracle, как правило, миграция - это дорого, плюс не считали профит от перехода.
Но ClickHouse используется в отделе R&D для решения их задач.
это же узкоспециализированный инструмент и подходит только для для доступа к данным без использования сложнонаписанных sql выражений. Какое может быть ХД на КХ?
Удачи вам, ребята!
С нетерпением жду статью про гринплам) Особенно интересна часть про моделирование, там из-за распределенности наверняка будут вылезать нюансы. Железо, кстати, придется же сменить?
Помню, хотели поднимать хадуп для DL... не взлетело?
Сталкивались ли с случаями, когда "гранулярность" историчности в системах-источниках не совпадает с "гранулярностью" историчности в вашем IL (который в 3NF)? То есть, например, в системе источнике есть:
неисторичная таблица КЛИЕНТ с полем ИМЯ (в которой при изменении данные просто апдейтятся)
и историчная таблица АДРЕС_КЛИЕНТА с историей всех адресов клиента (т.е. в самом простом виде там есть поля КЛИЕНТ_ИД + ДАТА_С + ДАТА_ПО + АДРЕС)
В IL же у вас есть одна общая таблица КЛИЕНТ с атрибутами ИМЯ и АДРЕС, в которой реализовано SCD2. Соответственно:
как вы обрабатываете изменения данных в таблицах с точки зрения корректного выстраивания историчности? Есть ли какая-либо договоренность с "бизнесом" на тему "как трактовать и какой датой отражать изменения в "неисторичных" таблицах источников?
есть ли правки "задним числом" и если да, то как вы их загружаете в IL?
1) У нас DL историчный, так как мы все почти грузим SCD2 (то есть даже неисторичные таблицы источников у нас обретают историю). На IL формируем таблицу с датами valid_from/valid_to по изменениям обеих таблиц (так как есть история на DL).
С бизнесом договоренности есть только по витринам на BL, так как бизнес не знает о всей логике хранилища - отображаем неисторичное на дату последнего изменения (то есть на текущий момент значения).
2) Если случаются на источнике такие правки, то перегружаем DL/IL таблицы с нужной даты или за все время.
Я правильно понял, что у вас история копируется и в слой IL? Как вы тогда обрабатываете генерацию суррогатных ключей для кажой версии записи? Например есть две таблицы dim_sku и dim_brand. dim_sku ссылается на dim_brand по суррогатному ключу. Что если приходит новая версия бренда и для неё генерится новый суррогат. Вы в dim_sku перебиваете ссылку на новый бренд или также генерите новую версию с новой ссылкой на бренд?
Можете рассказать какими механизмами переносите на слой Data Layer (DL) из Source systems?
В Vertica 7 Тб данных на 5 узлов в которых 160 CPU и 2,5Tb RAM.
Если посчитать TCO на 1 TB то будет очень больно.
И при этом они с оракла на гп переходят, а не с вертики :)
Как раз зашёл сказать, что оракл тянет 60 тб (представляю эту фулфлеш полку под ним), а чудо вертика всего 7.
А подоплека наверняка в том, что вертика сменила лицензию и теперь не докупить расширение для неё, надо покупать все с нуля.
Не будет больно, дешевле оракла почти на порядок...
ТСО это не только про лиц это еще про железо. Чтобы перейти на Вертика требуется купить железо, купить саппорт железа, саппорт оси, и только потом саппорт\лиц вертики.
Ну и кто то утверждает что Оракл дешевле будет? Просто когда у тебя базюлька всего на 7Тб (а скорее всего это get_complience который показывает размер исходной помойки, без сжатия) и закладываешь на нее 2,5Тб с 160 core, то это не может быть эффективным, исходя из моего 8-летнего опыта работы с MPP
Были ли у Вас такие ситуации или чтобы Вы сделали в следующем: обнаружили что в 50-70 % данных в DL не хватает какого нибудь поля из источников. Например ДатаАктуальности.
Тупо пересобираем весь DL заново?
Спасибо, было интересно прочитать.
А почему в скрине с APEX названия русских городов в транслитерации? Это какой-то общий подход по максимуму интернационализировать содержимое в DWH или просто частный не показательный пример?
Спасибо за статью.
На vc.ru видел ваше статью о том, что вся логистика у вас на 1С.
Извините за дилетантский вопрос, но все же:
Как вы организовываете работу 1С с микросервисами?
Возможно дадите советы, как лучше организовать работу с данными из 1С с такой большой сложной системой.
Когда REST к 1С уже не обойтись, и нужны все срезы данных из 1С в реальном времени.
У меня микропроект, по сравнению с вами. Есть курс на нарезку монолита, перевод на микросервисы, контроль товародвижения нормальными механизмами, вынесенными из 1С, но почти все исторически в 1С и как-то этот двигатель нужно чинить на ходу на коленке :(
Хранители данных: как устроена работа с DWH в Lamoda