Когда витрина данных можно заменить массивом

Стратегия инкрементального наполнения витрин: необходимость, реализация, подводные камни

• Обработка этих данных требует значительного времени (и затрат ��)
• Исторические данные не меняются (или не должны меняться) — как правило, это свершившиеся факты
• Если Вам удается не делать повторную обработку исторических данных — Вы экономите время и затраты

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

• Что значит новые данные и как их выделить?
• Что значит добавлять?
• Как не потерять строки и не остаться с копиями строк?

Если нам удастся найти ответы на эти вопросы — мы сумеем строить Хранилище более оптимальным способом!

Необходимость инкрементального расчета на реальном примере

Предлагаю попробовать найти решение на примере, приближенном к реальности. Рассмотрим сферу транспорта и передвижения по городу:

• Имеем координаты начала и окончания маршрута (широта / долгота — lat / lon)
• Справочник ГЕО-зон, включающий улицы, районы города, вокзалы, аэропорты, Points of interest (музеи, торговые центры и т.д.)
• Возможность выполнить Spatial Join в СУБД, то есть найти привязку точки на карте конкретной ГЕО-зоне (или нескольким)

Учитывая тот факт, что Spatial Join является довольно затратной (CPU-intensive) операцией, а также то, что маршрут поездки, как правило, не может меняться после её окончания, мне представляется очень удобным накапливать эти данные инкрементальным образом. Исходный запрос выглядит следующим образом:

select -- IDs orders.request_id , orders.city_id -- PICKUP , pickup.kind as pickup_kind , pickup.zone_name as pickup_zone , coalesce(pickup.is_airport, false) as pickup_is_airport -- DROPOFF , dropoff.kind as dropoff_kind , dropoff.zone_name as dropoff_zone , coalesce(dropoff.is_airport, false) as dropoff_is_airport -- METADATA , orders.__metadata_timestamp from > as orders left join > as pickup on ST_Intersects( ST_Point(orders.pickup_position_lon, orders.pickup_position_lat), pickup.geometry) left join > as dropoff on ST_Intersects( ST_Point(orders.dropoff_position_lon, orders.dropoff_position_lat), dropoff.geometry)

Эволюционно, этот запрос мог проделать следующий путь:

• Создадим VIEW для получения всех результатов на момент запроса
• Как только запросы станут слишком долгими, материализуем результаты в виде TABLE
• Когда расчет таблицы станет слишком долгим и дорогостоящим — рассмотрим применение стратегию INCREMENTAL

Как реализовать инкрементальную стратегию наполнения на уровне DDL/DML команд?

1. Первый запуск – полный пересчет из исходных данных

Здесь всё понятно. Пока у нас не сформирована витрина ни в каком виде, придется переварить весь набор данных из исходных таблиц.

• Для любого последующего запуска – идентифицировать новые записи (дельта / delta)

В этом может помочь либо монотонно возрастащий ключ (sequence), либо временная метка (timestamp) создания или обновления записи.

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

create temp table int_requests_zones_tmp as ( select -- IDs orders.request_id , orders.city_id -- PICKUP , pickup.kind as pickup_kind , pickup.zone_name as pickup_zone , coalesce(pickup.is_airport, false) as pickup_is_airport -- DROPOFF , dropoff.kind as dropoff_kind , dropoff.zone_name as dropoff_zone , coalesce(dropoff.is_airport, false) as dropoff_is_airport -- METADATA , orders.__metadata_timestamp from > as orders left join > as pickup on ST_Intersects( ST_Point(orders.pickup_position_lon, orders.pickup_position_lat), pickup.geometry) left join > as dropoff on ST_Intersects( ST_Point(orders.dropoff_position_lon, orders.dropoff_position_lat), dropoff.geometry) -- GET DELTA ROWS ONLY where orders.__metadata_timestamp >= (select max(__metadata_timestamp) as high_watermark from "intermediate"."int_requests_zones_tmp") )

• Записать дельту в основную таблицу

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

Сделать это можно несколькими способами, в зависимости от того, что поддерживает используемая Вами СУБД:

• DELETE + INSERT (удалить старые версии строк и вставить новые целиком)
• Операция MERGE (UPSERT) — оптимизированная версия UPDATE + INSERT
• INSERT OVERWRITE (замена целых партиций)

delete from "intermediate"."int_requests_zones_tmp" where request_id in (select request_id from int_requests_zones_tmp) ; insert into "intermediate"."int_requests_zones_tmp" select * from int_requests_zones_tmp ; 

Схематично инкрементальную стратегию можно изобразить следующим образом:

dbt упрощает использование материализации incremental

dbt умеет строить инкрементальные модели из коробки. Компилируемый код уже адаптирован под возможности конкретной СУБД, будь то Redshift, Snowflake, BigQuery или даже Clickhouse! Делается это при помощи ряда конфигураций и Jinja-шаблонов:

1. Выбор типа материализации incremental :

• Формулируем правило нахождения дельты

Ранее мы использовали конструкцию:

-- GET DELTA ROWS ONLY where orders.__metadata_timestamp >= (select max(__metadata_timestamp) as high_watermark from >) 

Однако это должен быть фильтр, который применяется только для инкрементального запуска и игнорируется для полного пересчета:

where true and orders.__metadata_timestamp >= (select max(__metadata_timestamp) as high_watermark from >)

Обратите внимание на специальные переменные Jinja:

> обозначает существующий объект в СУБД, который однозначно соответствует данной модели dbt (в которой эта консутркция используется).

is_incremental() принимает значение True при соблюдении следующих условий:

• В СУБД уже существует таблица, соответствующая модели dbt
• Модель сконфигурирована на материализацию incremental (см. пункт 1)
• Запуск осуществляется без флага —full-refresh (в противном случае будет полный пересчет витрины)

Обратная сторона и ограничения инкрементальных моделей

