Антихрупкость архитектуры хранилищ данных13.04.2016 22:33

В этой статье речь пойдет об архитектуре хранилищ данных. Чем руководствоваться при ее построении, какие подходы работают — и почему.
Посадил дед… хранилище. И выросло хранилище большое-пребольшое. Вот только толком не знал, как оно устроено. И затеял дед ревью. Позвал дед бабку, внучку, кота и мышку на семейный совет. И молвит такую тему: «Выросло у нас хранилище. Данные со всех систем стекаются, таблиц видимо-невидимо. Пользователи отчеты свои стряпают. Вроде бы все хорошо — жить да жить. Да только одна печаль — никто не знает, как оно устроено. Дисков требует видимо-невидимо — не напасешься! А тут еще пользователи ко мне ходить повадились с жалобами разными: то отчет зависает, то данные устаревшие. А то и совсем беда — приходим мы с отчетами к царю-батюшке, а цифры-то между собой не сходятся. Не ровен час — разгневается царь — не сносить тогда головы — ни мне, ни вам. Вот решил я вас собрать и посоветоваться: что делать-то будем?».
Окинул он своим взором собрание и спрашивает:
— Вот ты, бабка знаешь, как оно устроено наше хранилище?
— Нет, дед, не знаю. Да и откуда мне знать-то? Вон там какие бравые хлопцы его охраняют! Одни усищи какие! Не подступишься. Я зашла как-то их проведать, пирожков напекла. А они пирожки-то съели, усы вытерли и говорят: «Да чего ты пришла, бабка? Какое тебе хранилище? Ты скажи — какой тебе отчет нужен — мы тебе и сделаем! Ты главное пирожки почаще приноси! Уж больно они у тебя вкусные.»
— А ты, внученька любимая, знаешь ли как устроено наше хранилище?
— Нет, деда, не знаю. Дали мне как-то доступ к нему. Подключилась я, гляжу —, а там таблиц — видимо-невидимо. И в схемы разные упрятаны. Глаза разбегаются…. Я сперва растерялась. А потом пригляделась — какие-то из них пустые, другие заполнены, да лишь наполовину. А еще данные-то, похоже, повторяются. Немудрено, что дисков не напасешься, с такой избыточностью-то!
— Ну, а ты, кот, что скажешь про хранилище-то наше? Есть в нем что-то хорошее?
— Да как не сказать, дед — скажу. Я по внучкиной просьбе пытался в отдельной схемке пилотик смастырить — витринку маленькую. Дабы понять, какая торговля для нашего государства выгодна — какие продукты хорошо у купцов идут, те дань платят — казну пополняют. А какие — из рук вон плохо. И стал я из хранилища сего данные себе подбирать. Фактов насобирал. И стал пытаться сопоставить их супротив продуктов. И что же, дед, я увидел — продукты-то они вроде бы и одинаковые, а смотришь в таблички — разные! Принялся я их тогда гребешком внучкиным причесывать. Чесал-чесал — и привел к некому единообразию, глаз ласкающему. Но рано я возрадовался — на другой день запустил я свои скриптики чудесные данные в витринке обновить –, а у меня все и разъехалось! «Как так?» — думаю, — внучка-то поди расстроится — сегодня надо было бы наш пилотик министру показывать. Как же мы пойдем-то — с такими данными?
— Да, печальные сказки, кот, рассказываешь. Ну, а ты, мышка-норушка, неужто не пыталась разузнать про хранилище? Ты у нас девушка бойкая, юркая, общительная! Что ты нам поведаешь?
— Да как, дедушка, не пытаться — конечно, я мышка тихая, да проворная. Попросила как-то внучка кота модель данных нашего государственного хранилища раздобыть. А кот, конечно, ко мне пришел — на тебя, говорит, мышка, вся надежда! Ну что доброе дело хорошим людям (и котам) не сделать? Пошла я в замок, где начальник хранилища модель данных в сейфе прячет. И затаилась. Дождалась, когда он ту модель из сейфа-то вынет. Только он за кофе вышел — я прыг на стол. Гляжу на модель — ничего понять не могу! Как так? Не узнаю наше хранилище! У нас таблиц тысячи несметные, данных — потоки неуемные! А тут — все стройно да красиво… Посмотрел он на сию модель — и обратно в сейф убрал.
— Да, уж совсем странные вещи, ты нам, мышка, поведала.
Задумался крепко дед.
— Что делать-то будем, други мои? Ведь с таким-то хранилищем долго не проживешь… Пользователи вон скоро — совсем терпение потеряют.

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

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

