Корпоративное хранилище данных

В статье рассмотрено одно из ключевых BI-понятий (Business Intelligence) – ETL-технологии: определение, история возникновения, основные принципы работы, примеры реализации и типовые варианты использования (use cases). Также отмечены некоторые проблемы применения ETL и способы их решения с помощью программных инструментов обработки больших данных (Big Data).

Что такое ETL и зачем это нужно

Начнем с определения: ETL (Extract, Transform, Load) – это совокупность процессов управления хранилищами данных, включая :

  • извлечение данных из внешних источников (таблицы баз данных, файлы);
  • преобразование и очистка данных согласно бизнес-потребностям;
  • загрузка обработанной информации в корпоративное хранилище данных (КХД).

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

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

Как устроена ETL-система: архитектура и принцип работы

Независимо от особенностей построения и функционирования ETL-система должна обеспечивать выполнение трех основных этапов процесса ETL-процесса (рис.1) :

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

Рис. 1. Обобщенная структура процесса ETL

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

Рис. 2. Потоки данных между компонентами ETL

На практике ETL выступает в качестве промежуточного слоя между OLTP — и OLAP -системами. OLTP (Online Transaction Processing) – это транзакционные системы для обработки непрерывного потока небольших по размеру транзакций в режиме реального времени: ERP-, MES-, банковские и биржевые приложения. Они автоматизируют структурированные, повторяющиеся задачи обработки данных, например, ввод заказов и банковские транзакции, в большом количестве за короткие промежутки времени. Однако сложные аналитические запросы, например, сколько товаров категории «предметы народного промысла» было куплено молодыми людьми 18-30 лет в городах-миллионниках за последние 3 года, в таких системах выполняются очень долго .

Для подобных запросов предназначены OLAP-системы. OLAP (Online Analytical Processing) – это интерактивная аналитическая обработка, подготовка суммарной (агрегированной) информации на основе больших массивов данных, структурированных по многомерному принципу. При этом строится сложная структура данных – OLAP-куб, включающий таблицу фактов, по которым делаются ключевые запросы и таблицы агрегатов (измерений), показывающие, как могут анализироваться агрегированные данные. Например, группировка продуктов по городам, производителям, потребителям и другие сложные запросы, которые могут понадобиться аналитику. Куб потенциально содержит всю информацию, нужную для ответов на любые количественные и пространственно-временные вопросы. При огромном количестве агрегатов зачастую полный расчёт происходит только для некоторых измерений, для остальных же производится «по требованию» .

Таким образом, основные функции ETL-системы можно представить в виде последовательности операций по передаче данных из OLTP в OLAP (рис. 3) :

  1. загрузка в ETL «сырых» данных (Raw Data) произвольного качества для дальнейшей обработки. При этом выполняется сверка суммы пришедших строк: если в системе-источнике больше строк, чем в Raw Data, то загрузка прошла с ошибкой.
  2. валидация данных, когда данные последовательно проверяются на корректность и полноту, составляется отчет об ошибках для исправления;
  3. настройка соответствия (мэппинг) данных с целевой моделью, когда к валидированной таблице пристраиваются столбцы по количеству справочников целевой модели, а потом в каждой пристроенной ячейке каждой строки проставляются соответствие значений целевых справочников (1:1, *:1, 1:* или *:*);
  4. агрегация данных, необходимая из-за разности детализации данных в OLTP и OLAP-системах. OLAP представляет собой полностью денормализованную таблицу фактов и окружающие ее таблицы справочников по схеме звездочка или снежинка. При этом максимальная детализация сумм OLAP равна количеству перестановок (агрегаций) всех элементов всех справочников. OLTP-система может содержать несколько сумм для одного и того же набора элементов справочников. Чтобы проследить, из каких строк OLTP сформировалась сумма в ячейке OLAP-системы, необходим мэппинг OLTP-детализации, а потом «склейка» данных в отдельной таблице для загрузки в OLAP.
  5. выгрузка в целевую систему с использованием коннектора и интерфейсных инструментов.

Рис. 3. ETL-процесс по передаче данных от OLTP в OLAP

Немного про хранилища и витрины данных

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

