January 6, 2009 by admin
Часть 2
См. Часть 1
Во второй части статьи описываются основные правила проектирования и реализации процессов перегрузки данных, вводятся необходимые понятия и определения.
Сформулированные нами ранее определения позволяют перейти к главной теме - описанию процессов перегрузки данных. Какова их основная задача? Из каких этапов они состоят? Какие основные вопросы требуют своего решения до начала разработки? В этой части мы постараемся ответить на эти и затронуть некоторые другие связанные с данной темой вопросы, такие как: структура "получателей" данных, качество данных, хранилище данных - взгляд с точки зрения перегрузки, проектирование процессов с учетом существования хранилища данных, структура метаданных. Кстати, из-за того, что термин «источник данных» получил свое детальное определение, следует предложить термин для конкретной таблицы или файла данных. В данной статье в этом смысле будет применяться термин «набор данных».
Для начала изобразим область распределения «наборов данных» конкретного источника данных, в соответствии с определением, данным ранее.
Рис. 4. Область источника данных
Таким образом, можно сделать вывод, что наборы данных, составляющие источник данных, могут иметь (и всегда имеют) различный тип. С другой стороны с точки зрения многомерной модели представления информации, источник выглядит так, как изображено на Рис. 5. Примерно также выглядит и «получатель». Многомерная модель универсальна, хотя ничего нового в ней нет: факты (события) характеризуются показателями и всегда происходят в координатах некоторых измерений. (Новизна, как уже отмечалось, заключается лишь в том, что ее начали широко применять в реальных аналитических приложениях.) Особенность модели заключается в том, что в ней содержится только два типа наборов данных: измерения и факты. Измерения, как уже отмечалось, могут быть линейные или иерархические. Тот факт, что информационные системы, которые используются нами как источники информации для хранилища, на первый взгляд не содержат таких моделей, объясняется лишь тем, что в борьбе за скорость проведения транзакцийи и для достижения прочих эксплуатационно-технических характеристик, разработчики оперативных систем используют много дополнительных таблиц, которые "скрывают" суть дела. Однако, если хорошо разобраться в проекте БД, для той или иной оперативной системы можно всегда найти элементы, изображенные на Рис. 5. Делается это обычно при помощи простых и давно известных приемов, а именно: "убрать все ненужное" и нормализовать форму представления данных.
Рис. 5. Многомерное представление источника данных
Не всегда в модели оперативной системы присутствуют в явном виде все те измерения, в которых "случаются факты" и, соответственно, в разрезе которых эти факты могут быть проанализированы. (Одно измерение, помеченное на Рис. 5 штриховой линией отражает это) Разработчики оперативных систем всегда ограничиваются введением в модель только минимально необходимого набора измерений, требуемых для обработки транзакций. Метод проектирования оперативных систем в основном устоявшаяся дисциплина, однако, в связи с началом промышленной эксплуатации многомерной модели данных, которая значительно расширяет возможности использования накопленной информации, следует помнить, что просто провести транзакцию уже не достаточно. Нужно чтобы транзакция могла - наравне с остальными - быть "замечена" аналитиком и принять участие в формировании адекватной картины происходящего, а не пополнять залежи информационного мусора, который кроме, как количеством записей, ничем больше не характеризуется. Для иллюстрации сказанного стоит только привести оценку среднего объема некачественной (в смысле ее последующего анализа) информации, накапливаемой в оперативных системах. По самым оптимистическим оценкам доля такой некачественной информации составляет до 40% накапливаемого объема данных. Если опустить задачи, требующие абсолютной точности и предположить, что вполне приемлемой погрешностью анализа для принятия решений является 10% (имеется в виду количество записей), то станет более понятно, насколько возможности расходятся с потребностью. Наш практический опыт подтверждает вышеприведенные оценки. Вообще говоря, проблема качества данных - одна из основных при разработке аналитических систем и особенно процессов перегрузки данных. Для эффективного ее решения требуется целая система мер, в рамках единой стратегии управления качеством, технология измерения и управления качеством при перегрузках данных, а также мониторинга качества данных, накапливаемых в аналитической системе. Следует отметить, один неочевидный, но интересный факт: обычно, разные потребители имеют разные требования к качеству данных.
Рис. 6. Простейший случай перегрузки данных
Следовательно: во-первых, вы можете зря потратить силы и средства на достижение 100% корректности данных, в то время как потребителю будет достаточно 85% и от получения оставшихся 15%, его положение существенно не изменится; во-вторых, совершенно очевидно, что в хранилище данных находится информация не абсолютного качества и при организации аналитических работ потребуется анализ качества конкретного объема данных. Этот факт демонстрирует необходимость разработки системы измерения качества, для оценки пригодности информации для использования тем или иным "потребителем". Различие потребителей по требуемому уровню качества следует всегда учитывать при проектировании и развитии проекта. Процессы перегрузки составляют основу системы контроля качества, т.к. только они взаимодействуют с первичными источниками данных, продвигая информацию к аналитическим подсистемам. Следовательно, именно процессы перегрузки данных должны содержать в себе процедуры измерения и контроля качества, а так же поставлять соответствующую информацию в системы мониторинга качества. Более глубокое изложение этой проблемы будет предпринято отдельно. В рамках данной статьи, для обсуждения вопросов проектирования нам достаточно понимать, что такая проблема существует и предположить, что мы умеем ее решать.
Как уже отмечалось, простейшая многомерная витрина данных имеет такую же концептуальную многомерную модель, как и источник, поставляющий данные для нее. В этом случае процесс перегрузки можно изобразить так, как показано на Рис. 6. Естественно разделить все процессы на процессы перегрузки фактов и процессы перегрузки измерений. Казалось бы, зачем тогда придавать такое большое значение перегрузкам, если даже модели источника и получателя различаются только техническими деталями? Чтобы ответить на этот вопрос, давайте вспомним то, что говорилось выше относительно измерений в оперативных системах, и о структуре хранилища с выделенными ссылочными наборами данных (RDS).
Рис. 7. Соответствие фактов и размерностей источника и получателя
1 - процесс восстановления измерения по фактам;
2 - процесс восстановления измерения по существующему измерению
Схема, изображенная на Рис. 7 отражает более реальный взгляд на систему перегрузки данных, с учетом RDS и соответствия измерений в оперативной и аналитической системах.
В случае с перегрузкой фактов на Рис. 6 и Рис. 7 все понятно: мы должны перегрузить факты из оперативной системы в аналитическую (при необходимости проведя трансформацию структуры, и все необходимые перерасчеты). Относительно измерений ситуация существенно меняется. Следуя правилу выделения ссылочных наборов данных в отдеальную систему RDS естественно предположить, что многие измерения оперативной системы имеются в подсистеме RDS хранилища данных. Назовем такие измерения «существующими измерениями» оперативной системы. С точки зрения экономии ресурсов, очевидно, что в физической перегрузке существующих измерений нет необходимости. Однако, также очевидна необходимость проверки взаимного соответствия идентификаторов в справочниках, находящихся в оперативной системе и подсистеме RDS. Другими словами, мы обязательно должны убедиться в том, что содержимое справочника оперативной системы совпадает с содержимым справочника из RDS, причем взаимное соответствие записей не изменилось со времени последней загрузки данных. Иначе мы допускаем так называемую «семантическую подмену идентификаторов», что является грубейшей ошибкой и, естественно, искажает факты, накапливаемые в хранилище данных.
Рассмотрим более подробно процедуру проверки взаимного соответствия идентификаторов. Возьмем, например, ситуацию, когда в оперативной системе существует справочник счетов бухгалтерского учета и такой же справочник существует в RDS хранилища данных. Предположим, что счет с номером "42301" в справочнике оперативной системы имеет значение идентификатора (id), по которому на него ссылаются факты, равное 100. Этот же счет с номером "42301" в справочнике RDS имеет идентификатор (id) равный 987, а идентификатор (id) равный 100 имеет счет с номером "64302". Допустим далее, что некоторый факт в оперативной системе ссылается на счет "42301" из справочника счетов оперативной системы. В случае перегрузки фактов в хранилище данных без какой-либо обработки идентификаторов, мы получим в хранилище этот же факт, но ссылающийся на счет "64302", что недопустимо. Рассмотренный процесс потери смыслового содержания ссылки (ссылочная целостность при этом, в общем случае, не нарушается: факт все также ссылается на счет) называется семантической подменой идентификатора. Для правильной загрузки фактов из рассматриваемой системы, мы должны иметь процедуру обработки идентификаторов существующих измерений оперативной системы. В простейшем случае - это готовый служебный справочник согласования идентификаторов измерения оперативной системы и RDS. Однако такой подход не предполагает возможности изменения самого измерения оперативной системы, хотя такие изменения возможны практически всегда. Например, перекодировка справочника счетов при переходе к очередному учетному периоду совершенно безболезненна в оперативной системе, (обеспечивающей целостность данных внутри одного оперативного периода), но приносит массу трудностей при загрузке в хранилище, аккумулирующее данные из несколько оперативных периодов. В общем случае обработка идентификаторов при загрузке существующих измерений - это интерактивная процедура построения справочника замен идентификаторов на основе связывания измерений оперативной системы и RDS по значениям естественных ключей.
Мы рассмотрели порядок работы с существующими измерениями, но открытым остается вопрос с «восстанавливаемыми» измерениями аналитической системы, которые не существуют в явном виде (на Рис. 7 Измерение 1, Измерение 3). Как уже было отмечено, в оперативной системе существует минимум измерений для регистрируемых фактов. Если при проведении анализа мы хотим большего количества измерений - что бывает практически всегда - мы должны подумать над методами «восстановления» недостающих измерений по известным фактам или известным измерениям. В обоих случаях - это громоздкая задача. При восстановлении недостающих измерений по известным (существующим) измерениям требуется постоянный контроль (синхронизация) «правил восстановления» при изменениях существующих измерений. (О возможности изменения последних, было сказано выше.) При использовании правил восстановления (создания) измерений непосредственно по фактам происходит усложнение процедур перегрузки, которые выполняются для большого количества перегружаемых данных, а также усложнение обработки получаемых измерений в системах OLAP (т.к. чаще всего, получаемые размерности, являются медленноменяющимися и требуют особой обработки в аналитических системах).
Следует особо отметить, что в иных случаях, задача восстановления измерений может принципиально не иметь однозначного решения. Из всего вышеизложенного можно вывести первые правила проектирования процессов перегрузки данных:
Перед началом проектирования перегрузки данных необходимо точно представлять себе, с какими именно фактами и измерениями придется работать, какие из них существующие, а какие восстанавливаемые.
Дополнительно, измерения можно подразделить на «линейные» и «иерархические».
Не все желаемые «измерения» требуемых для анализа «фактов» явно существуют в оперативной системе. «Существующие измерения» можно выявить методом нормализации и исключения из модели незначимых (технических) сущностей.
Для «Восстанавливаемых измерений» необходимо проверить принципиальную возможность их получения по известным оперативным фактам или «Существующим измерениям».
На основе анализа характера изменяемости существующих измерений следует принять решение относительно конкретного способа замены его идентификаторов при перегрузке и способа получения восстанавливаемых измерений (если такие есть).
Рис. 8. Простейшая структура процесса перегрузки данных
Все сказанное выше излагалось для прямых перегрузок из оперативной системы в многомерную витрину данных, без учета промежуточного представления данных в виде «корпоративного хранилища» (см. Рис 3). Однако, забегая вперед, хотелось бы отметить, что все сказанное справедливо и в случае наличия хранилища, только распределено между процессами загрузки хранилища (backroom ETL) и процессами загрузки витрин данных (frontroom ETL). В частности, при таком разделении процессов вопросы замены идентификаторов существующих измерений решаются в back области, а восстановления измерений во front области.
Мы постараемся не повторять здесь того, что уже описано о хранилище данных. Хотелось бы изложить лишь взгляд с точки зрения разработчика системы перегрузки данных. Хранилище, как следует из Рис. 3 находится на полпути от оперативной системы к аналитику, и естественно ... усложняет процесс перегрузки данных, делая его более громоздким. Хранилище данных не вносит никаких принципиальных изменений в смысловое содержание процессов перегрузки (и порядок их проектирования, соответственно), оно лишь требует, чтобы в определенный момент данные могли бы разместиться в структуре хранилища. Имея в виду, что правильно спроектированное хранилище имеет очень гибкую структуру, указанное требование не является труднореализуемым.
Таким образом, с точки зрения разработчика процессов перегрузки данных, хранилище данных - это прием, усложняющий преобразование данных на пути к аналитику. Они трансформируются дважды: сначала приводятся к виду, который может быть загружен в хранилище; затем к виду, который может быть загружен в витрину. Тем не менее, как показывает практика, крупные аналитические системы создаются именно с такой архитектурой. Для этого должны быть веские основания. Попробуем их описать.
Первое - это время существования информации в оперативной системе и в хранилище. Можно сказать, что оперативная система (источник данных) обычно содержит информацию за некоторый (оперативный) период времени, а хранилище накапливает данные за гораздо более длительный (стратегический) период. Этот факт уже упоминался вскользь при описании возможных изменений «существующих измерений».
Однако, только различие в периодах накопления данных не может определить необходимость применения столь дорогостоящего и ресурсоёмкого решения, как хранилище данных. Тем более, что современные крупные оперативные системы (например АБС), являясь основными поставщиками информации для хранилища, могут содержать данные за любой период времени, а для остальных оперативных источников можно использовать подсистемы накопления исторической информации разработанные специально для них. Таким образом будет достигнута синхронизация источников данных, из которых можно будет загружать данные прямо в аналитические витрины.
В случае небольших проектов с ограниченными перспективами развития, именно так и поступают. Однако практика показывает, что для крупных проектов, характеризующихся, прежде всего, разнообразием хранимой информации и высокой динамикой изменений структуры оперативных систем, более эффективным является решение с единой моделью корпоративного хранилища. В частности, все ведущие разработчики поставщики применяют именно такую архитектуру.
Выше говорилось о преимуществах построения информационной системы предприятия с использованием хранилища данных. Одним из основных преимуществ указывалась гибкость по отношению к изменению структуры возможность учета этапности развития и даже замены оперативных систем, которые могут происходить в связи с развитием бизнеса или иными реорганизациями. Действительно, витрина данных в принципе не может обеспечить такую гибкость, так как стеснена требованиями соответствия инструменту OLAP, который накладывает определенные ограничения на структуру модели данных. Хранилище не стеснено подобными ограничениями и может быть разработано с использованием специальных приемов проектирования, которые позволяют гибко накапливать исторические данные.
При изменении структуры оперативных систем изменяются процессы загрузки данных только backroom - области, и только в той части, которая преобразует реальную модель оперативной системы к некоторому промежуточному ее представлению. От промежуточного представления и дальше через хранилище к витрине данных структура процессов загрузки в случае изменения модели оперативной системы не изменяется. Именно этот факт определяет основные преимущества эксплуатации корпоративного хранилища данных, но для его достижения необходимо, чтобы процессы перегрузки данных были спроектированы и разработаны правильным образом, который предполагает быструю адаптацию к изменениям лишь небольшой части процесса. В качестве примера для сравнения можно представить себе трудоемкость обеспечения гибкости накопления данных в случае прямых перегрузок из синхронизированных источников, который был описан, как возможный для небольших проектов...
Структура процесса перегрузки
Обратимся теперь к структуре самого процесса перегрузки данных. Для простейшего случая перегрузки данных (Рис.6) с учетом того, что было сказано о качестве данных, она будет выглядеть так, как показано на Рис. 8. Логические этапы процесса перегрузки данных будем называть фазами, которые в свою очередь могут состоять из отдельных шагов обработки данных. В частности, первой фазой процесса будет всегда фаза начального захвата данных (IDC - Initial Data Capture), которая содержит все элементарные шаги по установлению соединения с источником, преобразованию данных к промежуточному виду, загрузке данных из источника в область перегрузки для дальнейшей обработки и, наконец, контролю возможных критических ошибок исполнения шагов фазы.
Именно эта фаза будет изменяться при изменениях оперативного источника, что требует детального документирования ее шагов, применения максимально простых решений и открытого кода процедур, а так же переноса основной тяжести обработки и трансформации данных на последующие фазы процесса. Трансформация данных на Рис.8 разделена на две фазы, чтобы перенести основную нагрузку в область перегрузки.
Область перегрузки данных - это обычно отдельная реляционная база данных (логически обособленный набор реляционных таблиц), которая предназначена для промежуточного хранения данных при их обработке перед загрузкой в хранилище или витрину данных. Соответственно, область перегрузки данных, логически можно подразделить на backroom- область перегрузки и frontroom-область перегрузки данных.
После приведения структуры данных к промежуточному виду, необходимо проверить качество данных, что отражено соответствующей фазой процесса на Рис 8. Особенность проверки качества данных состоит в том, что на этом этапе все некачественные данные должны быть помечены соответствующим кодом ошибки и отделены от остальных, которые будут продвигаться дальше к хранилищу данных. С некачественными данными, в соответствии с кодом ошибки, должна быть проведена "работа над ошибками", после чего предпринята попытка дозагрузки данных, которые удалось исправить с пометкой о том, что это исправленные данные (см. выше обсуждение требуемого качества данных).
Оставшиеся две фазы процесса перегрузки могут быть реализованы различными путями с распределением между front и back - областями (Например, так, как это показано на Рис. 11.)
Последнее, что хотелось бы отметить относительно структуры процесса - это возможность распараллеливания шагов и фаз. Естественно, что возможность и необходимость распараллеливания зависит от количества процессоров сервера и должна отдельно оцениваться в каждом конкретном случае. Количество процессоров можно всегда нарастить, а время на перегрузку данных склонно увеличиваться к концу оперативного периода в частности (под воздействием роста объемов данных) и вообще с ростом времени эксплуатации (под воздействием развития системы контроля качества). Одним из очевидных резервов оптимизации (после исчерпания прочих: структурных реорганизаций, индексирования и др.) является распараллеливание.
Проектирование процессов перегрузки следует вести с учетом возможностей распараллеливания процедур в дальнейшем.
Сразу создавать параллельные процессы - не совсем оправдано из-за излишней сложности, которая на первых порах не желательна. Самое время заниматься указанными вопросами после того, как устоялась структура и логика перегрузки. (см. выше аналогию с и развитием и управлением кода программ). Следует учитывать, что при разработке схем процессов большее значение уделялось наглядности и содержанию, а не отражению возможности распараллеливания фаз и шагов. Дополнительные особенности в проектировании параллельных процессов объясняются применением в большинстве случаев для их разработки не процедурного, а директивного языка SQL, в котором целая последовательность процедур обработки данных (порой даже очень замысловатая) может быть выражена одним оператором языка. В реальных проектах часто приходится решать следующую дилему: сделать все одним запросом (например, в 300 и более строк) или разбить на несколько более коротких и понятных? Если разбивать на короткие - потребуются дополнительные таблицы в области перегрузки данных для хранения промежуточных результатов, количество которых будет "тем больше, чем короче запросы". Один большой запрос будет гораздо труднее сопровождать и распараллеливать. Таким образом, при решении вышеуказанной дилемы следует руководствоваться здравым смыслом и требуемыми возможностями распараллеливания.
Обновление данных
До сих пор нами рассматривались процессы загрузки данных в хранилище и аналитические витрины. Однако в реальных проектах, обязательно разрабатываются еще и процессы обновления данных, о которых пока ничего не было сказано. Дело в том, что каждый источник данных имеет свою периодичность выгрузки данных и время возможного доступа (окно доступа), при котором процесс выгрузки данных не мешает прочим приложениям, использующим источник. Теоретически, любое обращение к источнику данных должно приводить не только к подгрузке очередной порции фактов и контролю размерностей, но и к восстановлению соответствия фактов между хранилищем и оперативной системой в "сколь угодно давнем прошлом", т.е. в данных, относящихся к предыдущим периодам загрузки. (Если, конечно, данные изменялись в оперативной системе.) Практически, существуют естественные ограничения на период обновления прошлого из оперативной системы (и это обычно учитывается). Такими ограничениями могут быть длительность оперативного периода или принципиальная невозможность таких изменений в оперативной системе, начиная с какого-то момента в прошлом (например, каждый квартал данные могут блокироваться и изменения в них не допускаются). Вопрос об организации обновления данных - один из самых трудных при проектировании перегрузок.
Рис. 9. Структура процесса с полным сравнением
Теоретически возможны следующие варианты организации процесса захвата измененных данных (CDC):
- Контроль на уровне кода приложения
- Контроль на уровне обработки событий в СУБД (триггеры)
- Контроль посредствам анализа log-файлов СУБД.
- Полное сравнение записей.
Практически, в оперативных системах наиболее возможны два основных: контроль посредствам анализа log-файлов СУБД и полное сравнение записей. Остальные труднореализуемы или нежелательны: триггеры, например, снижают производительности системы в оперативном режиме, а возможность изменять код приложения имеется не всегда.
В случае применения полного сравнения увеличиваются требования к окну доступа источника, т.к. в этом случае из него необходимо выгружать факты за весь период обновления прошлого. Естественно, что существуют большое разнообразие схем для выбранного механизма захвата измененных данных, использующих те или иные особенности для оптимизации процессов перегрузки.
Таким образом, на этапе загрузки фактов необходимо производить не только загрузку, но и обновление фактов прошлых периодов, используя один из способов захвата измененных данных. Из этого следует дополнительное правило проектирования:
Необходимо выбрать конкретный механизм захвата измененных данных для обновления фактов, а также исследовать возможные пути его оптимизации.
Хотелось бы обратить внимание, что каких-либо обновлений размерностей за период обновления прошлого не предусматривается. Это следует из корректности текущей размерности для всего оперативного периода. Следовательно, размерности полностью синхронизируются в процессе загрузки данных и при обновлениях в обработке не нуждаются. Конкретные механизмы работы с разными типами размерностей были рассмотрены выше.
Рис. 10. Структура процесса с анализом log-файла
Структура процессов с полным сравнением записей для захвата изменений (Рис.9) и анализом log-файла (Рис.10) различаются. Как можно заметить, в случае полного сравнения записей, данные за весь период обновления прошлого загружаются в область перегрузки данных и трансформируются (сначала проверяют совпадение ключей, а затем трансформируют данные, чтобы сэкономить на времени трансформации).
В случае анализа log-файла (а также с помощью триггеров и кода приложения) в область перегрузки данных загружаются уже только измененные данные, что значительно сокращает требуемое окно доступа (фактически перераспределяя нагрузку по реализации процесса CDC между временем выгрузки и оперативной работы). Фазы относящиеся к обработке измененных записей обозначены штриховой линией для обозначения того факта, что разрабатываются они на основе фаз для пополнения, но могут иметь, как уже отмечалось, отличия связанные с оптимизацией CDC.
Рис. 11. Структура процесса с разделением по front и back областям
Хотелось бы еще раз отметить, что несмотря на использование здесь процедурной формы изложения (фразы типа: "сначала выполняется действие А, потом действие В") при реализации скорее всего будут использовать возможности директивного языка. (см. выше описание распараллеливания процесса) Соответственно, потребуются определенные усилия для "перевода процедурных представлений к директивным возможностям".
Единственным процедурным правилом, которое справедливо для любого процесса является необходимость в первую очередь обрабатывать справочники, а затем факты. Естественно, что данное правило учитываться в любом процессе, который рассчитан на работу со справочниками и фактами одновременно, а в случае наличия отдельных процессов для фактов и для размерностей - данное правило определяет обязательную очередность запуска процессов на исполнение.