Содержание:
- 1. «Комус»: техническая миграция с Oracle в облако VK
- 2. «Ашан»: переход к единой модели данных распределённой компании в условиях мультиоблачности
- 3. ПСБ: создание единого безопасного хранилища данных в «эпоху перемен»
- 4. X5 Group: спасение аналитики на сотнях терабайтов данных
- 5. ФНС России: единая интеграционно-аналитическая платформа ведомства на базе Arenadata
- 6. ММК: как построить хранилище данных в организации с очень сложным ИТ-ландшафтом
- 7. «Детский мир»: миграция функционала SAP HANA с экономией ресурсов
«Комус»: техническая миграция с Oracle в облако VK
О модернизации корпоративного хранилища данных «Комус» задумалась в 2020 году в связи с нарастающими проблемами с веб-аналитикой. На тот момент в компании работало хранилище SAP, а для веб-аналитики использовалось достаточное простое решение: содержимое виртуального журнала ClickStream«С течением времени объём базы веб-аналитики превысил 9 Тб, и это решение нас совсем перестало устраивать, ведь у нас в планах было дальнейшее активное развитие аналитического функционала в сторону продвинутой аналитики»
Рис. Архитектура модернизированной аналитической системы компании «Комус»
Проект, который выполнила компания Sapiens Solutions, начался в сентябре 2022 года и был завершён в марте 2023-го.
«В качестве ТЗ мы использовали Oracle-скрипт. Мы знали, что если будем изменять логику загрузки, то итоговые витрины могут оказаться разными, а этого нельзя было допустить»
В результате компания получила новые возможности для развития продвинутой веб-аналитики в АХД на базе Arenadata DB. Витрины этого хранилища также предоставляют данные для команды аналитиков (80 дата-специалистов), использующих Jupyterhub. За счёт сжатия и поколоночного хранения в Arenadata DB удалось достичь существенной экономии в объёме хранилища: вместо 9 Тб, хранившихся ранее в Oracle, теперь 1,5 Тб. По оценке Павла Мартынова, наибольший вклад в стоимость старого решения вносили лицензионные платежи за функционал Oracle и регулярное наращивание количества жёстких дисков для хранилища на базе IBM, а Arenadata DB выходит на 20 % дешевле в перспективе нескольких лет.
Смотреть полную версию доклада >>
«Ашан»: переход к единой модели данных распределённой компании в условиях мультиоблачности
«Примерно полтора года назад мы поняли, что корпоративное хранилище, которое у нас было на тот момент, не отвечает необходимым техническим требованиям. Нужна MPP-платформа — гибкая и легко масштабируемая»
Рис. Структура данных российского сегмента торговой сети «Ашан»
Arenadata DB была развёрнута в двух облаках: клиентские данные хранятся в облаке VK Cloud, а коммерческие данные — в CROC Cloud. Кроме того, по-прежнему используется старое корпоративное хранилище on-premise — оно отвечает за визуализацию. Хранилище данных для клиентской аналитики «Ашана» помогала создавать компания Glowbyte.
«Особенностью проекта можно считать большое количество конечных потребителей данных. К их числу можно отнести даже конечных клиентов, потому что они получают персонализированные скидки, личные предложения и т.д.»
Текущий объём хранилища клиентских данных российской сети «Ашан» составляет 10 Тб. В компании говорят, что возможности продуктов Arenadata позволяют выполнять все текущие задачи без каких-либо задержек на стороне потребителей. Это 5 млн чековых позиций ежедневно, 600 атрибутов, отражающих клиентское поведение по 8 млн клиентов, что даёт ежедневную обработку 500 млн строк для связки «клиент — товары». При этом в сети запускается приблизительно сотня маркетинговых кампаний в месяц. А после автоматизации целевого маркетинга эта цифра увеличится до 200–300. Но на производительности системы это не скажется существенно, ведь, как рассказывают в торговой сети, обращения идут к конкретным, предварительно рассчитанным сегментам, которые актуальны на текущий день.
Смотреть полную версию доклада >>
ПСБ: создание единого безопасного хранилища данных в «эпоху перемен»
Екатерина Варламова, директор департамента управления данными ПАО ПСБ, отметила, что мы живём в эпоху перемен и это отразилось на задаче обновления системы управления корпоративными данными и хранилищами банка.«Внутренние факторы, стимулирующие преобразования, были подобны тем, что действовали в любом крупном банке: децентрализация хранилищ, сложные запутанные процессы управления данными, большое количество различных систем и процессов интеграции данных, недостаточный уровень управления качеством данных. В период 2020–2022 годов несколько раз очень значимо менялся контекст внешней среды, что неизменно сказывалось на сроках, приоритетах и объёмах задач как самого проекта, так и программы управления данными в целом»
Целевая архитектура управления данными ориентирована на централизацию: самого хранилища, хранения холодных данных (озеро Big Data), процессов извлечения и доставки данных и работы с внешними данными. Ряд элементов целевой системы в 2020 году либо находились на начальной стадии становления (например, управление мастер-данными), либо вообще отсутствовали, но были жизненно необходимыми, как, например, управление мастер-справочниками, каталогизация данных, системы управления качеством данных.
Банк провёл сравнительное тестирование СУБД кандидатов на роль технологической платформы для единого централизованного хранилища данных: Oracle Database, MS SQL Server, Arenadata DB и Postgres Pro. Архитектурно-технологический комитет банка в 2021 году утвердил продукты Arenadata в качестве технологического стандарта для разработки ЕХД и задач Big Data.
Рис. ИТ-архитектура банка ПСБ: 2020 vs 2023 год
В настоящее время система находится на стадии опытной эксплуатации. Её ключевыми элементами являются:
- аналитическое хранилище ЕХД, ядром которого является Arenadata DB;
- озеро данных на базе Arenadata Hadoop. «ПСБ Data collector» — собственная разработка, которая обеспечивает централизованную интеграцию данных из приёмников и их передачу непосредственно в контур хранилища;
- модель мониторинга качества данных — ещё одна собственная разработка банка, которая включает как технические, так и бизнес-проверки.
Смотреть полную версию доклада >>
X5 Group: спасение аналитики на сотнях терабайтов данных
Для X5 Group проект модернизации корпоративного хранилища данных также окрашен алармистскими красками. К началу 2022 года в компании было два хранилища данных. Большая часть аналитической нагрузки приходилась на хранилище SAP BW. «Хранилище строилось достаточно давно и играло ключевую роль в подготовке регуляторной отчётности, закрытии финансового периода», — рассказывает Павел Денисенко, руководитель управления архитектуры данных CDO X5 Group. Несколько лет назад была запущена целевая платформа по работе с данными, состоящая из озера данных на Hadoop, хранилища данных на Arenadata DB и набора BI-инструментов для доставки данных пользователям.Рис. Платформа работы с данными X5 Group
Хранилище SAP BW располагалось в облаке SAP HEC. Весной 2022 года возникла необходимость в кратчайшие сроки вынести данные из HEC на свои серверы, в свой ЦОД.
«Появилась поговорка: “Раньше мы покупали серверы, а теперь мы их добываем”. Но оперативно добыть железо такого уровня, которое смогло бы принять нашу сборку BW — самую крупную в Европе, — было невозможно»
Целевая платформа, основанная на кластере Arenadata DB, стабильно работала. «Его уже несколько раз расширяли, ведь Arenadata DB поддерживает горизонтальное масштабирование, и несколько раз проводили оптимизацию, — говорит Павел Денисенко. — Мы с коллегами из Arenadata очень плотно поработали в плане проведения аудита и достигли хорошего уровня SLA». Для данных в этом хранилище разработали устойчивую модель, которая к моменту санкционных потрясений была достаточно зрелой и поддерживала все ключевые сущности: чеки, остатки, продажи, справочники и т. д. К тому же в компании уже действовала проработанная система BI-решений и отдельный портал по работе с данными. По оценке Павла Денисенко, без этого в столь сжатые сроки вряд ли удалось бы перевести в новую систему такое большое количество пользователей. Уровень сложности задачи миграции он оценивает как максимально высокий: свыше 1 000 отчётов, более 10 000 пользователей, суммарный объём данных в хранилище после выполнения миграции с SAP BW достигал 300 Тб.
Таким образом, в X5 Group были созданы 54 новые витрины данных в EDW (ключевое требование — «как в BW»), обеспечена выгрузка данных в Qlik Sense для управленческой аналитики и в Hadoop — для продуктов Big Data. Была запущена новая система рассылок по технологии nPrinting и внедрены инструменты self-service-аналитики. Был внедрён кластер ClickHouse. Это значительно повысило для пользователей уровень доступности данных на платформе, что помогло взять стратегический курс на освоение новых технологий.
Смотреть полную версию доклада >>
ФНС России: единая интеграционно-аналитическая платформа ведомства на базе Arenadata
Архитектура новой единой интеграционно-аналитической платформы ФНС России (ЕИАП) создавалась на основе анализа требований ФНС к сбору, хранению и анализу данных.Было решено, что основой платформы станет озеро данных с соответствующим набором слоёв данных, функционирующее на базе продукта Arenadata Hadoop. В числе других ключевых архитектурных элементов — блоки «Управление метаданными», «ETL-инструментарий» и «Хранение данных».
После ввода ЕИАП в промышленную эксплуатацию объём сырых данных составил более 6 Пб. С ними ежедневно работает больше 20 тыс. активных ETL-задач. Более 50 проектов являются как потребителями, так и источниками данных.
Рис. Архитектура ЕИАП
Чуть больше 10 лет назад Федеральная налоговая служба России приступила к проектированию аналитического сегмента ФНС, и с тех пор основную программную платформу управления данными всех аналитических задач составляло ПО компании Teradata.
«На момент решения вопроса об импортозамещении в ЦОДах ФНС России функционировало несколько машин баз данных Teradata различной конфигурации, которые обеспечивали работу пользователей на различных контурах АИС «Налог-3»
В рамках реализации проекта предстояло перенести из систем Teradata в новое хранилище 30 приложений аналитических задач, около 50 форм статистической налоговой отчётности, свыше 48 тыс. объектов (таблицы, представления, хранимые процедуры, ETL-потоки) — всего приблизительно 95 Тб данных, размещённых на двух программно-аппаратных комплексах объёмом 66,0 и 28,67 Тб. С архитектурной точки зрения было принято решение разделить процедуры работы с данными на подпроцессы и использовать разные технологии. Так, источники для аналитических задач и сами данные были переведены на озеро данных, а часть расчётов и пользовательская нагрузка — на Areanadata DB. Это позволило, по оценкам специалистов «ГНИВЦ», кратно увеличить производительность конечных процессов и сократить количество информации, хранимой в СУБД.
Вначале была произведена миграция на ПО Arenadata ресурсоёмких задач, что позволило снять высокую нагрузку с текущего промышленного контура, где продолжали функционировать машины баз данных Teradata, и обеспечить оптимальную работу до завершения процессов миграции. На следующем этапе миграции на продукты Arenadata перешли блоки сложнозависимых и взаимоувязанных задач в части данных и процессов.
Процесс импортозамещения продолжается. В настоящий момент идут работы по замещению Oracle Exadata, и скоро эта система перестанет быть источником данных для аналитической платформы. Новая архитектура, основанная на российских продуктах, станет основой для АИС «Налог-4».
Смотреть полную версию доклада >>
ММК: как построить хранилище данных в организации с очень сложным ИТ-ландшафтом
Идея создания единого корпоративного хранилища данных возникла в ИТ-подразделении ММК ещё в 2018 году. Уже тогда стало понятно, что сотрудники тратят неоправданно много сил на то, чтобы из большого количества разрозненных систем — порядка 20 баз данных и 12 цехов — собирать данные для различной отчётности. При этом отчёты сильно нагружали ИТ-системы, которые были предназначены в первую очередь для оперативного учёта, и аналитическая нагрузка сильно мешала их работе.«Нашей целью было создание чисто инженерного решения: собрать данные в одно место, снять нагрузку с оперативных систем и предоставить пользователям возможности анализа объединённых данных»
«Коллеги получили хорошие результаты на нескольких бизнес-кейсах, и дальше последовало тиражирование на всю компанию. Таким образом, усложнение проекта происходило постепенно, и к этапу промышленной эксплуатации ММК пришёл с согласованной архитектурой хранилища. На этой базе уже начинается органический рост проекта, экспоненциальный рост количества пользователей и объёмов данных. В это же время пришло понимание того, что вместе с развитием хранилища нужно развивать и направление Data Governance, чтобы накопленные данные становились удобным и быстрым инструментом для анализа»
Рис. Архитектура пилотного проекта ММК
Дмитрий Ганаев вспоминает, что на этапе MVP комбинат поставил вендору практически немыслимые бизнес-условия: требовалось, чтобы данные, которые были загружены в хранилище, и данные, хранящиеся в оперативных системах, но ещё не выгруженные в DWH, могли объединиться в некотором отчёте. «Нам казалась фантастикой возможность объединить данные и создать одну таблицу, у которой одна партиция будет смотреть в оперативную систему, вторая — в систему аналитики, а третья, например, в архив Hadoop, — рассказывает он. — Но пилотный проект убедил нас: это возможно!» Кроме того, для витрин, которые рассчитывались на системах-источниках, как обычно, по ночам, выбрали самые высоконагруженные аналитические задачи и реализовали их на Arenadata DB, для того чтобы в целевой системе перенести эту нагрузку на хранилище.
В целевой архитектуре ММК ETL-фреймворк и загрузка данных реализованы с помощью Arenadata Streaming, а решение Arenadata Hadoop используется в первую очередь для работы модулей расчёта производственных показателей. В ближайших планах — решение задач предиктивной аналитики. Специалисты ММК думают о добавлении в текущий стек Arenadata QuickMarts для выноса витрин данных в этот продукт и присматриваются к решению Arenadata Catalog для решения задач Data Governance.
Цели, поставленные на старте проекта, достигнуты, констатирует Дмитрий Ганаев. Так, значительно упростился доступ аналитиков к данным: их теперь можно предоставлять, не выгружая в хранилище, сразу из нужной ИТ-системы с помощью расширения PXF. В целевую систему КХД переносится тяжёлая аналитика из производственных цеховых MES-систем, функционируют модули по очистке и подготовке данных для математического моделирования процессов. Развиваются системы BI-аналитики, с помощью которых построен действующий корпоративный аналитический портал. С экономической точки зрения компания ММК уже видит эффект экономии за счёт сокращения времени на настройку загрузки данных, уменьшения затрат на развитие аналитической системы, упрощения процессов администрирования загрузки данных.
Смотреть полную версию доклада >>
«Детский мир»: миграция функционала SAP HANA с экономией ресурсов
«Детский мир», как и многие другие компании, активно занимающиеся цифровизацией бизнеса, на определённой стадии этого процесса столкнулась с проблемой: в начале 2022 года анализ темпов наращивания данных показал, что к концу 2023 года не останется места на жёстких дисках корпоративного хранилища SAP BW и это грозит остановкой хранилища.«Анализ возможных альтернатив показал, что наилучшим решением для переноса аналитического хранилища является Arenadata DB. Эта СУБД позволяет не только решить проблемы, связанные с ростом объёмов данных, но ещё и ускорить расчёты, что напрямую влияет на скорость закрытия операций»
Рис. Схема гибридной миграции
Этот гибридный подход предполагает поэтапную миграцию, что соответствовало задачам «Детского мира» — как можно быстрее разгрузить хранилище на базе SAP HANA, пока окончательно не исчерпаны ресурсы хранилища. На практике это означает, что в ландшафт КХД добавляется MPP-СУБД Arenadata DB и осуществляется пошаговая миграция.
«Таким образом, тяжесть ядра КХД инкрементально смещается в сторону Arenadata DB»
Как рассказывает Антон Гельмут, для практической реализации гибридной миграции был разработан фреймворк, который обеспечивает четыре основные функции:
- генерация DDL для автоматизированного переноса объектов хранилища;
- генерация дагов (DAG — сущность, описывающая пайплайн в ПО оркестрации обработки больших данных Airflow) и ETL-процессов по значениям настроечной таблицы;
- решение проблемы «узкого горлышка» при загрузке данных в кластер ADB (Greenplum);
- организация инкрементальной загрузки данных.
Прочитать больше информации о проектах, реализованных на базе программных продуктов Arenadata, можно в разделе «Клиенты и проекты».