Корпоративное хранилище данных (КХД, DWH – Data Warehouse) – это предметно-ориентированная информационная база данных, специально разработанная и предназначенная для подготовки отчётов и бизнес-анализа с целью поддержки принятия решений в организации. Информация в КХД, как правило, доступна только для чтения. Данные из OLTP-системы копируются в КХД таким образом, чтобы при построении отчётов и OLAP-анализе не использовались ресурсы транзакционной системы и не нарушалась её стабильность. Есть два варианта обновления данных в хранилище :

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

ETL-процесс позволяет реализовать оба этих способа. Отметим основные принципы организации КХД :

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

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

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

Прикладные кейсы использования ETL-технологий

Рассмотрим пару типовых примеров использования ETL-систем .

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

Аналогичным образом ETL-технологии помогут автоматизировать удаление аккаунтов сотрудника из всех корпоративных систем в случае увольнения. В частности, как только в HR-систему попадут данные о дате окончания карьеры сотрудника на этом месте работы, информация о необходимости блокировки его записи поступит контроллеру домена, его корпоративная почта автоматически архивируется, а почтовый ящик блокируется. Также возможен полуавтоматический режим с созданием заявки на блокировку в службу технической поддержки, например, Help Desk.

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

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

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

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

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

Рис. 4. Организация разноски платежей с помощью ETL

Современный рынок ETL-систем и особенности выбора

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

К категории условно бесплатных можно отнести :

  • Oracle Warehouse Builder;
  • Talend Open Studio;
  • Scriptella;
  • Pentaho.

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

  • совместимость с источниками данных – современные КХД могут строиться на основе различных моделей данных (многомерных, реляционных, гибридных), поэтому ETL-систем должна быть универсальной, чтобы извлекать и переносить данные как можно большего числа типов и форматов ;
  • наличие инструментов разработки (API, коннекторов и т.д.) для масштабирования и интеграции со сторонними системами (источниками и потребителями данных), а также для создания оригинальных алгоритмов операций с данными;
  • «зрелость» системы, включающая завершенность ее функциональных возможностей, простоту эксплуатации и уровень технической поддержки.

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

Некоторые проблемы ETL-технологий и способы их решения

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

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

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

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

  • разрозненность конечных данных – после того, как Data Analyst определил, какая информация и из каких источников должна попадать в КХД, эти источники становятся основными репозиториями. Содержимое витрин данных становится доступным для пользователей, однако исходные данные не хранятся и не могут быть извлечены. Но на практике различным категориям пользователей нужно больше информации, чем предоставляют ETL-системы. В этом случае пользователи создают свои собственные, локальные хранилища и витрины данных, которые не интегрированы с общим КХД. В результате при использовании одной и тоже же по смыслу информации у разных бизнес-подразделений возникают разночтения, что приводит к несогласованности в работе .
  • появление новых источников и форматов представления данных – традиционные ETL-инструментов хорошо подходят для обработки структурированных данных, однако в реальности часто возникает необходимость работы с полуструктурированной или неструктурированной информаций. В этом случае следует подключать технологии больших данных (Big Data), например, Apache Hive и Pig для загрузки и преобразования информации, хранящейся в распределенной файловой системе Hadoop Distributed File System (HDFS). Hive реализует принципы традиционных баз и хранилищ данных на основе SQL-запросов и схем, а Pig похож на стандартный язык ETL-сценариев. Оба инструмента используют функции MapReduce в пакетной обработке данных , т.е., как и типовые ETL-системы, ориентированы на регулярную загрузку информации для обеспечения согласованности источников и витрин данных с КХД . А для потоковой обработки множества разноструктурированной информации потребуются распределенные фреймворки, обеспечивающие работу с непрерывно поступающими данными, например, Apache Spark, Flink, Storm, Samza или Kafka Streams .

Таким образом, Big Data инструменты пакетной и потоковой обработки позволяют дополнить типовые ETL-системы, предоставляя бизнес-пользователям более широкие возможности по работе с корпоративной информацией. Однако, в этом случае временные, трудовые и финансовые затраты на аналитику данных существенно возрастут, т.к. понадобятся дорогие специалисты: Data Engineer, который выстроит конвейер данных (pipeline), а также Data Scientist, который разработает программное приложение для онлайн-аналитики, включая оригинальные ML-алгоритмы. Впрочем, такие инвестиции будут оправданы, если предприятие достигло хотя бы 3-го уровня управленческой зрелости по модели CMMI, обладает большим количеством разных данных с высоким потенциалом для аналитики и стремится стать настоящей data-driven компанией. Однако, чтобы эти вложения принесли выгоду, а не превратились в пустые траты, стоит адекватно оценить свои потребности и возможности, возможно, с привлечением внешнего консультанта по аналитике данных.

