Стратегии заполнения базы данных отчетности / хранилища

Question

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

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

Какие еще стратегии можно использовать для заполнения этой базы данных отчетов?

• SSIS? Это было рассмотрено, но, как представляется, не предлагает гораздо более чистого и более удобного подхода, чем просто хранимые процедуры.
• Отдельный процесс C # (или любого другого языка), который объединяет данные в памяти и затем помещает их в базу данных отчетов? Это позволило бы нам написать модульные тесты для логики и упорядочить код более удобным способом.

Я ищу какие-либо новые идеи или дополнительные мысли по поводу вышеизложенного. Спасибо!

Answer 1

Наш общий процесс:

1. Копирование данных из исходных таблиц в таблицы с одинаковыми структура в загрузочной базе данных
2. Преобразование данных в этап стол, имеющий одинаковую структуру в качестве конечной таблицы фактов / измерений
3. Копирование данных из промежуточных таблиц в таблицы фактов / измерений

Служба SSIS подходит для этапа 1, который представляет собой процесс копирования 1: 1 с некоторыми основными сопоставлениями типов данных и преобразованиями строк.

Для шага 2 мы используем сочетание хранимых процедур, .NET и Python. Большая часть логики в процедурах, с такими вещами, как тяжелый анализ во внешнем коде Основным преимуществом чистого TSQL является то, что очень часто преобразования зависят от других данных в загружаемой базе данных, например, Использование таблиц сопоставления в SQL JOIN намного быстрее, чем процесс построчного поиска во внешнем скрипте, даже с кэшированием. По общему признанию, это - только мой опыт, и процедурная обработка могла бы быть лучше для набора данных.

В некоторых случаях нам приходится выполнять сложный анализ (последовательностей ДНК), и TSQL просто не является жизнеспособным решением. Вот где мы используем внешний код .NET или Python для выполнения работы. Я полагаю, что мы могли бы делать все это в процедурах / функциях .NET и хранить их в базе данных, но для этого требуются другие внешние соединения, поэтому имеет смысл отдельная программа.

Шаг 3 - это серия операторов INSERT ... SELECT ...: это быстро.

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

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

Answer 2

Я бы посмотрел на лучшие практики ETL (извлечение / преобразование / загрузка). Вы спрашиваете о покупке против строительства, конкретного продукта и конкретной техники. Возможно, стоит сначала сделать резервную копию нескольких шагов.

Несколько соображений:

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

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

Answer 3

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

SSIS немного трудновато для изучения, и, безусловно, есть некоторые приемы, чтобы извлечь из этого максимум пользы, но я думаю, что это стоит инвестиций. Один или два хороших справочника, вероятно, были бы хорошим вложением (Wrox's Expert SQL Server 2005 Integration Services неплохой).