В этой статье мы расскажем, что такое корпоративное хранилище данных, зачем оно нужно и как устроено. Еще рассмотрим основные достоинства и недостатки Data Warehouse, а также чем оно отличается от озера данных (Data Lake) и как традиционная архитектура КХД может использоваться при работе с большими данными (Big Data).

Где хранить корпоративные данные: краткий ликбез по Data Warehouse

Потребность в КХД сформировалась примерно в 90-х годах прошлого века, когда в секторе enterprise стали активно использоваться разные информационные системы для учета множества бизнес-показателей. Каждое такое приложение успешно решало задачу автоматизации локального производственного процесса, например, выполнение бухгалтерских расчетов, проведение транзакций, HR-аналитика и т.д.

При этом схемы представления (модели) справочных и транзакционных данных в одной системе могут кардинально отличаться от другой, что влечет расхождение информации. Частично этот вопрос Data Governance мы затрагивали в контексте управления НСИ.

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

Поэтому возникли корпоративные хранилища данных (Data Warehouse, DWH) – предметно-ориентированные базы данных для консолидированной подготовки отчётов, интегрированного бизнес-анализа и оптимального принятия управленческих решений на основе полной информационной картины [1].

Принцип слоеного пирога или архитектура КХД

Вышеприведенное определение DWH показывает, что это средство хранения данных является реляционным. Однако, не стоит считать КХД просто большой базой данных с множеством взаимосвязанных таблиц.

В отличие от традиционной SQL-СУБД, Data Warehouse имеет сложную многоуровневую (слоеную) архитектуру, которая называется LSA – Layered Scalable Architecture. По сути, LSA реализует логическое деление структур с данными на несколько функциональных уровней.

Данные копируются с уровня на уровень и трансформируются при этом, чтобы в итоге предстать в виде согласованной информации, пригодной для анализа [2].

Классически LSA реализуется в виде следующих уровней [3]:

• операционный слой первичных данных(Primary Data Layer или стейджинг), на котором выполняется загрузка информации из систем-источников в исходном качестве и сохранением полной истории изменений. Здесь происходит абстрагирование следующих слоев хранилища от физического устройства источников данных, способов их сбора и методов выделения изменений.
• ядро хранилища (Core Data Layer) – центральный компонент, который выполняет консолидацию данныхиз разных источников, приводя их к единым структурам и ключам. Именно здесь происходит основная работа с качеством данных и общие трансформации, чтобы абстрагировать потребителей от особенностей логического устройства источников данных и необходимости их взаимного сопоставления. Так решается задача обеспечения целостности и качества данных.
• аналитические витрины (Data Mart Layer), где данные преобразуются к структурам, удобным для анализа и использования в BI-дэшбордах или других системах-потребителях. Когда витрины берут данные из ядра, они называются регулярными. Если же для быстрого решения локальных задач не нужна консолидация данных, витрина может брать первичные данные из операционного слоя и называется соответственно операционной. Также бывают вторичные витрины, которые используются для представления результатов сложных расчетов и нетипичных трансформаций. Таким образом, витрины обеспечивают разные представления единых данных под конкретную бизнес-специфику.
• Наконец, сервисный слой (Service Layer) обеспечивает управление всеми вышеописанными уровнями. Он не содержит бизнес-данных, но оперирует метаданными и другими структурами для работы с качеством данных, позволяя выполнять сквозной аудит данных (data lineage), использовать общие подходы к выделению дельты изменений и управления загрузкой. Также здесь доступны средства мониторинга и диагностики ошибок, что ускоряет решение проблем.

LSA — слоеная архитектура DWH: как устроено хранилище данных

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

Для обеспечения процессов загрузки и аудита ETL-процессов данные в целевых таблицах стейджинга, ядра и витринах маркируются техническими полями (мета-атрибутами) [3]. Еще выделяют слой виртуальных провайдеров данных и пользовательских отчетов для виртуального объединения (без хранения) данных из различных объектов.