Стоит отметить, что разработчики многих ETL-систем учитывают потребность аналитики больших данных с помощью своих продуктов и потому включают в их возможности работы с Apache Hadoop и Spark, как, например, Pentaho Business Analytics Platform . В этом случае не придется самостоятельно разрабатывать средства интеграции ETL-системы с распределенными решениями сбора и обработки больших данных, а можно воспользоваться готовыми коннекторами и API-интерфейсами. Впрочем, это не отменяет необходимость предварительной аналитической работы по проектированию и реализации ETL-процесса. Организация сбора информации в хранилище данных может достигать до 80% трудозатрат по проекту. Учет различных аспектов ETL-процессов с прицелом на будущее позволит тщательно спланировать необходимые работы, избежать увеличения общего времени реализации и стоимости проекта, а также обеспечить BI-систему надежными и актуальными данными для анализа .

Источники

  1. ETL
  2. ETL – технология, сопутствующая любой BI-инициативе
  3. Business Intelligence
  4. Введение в ETL
  5. OLTP
  6. OLAP
  7. Основные функции ETL-систем
  8. Хранилище данных
  9. Витрина данных
  10. Знакомый-незнакомый ETL
  11. Реализация подсистемы ETL (Extract, Transform, Load) корпоративного хранилища данных
  12. Hive как инструмент для ETL или ELT
  13. Что выбрать для потоковой обработки Big Data: Apache Kafka Streams или Spark Streaming
  14. Pentaho Data Integration

Хранилище данных без Е

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

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

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

Способы и виды хранилищ данных

Однако, когда размер организации становится достаточно большим, или же требуется повысить конкурентное преимущество, то уже недостаточно только создать продукт и вывести его на рынок. Современные тенденции — во всестороннем изучении потребителя для повышения его лояльности. Необходимо анализировать бизнес с разных углов и научиться более точно оценивать затраты. Типовые задачи из разряда must have следующие:

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

В каждом из вышеприведенных примеров требуется использование более одного источника данных. Кроме того, важно, чтобы методы сопоставления данных между источниками были едины. Иначе неизбежно возникнет ситуация, когда в организации, скажем, директор по стратегии и директор по продажам будут приносить генеральному директору одну и ту же информацию, но с разными цифрами. А потом месяц выясняют, кто же был «правее», используя чуть ли не половину имеющегося в их распоряжении персонала.
Самым примитивным способом организации хранилища данных является так называемое «озеро данных» (или data lake), когда мы просто берем и сваливаем в кучу данные из разных источников. В этом случае мы имеем единую техническую платформу для работы с данными и изолируем сложные аналитические запросы от первичных задач информационных систем. Такое хранилище данных может быть вполне себе и нереляционным. Однако в этом случае можно забыть о сложном анализе, и оперировать лишь простыми запросами. Кроме того, люди, работающие с данными, должны быть хорошо осведомлены не только о бизнес-области, но и о моделях данных исходных систем.
Далее по уровню организации хранилища данных следует хранилище, по т.н. классификации Кимбелла (Kimpball). Измерения из разных систем унифицируются, и таким образом, получается что-то вроде сети с двумя типами таблиц — фактов и измерений. Это первичное обогащение справочников, когда мы, используя какой-то общий натуральный ключ в одних и тех же таблицах разных источников, например, ИНН в справочнике организаций, получаем единый справочник.
Следующим по сложности и надежности является хранилище данных с единой моделью данных, отражающей наиболее важные объекты, описывающие деятельность организации. Надежность заключается в том, что данные, будучи представлены в форме, близкой к третьей нормальной, при правильно составленной модели, являются универсальным средством описания жизнедеятельности всего бизнеса, и таким образом, модель данных может быть легко приспособлена не только для аналитической и регуляторной отчетности, но и для работы некоторых систем предприятия.

Е — Единое