В принципе, у нас неплохое хранилище: если не трогать — то все работает. Правда, как только требуется внести изменение — начинаются «локальные обвалы».
Данные загружаются ежедневно, по регламенту, в рамках одного большого процесса, в течение 8ч. И нас это устраивает. Но если вдруг возникает сбой — это требует ручного вмешательства. И дальше все может работать непредсказуемо долго, т.к. потребуются участие человека в процессе.
Накатили релиз — жди проблем.
Какой-то один источник не смог вовремя отдать данные — ждут все процессы.
Целостность данных контролирует база данных — поэтому наши процессы падают с ошибкой, когда она нарушается.
У нас очень большое хранилище — 2000 таблиц в одной общей схеме. И еще 3000 в множестве других схем. Мы уже слабо представляем, как они устроены и по какому поводу появились. Поэтому, нам бывает сложно что-то переиспользовать. И приходится многие задачи решать заново. Поскольку, так проще и быстрее (чем разбираться «в чужом коде»). В итоге имеем расхождения и дублирующийся функционал.
Мы ожидаем, что источник будет давать качественные данные. Но оказывается, что это нет так. В итоге мы много времени тратим на выверку своих финальных отчетов. И весьма в этом преуспели. У нас даже есть отлаженный процесс. Правда, это занимает время. Но пользователи привыкли…
Пользователь не всегда доверяет нашим отчетам и требует обоснования той или иной цифры. В каких-то случаях он прав, а в каких-то нет. Но нам очень сложно их обосновывать, т.к. у нас не предусмотрено средств «сквозного анализа» (или data lineage).
Мы могли бы привлечь дополнительных разработчиков. Но у нас проблема — как нам включить их в работу? Как наиболее эффективно распараллелить работы?
Как развивать систему постепенно, не уходя в разработку «ядра системы» на целый год?
Хранилище данных ассоциируется с корпоративной моделью. Но мы точно знаем (видели в банке XYZ), что строить модель можно бесконечно долго (в банке XYZ шесть месяцев ходили и обсуждали бизнес-сущности, без какого-либо движения). А зачем она вообще? Или может, лучше без нее, если с ней столько проблем? Может, ее вообще как-то сгенерировать?
Мы решили вести модель. Но как системно развивать модель данных хранилища? Нужны ли нам «правила игры» и какие они могут быть? Что нам это даст? А что, если мы ошибемся с моделью?
Должны ли мы сохранять данные, или историю их изменений, если «бизнесу они не нужны»? Не хотелось бы «хранить мусор» и усложнять использование этих данных для реальных задач. Должно ли хранилище сохранят историю? Какая она бывает? Как хранилище работает со временем?
Нужно ли пытаться унифицировать данные на хранилище, если у нас есть система управления НСИ? Если есть МДМ, означает ли это, что теперь вся проблема с мастер-данными решена?
У нас скоро ожидается замена ключевых учетных систем. Должно ли хранилище данных быть готовым к смене источника? Как этого достичь?
Нужны ли нам метаданные? Что под этим будем понимать? Где именно они могут быть использованы? Как можно реализовать? Нужно ли их хранить «в одном месте»?
Наши Заказчики крайне не стабильны в своих требованиях и желаниях — постоянно что-то меняется. У нас вообще бизнес- очень динамичный. Пока мы что-то делаем — это уже становится ненужным. Как нам сделать так, чтобы выдавать результат максимально быстро — как горячие пирожки?
Пользователи требуют оперативности. Но мы не можем наши основные процессы загрузки запускать часто, т.к. это нагружает системы-источники (плохо сказывается на производительности) — поэтому, мы вешаем дополнительные потоки данных — которые будут забирать точечно — то, что нам нужно. Правда, получается много потоков. И часть данных мы потом выкинем. К тому же будет проблема сходимости. Но по-другому никак…

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

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

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

