Простор для данных
Если коротко, то витрины (витрина от англ. data mart) – это набор структурированных данных. Обычно это данные по определенной теме или задаче в компании. Например, витрина с данными о заказчиках для отдела маркетинга может содержать подробные данные по договорам, истории заказов и поставок, оплатах, звонках и адресах доставки. Ничего лишнего, только нужные и актуальные очищенные данные, полученные из других ИС предприятия. Таких витрин даже на одном предприятии может быть множество.
Чаще всего с помощью витрин анализируют данные и строят ML-модели. Также витрины могут использоваться на предприятиях в качестве мастер-данных, например как справочники. Помимо этого, витрина может выступать периферическим узлом в сетях обмена данными между различными участниками. Примером концепции построения таких сетей для обмена данными является Data mesh (вот тут есть хороший перевод статьи по теме Хабр).
Типовой проект внедрения витрин состоит из технологической и прикладной частей. Если для решения технологических задач брать готовый инструмент, а не писать систему с нуля, то можно заложить больше ресурсов на прикладные задачи, которым зачастую уделяют незаслуженно мало внимания. Для B2B и других проектов, предполагающих внедрение множества витрин у различных заказчиков, готовый инструмент позволит существенно снизить технические риски, уменьшить затраты и сократить сроки внедрения.
Что требуется от витрины?
Сразу хотелось бы ответить на вопрос: а почему нельзя просто взять любую из существующих СУБД и сразу закрыть технологические задачи?
На самом деле, можно, но, как обычно, всё дело в деталях, а точнее в требованиях к витринам, которые нередко упускаются из вида и могут болезненно проявиться уже на поздних этапах, например при ОПЭ:
Изоляция данных. Обновление данных, например загрузка справочника, может быть растянуто во времени, при этом до окончания загрузки текущая версия справочника должна быть полностью доступна с исключением «грязного чтения» загружаемой версии.
Гарантии атомарности операций при обновлении данных. В случае сбоев и ошибок загрузки данных витрина остаётся в состоянии, которое предшествовало сбойному процессу. Другими словами, или данные обновляются полностью, или не обновляются вовсе, не оставляя следов сбойных операций.
Устойчивость к дубликатам изменений. Весьма сложно и дорого реализовывать во всех ИС-источниках данных выгрузку по принципу exactly-once. Наличие дублей одинаковых изменений объектов не должно приводить к нарушению логической целостности состояния витрин.
Системная темпоральность. Мало какая реляционная СУБД имеет функцию системной темпоральности «из коробки». Ведение системного времени и версионирование записей по системному времени позволяет сравнивать состояние данных витрины между двумя разными моментами времени или проводить «расследование», основываясь на данных, которые были в витрине в определенный момент в прошлом. Одним из вариантов обеспечения темпоральности является реализация SCD2 с ведением диапазонов сроков действия для версий записи.
Эффективное выполнение различных видов запросов: сравнительно редких и тяжелых аналитических запросов, затрагивающих большой объем данных (OLAP-нагрузка), и множества одновременных простых запросов (OLTP-нагрузка). Как правило, СУБД заточены на какой-то один вариант нагрузки: OLAP или OLTP.
Концепция
С середины 2020 года наша команда разрабатывает Систему, предназначенную для построения витрин данных. Начав с разработки прототипа, мы продолжили развивать функционал в рамках той же архитектуры. Сейчас это открытое программное обеспечение, которое мы используем при внедрениях витрин данных.
У нас в тех. проекте записано: «Простор – интеграционная система, обеспечивающая унифицированный интерфейс темпоральной реляционной СУБД к гетерогенному хранилищу данных». Гетерогенное хранилище позволяет использовать сильные стороны каждой из СУБД, входящих в состав хранилища, и не быть заложником недостатков одной из них.
В Просторе гетерогенное хранилище представлено такими СУБД:
Greenplum – аналитическая СУБД, предназначенная для OLAP-нагрузки. Хорошо горизонтально масштабируется, имеет высокий уровень поддержки стандарта SQL.
Clickhouse – аналитическая СУБД. Демонстрирует одни из лучших в классе показатели выполнения агрегационных запросов. Не полностью поддерживает SQL и имеет ряд иных ограничений при эксплуатации, например при изменении или удалении записей.
Tarantool – In-memory СУБД с персистентным хранением данных. Отличные показатели при OLTP-нагрузке (чтение отдельных записей). В кластерном режиме имеет ограничения по исполнению SQL-запросов.
PostgreSQL – всеми любимая реляционная СУБД. Хорошо держит OLTP-нагрузку, но горизонтально не масштабируется и, соответственно, не подходит для аналитических запросов с действительно большим объемом данных.
Состав СУБД хранилища данных можно изменять в зависимости от характера предполагаемой нагрузки или уже в процессе эксплуатации. Для небольших витрин можно использовать одну СУБД, например PostgreSQL. Для крупных витрин, содержащих большие объемы данных и предполагающих разнородные запросы, можно использовать различные сочетания, например Greenplum + Tarantool или Greenplum + Tarantool + Clickhouse.
Ядро системы – сервис, выполняющий роль координатора и диспетчера. Обеспечивает единый интерфейс доступа, маршрутизирует запросы, управляет процессами загрузки и выгрузки данных, контролирует целостность данных. Также ядро парсит входящие SQL-запросы и обогащает их до вида, готового к исполнению в той или иной СУБД. Непосредственно выполнением запросов занимаются СУБД хранилища.
Обмен большими объемами данных между витриной и поставщиками/потребителями этих данных выполняется через Kafka. Но если речь идет о небольших объемах данных (сотни записей), то загружать или читать данные можно напрямую через Ядро.
Ядро управляет специальными компонентами – коннекторами, предназначенными для массивно-параллельной загрузки данных из Kafka в СУБД хранилища и массивно-параллельной выгрузки данных в Kafka из СУБД хранилища.
С точки зрения пользователя
Если пользователем называть поставщика или потребителя данных, то с точки зрения такого «пользователя» Простор выглядит так:
Единый интерфейс доступа – JDBC 4.2. Подключиться к Простору можно как к обычной реляционной СУБД, например, используя SQL-клиент, в котором доступны все элементы логической модели и запросы к ним.
Единая логическая реляционная модель данных, скрывающая «под капотом» реальные физические модели данных СУБД хранилища.
При изменении логической модели данных автоматически изменяются и соответствующие физические модели в СУБД хранилища. Логическая модель – внешнее пользовательское представление модели данных витрины. Включает следующие логические сущности:
a. Логическая таблица (table) – для «пользователя» это обычная таблица, но с возможностью указать момент времени в прошлом, относительно которого требуется «наблюдать» данные таблицы.
Также для логической таблицы можно ограничить СУБД хранилища, в которых она будет физически расположена.
b. Логическое представление (view) – сохраненный именованный SQL-запрос, к которому можно выполнять запросы, также с возможностью указания момента времени «наблюдения» данных.
c. Логическое материализованное представление (materialized view) – необычная логическая таблица, новые или измененные данные в которую попадают автоматически на основании сохраненного запроса к другим логическим таблицам, расположенным в других СУБД хранилища. Особой возможностью запросов к логическим материализованным представлениям является автоматическое перенаправление такого запроса к исходным логическим таблицам, если отставание данных материализованного представления больше заданного предела. Материализованные представления позволяют реализовать более интересные варианты топологии витрины, в которых одна из СУБД исполняет роль отказоустойчивого мастера, а другая — содержит материализованные read-only-представления.
d. Логическая внешняя таблица – виртуальная таблица, по сути являющаяся указателем на источник или приёмник данных. Записывая или считывая данные из этой таблицы, можно управлять загрузкой и выгрузкой данных.
Язык запросов – подмножество стандарта SQL с дополнительными функциями и командами. Позволяет управлять состоянием, моделью данных и самими данными витрины. Запросы на выборку данных автоматически маршрутизируются в наиболее эффективную для их исполнения СУБД хранилища из доступных.
Отдельно стоит упомянуть механизм дельт, позволяющий «пользователю» указывать начало и конец логически целостной пачки изменений. Внешне этот механизм несколько напоминает ACID-транзакции, позволяя обрамить набор операций по изменению данных витрины командами начала дельты и ее окончания (комита).
Все изменения, выполненные в одной дельте, помечаются единой меткой времени комита дельты. Изменения данных, производимые в рамках открытой дельты, изолированы от пользовательских запросов с целью исключения «грязного чтения». Можно утверждать, что изменения в рамках дельты доступны для пользователя целиком и одномоментно или не доступны вовсе. Если необходимо, то открытую дельту можно откатить.
Неотъемлемой частью Простора как продукта является подробная открытая документация, обновляемая одновременно с выпуском каждого релиза. С перечнем базовых функций и примерами их использования можно ознакомиться по ссылке.
Заключение
Простор – система для построения витрин данных, доступная под лицензией Apache 2.0. Для тестирования и ознакомления с возможностями системы можно развернуть минимальную конфигурацию, где Простор использует в качестве хранилища только PostgreSQL. Инструкция по развертыванию доступна тут. Если объем данных для витрины не очень большой, то такая конфигурация может использоваться и для PROD.
Когда витрина данных можно заменить массивом
Видео: Анализ данных на языке SQL ч.4. Хранилища и витрины данных
Хранилище данных против витрин данных
Хранилище данных и витрина данных — это инструменты, используемые для хранения данных. Со временем маленькие компании становятся большими, и именно тогда они понимают, что накопили огромные объемы данных в различных отделах организации. У каждого отдела есть своя собственная база данных, которая хорошо подходит для этого отдела. Но когда организации намереваются сортировать данные из различных отделов для продаж, маркетинга или составления планов на будущее, этот процесс называется интеллектуальным анализом данных. Хранилище данных и витрины данных — два инструмента, которые помогают компаниям в этом отношении. В чем заключается разница между хранилищами данных и витринами данных и как они соотносятся друг с другом, — вот что цель этой статьи.
Хранилище данных
Это место, где хранятся все данные компании. На самом деле это очень быстрая компьютерная система с большой емкостью памяти. Он содержит данные из всех отделов компании, где он постоянно обновляется для удаления избыточных данных. Этот инструмент может ответить на все сложные запросы, касающиеся данных.
Витрина данных
Это система индексации и извлечения. Вместо того, чтобы помещать данные из всех отделов компании в хранилище, витрина данных содержит базу данных отдельных отделов и по запросу может предоставлять информацию, используя несколько баз данных.
ИТ-менеджеры любой растущей компании всегда не понимают, следует ли им использовать витрины данных или вместо этого переключиться на более сложные и более дорогие хранилища данных. Эти инструменты легко доступны на рынке, но создают дилемму для ИТ-менеджеров.
Разница между хранилищем данных и витриной данных
Важно отметить, что между этими двумя инструментами есть огромные различия, хотя они могут служить одной и той же цели. Во-первых, витрина содержит программы, данные, программное и аппаратное обеспечение конкретного подразделения компании. Могут быть отдельные витрины данных для финансов, продаж, производства или маркетинга. Все эти витрины данных разные, но их можно согласовать. Витрина данных одного отдела отличается от витрины данных другого отдела, и, несмотря на то, что она проиндексирована, эта система не подходит для огромной базы данных, поскольку она предназначена для удовлетворения требований конкретного отдела.
Хранилище данных не ограничивается конкретным отделом и представляет собой базу данных всей организации. Данные, хранящиеся в хранилище данных, более подробны, хотя индексирование не требует особых усилий, поскольку в нем хранятся огромные объемы информации. Это также сложно в управлении и требует много времени для обработки. Это означает, что витрины данных можно быстро и легко использовать, поскольку они используют небольшие объемы данных. Хранилище данных также дороже по той же причине.
Резюме
• Витрина данных и хранилище данных — это инструменты, помогающие руководству получить актуальную информацию об организации в любой момент времени.
• Хотя витрины данных ограничены для использования только отделом, хранилище данных применяется ко всей организации.
• Витрины данных легко проектировать и использовать, в то время как хранилище данных сложно и сложно в управлении.
• Хранилище данных более полезно, поскольку оно может предоставлять информацию из любого отдела.
Русские Блоги
Концепция, отличие и связь хранилища данных и витрины
1. Почему существуют хранилища данных и витрины?
Концепция «хранилища данных» восходит к середине 1980-х годов. По сути, исходное хранилище данных предназначалось для предоставления архитектурной модели для потока данных из операционной системы в среду поддержки принятия решений и пыталось решить различные проблемы, связанные с этими потоками данных.
В отсутствие архитектуры «хранилища данных» среда поддержки раннего принятия решений показана на рисунке 1. На предприятии существует множество избыточных и многократно сконструированных систем поддержки принятия решений (обычно систем отчетности). Эти системы используются различными типами пользователей. Уровень извлечения данных сложный. Сначала он извлекается на OLTP, а затем на извлеченном наборе данных. Извлечение и т. Д. Имеют форму «паутины». Поскольку общедоступного источника данных нет, а данные не имеют момента времени, достоверность сгенерированного отчета снижается, а проблема несоответствия данных особенно важна, не говоря уже о том, чтобы преобразовать ее в эффективный процесс принятия решений. Информация.
Для решения вышеуказанных проблем было создано хранилище данных. Хранилище данных строит архитектуру с централизованным хранилищем данных в качестве ядра.Для адаптации к требованиям анализа решений модель хранения данных сформировала независимую поддержку принятия решений, которая не зависит от операционной среды (OLTP), сформированной исходной бизнес-системой. окружение. Базовая архитектура хранилища данных показана на рисунке 2.
Среда поддержки принятия решений на основе хранилища данных, показанная на рисунке 2, требует, чтобы хранилище данных удовлетворяло потребности всех конечных пользователей. Однако потребности конечных пользователей постоянно меняются, а информационные потребности разных типов пользователей различны, поэтому для хранения данных в хранилище данных требуется достаточная гибкость, чтобы адаптироваться к запросам и анализу различных пользователей. С другой стороны, потребность конечного пользователя в информации должна быть легко доступной и иметь возможность получать результаты с более высокой производительностью. Однако гибкость и производительность противоречат хранилищу данных. Чтобы адаптироваться к требованиям гибкости, хранилище данных должно хранить различные исторические данные в стандартизированном режиме (как правило, в третьей нормальной форме). Поэтому для конкретного пользователя информация, требуемая TA, должна быть соединена во многих больших таблицах, чтобы получить результаты, так что требования к производительности для быстрого доступа не могут быть выполнены. Чтобы устранить противоречие между гибкостью и производительностью, в архитектуру хранилища данных был добавлен витрина данных, в котором хранятся данные, которые были предварительно рассчитаны для потребностей конкретных пользователей, что соответствует требованиям пользователей к производительности. Архитектура с витриной данных показана на рисунке 3.
Как упомянуто выше, в дополнение к построению модели архитектуры для потока данных, хранилище данных также пытается решить различные проблемы, связанные с потоком данных.Эти проблемы показаны на рисунке 4, включая различные задачи и характеристики, которые необходимо выполнить во время построения хранилища данных. ,
2. Концепции хранилища данных и витрины
Хранилище данных: это интегрированный предметно-ориентированный сбор данных, предназначенный для поддержки функции DSS (системы поддержки принятия решений) .В хранилище данных каждый блок данных связан с определенным временем. Хранилище данных включает в себя данные на атомарном уровне и слегка обобщенные данные. Хранилище данных — это набор данных, которые являются предметно-ориентированными, интегрированными, не обновляемыми (стабильными) и изменяются во времени (разное время) для поддержки процесса принятия решений в управлении бизнесом.
Хранилище данных не может быть просто понято как набор программного обеспечения. Хранилище данных — это процесс перестройки корпоративного потока данных и информационного потока. В этом процессе среда поддержки принятия решений на предприятии строится таким образом, чтобы различать исходный Операционная среда, созданная бизнес-системами. Ценность хранилища данных не в том, сколько данных вы храните в хранилище, а в ключе — качестве информации и результатов анализа, доступных в хранилище.
Стенд данных: это небольшое хранилище данных на уровне отдела или рабочей группы. Существует два типа витрин данных — независимые и зависимые. Независимые витрины данных получают данные непосредственно из операционной среды. Зависимые витрины данных получают данные из хранилищ данных уровня предприятия. В долгосрочной перспективе подчиненная витрина данных более стабильна в архитектуре, чем независимая витрина данных.
Существование независимого витрины данных создаст иллюзию, кажется, что витрину данных можно сначала построить независимо, а когда витрина данных достигает определенного масштаба, его можно напрямую преобразовать в хранилище данных, Однако это неверно: накопление нескольких независимых витрин данных не может сформировать хранилище данных уровня предприятия, которое определяется характеристиками хранилища данных и самим витриной данных. Если вы отделитесь от централизованного хранилища данных и создадите несколько витрин данных независимо, предприятие добавит только некоторые хранилища информации, и вы по-прежнему не сможете анализировать данные с точки зрения всего предприятия. Витрина данных используется различными отделами или рабочими группами. Там будут несоответствия между городами. Конечно, независимая витрина данных — это свершившийся факт, аналитическая среда, созданная для удовлетворения потребностей конкретных пользователей, но в долгосрочной перспективе это целесообразная мера, которая обязательно должна быть данными корпоративного уровня. Склад был заменен.
3. Разница между хранилищем данных и витриной
Разница между хранилищем данных и витриной данных может быть визуально представлена на рисунке 5.
Из рисунка видно, что структура данных в хранилище данных принимает стандартизированный режим (теория проектирования реляционных баз данных), а структура данных витрины данных использует режим «звезда» (теория проектирования многомерных баз данных). Степень детализации данных в хранилище данных меньше, чем в витрине данных. Приведенный выше рисунок отражает только две характеристики структуры данных и содержания данных, остальные различия показаны в следующей таблице, и банк будет использован в качестве примера для краткого пояснения.
Предположим, что для банка создается хранилище данных на уровне филиала, а затем создается информационный киоск для отдела международного бизнеса филиала. Данные хранилища данных поступают из бизнес-системы банка, в том числе: сбережения, карты, личные займы, валютные сокровища, промежуточный бизнес и т. Д. Темы анализа включают клиентов, каналы, продукты и т. Д. Детализация данных хранилища данных зависит от требований анализа и обычно включает в себя конкретные исторические записи (депозиты, снятие средств, операции с иностранной валютой, потребление POS, промежуточные записи деловых платежей), и затем эти записи агрегируются в день / неделю / месяц / квартал / На различных уровнях, таких как годы, детализация конкретных данных определяется потребностями анализа. Кроме того, хранилище данных также хранит некоторую бизнес-логику — некоторые показатели, рассчитанные для анализа. Например, ценность клиента или лояльность клиента. Расчет этих показателей не может проходить через единую бизнес-систему и должен быть всесторонне рассмотрен во всех компаниях, что также является одним из преимуществ системы хранилища данных. Если предположить, что у всего филиала 200 000 клиентов, тогда хранилище данных будет содержать исторические данные, сводные данные и данные индикаторов хранилища данных по всем предприятиям с 200 000 клиентов, а объем данных достигнет десятков или даже сотен G (это очень маленький масштаб). Хранилище данных). Чтобы удовлетворить запросы и анализ пользователей во всех отделах банка, хранилище данных может принять только схему парадигмы, так что независимо от того, что нужно пользователю, пока существуют данные, они могут быть удовлетворены. Предполагая, что в международном бизнес-отделе 20 000 клиентов (использующих валютные сокровища), если они не построят витрину данных, они будут напрямую запрашивать соответствующую информацию в хранилище данных, например, клиенты валютных сокровищ в прошлом году, валютные операции в различных транзакциях. Распределение с точки зрения методов (счетчик, онлайн, телефонный банкинг и т. Д.). Эффективность и производительность запроса очень низки. Если все пользователи в различных отделах напрямую запрашивают соответствующую информацию в хранилище данных, производительность хранилища данных снизится, и он не сможет удовлетворить требования пользователя к производительности. Никто не хочет быть простым Запросы ждут минут или даже часов. Поэтому необходимо создать витрину данных отдела, главным образом исходя из соображений производительности. Информационный киоск международного бизнес-отдела включает историю операций с иностранной валютой, насчитывающей 20 000 клиентов, и сводку с использованием звездного режима (или снежинки, или их комбинации) для упрощения запросов и анализа инструментов OLAP. Из этого простого примера мы видим, что данные витрины данных поступают из хранилища данных, которое в основном представляет собой реорганизованные сводные данные. Таким образом, несколько витрин данных не могут представлять собой хранилище данных на уровне предприятия. Воспользуясь аналогией Инмона: невозможно накапливать мелкую рыбу в море, образуя большого кита. Это также показывает, что хранилище данных и витрина данных существенно различаются.
Следуя концепциям хранилища данных и витрины данных, методы проектирования хранилища данных также подразделяются на три типа: сверху вниз, снизу вверх и их сочетание. Так называемый нисходящий метод заключается в том, чтобы сначала создать хранилище данных на уровне предприятия, а затем установить каждый киоск данных. В противоположность восходящему, гибридный метод должен требовать создания витрины данных с учетом структуры хранилища данных на уровне предприятия. , содержание.
Хранилища данных и карты данных
Что вы должны сначала создать: хранилище данных или хранилище данных? Это вопрос, который в последнее время беспокоит ИТ-менеджеров. Большинство поставщиков заявили, что хранилища данных сложны и дороги, и что они нецелесообразны. Говорят, что хранилища данных занимают много времени. Кроме того, они говорят, что перед ним стоит много вопросов, с которыми сталкивается корпорация в то же время. Некоторые из них — это интеграция устаревших данных и сложность управления большими объемами данных. Data Mart определенно сделал мрачный образ из хранилища данных, но все это не так. Для этого заблуждения требуется тщательное определение и различие. Но что такое витрины данных и хранилища данных?
Сначала нужно знать, что data mart представляет определенную компанию. Он представляет свои программы, данные, программное обеспечение и аппаратное обеспечение. Это означает, что для каждого отдела имеется отдельный файл данных. Например, для производства, для финансов, для печати используется информационный пакет, другой для отдела продаж и еще один для маркетинга. Каждый файл данных имеет свои собственные функции и функции. Он не идентичен другим витринам данных других отделов, но они могут координировать свои действия. Пакет данных ориентирован на индивидуальный и специфический отдел, поэтому он не может обрабатывать большие данные. База данных звездных объединений используется для сбора всей базы данных данных для проектирования. Существует два типа данных, независимый массив данных (это более сильные данные) и зависимый массив данных (это менее сильный). Необходимо создать несколько независимых витрин данных, чтобы их можно было использовать для организации.
Хранилище данных является широким и не ограничивается сосредоточением внимания только на конкретных отделах. Он может представлять всю компанию; он включает все предметы и модели корпоративных данных. Хранилище данных не ограничивается тем, что связано с предметными областями отделов и корпораций. Данные, хранящиеся в хранилищах данных, более подробные, чем данные. То, как индекс хранилища данных является легким, поскольку он должен обрабатывать большой объем данных. Хранилище данных охватывает большую часть корпорации или компании, поэтому для ее обработки требуется много времени. Именно поэтому витрины данных бывают быстрыми и простыми в использовании, дизайне и реализуются, поскольку обрабатывают только небольшие объемы данных. Это также связано с тем, что хранилище данных является более дорогостоящим по сравнению с хранилищем данных.
Data Mart ориентирован на отдельные подразделения корпорации или компании, а хранилище данных может представлять всю компанию или корпорацию в целом. 2.
Пакет данных может обрабатывать только небольшие объемы данных, в отличие от хранилищ данных, которые могут обрабатывать большие объемы данных. 3.
Хранилище данных может стать дорогостоящим и сложным в использовании, поскольку оно охватывает значительную часть компании или корпорации, в отличие от пакета данных, доступного и удобного, поскольку он имеет дело с небольшими подразделениями компании или корпорации.