Говоря о тезисе данной статьи, я перечислю основные проблемы, с которыми сталкиваются лица, ответственные за построение хранилищ данных:
«Конь в вакууме». Хранилище построено, но им никто не пользуется.
«Черный ящик». Хранилище построено, но что в нем есть и как оно работает непонятно. Из-за этого возникают постоянные ошибки, а если еще и уволилась часть команды разработчиков, то как результат, скатываемся в пункт a.
«Калькулятор». Хранилище построено, но оно удовлетворяет только примитивные запросы, бизнес меняется гораздо быстрее, чем реализация требований, новые запросы бизнеса в ней не учтены. К тому же некоторые данные могут быть устаревшими или обновляться достаточно редко.
«Хрустальная ваза». Для хранилища необходимо много ручного контроля, проверок и неавтоматизированных управляющих воздействий, если один из участников поддержки не на работе, есть большой риск получить невалидные данные или не получить их вообще.
Разберем все четыре случая более подробно
«Конь в вакууме». Если вы получили этот результат, то это произошло по одной из двух причин:

  1. Менее вероятно. Вами не были собраны требования от бизнес-подразделений (или, что — то же самое, они были плохо проработаны). Такая, казалось бы, абсурдная ситуация возникает, если идея создания хранилища идет не от бизнеса, а от ИТ подразделения, у которого просто есть «лишний» бюджет, а хранилище — задумывалось потому, что оно есть у всех. Заказчиков вроде как потом найдем (еще лучше вариант «сами прибегут с протянутыми руками») — если все туда уложим. Лица, ответственные за выделение бюджета, считают это чем-то необходимым, в книжках читали, слыхали, ну вроде это как модернизация, и согласно кивают.
  2. Более вероятно. Определены заказчики хранилища данных, допустим, это департамент по продажам, и тут приходит светлая идея: «а давайте сделаем еще небольшое усилие дельта, загоним в него финансы, кадры и еще чуть-чуть и хранилищем будет пользоваться все предприятие». Хранилище построено, но им пользуется только департамент продаж, хотя там все красиво, и молочные береги — бери не хочу, но нет, времени на кисельные берега у коллег нет, им нужно скорее в шахту, с утра до ночи долбить кусочек данных. Ведь это кусочек, добытый потом и кровью (читай: потраченным рабочим временем).

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

  1. Определить формально спонсора проекта хранилища данных — кто будет отвечать за результат и финансово, и духовно
  2. Утвердить скоуп проекта, возможно, этапность, обозначить приблизительные сроки
  3. Согласовать со всеми подразделениями — желательно, с построением бизнес-процессов as is и to be

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

  • Актуальность — текущее состояние программного кода полностью определено составом документации
  • Версионность — возможность анализировать документацию прошлых релизов и планировать модификации на будущие релизы
  • Разделяемость — над документом могут работать одновременно несколько человек
  • Применимость. Тут говорится о том, что для каждого вида документации хранилища важно подобрать такую структуру, которая будет лучше всего восприниматься целевыми пользователями: так, структуру таблиц лучше описывать в табличной форме, бизнес-процессы в виде нотаций, взаимодействие между информационными системами в виде диаграммы, бизнес-словарь в виде вики-системы, и т.д.

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

  • ER-диаграммы
  • BPMN-продукты
  • ETL-решения