ранее для построения отчета данных хватало — теперь потребовалось подключить дополнительные поля либо новый источник данных;
ранее реализованные методики обработки данных устарели — нужно переработать алгоритмы и все, на что это влияет;
ранее всех устраивало текущее значение атрибута справочника на информационной панели — теперь требуется значение, актуальное на момент возникновения анализируемого факта/ события;
возникло требование к глубине истории хранения данных, которого раньше не было — хранить данные не за 2 года, а за 10 лет;
ранее было достаточно данных по состоянию «на конец дня/ периода» — теперь нужно состояние данных «внутри дня», либо на момент определенного события (например, принятия решения по кредитной заявке — для Basel II);
ранее нас устраивала отчетность по данным на вчера (T-1) или позже, сейчас нам нужен T0;
и т.д.

И интеграционные взаимодействия с системами-источниками, и требования со стороны потребителей данных хранилища — это внешние факторы для хранилища данных: одни системы-источники сменяют другие, объемы данных растут, форматы поступающих данных меняются, пользовательские требования меняются и т.п. И все это — типовые внешние изменения, к которым наша система — наше хранилище — должно быть готово. При правильной архитектуре они не должны убить систему.
Но это еще не все.
Говоря об изменчивости, мы, прежде всего, вспоминаем внешние факторы. Ведь внутри мы можем все контролировать, нам так кажется, верно? И да, и нет. Да, большинство факторов, которые вне зоны влияния — внешние. Но есть и «внутренняя энтропия». И именно в силу ее наличия нам иногда нужно вернуться «в точку 0». Начать игру сначала.
В жизни мы часто склонны начинать с нуля. Почему нам это свойственно? И так ли это плохо?
Применительно к ИТ. Для самой системы — это может оказаться очень хорошо — возможность пересмотреть отдельные решения. Особенно, когда мы можем сделать это локально. Рефакторинг — процесс распутывания той «паутины», которая периодически возникает в процессе развития системы. Возврат «к началу» может быть полезен. Но имеет цену.
При грамотном управлении архитектурой эта цена снижается — и сам процесс развития системы становится более контролируемым и прозрачным. Простой пример: если соблюдается принцип модульности — можно переписать отдельный модуль, не затронув внешние интерфейсы. И этого нельзя сделать при монолитной конструкции.
Антихрупкость системы определяется архитектурой, которая в нее заложена. И именно это свойство делает ее адаптивной.
Когда мы говорим об адаптивной архитектуре — мы подразумеваем, что система способна адаптироваться к изменениям, а вовсе не то, что мы саму архитектуру постоянно изменяем. Наоборот, чем более устойчива и стабильна архитектура, чем меньше требований, которые влекут за собой ее пересмотр — тем более адаптивна система.
Гораздо более высокую цену будут иметь решения, предполагающие пересмотр всей архитектуры целиком. И для их принятия нужно иметь очень веские основания. Например, таким основанием может служить требование, которое нельзя реализовать в рамках существующей архитектуры. Тогда говорят — появилось требование, влияющее на архитектуру.
Таким образом, мы также должны знать свои «границы антихрупкости». Архитектура не разрабатывается «в вакууме» — она опирается на текущие требования, ожидания. И если ситуация принципиально меняется — мы должны понимать, что вышли за пределы текущей архитектуры — и нам нужно пересмотреть ее, выработать иное решение — и продумать пути перехода.
Например, мы заложились на то, что в хранилище нам нужны будут данные всегда на конец дня, забор данных мы будем делать ежедневно по стандартным интерфейсам систем (через набор представлений). Потом от подразделения управления рисками пришли требования о необходимости получать данные не в конце дня, а на момент принятия решения о кредитовании. Не нужно пытаться «натягивать не натягиваемое» — нужно просто признать этот факт — чем скорее, тем лучше. И начать прорабатывать подход, который позволит нам решить задачу.
Тут возникает весьма тонкая грань — если мы будем принимать во внимание только «требования в моменте» и не будем смотреть на несколько шагов вперед (и на несколько лет вперед), то мы увеличиваем риск столкнуться с влияющим на архитектуру требованием слишком поздно — и цена наших изменений будет очень высока. Смотреть чуть вперед — в границах нашего горизонта — еще никому не вредило.
Пример системы из «сказки про хранилище» — это как раз пример весьма шаткой системы, построенной на хрупких подходах к проектированию. И если так происходит — разрушение наступает довольно быстро, именно для этого класса систем.
Почему я могу так утверждать? Тема хранилищ не нова. Подходы и инженерные практики, которые были за это время выработаны, были направлены именно на это — сохранение жизнеспособности системы.
Простой пример: одна из наиболее частых причин провала проектов хранилищ «на взлете» — это попытка построить хранилище над системами-источниками, находящимися в стадии разработки, без согласования интеграционных интерфейсов — попытка забрать данные напрямую из таблиц. В итоге ушли в разработку — за это время база данных источника поменялась — и потоки загрузки в хранилище стали неработоспособны. Переделывать что-то поздно. А если еще и не подстраховались, сделав несколько слоев таблиц внутри хранилища — то все можно выкинуть и начинать заново. Это лишь один из примеров, причем один из простых.
Критерий хрупкого и антихрупкого по Талебу прост. Главный судья — время. Если система выдерживает проверку временем, и показывает свою «живучесть» и «неубиваемость» — она обладает свойством антихрупкости.
Если при проектировании системы мы будем учитывать антихрупкость как требование — то это сподвигнет нас использовать такие подходы к построению ее архитектуры, которые сделают систему более адаптивной и к «хаосу извне», и к «хаосу изнутри». И в конечном счете система будет иметь более долгий срок жизни.
Никому из нас не хочется делать «времянки». И не надо себя обманывать, что по-другому нынче нельзя. Смотреть на несколько шагов вперед — это нормально для человека в любое время, тем более в кризисное.
Статья, посвященная архитектуре хранилищ, предполагает, что читатель не только осведомлен, что это такое, но также и имеет некоторый опыт работы с подобными системами. Тем не менее я посчитала нужным это сделать — вернуться к истокам, к началу пути, т.к. именно там находится «точка опоры» развития.
Как вообще люди пришли к тому, что необходимы хранилища данных? И чем они отличаются от просто «очень большой базы данных»?
Давным-давно, когда на свете жили просто «системы обработки бизнес-данных», не было разделения ИТ-систем на такие классы как фронтальные oltp-системы, бэк-офисные dss, системы обработки текстовых данных, хранилища данных и т.д.
Это было то время, когда Майклом Стоунбрейкером была создана первая реляционная СУБД Ingres.
И это было время, когда эра персональных компьютеров вихрем ворвалась в компьютерную индустрию и навсегда перевернула все представления ИТ сообщества того времени.
Тогда можно было легко встретить корпоративные приложения, написанные на базе СУБД класса desktop — таких как Clipper, dBase и FoxPro. А рынок клиент-серверных приложений и СУБД только набирал обороты. Одна за другой появлялись сервера баз данных, которые надолго займут свою нишу в ИТ-пространстве — Oracle, DB2 и т.д.
И был распространен термин «приложение баз данных». Что включало в себя такое приложение? Упрощенно — некие формы ввода, через которые пользователи могли одновременно вводить информацию, некие расчеты, которые запускались «по кнопке» или «по расписанию», а также какие-то отчеты, которые можно было увидеть на экране либо сохранить в виде файлов и отправить на печать.
«Ничего особенного — обычное приложение, только есть база данных,» — так заметил один из моих наставников на раннем этапе трудового пути. «Так ли ничего особенного?» — подумала тогда я.
Если приглядеться — то особенности-то все же есть. По мере роста пользователей, объема поступающей информации, по мере возрастания нагрузки на систему — ее разработчики-проектировщики, чтобы сохранить быстродействие на приемлемом уровне идут на некие «ухищрения». Самое первое — это разделение монолитной «системы обработки бизнес-данных» на приложение учета, которое поддерживает работу пользователей в режиме on-line, и отдельно выделяют приложение для batch-обработки данных и отчетности. Каждое из этих приложений имеет свою базу данных и даже размещается на отдельном экземпляре сервера БД, с разными настройками под разный характер нагрузки — OLTP и DSS. И между ними выстраиваются потоки данных.
Это все? Казалось бы — проблема решена. Что же происходит далее?
А далее компании растут, их информационные потребности множатся. Растет и число взаимодействий с внешним миром. И в итоге есть не одно большое приложение, которое полностью автоматизирует все процессы, а несколько разных, от разных производителей. Число систем, порождающих информацию — систем-источников данных в компании увеличивается. И рано или поздно, возникнет потребность увидеть и сопоставить между собой информацию, полученную из разных систем. Так в компании появляется Хранилища данных — новый класс систем.
Общепринятое определение данного класса систем звучит так.