Однако как и почти везде, у инкрементального подхода тоже есть ряд ограничений, недостатков и сложностей. В основном, они связаны со спецификой использования и характером поступления исходных данных:

• Late arriving data — данные, которые приходят не в порядке возникновения событий
• Сложности с расчетом оконных функций (window functions), требующих наличия всей выборки строк для корректных расчетов

В случае данных, которые приходят в DWH позже есть опасность просто потерять записи. Отловить такие кейсы могут помочь тесты данных:

Каким образом можно попробовать решить эту проблему? Увеличить интервал фильтр на look-back period! Например, на 3 часа назад:

where true and orders.__metadata_timestamp >= (select max(__metadata_timestamp) as high_watermark from >) - interval '3 hours'

Этот вариант уже означает, что я с меньшей вероятностью пропущу какие-либо строки, однако я 100% буду обрабатывать некоторый объем записей повторно, а значит мне придется выполнить ряд операций DELETE / INSERT / MERGE , чтобы избежать формирования дублирующих записей, что, конечно, в свою очередь скажется на производительности.

Чувствуете trade-off? Что-то приобретаем, что-то платим.

В свою очередь и look-back period не гарантирует 100% соответствия. Я сталкивался с ситуациями ошибок, пауз, отключений в пайплайнах Extract & Load, что look-back period в 3 часа было уже недостаточно. Можно, конечно, увеличивать интервал до 12, 24 или даже 48 часов, однако можно подумать и над альтернативным подходом.

Что если мы попробуем выполнить так называемый Anti-join?

 left join > on orders.request_id = >.request_id and orders.__metadata_timestamp = >.__metadata_timestamp where >.request_id is null

По сути это означает:

• взять либо совершенно новые записи ( request_id отсутствует в > )
• либо взять те request_id которые уже есть в > но имеют более свежий __metadata_timestamp (запись была модифицирована с полсднего расчета)

Здесь стоит обратить внимание на план запроса, ведь наша основная задача – выполнять расчеты только с дельтой. Если этот фильтр будет применен после обработки всего массива строк — всяческий смысл в инкрементальном подходе пропадает.

Посмотрите на пример неудовлетворительного плана запроса – фильтрация происходит после выполнения 2-х GEO-spatial joins:

И теперь пример желаемого плана запроса – сначала фильтруем строки, потом обрабатываем:

Инкрементальная стратегия — отличный паттерн, но не панацея

Инкрементальные модели предполагают некий tradeoff:

• Большинство таких моделей не гарантируют 100% точность
• Подразумевается дополнительная сложность в виде кода по обработке дельта-строк
• В погоне за точностью результатов можно потерять всяческие преимущества инкрементальности

Для применения этого паттерна однозначно есть хорошие кандидаты:

• Immutable event streams – append-only поток событий, которые не меняются
• Наличие в таблице надежной временной метки изменения записи updated_at

В свою очередь, не очень хорошие кандидаты на применение паттерна:

• Относительно небольшие таблицы
• Частые изменения в данных: новые колонки, названия атрибутов и т.д.
• Строки могут быть модифицированы в непредсказуемом порядке
• Логика расчета требует наличия всего массива строк (оконные функции)

Умение упрощать и оптимизировать хотят видеть нанимающие менеджеры

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

На live-сессиях я и мои коллеги делимся своим опытом и реальными кейсами:

• Продвинутое моделирование и Data Vault
• dbt + подготовка собственных модулей к нему
• Data Testing + Slim Continous Integration
• Materialized Views
• И многое другое

Реальные специалисты отрасли, практические знания, проекты с использованием ресурсов Яндекс.Облака. Если Вам стало интересно, изучите программы и приходите на вебинары DWH Analyst.

Также своими наблюдениями, опытом и практиками я делюсь в ТГ-канале Technology Enthusiast.

Напишите в комментарий, если сталкивались с необходимостью строить инкрементальные модели, и каким образом решали эту задачу?

Как построить современное аналитическое хранилище данных на базе Cloudera Hadoop

В конце прошлого года GlowByte и Газпромбанк сделали большой совместный доклад на конференции Big Data Days, посвященный созданию современного аналитического хранилища данных на базе экосистемы Cloudera Hadoop. В статье мы рассказали об опыте построения системы, сложностях и вызовах, с которыми пришлось столкнуться и преодолеть, чтобы достичь успеха в проекте.

Появление технологии Hadoop десятилетние назад вызвало на рынке интеграции данных небывалый ажиотаж и оптимизм. Индустрия задалась вопросом — «а готова ли технология вытеснить традиционные системы обработки данных?». За прошедшую декаду было сломано немало копий в этой битве. Кто-то успел разочароваться, кто-то добился локальных успехов, а тем временем сама экосистема прошла короткий, но стремительный эволюционный путь, который позволяет уверенно сказать, что в настоящий момент не существует задачи и вызова в области обработки и интеграции данных, которую не способен решить Hadoop.

В этой статье мы попытаемся дать ответ на главный вопрос — как создать современное аналитическое хранилище данных на базе экосистемы Cloudera на примере проекта, реализованного нами в “Газпромбанк” АО. Попутно расскажем как мы справились с основными вызовами при решении задачи.

“Газпромбанк” АО — один их ведущих системообразующих финансовых институтов РФ. Он входит в топ-3 банков по активам России и всей Восточной Европы и имеет разветвленную сеть дочерних филиалов.

Банк традиционно на рынке финансовых услуг был консервативным и ориентировался на корпоративный сектор, но в 2017 году принял стратегию “Цифровой трансформации” с целью развития направления розничного бизнеса.

Розничный банковский сектор является высококонкурентным в РФ и для реализации стратегии Газпромбанку потребовалось создание новой технологической платформы, которая должна удовлетворять современным требованиям, так как основой интенсивного роста на конкурентном рынке могут быть только data driven процессы.