Без актуальной документации сложность разработки новых требований будет увеличиваться, а при грамотной — сокращаться.
«Калькулятор». Если считать, что мы не получили «коня в вакууме», тогда эта ситуация о том, когда требования вроде бы выполнены, но выполнены они формально. Вы хотели посчитать остатки по дням — пожалуйста. Хотите получить их в разрезе по регионам контрагентов — такого в требованиях не было, вам нужно сделать выгрузку в excel, далее берете из системы X выгрузку по контрагентам с выбором поля Y, и затем ВПР-ите.
Сложившаяся ситуация свидетельствует об отсутствии опыта у команды, без архитектурного взгляда на последующее развитие хранилища, без, даже примитивной, модели данных. Обычно такие хранилища становятся временными, или о них быстро забывают. По-хорошему, хранилище должно обладать силой снежного кома, катящегося с горы. Сначала, когда ком еще небольшой, а впереди рыхлый снег, вам самим с трудом нужно будет его собирать и толкать. В какой-то момент времени слава о вашем продукте будет распространяться, и пользователи будут смотреть в хранилище все чаще.
Итак, чтобы хранилище не оказалось калькулятором, необходимо обеспечить:

  1. квалифицированные кадры — архитекторы, аналитики, разработчики EtL и SQL
  2. Устав проекта, в котором будут обозначены цели хранилища не только на ближайший бюджетный период, но и на последующие годы
  3. Количественные и качественные критерии хранилища данных. Если не хватает своих кадров, рекомендуется привлечь консультантов
  4. Четко представлять себе, что поможет оптимизировать хранилище данных в дальнейшем — расходы на персонал, ПО, увеличить скорость разработки отчетов и т.д.

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

  1. О ней уже было сказано выше — недостаток квалифицированных кадров;
  2. Безархитекутрная концепция — когда разные части хранилища делаются разными людьми или командами без общей утвержденной концепциии, в результате имеем множественные способы извлечения, трансформации и загрузки данных;
  3. Очень частая ситуация — «аутсорсим разработку», поддержка своя, при этом приемка работ сделана плохо
  4. На каком-то этапе развития хранилища «бюджет кончился». И далее хранилище дорабатывает (поддерживает) не та команда, которая создавала, а те, кому нужны данные

Для предотвращения данных ситуаций, рекомендуются следующие действия:

  1. Сказанное в пунктах выше — квалифицированные кадры, устав проекта, долгосрочный план и бюджет, заинтересованное лицо из топ-менеджера.
  2. Не аутсорс руководит процессом, а внутренний сотрудник (главный аналитик или архитектор) руководит аутсорсом.
  3. Любые сбойные ситуации должны выноситься на собрания на рассмотрения архитектору хранилища. Если архитекторов несколько, то на архитектурный комитет.
  4. Желательно ввести метрику качества хранилища данных, можно использовать эту метрику для привязки к KPI команды.

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

Переход от хранилища данных к единому

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

  1. Процессы поддержания технической и пользовательской документации в актуальном состоянии
  2. Процессы ведения в актуальном состоянии бизнес-словаря (глоссария) данных
  3. Процессы контроля качества данных
  4. Процессы сбора и управления требованиями к ХД и системе отчетности
  5. Процессы управления инфраструктурой хранения и обработки данных
  6. Процессы оптимизации хранения и сбора данных

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

  • Введение горизонтальной структуры ответственности (каждый участник может отвечать за небольшую область)
  • Изображение в графическом виде всех возможных workflow для всех сотрудников (формализация процесса)
  • Внедрение в систему KPI процент и качество выполнения ответственности

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

Немного о целевом архитектурном решении

Несмотря на то, что архитектура ЕХД тянет на отдельную большую статью, или даже книгу, обозначу также основные технические требования к зрелому хранилищу данных:

  1. Парадигма data lake не заменяет корпоративных хранилищ данных, а сосуществует с ним вместе
  2. ЕХД должно иметь различные интерфейсы предоставления данных: средства bi, возможность выполнения ad-hoc sql запросов, стандартное предоставление данных в форматах json, xml и т.д.
  3. Должна быть реализована ролевая модель доступа к данным
  4. Скорость отклика при обращении к данным: 90% типовых запросов — менее 1 секунды, 99% запросов — менее 10 секунд. Должен быть достаточно хороший запас по ресурсам
  5. Наличие единого и связного центрального слоя ХД (предпочтительно — Inmon методология)

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

За время создания в российских компаниях систем под общим названием «корпоративное хранилище данных» (Data Warehouse) было приведено огромное количество различных обоснований важности и нужности этих проектов. В результате КХД из термина, обозначающего класс систем, превратилось в некий абстрактный, но обязательный элемент современного ИТ-ландшафта компании с размытой функциональностью склада информации.

Неудивительно, что при таком положении дел у большинства организаций до сих пор не существует внятного ответа на вопрос о практической ценности КХД и круге решаемых им задач. Что, в конечном итоге, нередко приводит к реализации проектов по построению «супербазы данных», выполняющей функцию backup. Функция, безусловно, полезная, но стоит ли такой эффект усилий, затраченных на проект?

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

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

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