Хранилище данных (или Data Warehouse) — предметно-ориентированная информационная база данных, специально разработанная и предназначенная для подготовки отчётов и бизнес-анализа с целью поддержки принятия решений в организации

Таким образом, консолидация данных из разных систем, возможность посмотреть на них неким «единым» (унифицированным) образом — это одно из ключевых свойство систем класса хранилищ данных. Это причина, по которой появились хранилища в ходе эволюции ИТ-систем.
Давайте посмотрим подробнее. Какие ключевые особенности есть у данных систем? Что отличает хранилища данных от прочих ИТ-систем предприятия?
Во-первых, это большие объемы. Очень большие. VLDB — так именуют такие системы ведущие вендоры, когда дают свои рекомендации по использованию своих продуктов. Со всех систем компании данные стекаются в эту большую базу данных и хранятся там «вечно и неизменно», как пишут в учебниках (на практике жизнь оказывается сложнее).
Во-вторых, это исторические данные — «Corporate memory» — так называют хранилища данных. По части работы со временем в хранилищах все совсем интересно. В учетных системах данные актуальные в моменте. Потом пользователь совершает некую операцию — и данные обновляются. При этом история изменений может и не сохраниться — это зависит от практики учета. Возьмем, например, остаток на банковском счете. Нас может интересовать актуальный остаток на «сейчас», на конец дня или на момент некого события (например, в момент расчета скорингового балла). Если первые два решаются довольно просто, то для последнего, скорее всего, потребуется специальные усилия. Пользователь, работая с хранилищем, может обращаться к прошлым периодам, осуществлять их сравнение с текущим и т.д. Именно подобные возможности, связанные со временем, существенным образом отличают хранилища данных от систем учета — получение состояния данных в различных точках оси времени — на определенную глубину в прошлом.
В-третьих, это консолидация и унификация данных. Для того, чтобы стал возможен их совместный анализ, нужно привести их к общему виду — единой модели данных, сопоставить факты с унифицированными справочниками. Здесь может быть несколько аспектов и сложностей. Прежде всего — понятийная — под одним и тем же термином разные люди из разных подразделений могут понимать разные вещи. И наоборот — называть по-разному что-то, что по сути, одно и то же. Как обеспечить «единый взгляд», и при этом сохранить специфику видения той или иной группы пользователей?
В-четвертых, это работа с качеством данных. В процессе загрузки данных в хранилище выполняются их очистка, общие преобразования и трансформации. Общие преобразования необходимо делать в одном месте — и далее использовать для построения различных отчетов. Это позволит избежать расхождений, которые вызывают столько раздражения у бизнес-пользователей — особенно у руководства, которому приносят «на стол» цифры из разных отделов, которые не сходятся между собой. Низкое качество данных рождает ошибки и расхождения в отчетах, последствие которых — это снижение уровня доверия пользователя ко всей системе, ко всему аналитическому сервису в целом.
Каждый, кто сталкивался с хранилищем, скорее всего наблюдал некую «слоистую структуру» — т.к. именно эта архитектурная парадигма прижилась для систем данного класса. И не случайно. Слои хранилища можно воспринимать как отдельные компоненты системы — со своими задачами, зоной ответственности, «правилами игры».
Уровневая архитектура — это средство борьбы со сложностью системы — каждый последующий уровень абстрагирован от сложностей внутренней реализации предыдущего. Такой подход позволяет выделять однотипные задачи и решать их единообразным образом, не изобретая каждый раз «велосипед» с нуля.
Схематично концептуальная архитектурная схема представлена на рисунке. Это упрощенная схема, которая отражает лишь ключевую идею — концепцию, но без «анатомических подробностей», которые будут возникать при более глубокой проработке деталей.

