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

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

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

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

Почему хранилища данных должны развиваться

Традиционный подход

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

• Выявление потребности: На этом этапе разработчики встретятся с бизнес-аналитиками и другими конечными пользователями, чтобы документально определить, какой тип BI требуется.
• дизайн: После изучения требований разработчики разработают прототип архитектуры, который включает в себя физическую/логическую структуру и сопоставления данных, необходимые для заполнения и обслуживания.
• Создать доступность: Затем разработчики должны решить, как получить доступ к данным хранилища для составления отчетов и анализа. Данные могут быть доступны через интерфейсную платформу BI, такую ​​как PowerBI или Tableau, или через специальное решение, созданное в соответствии с потребностями организации.
• Тестирование: Включает в себя как часть контроля качества для выявления и устранения любых ошибок, которые могут ухудшить удобство использования/производительность. А также приемочное тестирование пользователей, чтобы убедиться, что хранилище данных соответствует заявленной цели.

Ваше хранилище данных — это не проект. Это Процесс.

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

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

 

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

 

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

 

• Конечно, поскольку большинство этих проблем выявляются только на этапе тестирования, любые исправления увеличивают стоимость и сроки проекта.

Хорошо, но что делает подход, основанный на метаданных, лучше?

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

Все начинается с модели данных

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

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

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

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

Работайте итеративно для удовлетворения требований BI

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

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

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

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

Попрощайтесь с ручным кодированием

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

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

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

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

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

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

Тестируйте одновременно перед развертыванием

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

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

Реплицируйте свою схему в любой ведущей базе данных.

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

Стремясь воспользоваться преимуществами масштабируемости и производительности Амазонка Redshift, устанавливаем соединение с базой данных и вперед инженер. Хотите сохранить отчетность внутри компании? Выберите локального поставщика, например SQL Server или базу данных Oracle — выбор за вами.

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

Познакомьтесь с хранилищем данных на основе метаданных с помощью Astera Построитель хранилища данных

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