Такому подходу во многом способствуют и вендоры с интеграторами, предлагая построить КХД как панацею от всех бед. Необходимо сохранять значимую информацию из различных источников, используемых в компании, с учетом истории ее изменения во времени? Строим корпоративное хранилище данных! Сложности с построением отчетов? Оперативные системы не выдерживают нагрузки при формировании очередного списка транзакций? Строим специальную базу данных под отчеты – корпоративное хранилище данных! Решили создать ситуационный центр компании? Построить систему управления событиями? Создать панель руководителя? Строим КХД! Вам нужна ERP? Да вы не обойдетесь без корпоративного хранилища! Согласитесь, все перечисленные задачи разные и методы их решения не очевидны. Поэтому если фактически решаемая задача не может быть сформулирована как задача оптимизации процессов построения отчетов для конкретных пользователей в рамках указанных бизнес-функций (даже создаваемых, а не существующих), проект построения КХД обречен на провал.

Наша экспертиза

Мы настаиваем на том, что в постановке цели и задач проекта создания КХД отчеты и их потребители первичны. Перечислим 3 признака того, что компании нужно хранилище данных:

  1. процесс подготовки сводного отчета для руководителя напоминает пирамиду Хеопса или, если хотите, лавину: несколько необходимых руководителю показателей превращаются на следующем уровне в необходимость собрать информацию из десятка отчетов. А они, в свою очередь, готовятся вручную на основе информации из многочисленных информационных систем и десятков Excel-файлов. Десятки сотрудников и даже целые подразделения занимаются перекладыванием цифр из одного Excel-файла в другой;
  2. программисты постоянно заняты написанием новых отчетов, каждый в своей информационной системе, эти отчеты облегчают жизнь на нижнем уровне пирамиды, но не выше. Они стремительно устаревают, т.к. меняются потребности руководства в информации. Соотношение полезный эффект/затраты на разработку для одного отчета невысоко;
  3. сводная отчетность появляется редко и «посмертно», например, за прошедший месяц в середине следующего. Механизм «пирамиды» требует значительного времени на проворачивание «шестеренок», нельзя получить отчет «сегодня за вчера».

Три признака того, что проект по построению хранилища задуман и организован плохо и, скорее всего, окончится неудачей:

  1. вы не знаете, какие отчеты хотите получать из хранилища, анализ какой информации в каких разрезах нужен;
  2. вы не знаете, какие данные есть в системах-источниках, по системам нет документации, описывающей структуры данных или хотя бы принципы работы пользователей в них;
  3. вы хотите «всё и сразу»: в рамках одного первого проекта свести в единое хранилище данные из полусотни систем, эксплуатируемых компанией в несколько тысяч, а то и десятков тысяч человек.

Рецепт правильного КХД

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

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

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

Три признака того, что КХД не спасет:

  1. значительная часть необходимых в хранилище данных не «прописана» ни в одной информационной системе, а существует только в виде Excel-файлов, которые ведут отдельные сотрудники на своих локальных компьютерах. Данные из Excel, конечно, можно загрузить в хранилище, но есть моменты:
  • возникает проблема справочников: их нет. Например, данные на разных листах или в разных файлах, может быть, и относятся к одному клиенту, но об этом знает только человек. Сотрудник понимает, что «ОАО Мечта» и «Мечта г. Бердянск» – один и тот же клиент, а системе это не очевидно;
  • проблема формата: он меняется (а процедура загрузки без программиста – нет). Так просто добавить еще пару столбцов и желательно не в конец таблицы, а там, где удобнее – в середину… А еще можно под каждый месяц добавлять новый лист и называть их то «январь 2013», то «01.2013», то «янв.13»;
  • есть и другие, более «технические» проблемы, например, проблема уникальных идентификаторов строк данных, но об этом в другой раз;
  1. данные в основном находятся в нормальных информационных системах, вот только сами эти системы ничего друг о друге не знают. В каждой из них – свой справочник контрагентов, городов, номенклатурных позиций, а нужны сводные отчеты по данным из систем в разрезе контрагентов, городов, номенклатурных позиций… Здесь сначала нужно озаботиться синхронизацией справочной информации, т.е. нужен MDM (Master Data Management) или НСИ (управление нормативно-справочной информацией);
  2. информационные системы с данными для хранилища представляют собой «черные ящики». Данные в них накапливаются, но не понятно, как вытащить их наружу, и нет возможности доработать систему. Чуть более мягкий вариант – вытащить данные все-таки можно, но каждый раз вручную, с помощью специально обученного человека. Актуальность и полнота данных в хранилище здесь будут завязаны на человеческий фактор.