Каждый уровень может быть реализован с помощью разных технологий хранения и преобразования данных или универсальных продуктов, например, SAP NetWeaver Business Warehouse (SAP BW) [2].

Data Lake и корпоративное хранилище данных: как работать с Big Data

В 2010-х годах, с наступлением эпохи Big Data, фокус внимания от традиционных DWH сместился озерам данных (Data Lake). Однако, считать озеро данных новым поколением КХД [4] не совсем корректно по следующим причинам:

• разное целевое назначение – DWH используется менеджерами, аналитиками и другими конечными бизнес-пользователями, тогда как озеро данных – в основном Data Scientist’ами. Напомним, в Data Lake хранится неструктурированная, т.н. сырая информация: видеозаписи с беспилотников и камер наружного наблюдения, транспортная телеметрия, графические изображения, логи пользовательского поведения, метрики сайтов и информационных систем, а также прочие данные с разными форматами хранения (схемами представления). Они пока непригодны для ежедневной аналитики в BI-системах, но могут использоваться Data Scientist’ами для быстрой отработки новых бизнес-гипотез с помощью алгоритмов машинного обучения [5];
• разные подходы к проектированию. Дизайн DWH основан на реляционной логике работы с данными – третья нормальная форма для нормализованных хранилищ, схемы звезды или снежинки для хранилищ с измерениями [1]. При проектировании озера данных архитектор Big Data и Data Engineer большее внимание уделяют ETL-процессам с учетом многообразия источников и приемников разноформатной информации. А вопрос ее непосредственного хранения решается достаточно просто – требуется лишь масштабируемая, отказоустойчивая и относительно дешевая файловая система, например, HDFS или Amazon S3 [5];
• наконец, цена – обычно Data Lake строится на базе бюджетных серверов с Apache Hadoop, без дорогостоящих лицензий и мощного оборудования, в отличие от больших затрат на проектирование и покупку специализированных платформ класса Data Warehouse, таких как SAP, Oracle, Teradata и пр.

Таким образом, озеро данных существенно отличается от КХД. Тем не менее, архитектурный подход LSA может использоваться и при построении Data Lake. Например, именно такая слоенная структура была принята за основу озера данных в Тинькоф-банке [6]:

• на уровне RAW хранятся сырые данные различных форматов (tsv, csv, xml, syslog, json и т.д.);
• на операционном уровне (ODD, Operational Data Definition) сырые данные преобразуются в приближенный к реляционному формат;
• на уровне детализации (DDS, Detail Data Store) собирается консолидированная модель детальных данных;
• наконец, уровень MART выполняет роль прикладных витрин данных для бизнес-пользователей и моделей машинного обучения.

В данном примере для структурированных запросов к большим данным используется Apache Hive – популярное средство класса SQL-on-Hadoop. Само файловое хранилище организовано в кластере Hadoop на основе коммерческого дистрибутива от Cloudera (CDH). Традиционное DWH банка реализовано на массивно-параллельной СУБД Greenplum [6].

От себя добавим, что альтернативой Apache Hive могла выступить Cloudera Impala, которая также, как Greenplum, Arenadata DB и Teradata, основана на массивно-параллельной архитектуре. Впрочем, выбор Hive обоснован, если требовалась высокая отказоустойчивость и большая пропускная способность.

Подробнее о сходствах и различиях Apache Hive и Cloudera Impala мы рассказывали здесь. Возвращаясь к кейсу Тинькофф-банка, отметим, что BI-инструменты считывают данные из озера и классического DWH, обогащая типичные OLAP-отчеты информацией из хранилища Big Data.

Это используется для анализа интересов, прогнозирования поведения, а также выявления текущих и будущих потребностей, которые возникают у посетителей сайта банка [6].

LSA-архитектура корпоративного Data Lake в Тинькоф-банке

В следующей статье мы продолжим разговор про архитектурные особенности современных DWH с учетом потребности работы с Big Data и рассмотрим еще несколько примеров таких гибридных подходов.