Как показано на схеме, концептуально выделяем следующие слои. Три основных слоя, которые содержат область хранения данных (обозначено закрашенным прямоугольником) и ПО загрузки данных (условно показано стрелками того же цвета). А также вспомогательный — сервисный слой, который однако играет весьма важную связующую роль — управления загрузкой данных и контроля качества.
Primary Data Layer — слой первичных данных (или стейджинг, или операционный слой) — предназначен для загрузки из систем-источников и сохранения первичной информации, без трансформаций — в исходном качестве и поддержкой полной истории изменений.
Задача данного слоя — абстрагировать последующие слои хранилища от физического устройства источников данных, способов забора данных и методов выделения дельты изменений.
Core Data Layer — ядро хранилища — центральный компонент системы, который отличает хранилище от просто «платформы batch-интеграции», либо «большой свалки данных», поскольку его основная роль — это консолидация данных из разных источников, приведение к единым структурам, ключам. Именно при загрузке в ядро осуществляется основная работа с качеством данных и общие трансформации, которые могут быть достаточно сложны.
Задача данного слоя — абстрагировать своих потребителей от особенностей логического устройства источников данных и необходимости сопоставлять данные из различных систем, обеспечить целостность и качество данных.
Data Mart Layer — аналитические витрины — компонент, основная функция которого — преобразование данных к структурам, удобным для анализа (если с витринами работает BI — то это, как правило, dimensional model), либо согласно требованиям системы-потребителя.
Как правило, витрины берут данные из ядра — как надежного и выверенного источника — т.е. пользуются сервисом этого компонента по приведению данных к единому виду. Будем называть такие витрины регулярными. В отдельных случаях витрины могут брать данные непосредственно из стейджинга — оперируя первичными данными (в ключах источника). Такой подход, как правило, используется для локальных задач, где не требуется консолидация данных из разных систем и где нужна оперативность более, чем качество данных. Такие витрины называют операционными. Некоторые аналитические показатели могут иметь весьма сложные методики расчетов. Поэтому, для таких нетривиальных расчетов и трансформаций создают так называемые вторичные витрины.
Задача слоя витрин — подготовка данных согласно требований конкретного потребителя — BI-платформы, группы пользователей, либо внешней системы.
Описанные выше слои состоят из области постоянного хранения данных, а также программного модуля загрузки и трансформации данных. Такое разделение на слои и области является логическим. Физически реализация этих компонентов может быть различной — можно даже использовать различные платформы для хранения или преобразования данных на разных слоях, если это будет более эффективно.
Области хранения содержат технические (буферные таблицы), которые используются в процессе трансформации данных и целевые таблицы, к которым обращается компонент-потребитель. Правилом хорошего тона является «прикрытие» целевых таблиц представлениями. Это облегчает последующее сопровождение и развитие системы. Данные в целевых таблицах всех трех слоев маркируются специальными техническими полями (мета-атрибутами), которые служат для обеспечения процессов загрузки данных, а также для возможности информационного аудита потоков данных в хранилище.
Также выделяют специальный компонент (или набор компонентов), который оказывает сервисные функции для всех слоев. Одна из ключевых его задач — управляющая функция — обеспечить «единые правила игры» для всей системы в целом, оставляя право на использование различных вариантов реализации каждого из описанных выше слоев — в т.ч. использовать разные технологии загрузки и обработки данных, разные платформы хранения и т.п. Будем называть его сервисным слоем (Service Layer). Он не содержит бизнес-данных, но имеет свои структуры хранения — содержит область метаданных, а также область для работы с качеством данных (и возможно, другие структуры — в зависимости от возложенных на него функций).
Такое четкое разделение системы на отдельные компоненты существенно повышает управляемость развития системы:

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