Каждой отрасли – по хранилищу?

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

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

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

Более того, мнимая «готовость» коробочных решений в виде отраслевых хранилищ чаще всего и толкает компанию к воплощению глобальной цели – интеграции всех данных из всех имеющихся систем. Потребности пользователей размываются, задача вновь становится неподъемной, и проект проваливается.

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

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


(Источник картинки)

Введение

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

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

Традиционная архитектура хранилища данных

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

Трехуровневая архитектура

Довольно часто традиционная архитектура хранилища данных имеет трехуровневую структуру, состоящую из следующих уровней:

  • Нижний уровень: этот уровень содержит сервер базы данных, используемый для извлечения данных из множества различных источников, например, из транзакционных баз данных, используемых для интерфейсных приложений.
  • Средний уровень: средний уровень содержит сервер OLAP, который преобразует данные в структуру, лучше подходящую для анализа и сложных запросов. Сервер OLAP может работать двумя способами: либо в качестве расширенной системы управления реляционными базами данных, которая отображает операции над многомерными данными в стандартные реляционные операции (Relational OLAP), либо с использованием многомерной модели OLAP, которая непосредственно реализует многомерные данные и операции.
  • Верхний уровень: верхний уровень — это уровень клиента. Этот уровень содержит инструменты, используемые для высокоуровневого анализа данных, создания отчетов и анализа данных.

Kimball vs. Inmon

Два пионера хранилищ данных: Билл Инмон и Ральф Кимбалл предлагают разные подходы к проектированию.
Подход Ральфа Кимбалла основывается на важности витрин данных, которые являются хранилищами данных, принадлежащих конкретным направлениям бизнеса. Хранилище данных — это просто сочетание различных витрин данных, которые облегчают отчетность и анализ. Проект хранилища данных по принципу Кимбалла использует подход «снизу вверх».
Подход Билла Инмона основывается на том, что хранилище данных является централизованным хранилищем всех корпоративных данных. При таком подходе организация сначала создает нормализованную модель хранилища данных. Затем создаются витрины размерных данных на основе модели хранилища. Это известно как нисходящий подход к хранилищу данных.

Модели хранилищ данных

В традиционной архитектуре существует три общих модели хранилищ данных: виртуальное хранилище, витрина данных и корпоративное хранилище данных:

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

Звезда vs. Снежинка

Схемы «звезда» и «снежинка» — это два способа структурировать хранилище данных.
Схема типа «звезда» имеет централизованное хранилище данных, которое хранится в таблице фактов. Схема разбивает таблицу фактов на ряд денормализованных таблиц измерений. Таблица фактов содержит агрегированные данные, которые будут использоваться для составления отчетов, а таблица измерений описывает хранимые данные.
Денормализованные проекты менее сложны, потому что данные сгруппированы. Таблица фактов использует только одну ссылку для присоединения к каждой таблице измерений. Более простая конструкция звездообразной схемы значительно упрощает написание сложных запросов.

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

ETL vs. ELT

ETL и ELT — два разных способа загрузки данных в хранилище.
ETL (Extract, Transform, Load) сначала извлекают данные из пула источников данных. Данные хранятся во временной промежуточной базе данных. Затем выполняются операции преобразования, чтобы структурировать и преобразовать данные в подходящую форму для целевой системы хранилища данных. Затем структурированные данные загружаются в хранилище и готовы к анализу.

В случае ELT (Extract, Load, Transform) данные сразу же загружаются после извлечения из исходных пулов данных. Промежуточная база данных отсутствует, что означает, что данные немедленно загружаются в единый централизованный репозиторий.
Данные преобразуются в системе хранилища данных для использования с инструментами бизнес-аналитики и аналитики.

Организационная зрелость

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

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

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

Новые архитектуры хранилищ данных

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

Amazon Redshift