А технические подробности реализации КХД и другие актуальные вопросы управления бизнес-данными вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Источники

Концепция ИТ-поддержки процессов налогового администрирования в условиях централизации информационных ресурсов ФНС России

Асадулаев В.Ю. выпускник группы MBA CIO 28А Школа IT-менеджмента

РАНХиГС при Президенте РФ

В правительственном документе «Основные направления налоговой политики Российской Федерации на 2013 год и на плановый период 2014 и 2015 годов» совершенствование налогового администрирования называется одним из приоритетных направлений налоговой политики государства, источником дополнительных поступлений в бюджетную систему. Без комплексной модернизации налоговых органов поставленная задача  обеспечения максимально возможного сбора налогов при минимизации соответствующих затрат, включая административное бремя, возлагаемое на налогоплательщиков, представляется не решаемой.

Одним из ключевых факторов повышения результативности работы службы руководство ФНС России определяет эффективность поддержки процессов налогового администрирования со стороны информационных технологий.

Следующим шагом на этом пути становится принятие первым лицом ведомства стратегического решения об инвестировании в принципиально новую автоматизированную информационную систему (АИС Налог — 3), решения, основанного на понимании того, что для реализации поставленных государством задач налоговая служба должна стать сервисной службой, деятельность которой строится  на партнерских взаимоотношениях с налогоплательщиками. При этом  задачей информационного менеджмента становится предоставление информационных сервисов как внешним (налогоплательщикам, государственным и муниципальным органам власти), так и внутренним пользователям АИС.

Архитектура действующей автоматизированной информационной системы ФНС России сформирована более 10 лет назад и повторяет трехуровневую структуру ФНС России (ИФНС – УФНС по субъектам РФ – ЦА ФНС).

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

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

Анализ вариантов реализации АИС Налог – 3, как информационной системы, удовлетворяющей современному уровню налогового администрирования, и с учетом перспектив его дальнейшего развития, показал, что предпочтительным является архитектурное решение, основанное на централизации всех информационных ресурсов в Федеральном хранилище данных (ФХД).  Взаимодействие основных компонентов прикладной архитектуры (верхнего уровня) строится через ФХД и представлено на рисунке.

Федеральное хранилище данных является ядром АИС Налог – 3 и представляет собой логически целостное хранилище полной, непротиворечивой,  очищенной, юридически значимой, актуальной информации, необходимой налоговым органам и налогоплательщикам для обеспечения налогового администрирования и исполнения налогового законодательства. При этом хранилище состоит из двух сегментов: транзакционного(OLTP) и аналитического(OLAP) сегментов; передача данных из транзакционного в аналитический сегмент осуществляется посредством ETL.  

Автоматизация процессов  налогового администрирования  в новой  архитектуре (подсистемы налогового администрирования) потребовала проведение реинжиниринга бизнес-процессов  ведомства.

В результате были выделены функции, требующие интерактивного взаимодействия пользователей с системой и налогоплательщиками, которые выполняются на уровне налоговых органов(интерактивные сервисы), и функции «налогового автомата», которые должны быть перенесены в ЦОДы.

Подсистемы внешнего взаимодействия обеспечивают единую точку входа как для решения задач по предоставлению информации государственным и муниципальным органами власти через систему межведомственного электронного взаимодействия(СМЭВ) и портал госуслуг, так и для развития таких сервисов, как «Личный кабинет», который позволит перенести все предусмотренные законодательством виды взаимодействия с ФНС России в электронный вид и обеспечит налогоплательщиков удобным и оперативным инструментом контроля за состоянием своих налоговых обязательств. При этом существенно снижается нагрузка на налоговые органы.

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

Для каждой из компонент целевой архитектуры АИС Налог – 3  на основе разработанной методики был произведен выбор программно-технологической платформы.