На тот момент в Банке уже было несколько платформ интеграции данных. Основная платформа КХД занята классическими, но критичными с точки зрения бизнеса задачами: управленческой, финансовой и регуляторной отчетности. Внесение изменения в текущую архитектуру КХД несло серьезные риски и финансовые затраты. Поэтому было принято решение разделить задачи и создавать аналитическую платформу с нуля.

Верхнеуровнево задачи ставились следующие:

• Создание озера данных (как единой среды, в которой располагаются все необходимые для анализа данные);
• Консолидации данных из озера в единую модель;
• Создание аналитический инфраструктуры;
• Интеграция с бизнес-приложениями;
• Создание витрин данных;
• Внедрение Self-service инструментов;
• Создание Data Science окружения.

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

• Обеспечение данными бизнес-приложений: аналитический CRM, Real Time Offer, Next Best Offer, розничный кредитный конвейер;
• Возможность работы с сырыми данными из систем-источников as is (функция Data Lake);
• Среда статистического моделирования;
• Быстрое подключение новых систем источников к ландшафту;
• Возможность обработки данных за всю историю хранения;
• Единая модель консолидированных данных (аналитическое ядро);
• Графовая аналитика;
• Текстовая аналитика;
• Обеспечение качества данных.

• Высокая производительность при дешевом горизонтальном масштабировании;
• Отказоустойчивость и высокая доступность;
• Разделяемая нагрузка и гарантированный SLA;
• ELT обработка и трансформация данных;
• Совместимость с имеющимися Enterprise решениями (например, SAP Business Objects, SAS);
• Ролевая модель доступа и полное обеспечение требований информационной безопасности.

Кроме этого, система должна быть линейно масштабируемой, основываться на open source технологиях, и самое главное — соотношение стоимость\производительность должно быть самым конкурентным из всех предложений на рынке.

Для создания единой аналитической платформы розничного бизнеса мы выбрали стек Hadoop на базе дистрибутива Cloudera Data Hub

Архитектура решения

Рассмотрим архитектуру решения.

Система разделена на два кластера Cloudera Data Hub. Кластер регламентных процессов и Лаборатория данных

1. Кластер регламентных процессов

Все регламентные источники данных подключаются к данному кластеру. Все регламентные ETL расчеты также работают на этом контуре. Все системы потребители данных “запитываются” из регламентного кластера. Таким образом выполняется жесткая изоляция непредсказуемой пользовательской нагрузки от критичных бизнес процессов.

В настоящий момент к Hadoop подключено свыше 40-ка систем-источников с регламентом от t-1 день до t-15 минут для batch загрузки, а также real-time интеграция с процессинговым центром. Регламентный контур поставляет данные во все системы розничного бизнеса:

• Аналитический CRM;
• Розничный кредитный конвейер;
• Антифрод система;
• Система принятия решений;
• Collection;
• MDM;
• Система графовой аналитики;
• Система текстовой аналитики;
• BI отчетность

2. Кластер пользовательских экспериментов “Лаборатория данных”

В то же время, все данные, которые загружаются на регламентный контур в режиме онлайн, реплицируются на контур пользовательских экспериментов. Задержка по времени минимальная и зависит только от пропускной способности сетевого канала тк контур лаборатории данных находится в другом ЦОДе. Те пользовательский контур одновременно выполняет роль Disaster Recovery плеча в случае выхода из строя основного ЦОДа.

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

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

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

Система мониторинга и управления кластерами, загрузками, ETL, реализована на дополнительных виртуальных машинах, не включенных напрямую в кластера Cloudera.

Сейчас версия дистрибутива CDH 5.16.1. В архитектурный подход закладывалась ситуация выхода из строя двух любых узлов без последующей остановки системы.

Характеристики Data узлов следующие: CPU 2×22 Cores 768Gb RAM SAS HDD 12x4Tb. Все собрано в HPE DL380 в соответствии с рекомендациями Cloudera Enterprise Reference Architecture for Bare Metal Deployments. Такой “необычный”, как кому-то может показаться, сайзинг связан с выбором подхода по ETL и процессингового движка для работы с данными. Об этом немного ниже. Необычность его в том, что вместо “100500” маленьких узлов, мы выбираем меньше узлов, но сами узлы “жирнее”.

Основные технические вызовы

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

• Выбор основного процессингового движка в Hadoop;
• Подход по трансформации данных (ETL);
• Репликация данных «Система-источник –> Hadoop» и «Hadoop –> Hadoop»;
• Изоляция изменений и консистентность данных;
• Управление конкурентной нагрузкой;
• Обеспечение требований информационной безопасности

Далее рассмотрим каждый из этих пунктов детально.

Выбор основного процессингового движка

Горький опыт первых попыток некоторых игроков реализовать ХД в Hadoop 1.0 показал, что нельзя построить систему обработки данных руками java программистов, не имеющих опыта построения классических ХД за плечами, не понимающих базовых понятий жизненного цикла данных, не способных «отличить дебет от кредита» или «рассчитать просрочку». Следовательно, для успеха нам надо сформировать команду специалистов по данным, понимающих нашу предметную область и использовать язык структурированных запросов SQL.

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

Для нас это означало что необходимо выбрать «правильный» SQL движок для работы с данными в Hadoop. Остановили свой выбор на движке Impala так как он имеет ряд конкурентных преимуществ. Ну и собственно ориентация на Impala во многом и предопределила выбор в пользу Cloudera как дистрибутива Hadoop для построения аналитического хранилища.

Чем же Impala так хороша?

Impala – движок распределенных вычислений, работающий напрямую с данными HDFS, а не транслирующий команды в другой фреймворк вроде MapReduce, TEZ или SPARK.

Impala – движок который большинство всех операций выполняет в памяти.

Impala читает только те блоки Parquet, которые удовлетворяют условиям выборки и соединений (bloom фильтрация, динамическая фильтрация), а не поднимает для обработки весь массив данных. Поэтому в большинстве аналитических задач на практике Impala быстрее, чем другие традиционные MPP движки вроде Teradata или GreenPlum.