Amazon Redshift — это облачное представление традиционного хранилища данных.
Redshift требует, чтобы вычислительные ресурсы были подготовлены и настроены в виде кластеров, которые содержат набор из одного или нескольких узлов. Каждый узел имеет свой собственный процессор, память и оперативную память. Leader Node компилирует запросы и передает их вычислительным узлам, которые выполняют запросы.
На каждом узле данные хранятся в блоках, называемых срезами. Redshift использует колоночное хранение, то есть каждый блок данных содержит значения из одного столбца в нескольких строках, а не из одной строки со значениями из нескольких столбцов.
Redshift использует архитектуру MPP (Massively Parallel Processing), разбивая большие наборы данных на куски, которые назначаются слайсам в каждом узле. Запросы выполняются быстрее, потому что вычислительные узлы обрабатывают запросы в каждом слайсе одновременно. Узел Leader Node объединяет результаты и возвращает их клиентскому приложению.
Клиентские приложения, такие как BI и аналитические инструменты, могут напрямую подключаться к Redshift с использованием драйверов PostgreSQL JDBC и ODBC с открытым исходным кодом. Таким образом, аналитики могут выполнять свои задачи непосредственно на данных Redshift.
Redshift может загружать только структурированные данные. Можно загружать данные в Redshift с использованием предварительно интегрированных систем, включая Amazon S3 и DynamoDB, путем передачи данных с любого локального хоста с подключением SSH или путем интеграции других источников данных с помощью API Redshift.

Google BigQuery

Архитектура BigQuery не требует сервера, а это означает, что Google динамически управляет распределением ресурсов компьютера. Поэтому все решения по управлению ресурсами скрыты от пользователя.
BigQuery позволяет клиентам загружать данные из Google Cloud Storage и других читаемых источников данных. Альтернативным вариантом является потоковая передача данных, что позволяет разработчикам добавлять данные в хранилище данных в режиме реального времени, строка за строкой, когда они становятся доступными.
BigQuery использует механизм выполнения запросов под названием Dremel, который может сканировать миллиарды строк данных всего за несколько секунд. Dremel использует массивно параллельные запросы для сканирования данных в базовой системе управления файлами Colossus. Colossus распределяет файлы на куски по 64 мегабайта среди множества вычислительных ресурсов, называемых узлами, которые сгруппированы в кластеры.
Dremel использует колоночную структуру данных, аналогичную Redshift. Древовидная архитектура отправляет запросы тысячам машин за считанные секунды.
Для выполнения запросов к данным используются простые команды SQL.

Panoply

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

Интеллектуальная инфраструктура данных Panoply включает в себя следующие функции:

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

По ту сторону облачных хранилищ данных

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

  • Загрузка данных в облачные хранилища данных нетривиальна, а для крупномасштабных конвейеров данных требуется настройка, тестирование и поддержка процесса ETL. Эта часть процесса обычно выполняется сторонними инструментами;
  • Обновления, вставки и удаления могут быть сложными и должны выполняться осторожно, чтобы не допустить снижения производительности запросов;
  • С полуструктурированными данными трудно иметь дело — их необходимо нормализовать в формате реляционной базы данных, что требует автоматизации больших потоков данных;
  • Вложенные структуры обычно не поддерживаются в облачных хранилищах данных. Вам необходимо преобразовать вложенные таблицы в форматы, понятные хранилищу данных;
  • Оптимизация кластера. Существуют различные варианты настройки кластера Redshift для запуска ваших рабочих нагрузок. Различные рабочие нагрузки, наборы данных или даже различные типы запросов могут потребовать иной настройки. Для достижения оптимальной работы, необходимо постоянно пересматривать и при необходимости дополнительно настраивать конфигурацию;
  • Оптимизация запросов — пользовательские запросы могут не соответствовать передовым методам и, следовательно, будут выполняться намного дольше. Вы можете работать с пользователями или автоматизированными клиентскими приложениями для оптимизации запросов, чтобы хранилище данных могло работать так, как ожидалось
  • Резервное копирование и восстановление — несмотря на то, что поставщики хранилищ данных предоставляют множество возможностей для резервного копирования ваших данных, их нетривиально настроить и они требуют мониторинга и пристального внимания

Записи созданы 8837

Добавить комментарий

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

Похожие записи

Начните вводить, то что вы ищите выше и нажмите кнопку Enter для поиска. Нажмите кнопку ESC для отмены.

Вернуться наверх