Так, например, для транзакционного сегмента в качестве машины базы данных была выбрана Exadata, для аналитического сегмента тесты показали преимущество Teradata, обеспечивающую подсистему «Электронный архив» планируется построить на IBM FileNet, а информационно-аналитические подсистемы на платформе «Прогноз» 7.

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

• Переход на новую централизованную технологию налогового администрирования предлагается осуществить методом «большого взрыва», то есть единовременно по всей стране, чтобы  избежать необходимости реализации механизмов обмена информацией между системами.
• Среди многочисленных эффектов, ожидаемых от внедрения АИС «Налог-3», можно выделить социальные: снижение потенциальной коррупционности процессов налогового администрирования на всех уровнях управления ФНС России, повышение «открытости» налоговых органов для налогоплательщика, снижение общего уровня налоговых нарушений в стране.

Рубрика: 

Архитектура корпоративного хранилища данных. Структура хранилища данных, область временного хранения, детальные данные, system records, витрина данных, метаданные

Основными компонентами корпоративного хранилища данных являются:

• Модель данных;
• База данных;
• ETL-приложение;
• BI-приложение.

Архитектура области хранения данных базы данных корпоративного хранилища, как правило, состоит из следующих областей:

• область временного хранения данных (Staging Area) – предназначена для временного хранения данных, извлеченных из систем-источников; является промежуточным слоем между операционными системами компании и хранилищем данных;
• область постоянного хранения данных, которая включает:
  • детальные данные (System of records) – область хранения детальных данных, приведенных к структуре модели данных корпоративного хранилища, прошедших очистку и обогащение;
  • агрегаты (Summary area) – сгруппированные по времени (чаще просуммированные) детальные данные;
  • витрины данных (Data Marts) – тематические наборы данных, хранящиеся в виде пригодном для их анализа (например, схема «звезда»); ориентированны на поддержку конкретных бизнес-процессов, приложений, подразделений компании, бизнес-целей;
• интерфейсы обмена данными с другими системами (Data Exchange Interface или Feedback Area) – таблицы БД, в которых храняться подготовленные для передачи в другие информационные системы компании данные из области постоянного хранения данных;
• метаданные (Metadata) – являются важной частью архитектуры хранилища данных. Метаданные — это данные, описывающие правила, по которым «живет» хранилище. Например, с точки зрения базы данных хранилища, метаданными является описание структур таблиц, взаимосвязей между ними, правил секционирования, описание витрин данных и т.п. С точки зрения ETL, метаданными являются описания правил извлечения и преобразования данных, периодичность выполнения ETL-процессов и т.п.

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

Ниже представлена общая схема организации областей хранения данных.

Область временного хранения данных (Staging Area)