Impala имеет хинты, позволяющие очень легко управлять планом запроса, что весьма важный критерий при разработке и оптимизации сложных ETL преобразований без переписывания запроса.

Движок не разделяет общие ресурсы Hadoop с другими сервисами так как не использует YARN и имеет свой ресурсный менеджмент. Это обеспечивает предсказуемую высоко конкурентную нагрузку.

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

Вот как работа с Hadoop выглядит глазами аналитика:

Это работа в веб-ноутбуке Hue, который идет вместе с Cloudera. Не обделены и те пользователи, кто предпочитает работать с классическими толстыми SQL клиентами или сводными таблицами Excel.

Многие кто читал рекомендации Cloudera, могут задаться вопросом – а почему Impala не рекомендована как ETL движок, а только как движок пользовательского ad-hoc или BI доступа? Ответ на самом деле прост — Impala не имеет гарантии исполнения запроса «чтобы не стало» в отличие от Hive. Eсли падает запрос или узел, то запрос автоматически не перезапустится и поднимать его надо вручную.

Это проблема легко решаема – ETL поток или запрос в приложении должны уметь перезапускаться в таких ситуациях.

ETL потоки в нашем решении перезапускаются без вмешательства администратора автоматически:

• При падении запроса происходит автоматический анализ причины;
• При необходимости автоматически подбираются параметры конкретного запроса или параметры сессии чтобы повторный перезапуск отработал без ошибок;
• Выполняется сбор статистической информации по ошибкам для дальнейшего анализа и настройки потока чтобы в будущем по данному запросу или job’у таких ситуаций не возникало.

У нас на проекте сложилась парадоксальная ситуация — команда аналитиков и инженеров по данным, работающих над проектом, знала про Hadoop только то, что на логотипе есть желтый слоник. Для них Hadoop — это привычный SQL. Уже после “уборки урожая” (завершения разработки аналитического слоя, о котором речь пойдет ниже), ребята попросили провести для них обучение по Hadoop чтобы быть “в теме”.

Подход по трансформации данных

В разработке трансформации данных важно не только выбрать правильный движок, но и принять правильные стандарты разработки. У нас давно сформировался подход к таким задачам как metadata driven E-L-T при котором трансформация данных отрисовывается в диаграмме ETL инструмента, который в свою очередь генерирует SQL и запускает его в среде исполнения. При этом SQL должен быть максимально оптимальным с точки зрения конкретной среды исполнения. На рынке не так много ETL инструментов, позволяющих управлять генерацией SQL. В данном внедрении использовался инструмент SAS Data Integration.

Весь регламентный ETL выполнен в подходе metadata driven ELT. Никаких ручных скриптов с планировкой на airflow!

Такой подход позволяет

• Автоматизировать процессы управления метаданными;
• Автоматизировать процесс построения lineage данных как средствами самого ETL инструмента, так и средствами доступа к API;
• Повысить качество процессов внесения изменений и управления данными т.к. вся информация о зависимостях всех объектов и всех job’в хранится в метаданных ETL инструмента.
• Использовать CI/CD процессы в разработке

SAS DI позволяет визуализировать граф зависимостей в штатном функционале или можно выгрузить метаданные через API и использовать их для анализа в других средах.

Репликация данных

Загрузка данных в систему – ключевая отправная точка реализации функциональных бизнес требований системы.

Для этой функции был разработан специализированный инструмент – Data Replicator. Инструмент позволяет в очень короткие сроки подключать системы источники и настраивать загрузку данных в Hadoop.

• Синхронизация метаданных с источника;
• Встроенные механизмы контроля качества загруженных данных;
• Загрузка в различных режимах работы в т.ч. полная копия, извлечение и загрузка инкремента (по любой скалярной детерминированной функции), архивация данных источника и т.д.

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

Другая очень важная функция Data Replicator’а — автоматическая репликация данных с регламентного кластера Hadoop на DR кластер. Данные, загружаемые из систем-источников реплицируются автоматически, для деривативных данных существует API. Все регламентные ETL процессы, при обновлении целевой таблицы вызывают API которое запускает процесс мгновенного копирования изменений на резервный контур. Таким образом, DR кластер, который так же выполняет роль пользовательской песочницы, всегда имеет «свежие» данные.

Нами реализовано множество конфигураций для различных СУБД используемых как источники в ГПБ, также для других процессинговых движков Hadoop (для случаев когда другой кластер Hadoop является источником данных для системы) и есть возможность обрабатывать данные, загруженные в систему другими инструментами, например kafka, flume, или промышленный ETL tool.

Изоляция изменений и консистентность

Любой кто работал в Hadoop сталкивался с проблемой конкурентного доступа к данным. Когда пользователь читает таблицу, а другая сессия пытается туда записать данные, то происходит блокировка таблицы (в случае Hive) либо пользовательский запрос падает (в случае Impala).

Самое распространенное решение на практике – выделение регламентных окон на загрузку во время которых не допускается работа пользователей, либо каждая новая порция загрузки записывается в новую партицию. Для нас первый подход неприемлем тк мы должны гарантировать доступность данных 24х7 как по загрузке так и по доступу. Второй подход не применим т.к. он предполагает секционирование данных только по дате\порции загрузке, что неприемлемо если требуется отличное секционирование (по первичному ключу, по системе источнику и т.д.). Так же второй метод приводит к избыточному хранению данных.

Забегая вперед хочется отметить, что в настоящее время в HIVE 3 проблемы решена путем добавления поддержки ACID транзакционности, но, в нашей версии дистрибутива у нас далеко не третий Hive (да еще и на Map Reduce), а хотим получить высокую производительность и конкурентную нагрузку и поэтому нам пришлось реализовать ACID для Impala в Hadoop самостоятельно.

