Михаил Коновалов, начальник отдела сопровождения интеграционных проектов дирекции информационных технологий МКБ Доброго времени суток, хабровчане!
Цель
Системный подход к управлению загрузками.Мы хотим рассказать вам, как организовать и автоматизировать наполнение репозитория информацией и при этом не запутаться в потоках из различных источников.
Преамбула
В корпоративной базе данных любой компании рано или поздно наступает момент, когда она разрастается до таких размеров, что глаз архитектора перестает улавливать неопределенность (хаос) системы, и превращается в неуправляемую массу всевозможных загрузки из разных источников.Вам повезло, если ваша система была разработана с нуля (с первой таблицы) и обслуживалась одним архитектором, одной командой разработчиков и аналитиков.
А кроме того, этот архитектор грамотно управлял моделью хранилища данных.
Но жизнь многогранна, в большинстве случаев СХД разрастается спонтанно, сначала было 30 таблиц, потом добавлялось еще немного по мере необходимости, а потом «нам понравилось» и мы начали добавлять при каждой возможности, а теперь у нас их больше пяти тысяча, да Слои, постановка и витрины тоже появились.
И все это «счастье» свалилось на нас в результате одного, но очень удобного процесса, представляющего собой строгую причинно-следственную связь: Бизнес говорит: «Нам нужны такие-то данные.
Нам нужен новый отчет» аналитик ищет разработчик реализует архитектор соглашается и вводит это в модель данных Но, как правило, последнего пункта в действительности не существует. И появляется оно лишь в определенный момент в крупных компаниях, разросшихся до собственной СХД, где заботливый архитектор грамотно управляет целостностью информации в базе данных.
Такие репозитории представляют собой обзор предыдущей структуры, которая была передокументирована, а чаще всего перестроена с прицелом на предыдущую (недокументированную) версию.
Итак, краткое содержание: нет СХД, которая родилась сразу и не представляла собой ранее обычную базу данных с набором таблиц; все, что существует сейчас и представляет собой четко алгоритмизированную и документированную структуру, получено в результате «горького опыта» предыдущих разработок.
Если вы являетесь счастливым обладателем «правильной» СХД, или входите в команду этого счастливого обладателя, эта статья «в теории» может показаться вам интересной.
А если вам просто предстоит пройти обзор, или (не дай бог) перестроиться, то эта статья может значительно облегчить вам жизнь.
Поскольку источников информации может быть невообразимое количество, то и потоков для загрузки и перезагрузки разных объектов существует как минимум столько же, а зачастую и гораздо больше, так как каждый объект базы данных может претерпеть не одно преобразование, прежде чем его данные смогут быть использованы в конечном итоге.
пользователь для создания бизнес-отчетов.
Но ведь именно для него, для бизнеса, а не для собственного удовольствия, построена вся эта экосистема «переливания из сосуда в сосуд».
В качестве нашей базы данных хранения используется Oracle. Когда-то, на этапе создания, центральное ядро нашей базы данных состояло из пары сотен таблиц.
О постановке и витринах мы даже не думали.
Но, как говорится, «все течет, все меняется», и вот мы повзрослели! Бизнес диктует новые требования, и уже появилась интеграция с различными базами данных MS SQL, SyBASE, Vertica, Access. Информация поступает к нам отовсюду, появились даже такие экзотические вещи, как обмен XML и JSON со сторонними системами, а также появился совершенно анахроничный файл XLS как источник информации.
Жизнь заставила нас пройти обзор и обновить модель данных, поддерживать ее и поддерживать.
Вот как выглядит одна из частей основного ядра: 
Рис.
1 Смотря кого выберете, но по мне это читается только на ватмане, а А0 будет мелковато, 4А0 лучше, на экране это за гранью зрения и воображения.
Теперь вспомните, что это только ядро (Core Data Layer), а точнее его основная часть, полное ядро состоит из нескольких подсистем, которые мало чем уступают основной.
К этому добавлено Первичный уровень данных И Уровень витрины данных .
Дальше — больше, первичный уровень получает свою информацию из источников данных, а это, как уже говорилось выше, различные базы данных и файлы.
С другой стороны, различные системы отчетности подключаются потребителем к уровню отображения.
Поначалу, когда таблиц в базе данных было мало и алгоритмы загрузки были реализованы на PL/SQL, особых сложностей с пониманием обновления данных не возникало.
Но с ростом DWH покупка Informatica PowerCenter стала стратегически важным решением.
Несмотря на все удобство этого инструмента, как с точки зрения надежности загрузки, так и с точки зрения визуализации разработки, этот инструмент имеет ряд недостатков.
На рисунке ниже показана модель последовательности запуска загрузки DWH. 
Рис.
2 Самый главный недостаток — субъективность; точнее, только архитектор может гарантировать, что транзакции не загружаются раньше счетов.
К сожалению, по мере увеличения DWH растет и энтропия информации.
С учетом физической модели данных (рис.
1) и логики загрузки этих данных (рис.
2) конструкция получается одинаковая.
Что делать и как с этим справиться, спросите вы.
Естественно: иметь гениального архитектора, способного разобраться во всех связях этих тонкостей.
Который будет отслеживать все потоки, координировать новые потоки и предотвращать загрузку таблицы проводок раньше таблицы счетов.
Конечно, все это заложено в алгоритмы и регламентируется в процессе отсечками нагрузок, но изначально понять и установить строгую последовательность нагрузок может только архитектор, а при таких разветвлениях вероятность допустить ошибку очень велика.
высокий.
Теория
Теперь я попытаюсь изложить основные мысли словаря модели данных, а также какие проблемы он решает. Поскольку данные в хранилище находятся в таблицах, а источники данных — частично таблицы и частично представления, последние сами по себе являются таблицами.Это приводит к простой идее — создать структуру зависимостей.
ТАБЛИЦА-ТАБЛИЦА .
Форма 3НФ идеально подходит для этого.
Сначала, заполняя сущность DWH данными, мы называем ее (цель) , в самом общем случае можно представить в виде выбирать из разных таблиц.
Будь то таблицы Oracle, SyBase, MSSQL, xls файлы или что-то еще, не так важно, все это мы называем их исходниками.
(источник) .
То есть у нас есть источник , которая впадает в цель .
Во-вторых, каждая сущность DWH имеет ссылки, которые зависят друг от друга.
В-третьих, существует хронология начала загрузок различных сущностей СХД.
Осталось только реализовать это – как? Казалось бы, очень просто, от основания вашего СХД, архитектор при появлении следующей таблицы сущностей (цель) необходимо просмотреть и ввести в словарь сущность-получатель и все сущности, служащие источниками.
Далее во второй таблице словаря устанавливаем связи между этими исходными сущностями в селекте, а также всеми подчиненными таблицами, которые связаны ссылками.
Затем вы можете интегрировать загрузку этой сущности в цепочку загрузки хранилища.
Всего две таблицы – и возможность учета последовательности заполнения хранилища данными в алгоритме решена.
Словарь модели данных позволит решить следующие задачи: Просмотр зависимостей.
Вы можете увидеть, какие данные откуда поступают. Это удобно для аналитиков, которых всегда мучают вопросы: «откуда, что есть и откуда все берется».
Представьте это в приложении в виде дерева, а из источник К цель и наоборот: из цель К источник .
Разрыв петель.
При интеграции очередной загрузки в уже работающий общий поток, не имея словаря модели данных, вполне можно допустить ошибку и назначить время начала загрузки следующей цели раньше одного из ее источников.
Это создает петлю.
Словарь модели данных может легко избежать этого.
Можно написать алгоритм заполнения хранилища с учетом модельного словаря.
В этом случае нет необходимости куда-либо вставлять еще одну загрузку; достаточно отразить его в словаре и алгоритм сам определит его место.
Все, что вам нужно сделать, это нажать нужную кнопку «Делать все» .
Загрузчик запустит лавину загрузок всех сущностей хранилища — от простых (независимых) до сложных (зависимых).
Выполнение
В теории всегда всё просто и красиво; на практике дела обстоят несколько иначе.То, что написано в предыдущем разделе, — это идеальная ситуация, когда СХД разрабатывалась с нуля, когда с ней всегда был архитектор.
Если вам не повезло, вы «благополучно» все это прошли, архитектора нет, но есть гигантский набор столов, то выход все равно есть.
Теперь, собственно, расскажу, как нам удалось наверстать упущенное и сделать обзор и перестроить довольно дешево.
Наша СХД начала развиваться с решения руководства об этой (СХД) острой необходимости.
Первоначально использовался инструмент PL/SQL. Чуть позже мы перешли на Информатику.
Естественно, приоритетом было время создания.
Модель данных в PowerDesigner появилась некоторое время спустя, в то время, когда четко сформировалась уверенность, что четкого представления о СХД ни у кого нет. С моделью на стене мы пожили еще некоторое время, когда стало понятно, что мы не справляемся с управлением всей этой системой, мы начали искать решение, которое я попытаюсь кратко описать здесь.
Сам словарь модели данных прост, как палка.
А вот заполнить - проблема.
N-месяцев кропотливого, а главное внимательного рассмотрения трех вышеперечисленных частей: из каких источников (источников) состоит каждый объект хранения (цель); каковы отношения между объектами хранения (ссылками); хронология начала загрузок и заполнения хранилища.
К счастью, нам помогли Oracle и Informatica, а еще очень повезло, что репозиторий Informatica находится в базе данных Oracle. Взяв за основу, что одна сессия Informatica — это атом загрузки любой сущности DWH, немного покопавшись в репозитории, мы нашли все исходники и цели.
То есть в пределах одной сессии для всех ее целей (обычно только одна) источниками являются все ее источники.
Таким образом, мы можем заполнить первое условие задачи.
Но не спешите радоваться, источник можно представить как весьма навороченный селект, поэтому мне пришлось написать парсер, который вытаскивает все указанные в селекте таблицы — это было совсем несложно.
Но это еще не все, эти таблицы сами по себе могут быть представлениями.
Эта проблема также была решена с помощью DBA_VIEWS (или через DBA_DEPENDENCIES).
Второе условие этой трилогии мы вытащили из модели данных (рис.
1) и DBA_CONSTRAINTS. Третье условие мы также получили из репозитория Информатика на основе (рис.
2).
Что из всего этого получилось? Во-первых, мы распутали все петли, которые нам удалось накрутить в ходе эволюции нашей СХД.
Во-вторых, у нас получилось замечательное дерево для аналитиков: 
Рис.
3 В-третьих, наш суперзагрузчик, показанный на рис.
2, превратился в элегантный (извините, коллеги, но размытость картинки намеренна, так как это рабочие данные): 
Рис.
4 Вероятно, существует множество других способов использования словаря модели данных.
Спасибо всем! Теги: #базы данных #Администрирование баз данных #Анализ и проектирование систем
-
Написание Сценариев Bash Стало Проще
19 Oct, 24 -
Электровелосипед Из Дерьма И Палок
19 Oct, 24 -
Герои Gdc 2010: Uncharted 2, Кармак И Ньюэлл
19 Oct, 24 -
Идеальная Компания?
19 Oct, 24 -
Китайская База Данных Вредоносных Программ
19 Oct, 24 -
Autodesk Переходит На Мобильные Телефоны
19 Oct, 24