Область временного хранения данных является промежуточным слоем между источниками данных и областью постоянного хранения. В данной области сохраняются извлеченные из операционных систем-источников (СУБД, csv, dbf, xml файлов, web-сервисов и т.д.

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

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

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

Одной из наиболее важных задач при построении хранилища данных является определение соответствия (mapping) сущностей систем-источников данных и сущностей модели хранилища данных.

Обычно подобное соответствие представляет собой отношение десятков (а иногда и сотен) таблиц систем-источников к десяткам таблиц области постоянного хранения данных.

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

Ниже представлены основные принципы формирования области временного хранения.

1. В области временного хранения данных должно быть относительно небольшое количество сущностей — до 20, в которые сохраняются все необходимые данные, извлеченные из систем-источников.
2. Основой для проектирования состава сущностей области временного хранения должны являться предметные области (Subject Area) модели данных.
3. При извлечении данных из систем-источников сами данные и их типы не должны принципиально изменяться.

Детальные данные (System of records)

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

Данная область содержит следующие типы сущностей:

• справочники и классификаторы;
• сущности, содержащие фактические значения;
• сущности, описывающие связи.

Справочники и классификаторы определяют:

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

Сущности, содержащие фактические значения, – транзакционные данные из систем источников. Например, информация о совершенных телефонных звонках, выставленных счетах, проводках, проданных товарах и т.п.

Сущности, содержащие связи, определяют взаимосвязи между остальными сущностями. Например, Клиент-Услуга.

Область детальных данных не содержит никаких агрегатов. Только детальные, очищенные и структурированные в соответствии с моделью данные.

Агрегаты (Summary area)

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

Витрины данных (Data Marts)

Витрины данных являются объектами хранения аналитической информации, нацеленными на поддержку конкретных бизнес-функций, конкретных подразделений компании.

На уровне базы данных витрины обычно реализуются по схеме «звезда» или «снежинка» и содержат данные из области детальных данных (System of records). Также могут быть реализованы в виде многомерного OLAP-куба.

Витрины данных являются основой, обеспечивающей возможность проведения многомерного анализа (OLAP) данных.

Ниже представлены основные принципы проектирования витрин данных.

1. Витрины данных ориентированы на бизнес и при их проектировании необходимо учесть все измерения, показатели и иерархии, необходимые пользователям.
2. При проектировании витрин данных необходимо учитывать особенности BI-приложения, используемого на проекте. Например, в Oracle Discoverer нет возможности создавать несбалансированные иерархии и это нужно учитывать.

Интерфейсы обмена данными (Data Exchange Interface)

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

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

Интерфейсы обмена желательно создавать как можно более универсальными.

Метаданные (Metadata)

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

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

Обычно управление метаданными осуществляется отдельными инструментами для каждого из компонентов хранилища. Например, для базы данных Oracle, метаданные которой хранятся в системных таблицах и настроечных файлах, это будет Oracle Enterprise Manager.

Источники:

Подходы к созданию федеративных Хранилищ данных

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

Федеративное корпоративное Хранилище данных — это подходящее интеграционное
решение для многих крупных организаций, в которых существует внутренняя
автономия подразделений.

Осуществлять или нет федерализацию?

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

Для одних компаний подходящим решением
может стать единое Хранилище, а для других — федеративная модель.

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

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

1. Внутренняя организация компании и требования бизнеса.
   Один из доводов в пользу федерализации может быть косвенно связан со структурой
   организации. Но иерархическая внутренняя структура еще не означает, что
   федерализация автоматически окажется наилучшим решением. Принципиальным
   фактором является степень делегированной или местной автономии. Обычно это
   тесно связано с уровнем местного контроля над данными. Если пользователи на
   места привыкли контролировать и осуществлять изменения на локальном уровне,
   тогда федерализация является подходящим решением.
   Опыт также показывает, что если структура организации включает высокий уровень
   местной автономии, то в конце концов все требования, которые изначально были
   установлены едиными, начинают отличаться. Подход, связанный с созданием единой
   структуры, в такой ситуации не годится, поэтому очень важно с самого начала
   выбрать такую архитектуру, которая сможет с ней справиться.
2. Степень расхождения моделей бизнес-данных.
   Это одни из самых важных критериев для принятия решения об использовании
   федерализации для интеграции информации. Например, если двум частям организации
   требуются различные классификации продуктов, то обе эти классификации могут
   быть включены в одну модель. Некоторые компании размещают до 20 классификаций в
   одной модели. Но здесь есть свои ограничения. Если увеличение числа различий
   становится системным, то в конце концов единое Хранилище станет неуправляемым.
   Как показывает опыт, именно это обстоятельство было причиной неудач многих
   проектов, направленных на создание традиционных Хранилищ данных по специальным
   заказам.
   Глобальные структурные расхождения — это еще один довод в пользу федерализации.
   Например, если одно подразделение компании общественного питания работает
   напрямую с потребителями, а другое — только с дистрибьюторами, то контекст и
   структура транзакций будут очень сильно отличаться, что затруднит их совмещение
   в одной модели данных.
3. Степень расхождения содержимого данных.
   Часто одно бизнес-подразделение не использует данные другого подразделения при
   принятии решений относительно своего бизнеса. Но при этом могут существовать
   некоторые общие справочные данные, например, общая корпоративная классификация
   потребителей. Если очевидно, что каждому потенциальному члену федерации
   необходимы все данные о транзакциях и все справочные данные, то лучше
   остановиться на создании единого Хранилища данных.
4. Количество источников данных.
   Это также очень важный фактор. Если существует один основной источник данных,
   то их фильтрация для загрузки в отдельные Хранилища увеличит объем работы. Но
   если данные размещены в локальных источниках, то федерация оказывается более
   подходящим решением.

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

Архитектурные возможности

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

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

Федерализация по областям бизнеса означает, что члены федерации представляют
отдельные сферы бизнеса.

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

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

Помимо этого, возможно и использование единого физического Хранилища
данных.

Единое физическое корпоративное Хранилище данных

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

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

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

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

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

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

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

Типы федераций

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

Все эти модели, по сути, являются вариантами географической федеративной
архитектуры.

Любой глобальный бизнес, такой, например, как компания Shell, имеет серию
региональных Хранилищ данных, которые являются членами федерации второго
уровня. В случае крупных стран может существовать федерация первого уровня с
бизнес-подразделениями, работающими в каждой стране.

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

На местах эти общие справочные данные добавляются к
уже существующим и изменяются, если это необходимо.

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

Эта компания создавала федерацию на основе бизнес-функций (продажи и
маркетинг), которые считались приоритетными направлениями. В общей форме схема
такой федерации показана на рис. 1.

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

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

Рис. 1. Федерация на основе бизнес-функций (например, продажи и
маркетинг)

Если Хранилище данных для одной страны или функциональной области
оказывается по каким-то причинам недоступным, то это наносит меньший ущерб
бизнесу, чем потеря всей информационной системы, поскольку такие индивидуальные
Хранилища представляют только часть федерации.

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

Публикации

Дэвид Уэддингтон (David Waddington). Архитектурный подход к интеграции
информации: обзор проблемы федеративных Хранилищ данных.
(An Architected Approach
to Information Integration — Federated Enterprise Data Warehousing
Overview).

По материалам зарубежных сайтов

3. КОНЦЕПЦИЯ СОЗДАНИЯ ЦИФРОВОЙ АНАЛИТИЧЕСКОЙ ПЛАТФОРМЫ ПРЕДОСТАВЛЕНИЯ СТАТИСТИЧЕСКИХ ДАННЫХ

• 3. Создание единого хранилища первичных статистических данных (включая агрегированные и первичные
• данные) и совершенствование распространения данных

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

По результатам опроса, проведенного Федеральной службой государственной статистики в рамках плана мероприятий, в котором приняли участие 16 из 62 федеральных органов исполнительной власти, являющихся субъектами официального статистического учета, была получена информация о том, что федеральные органы исполнительной власти, участвовавшие в опросе, являются операторами 45 государственных информационных систем, в составе которых насчитывается 617 баз данных.

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

На федеральном уровне информация представлена в агрегированном виде, а на региональном — в виде первичных статистических данных или отсутствует, а статистические данные представлены в виде набора бумажных или электронных таблиц или форм федерального статистического наблюдения.

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

При этом различие в методиках сбора и обработки (агрегирования) данных не позволяет обеспечить взаимосвязь статистических данных разных ведомств.

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

1. Кроме того, для эксплуатации и развития информационных систем, поддерживающих процессы хранения и агрегирования статистических данных, необходимы существенные затраты всех субъектов статистического учета и бюджета Российской Федерации.
2. Создание платформы направлено в том числе на обеспечение возможности повторного использования первичных статистических данных для расчета и построения аналитических отчетов, анализа «больших» данных, обеспечения доступа всех заинтересованных лиц к деперсонифицированным микроданным, создания предпосылок к переходу на потоковый сбор первичных статистических данных.
3. Существующая в настоящее время в федеральных органах исполнительной власти система сбора и хранения первичных статистических данных, а также организационное, методологическое и правовое обеспечение не позволяют в полной мере обеспечить достижение указанных целей и задач.

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

• С учетом положительного опыта создания и эксплуатации Системы многомерного анализа данных на основе единого хранилища данных в рамках создания платформы необходимо:
• создать единое хранилище первичных статистических данных;
• осуществить систематизацию и нормализацию накопленных в ведомственных системах агрегированных статистических данных;
• создать инструменты аналитической работы с первичными данными, разрозненными данными и данными различных источников, в том числе с созданием для выполнения указанных работ государственно-частного партнерства;
• создать в целях государственного управления инструменты доступа к ведомственным данным на базе единого хранилища первичных статистических данных платформы, обеспечить межведомственное взаимодействие;
• обеспечить взаимодействие с международными организациями, в том числе с применением SDMX, XBRL;
• предоставить доступ к деперсонифицированным микро- и макроданным с привлечением центра компетенций и с созданием государственно-частного партнерства;
• обеспечить методологическую и нормативную правовую основы работы с деперсонифицированными микро- и макроданными, включая возможность тестового доступа к данным;
• создать инструменты доступа к деперсонифицированным микро- и макроданным.
• Поступившие от субъектов статистического учета через «Единое окно» для представления отчетности в электронном виде первичные статистические данные должны размещаться в едином хранилище первичных статистических данных платформы.
• Доступ субъектов официального статистического учета и федеральных органов исполнительной власти к единому хранилищу первичных статистических данных платформы должен осуществляться с использованием единого унифицированного механизма, в качестве которого возможно рассматривать, например, единую систему межведомственного электронного взаимодействия.
• Для реализации доступа субъектов официального статистического учета и федеральных органов исполнительной власти к единому хранилищу первичных статистических данных платформы с использованием единой системы межведомственного электронного взаимодействия необходимо:
• организовать разработку и последующее рассмотрение Правительственной комиссией по цифровому развитию, использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности технологических карт межведомственного взаимодействия, определяющих перечень первичных статистических данных, подлежащих передаче из единого хранилища первичных статистических данных платформы в соответствующие государственные информационные системы;
• организовать разработку электронного сервиса единой системы межведомственного электронного взаимодействия, реализующего информационный обмен по соответствующим технологическим картам межведомственного взаимодействия.
• При выполнении работ по созданию единого хранилища первичных статистических данных платформы и совершенствованию распространения данных должны быть учтены мероприятия, проводимые в рамках создания и внедрения единой системы нормативной справочной информации и национальной системы управления данными.
• В качестве одного из перспективных способов доступа пользователей к ресурсам платформы можно рассматривать единый портал государственных и муниципальных услуг с использованием сервиса, реализующего запрос на получение сводных (агрегированных) данных с учетом требований к конфиденциальности первичных статистических данных.

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

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

1. Целесообразным также представляется выполнение центром компетенций функций по приему запросов и формированию аналитических отчетов и витрин данных на основе деперсонифицированных микро- и макроданных.
2. Также необходимо отметить, что на 2020 год запланировано проведение Всероссийской переписи населения, в рамках которой предусмотрен сбор данных для формирования основы всей статистики о населении.
3. В настоящее время существует несколько государственных информационных источников о населении: Всероссийская перепись населения и единый федеральный информационный ресурс, содержащий сведения о населении Российской Федерации, создаваемый Федеральной налоговой службой.

Вместе с тем единый федеральный информационный ресурс, содержащий сведения о населении Российской Федерации, создаваемый на основе данных государственных и муниципальных информационных систем (единые государственные ресурсы органов записи актов гражданского состояния, Министерства внутренних дел Российской Федерации, Пенсионного фонда Российской Федерации, Федеральной налоговой службы и др.), оперирует прежде всего данными, полученными по месту регистрации, а также специфическими данными, имеющими отношение к определенному министерству, собирающему такие данные.

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

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

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

При этом актуализацию данных в платформе необходимо проводить после каждой переписи населения и микропереписи (раз в 5 лет).