В нашем решении изоляция выполнена с применением подхода HDFS snapshot и разделения слоя хранения и доступа к данным через VIEW.

Когда данные записываются в HDFS, сразу, мгновенно создается снапшот на который переключается VIEW.

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

Все что остается делать – это переключать VIEW на новые HDFS снапшоты, число которых определяется максимальной длительностью пользовательских запросов и частотой обновления данных в Hadoop. Те в сухом остатке мы получаем аналог UNDO в Oracle, retention период которого зависит от количества снапшотов и регламента загрузки данных.

Основной секрет в том, что как только процессинговый движок определил какие данные из HDFS он должен прочитать, после этого DDL VIEW или таблицы может быть изменен т.к. оптимизатор больше не будет обращаться к словарю metastore. Т.е. можно выполнить переключение VIEW на другую директорию.

Функционал HDFS Snapshot настолько легковесный и быстрый что позволяет создавать сотни снапшотов в минуту и никак не влияет на производительность системы.

Изоляции изменений в нашем решении также является функцией DataReplictor’а. Все загружаемые данные изолируются автоматически, причем на обеих контурах системы, а производные ETL данные изолируются через вызов API. Каждое изменение целевого объекта, которое происходит в рамках ETL процесса завершается вызовом API по созданию снапшота и переключению VIEW.

Благодаря такому решению, все загрузки и все данные доступны в режиме 24х7 без регламентных окон. HDFS снапшоты не приводят к большому избыточному хранению данных в HDFS. Наш опыт показал, что для часто меняющихся регламентных данных хранение снапшотов за трое суток приводит к увеличению размера максимум на 25%.

Управление конкурентной нагрузкой

Следующий большой блок требований – управление конкурентной нагрузкой.

На практике это означает что нужно обеспечить

• Предсказуемую работу регламентных процессов;
• Приоритизация пользователей в зависимости от принадлежности к ресурсной группе;
• Отсутствие, минимизация или управление отказами в обслуживании;

Как это обеспечено на практике

• Настроено разделение ресурсов между сервисами Hadoop на уровне ОС через cgroups;
• Правильное распределение памяти между нуждами ОС и Hadoop;
• Правильное распределение памяти внутри кластера между служебными сервисами Hadoop, YARN приложениями и Impala;
• Выделение ресурсных пулов Impala отдельным пользовательским группам – для гарантии обслуживания и приоритизации запросов.

Результат – предсказуемая высококонкурентная нагрузка десятков пользователей одновременно и десятков тысяч ETL запросов в сутки без влияния на другие составляющие экосистемы Cloudera.

Ри. Количество SQL запросов, завершающихся каждую секунду.

В настоящий момент на кластере регламентных расчетов в сутки регистрируется и успешно выполняется в среднем 900 тыс SQL запросов по трансформации и загрузке данных. В дни массовых загрузок и расчетов эта цифра поднимается до полутора миллионов.

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

Информационная безопасность

В финансовом секторе традиционно вопросы информационной безопасности являются одними из самых ключевых тк приходится работать с данными, которые не только подлежат защите с тз федерального законодательства, но и с требованиями, которые периодически ужесточаются госрегулятором. При выборе дистрибутива Hadoop стоит особое внимание уделять этим требованиям, так как большинство не вендорских сборок, либо сборок, спроектированных на базе популярных open source дистрибутивов (например Apache Big Top) не позволяют закрывать часть требований и при выводе системы в промышленную эксплуатацию можно столкнуться с неприятными сюрпризами недопуска системы от службы ИБ.

В кластере Cloudera нами были реализованные следующие требования:

• Ролевая модель доступа к данным
  • Все пользователи включены в группы Active Directory (AD) каталога;
  • Группы AD зарегистрированы в Sentry;
  • В Sentry выполнено разграничение доступа для баз Impala и директорий HDFS;
  • Каждый Target слой данных имеет ролевые слои VIEW с ограничениями на чувствительные данные в соответствии с ролевой моделью доступа;
  • Пользовательские запросы;
  • Запросы ETL;
  • Точки интеграции Hadoop с другими системами;

  Единый аналитический слой данных

  Наличие общего слоя консолидированных данных – основное требование аналитического ХД.

  Без этого Hadoop (как и любое другое ХД) – озеро данных, которое пользователи начинают превращать со временем в неуправляемое болото. Поэтому важно иметь общую версию правды над этим озером чтобы все задачи решались в единой системе координат.

  Был разработан единый аналитический слой консолидированных данных. Источником для него является копия детального слой КХД, которая регулярно реплицируется в среду Hadoop, а также дополнительные источники, подключаемые напрямую, минуя КХД.

  Модель ориентирована на пользовательский ad-hoc доступ и проектировалась с учетом требований типовых задач клиентской аналитики, риск моделей, скоринга.

  Реализованы все области данных, необходимые для решения задач розничного бизнеса и моделирования такие как:

  • Аккредитивы;
  • Депозиты;
  • Залоги;
  • Заявки;
  • Карты;
  • Контрагенты;
  • MDM;
  • Кредиты;
  • Сегмент клиента;
  • Рейтинги;
  • Агрегаты;
  • Справочники;
  • Счета;
  • Эквайринг;
  • Векселя;
  • РЕПО;
  • Резервы.

  В настоящий момент, слой состоит из 177 целевых объектов и порядка 2350 бизнес-атрибутов. В snappy сжатии объем данных порядка 20 Тб (не менее 100 Тб в RAW).

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

  Реализованный единый слой — источник данных для производных прикладных витрин под бизнес-приложения, отчетность и модели. Сейчас у нас около 40 производных регламентных витрин, состоящих из 550 целевых таблиц и примерно 13200 атрибутов.

  Надежность

  Часто приходится слушать о ненадежности решений, спроектированных на Hadoop. За два года эксплуатации Cloudera Data Hub у нас практически не было каких-либо проблем, связанных с простоем системы. Случилось буквально пара инцидентов, повлиявших не регламентные процессы.

  Один раз у нас забилось место, выделенное под БД metastore (недостатки мониторинга).

  В другой раз была попытка выгрузить несколько сотен миллионов транзакций через Impala. В результате “прилег” координатор и другие пользователи и процессы не могли подключиться на этот координатор. Как результат выработали правило – каждый отдельный вид процессов (загрузка данных, ETL, пользователи, приложения) подключается к своему координатору, который еще имеет дублера для балансировки. Ну и конечно большие выгрузки данных в системы потребители лучше делать через sqoop export. Ну и в последних релизах Impala уже без проблем может отдавать десятки миллионов записей на подключение.

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

  Итоги

  В настоящий момент система является фабрикой данных всех розничных процессов Банка и аналитических приложений. Платформой ежедневно пользуется 36 департаментов и примерно 500 пользователей для самостоятельного решения задач по аналитике и моделированию.

  

  Реализованный нами проект стал финалистом номинации Cloudera Data Impact 2020 в категории Data For Enterprise AI.

  Выводы

  После двух лет промышленной эксплуатации нашей Системы мы сегодня с уверенностью можем сказать, то экосистема Hadoop полностью позволяет реализовать все современные требования к аналитической платформе при использовании дистрибутива Cloudera и при правильных архитектурных подходах. Система может полностью вытеснить все традиционные аналитические СУБД без какого-либо ущерба к накопленному опыту разработчиков и аналитиков. Нужно всего лишь принять правильные решения и сделать “прыжок веры”. Традиционно консервативный Газпромбанк сделал с нами этот “прыжок веры” и смог построить современную аналитическую платформу, ввязавшись в гонку на розничном рынке в кратчайшие сроки.

  Об успехах в цифрах можно посмотреть в записи нашего совместно доклада.

  Для проектирования современной аналитической системы не требуется гетерогенная архитектура слоеного пирога с пропитками из “гринпламов”, “тарантулов”, “игнайтов” и так далее. Все данные и сервисы работы с данными должны находится под управлением одной целостной системы. Такой подход снижает наличие дополнительных точек интеграции, а следовательно, и потенциальные отказы. Не требуются дополнительные работы и длительные сроки по интеграции и «пропитке» этих слоев данными.

  Наш архитектурный подход позволяет ускорить внедрение нового функционала и как следствие улучшить time to market новых продуктов, основанных на data driven процессах.

  В современных аналитических задачах не существует понятий горячих и холодных данных. Ситуация “прилета” пачки проводок, за диапазон t — 3-5 лет — это каждодневная регламентная ситуация. И для такого случая вы должны пересчитать остатки, обороты, просрочки и предоставить данные для модели или определения сегмента клиента в аналитическом CRM. Как я уже писал выше, чем глубже в истории данные, тем точнее ваши модели. Такие задачи можно решить только если все данные в одном месте и в одной системе. Наш принцип — все данные горячие!

  Для успешной реализации проектной команде недостаточно опыта знания технологии Hadoop. Hadoop это всего лишь инструмент. Необходимо применять подходы проектирования классического ХД на базе SQL MPP, иначе ваша система навсегда останется “помойкой” под архивные данные, нарисованной внизу слоеного пирога как “хранилище неструктурированных и холодных данных” на архитектурной картинке.

  Наши ближайшие планы

  В настоящий момент мы находимся в завершающей стадии миграции на новую платформу Cloudera Data Platform 7.1. Вполне вероятно, что на момент публикации мы уже на CDP и в ближайшее время тут будут опубликованы результаты. Пока, можно с уверенностью сказать, что после проведенных тестов, мы ожидаем ряд оптимизационных улучшений, связанных с Impala 3.4, появлением страничных индексов в parquet, наличием Zstd компрессии. Новые сервисы вроде Atlas и Cloudera Data Flow позволят закрывать функции управления данными и потоковой аналитики «из коробки». В ближашее время мы также планируем пилотировать родной для Cloudera BI инструмент — Cloudera Data Visualization.

  Что еще мы сделали в нашем ландшафте Hadoop:

  • Real-time интеграция системы с процессинговым центром с использованием Kudu (real-time клиентские данные, доступные для работы с минимальной задержкой наступления события). Горячие данные в Kudu, холодные в Parquet, общий «склеивающий» интерфейс доступа для пользователей через SQL Impala. Результат — данные в реальном времени о состоянии карточных транзакций и остатков по карточному счету открывают для бизнеса новые возможности.
  • Историзируемый слой ODS

  Построение слоя ODS с использованием Oracle Golden Gate с сохранением истории изменения источника с возможностью задания гранулярности истории по каждому объекту репликации, а также архивированием в Hadoop с возможностью «схлопывания» интервалов «холодных» данных.

  • Графовая аналитика
    • Построение витрины property графа в Hadoop;
    • Загрузка в графовую БД Arango;
    • Интерфейс работы с графом для андерайтеров над Arango;
    • Графовые модели (анализ окружения клиента при скоринге);
    • Работа моделей по распознаванию первичных документов клиента и поиска в них аномалий (контроль фронта, антифрод, автоматизация работы с заявкой);
    • Анализ новостных лент, тематических форумов
    • Анализ удаленности и проходимости офисов от основных пешеходных маршрутов, автомобильных проездов и парковок;
    • Оптимизация курьерских маршрутов

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

    Авторы:

    Евгений Вилков, ГлоуБайт.

    Колесникова Елена, Газпромбанк (АО).

    Мировые тренды работы с данными и лучшие практики построения хранилищ данных на базе российского ПО

    

    Лидирующие позиции вендора на ИТ-рынке определяются не только технологическим совершенством портфеля продуктов, размером партнёрской сети и качеством техподдержки. Мировые ИТ-лидеры приучили наши компании к тому, что вендор является ещё и носителем технологической «философии», помогающей клиентам уверенно прокладывать курс эффективного развития в неспокойном море геополитических и рыночных вызовов. Именно в таком ключе прошла конференция «Большие данные большой страны», которую организовала компания Arenadata.

    

    Естественная среда обитания крупного российского бизнеса — мир больших данных и цифровой трансформации. В этом мире до недавних пор тон задавали международные лидеры: Oracle, Teradata, SAP, Cloudera, Pivotal. Программно-аппаратные решения этих вендоров считались незаменимыми в сегменте высокопроизводительных продуктов для крупных организаций даже в те времена, когда разговоры об импортозамещении в различных сферах российской экономики уже перешли в фазу требований регуляторов. Однако прошедший год убедительно показал: в этой сфере незаменимых вендоров нет. И даже сама тема импортозамещения, похоже, перешла в разряд воспоминаний о волнующих, но прошедших временах, уступив место более актуальной повестке цифрового развития нашей страны.

    Это объясняет, почему тематика конференции Arenadata вызвала большой интерес у российских заказчиков. В мероприятии приняли участие свыше 1 200 представителей крупнейших российских организаций, включая ФНС России, «РЖД», «Лукойл», «Газпромбанк», X5 Group, «Промсвязьбанк», «Технониколь», «ПИК», «Альфа-Банк», «Русагро», «Норникель», «Дикси», «Северсталь», «Татнефть», «Комус», «Детский мир», «Ашан», ММК, ПСБ, «НЛМК», «Лента», «Росбанк», «Мегафон» и «Аэропорт Шереметьево».

    Ключевой темой конференции стало обсуждение технологических трендов, по которым сегодня развивается международный и российский ИТ-рынки. В своём докладе на эту тему сооснователь и технический директор Arenadata Александр Ермаков рассказал о том, какие подходы к работе с данными сегодня актуальны для международного ИТ-рынка: движение к распределённым облачным системам; переход на эластичную среду, предоставление технологий и решений как сервиса, к бессерверным и in-memory-вычислениям, нереляционным СУБД и AI Cloud Service. Также Александр остановился на том, какие «боли» заказчиков российского рынка можно решить благодаря новым архитектурным и инфраструктурным концепциям.

    Другой важной составляющей конференции стали доклады об опыте цифровизации в новых условиях, обзор кейсов мигрaции с западного ПО и построения хранилищ данных на базе российского стека от представителей компаний «Комус», «Ашан», ПСБ, X5 Group, ФНС, ММК и «Детский мир». Спикеры рассказали о том, с какими сложностями столкнулись в процессе реализации проектов и как их преодолевали; какие отечественные и Open source продукты выбрали для решения своих задач и какие ресурсы задействовали на пути к своей цели.

    Технологические тренды на рынке работы с данными

    Многолетний опыт информатизации предприятий в разных странах и секторах экономики однозначно говорит о том, что усиление цифровизации — это далеко не просто линейные процессы наращивания вычислительных ресурсов и ёмкости хранения данных. Речь идёт о принципиальных изменениях в архитектуре и принципах обработки больших данных. Отслеживание этих технологических трендов — хлеб ведущих исследовательских компаний вроде Gartner.

    

    Дорожная карта новых технологий

    В связи с этим Александр Ермаков приходит к парадоксальному (на первый взгляд) выводу: сегодняшние ИТ-лидеры — это вовсе не те компании, которые ушли с нашего рынка, а скорее те вендоры, которые позиционируют себя как Cloud Infrastructure или Cloud Platform. Причём полномасштабного перехода в облака пока не наблюдается нигде в мире, скорее мы видим различные гетерогенные конфигурации.

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

    Если в исторической перспективе посмотреть на развитие технологий и подходов, увидим, что в течение многих лет компании в основном занимались построением классических DWH, с которыми всё понятно и просто. Позднее появились озёра данных, или Data Lake, где можно хранить любые данные, которые покажутся полезными. И как результат плохого управления Data Lake стали появляться болота данных, или Data Swamp, в которых разобраться, что было загружено и как это использовать, уже невозможно.

    Для решения проблемы неупорядоченного роста данных и «болот данных» появилась концепция Data Governance. Она была призвана структурировать процессы, в том числе с помощью новой роли — Data Stewart’s (специалисты, отвечающие за правильную каталогизацию данных, соответствие таксономии и т. д.). Спустя какое-то время в компаниях стали появляться целые «океаны данных», или Data Ocean. Они представляют собой набор разрозненных структур хранения данных, предназначенных для обеспечения нужд разных подразделений организации.

    

    Экспоненциальный рост сложности процессов и ролей обработки данных

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

    Все вместе эти процессы постепенно заложили предпосылки для формирования новых подходов к архитектуре и инфраструктуре данных:

    ● Эластичная среда хранения и обработки данных

    

    ● Концепция Lakehouse

    Этот термин объединяет в одном платформенном решении возможности как обработки слабоструктурированных нереляционных данных, свойственных Data Lake, так и транзакционные операции, свойственные классическому DataWareHouse.

    ● Предметно-ориентированный дизайн (Domain Driven Design) модели данных

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

    Этот подход подводит к концепции Data Mesh, когда мы разделяем монолитную архитектуру с точки зрения команд и с точки зрения подходов к работе. Появляются микросервисы данных, которые позволяют решить проблему централизации. С учётом этих новых трендов запланировано и дальнейшее развитие платформы Arenadata EDP, в основе которой будет лежать концепция Cloud Native.

    

    Концепция новой платформы Arenadata EDP

    1. Разделение вычислений и хранения данных.
       Это очень важно, потому что система хранения по определению персистентная, то есть постоянно существующая инфраструктура, отказоустойчивая и масштабируемая. Вычислительная же часть должна быть максимально гибкой, способной адаптироваться к любым изменениям нагрузки или сценариев использования.
    2. Встроенные средства отказоустойчивости.
    3. Автоматизированный деплой: каждый вычислительный компонент «осознаёт себя», то есть понимает, какие действия необходимо предпринять.
    4. Средства автоматизированного масштабирования (auto scale out/down).
    5. Эффективные средства балансировки нагрузки.
    6. Встроенный Health Management.

    Практика: построение хранилищ данных на базе российского ПО

    «Комус»: техническая миграция с Oracle в облако VK

    О модернизации корпоративного хранилища данных «Комус» задумалась в 2020 году в связи с нарастающими проблемами с веб-аналитикой. На тот момент в компании работало хранилище SAP, а для веб-аналитики использовалось достаточное простое решение: содержимое виртуального журнала ClickStream.

    

    К тому времени, когда удалось получить бюджет на модернизацию, начались проблемы с поставками ИТ-оборудования, и тогда «Комус» взяла за основу облачный вариант Arenadata DB в VK Cloud. Миграцию требовалось провести очень быстро, поэтому выбрали вариант технической миграции, то есть не стали пересматривать тот подход к веб-аналитике, который был реализован в решении Oracle. В базе Oracle было создано около 100 таблиц для веб-аналитики, а над ней уже работает аналитическая система Tableau. Нужно было перенести всё в Arenadata DB таким образом, чтобы восемь юниверсов (логических наборов измерений и объектов, предназначенных для аналитической обработки) Tableau были основаны на данных из Arenadata DB. Приёмка завершённого проекта заключалась в сверке готовых витрин.

    

    Рис. Архитектура модернизированной аналитической системы компании «Комус»

    Проект, который выполнила компания Sapiens Solutions, начался в сентябре 2022 года и был завершён в марте 2023-го.

    

    Пока в ИТ-ландшафте компании остаётся три хранилища данных: SAP BW (комплексная система бизнес-аналитики на платформе SAP), старое хранилище на базе Oracle, которое используется для стандартизованной корпоративной отчётности, и аналитическое хранилище данных (АХД) на базе Arenadata DB. По оценке Александра Стулова, успешной реализации проекта помогло использование ETL-фреймворка, который состоял из таблиц метаданных и автоматизированных функций, упрощающих загрузку данных: через описание метаданных и одну функцию f_load_simple удалось реализовать до 60 % загрузок данных. Со всеми процедурами справилась за четыре месяца команда численностью шесть-семь человек.

    В результате компания получила новые возможности для развития продвинутой веб-аналитики в АХД на базе Arenadata DB. Витрины этого хранилища также предоставляют данные для команды аналитиков (80 дата-специалистов), использующих Jupyterhub. За счёт сжатия и поколоночного хранения в Arenadata DB удалось достичь существенной экономии в объёме хранилища: вместо 9 Тб, хранившихся ранее в Oracle, теперь 1,5 Тб. По оценке Павла Мартынова, наибольший вклад в стоимость старого решения вносили лицензионные платежи за функционал Oracle и регулярное наращивание количества жёстких дисков для хранилища на базе IBM, а Arenadata DB выходит на 20 % дешевле в перспективе нескольких лет.

    «Иннотех»: от компиляции данных и систем — к единой платформе данных

    Один из крупнейших российских банков выбрал Arenadata в качестве целевой технологии для своего хранилища и озера данных ещё в 2019 году. Помимо импортозамещения, перед банком стояла ещё одна непростая задача — интеграция ИТ-активов, систем и данных, которые стали частью технологического ландшафта компании после череды крупных слияний.

    

    Ядром концептуальной архитектуры платформы данных стало единое хранилище (ЦЕХ, целевое единое хранилище) и «озеро данных» как платформа анализа и обработки данных (DAPP, Data Analysis and Processing Platform). Data Lake предназначено главным образом для задач ad-hoc-аналитики и продвинутой аналитики. По оценке Владимира Громова, понадобится ещё около полугода для того, чтобы завершить полноценную миграцию в целевое хранилище. Следующим шагом станет замена технологической платформы оперативного хранилища (ODS) как с точки зрения хранения, так и с точки зрения загрузки данных.

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

    Леонид Шумский, начальник управления департамента перспективных проектов компании «Дататех» (входит в холдинг «Т1») рассказал о технических деталях реализации этого проекта:

    Специально для решения этих проблем специалисты «Дататех» разработали ETL-фреймворк KORE.DWH — инструментарий загрузки данных в хранилище Arenadata DB. По сути, фреймворк KORE.DWH обеспечивает гибкую автоматизацию управления загрузками и построение распределённых транзакций загрузки.

    Data warehouse, Data Lake или Data Lakehouse: какое решение выбрать

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

    На рынке так много систем для хранения данных, что может быть трудно выбрать лучшую для вашего бизнеса. Чтобы избавить вас от мук выбора, мы сравнили три самых распространённых метода хранения данных: data warehouse, data lake и data lakehouse. Узнайте о них больше и подберите метод, который будет хранить ваши данные.

    Data Warehouse, Data Lake, Data Lakehouse: краткое резюме

    Хранилище данных (data warehouse) хранит преобразованные и структурированные данные из разных источников: CRM- и транзакционных систем, сервисов для создания рекламы и т. д. Бизнес-аналитики, маркетологи, дата-инженеры могут получить к ним доступ с помощью инструментов BI, SQL-клиентов и других аналитических приложений.

    Озеро данных (data lake) хранит полу- и неструктурированные данные, что позволяет загружать их в хранилище и использовать на усмотрение команды. Метод предполагает глубокую аналитику и машинное обучение. Кроме того, озеро данных стоит меньше базы данных, его проще настроить и масштабировать.

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

    Похожие публикации:

    1. Как найти i1 i2 i3 в физике формула
    2. Как открыть старую версию эжд
    3. Как поставить интеграл в ворде
    4. Как узнать длину массива в си