Закончив с вводной частью на встрече и переходя к таким понятиям, как корпоративное хранилище данных, медленно меняющихся измерений, витрин данных и трехмерных OLAP-кубов, я начинаю видеть, как люди, отвечающие за бизнес, начинают лезть в карман за телефонами, делая вид, что им надо срочно ответить на сообщение или письмо. Но им простительно, у них есть свои не менее интересные аббревиатуры, над которыми им надо постоянно думать, как их улучшить – EBITDA, ROI, NPV, IRR. Однако технические специалисты не могут себе такого позволить, поэтому они принимают серьезный вид, который говорит о том, что сейчас будет проверка их умственных способностей.
Читая псевдонаучные журналы одного известного издательства о настоящем и будущем информационных технологий в России, пытающихся донести информацию до читателя в академическом виде, с долгим вступлением, а иногда даже и теорией, я так и представляю себе, как с появлением новой технологии открывается целая Вселенная возможностей, сулящая многие прибыли компаниям и несущая облегчение техническим специалистам. При всем этом, в жизни чаще встречаются люди, совсем слабо знакомые с теорией, но получившие свои знания практикой. Становиться неудивительным, что кругозор таких людей ограничен теми вещами, которые им удалось «пощупать» вживую. Что-то другое, находящееся за рамками практики, представляется темным лесом, а иногда даже мракобесием и казуистикой. «О чем вы говорите, какие Кимбаллы, при чем здесь Инмон? Это все плоды праздных размышлений, а нам тут работать надо!».
Хотя я увлекся, и Инмон здесь, наверное, действительно не при чем. Тем не менее, та технология, о которой я рассказываю, должна использоваться, как один из компонентов для построения решения. Не находя отклика в сердцах слушателей, я все-таки получаю вопрос от пытливых технических специалистов, более активных по сравнению со своими коллегами, и за счет этого, возможно, уже доплачивающих ипотеку 🙂 Вопрос этот непростой, а для кого-то даже сакраментальный. Звучит он примерно так – «А что думает на этот счет Oracle и как это работает?»
Что ж, извольте, информация, которую предоставляет Oracle: “Change Data Capture efficiently identifies and captures data that has been added to, updated in, or removed from, Oracle relational tables and makes this change data available for use by applications or individuals.”
Если попробовать перевести эту фразу на русский язык, то получится следующее: “Change Data Capture эффективно идентифицирует и захватывает данные, которые были добавлены, обновлены или удалены из таблиц Oracle и делает эти измененные данные доступными для приложений или отдельных людей». Это формулировка хоть и отличается своей лаконичностью, однако не дает полного представления, какие выгоды технология CDC может предоставить своим потребителям.
А что думает на этот счет такой гранд информационных технологий, как компания IBM? Поддерживает ли она эту технологию и как её описывает в своих продуктах? К сожалению, я не смог найти хоть какого-нибудь полного описания на сайте IBM. Приведу здесь лучшее и, пожалуй, единственное, что я нашел:
«Технология Change Data Capture (CDC) с ведением журнала, которую IBM получила в результате приобретения компании DataMirror, реплицирует сведения о важнейших событиях, связанных с данными, в режиме реального времени, не влияя на производительность системы.»
После этого описания все, конечно же, должны понять, в чем суть технологии CDC и зачем она нужна. По крайней мере, на это рассчитывает компания IBM, если выкладывает подобную информацию на своем сайте. Я же сильно сомневаюсь, что описания подобного рода могут в чем-то помочь продвинуться в понимании, а тем более в использовании подобной технологии.
Можно почитать, что пишет Microsoft, если у вас есть куча свободного времени, которое вы не знаете, как потратить и решили убить на совершенно бесполезное занятие.
Именно по этой причине, я попытаюсь объяснить в этой статье, что же это такое и зачем это нужно. Представим себе, что у вас появилась необходимость отслеживать изменения данных, которые происходят в определенных таблицах в базе данных. Для чего это нужно, я объясню позже. И вот, в момент зарождения этой потребности, вы начинаете думать, как же это реализовать в жизни. На заре своего развития технология CDC предлагала следующие методы решения – добавляем новый столбец с временной меткой и, вуаля, теперь мы знаем, какие строки обновлялись после определенного времени. Но для этого мы должны прочитать всю таблицу, а если изменения происходят слишком часто, то это становиться накладным и долгим процессом, и есть ненулевая вероятность того, что вы можете потерять изменение. Чтобы не терять изменения, пробовали версионирование строчек, получили примерно тот же результат – работает, но плохо и ресурсозатратно. Да и к тому же, для того, чтобы эти методы воплотить в жизнь, необходимо менять логику приложения, а если приложение купленное, и никто в нем просто так что-то менять не даст? Эта проблема решилась с появлением триггеров – вешаем триггер на табличку, который будет отслеживать все изменения и записывать их в какую-нибудь промежуточную или даже конечную таблицу, хранящую необходимые изменения. Казалось бы, что еще нужно? Но нет, опять не то – теперь при любом изменении данных в таблице вызывается триггер, для обработки которого нужна вычислительная мощность, к тому же количество операций записи возрастает вдвое, и это в лучшем случае, а также возрастает сложность в сопровождении такой базы данных. Однако, некоторые продукты, предполагающие использование технологии CDC, до сих пор основаны на триггерах.
Тем не менее, другие компании пошли дальше и вспомнили о том, что базы данных на самом деле транзакционные, и обладают такой функцией, как журнализация изменений. Все что нужно сделать, это получить доступ к журналу этих изменений (транзакционный лог) и выделить из него те изменения, которые мы хотим отслеживать. Здесь самое сложное заключается в том, чтобы правильно прочитать этот транзакционный лог и отследить те изменения, которые нам действительно интересны. Раньше, большинство продуктов использовало для этого агента, который устанавливался на источнике изменений, читал транзакционный лог и передавал эти изменения в файл или же сразу применял к получателю. Честно говоря, большинство продуктов с тех пор не поменялось и все также использует агентов. Есть несколько лидеров в области CDC, которые читают транзакционный лог удаленно, обрабатывая его в памяти на отдельном сервере, выделяя в нем необходимые изменения и применяя эти изменения к получателю. Такая архитектура не создает нагрузку на источник и позволяет добиться впечатляющей производительности, которая предоставляет возможность отслеживать изменения, происходящие с данными, и применять их к получателю этих изменения в режиме реального времени. Представляете, кто-то заплатил карточкой в секс-шопе, а через три секунды вы это можете видеть в своем отчете. Если вы приверженец англицизмов, то это звучит как онлайн репликация данных. Технология CDC достигла того этапа, когда уже нет необходимости накапливать изменения где-то в определенном месте и потом, в определенное время, применять их к получателю этих изменения – теперь это доступно в режиме реального времени – данные всегда доступны и верны. Забыл упомянуть, что лидирующие решения в этой области работают с гетерогенными источниками и получателями, т.е. из SQL Server в Oracle, Oracle в SQL Server, Oracle в DB2, CICS в SQL Server, Informix в файл, Enscribe в Oracle. Любые вариации доступны, любые объемы и направления.
Поддерживаемые топологии можно увидеть на картинке:
Возможно, кто-то спросит — Почему бы не считывать изменения прямо из памяти (например, из Redo Buffer или Log Buffer), ведь это должно быть намного быстрее дискового чтения? Передавайте большой, пламенный привет Intel и архитектуре x86.
Необходимо заметить, что продукты, использующие технологию CDC для репликации данных, не являются полноценными ETL инструментами. Хотя они и позволяют проводить простые трансформации и фильтрации строк, однако этого недостаточно для того, чтобы обладать правом называть себя ETL инструментом. Тем не менее, они предоставляют доступ к данным для любых ETL инструментов с помощью ODBC, JDBC, JCA, OLEDB или просто записывая изменения в файл. Впрочем, сейчас все большую популярность набирает подход ELT, и технология CDC как раз соответствует концепции этого подхода – сначала репликация данных как есть, а уже потом их трансформация. Стоит также отметить, что некоторые известные ETL инструменты также пытаются встроить использование CDC в механизм извлечения данных. Однако они используют триггеры, а этот подход обладает многочисленными недостатками, перечисленными выше, и тут можно сказать, что использование CDC, основанного на триггерах не имеет смысла в продуктивных системах.
В этот момент в глазах слушателей загорается огонек робкой надежды на понимание технологической сути CDC. В принципе, больше информации техническим специалистам не требуется. Однако, тут, люди, отвечающие за бизнес, и обладающие некоторой прозорливостью задают вопрос:
А зачем он вообще нужен, этот CDC?
Этот довольно щекотливый момент времени в литературе называют кульминационным. Именно сейчас будут расставлены все точки над i, и станет понятным, имеет ли право на существование, и более того, на применение в реальной жизни, такая технология, как CDC. Наступает тот момент, когда можно сделать глубокий вздох и оглянуться по сторонам. Если в этот миг я замечаю на стене портрет президента компании, счастливо улыбающегося со своей яхты в камеру, то, в принципе, становиться понятным, что CDC в этой компании не было, нет, и, скорей всего, уже не будет. Впрочем, мода на портреты осталась только в госучреждениях, что дает надежду на то, что бизнес в России когда-нибудь станет цивилизованным.
Переходя к сути вопроса, я могу сказать, что самым очевидным применением технологии CDC в жизни является устранение нагрузки с операционных баз данных за счет вывода процесса формирования отчетности на отдельную базу (так называемую Operation Data Store). Можно объяснить это на примере – допустим, у нас есть база данных, с которой работает некоторое количество пользователей. Они заводят там заявки, ставят статус, уточняют, на какой стадии находятся эти заявки, закрывают их, исправляют, в общем, выполняют целый ряд действий. Это может быть CRM, ERP, автоматизированная банковская система, биллинговая система или даже POS-терминалы. Бизнесу необходимо понимать, в каком состоянии находятся заявки или другие сущности, хранящиеся в этой системе – счета, вклады, производство и т.п. Поэтому бизнес формирует отчет на периодичной основе, в котором отражаются все основные показатели, интересующие бизнес и необходимые для принятия дальнейших управленческих решений. Однако, вот незадача – во время формирования отчетности все пользователи замечают, что скорость системы значительно падает и становится некомфортной для работы. И тут на помощь приходит технология CDC – мы определяем, какие данные нас интересуют, т.е. отслеживаем изменения в определенных таблицах и применяем их к другой базе данных(ODS). А на ней уже и запускается процесс формирования отчетности. В итоге получается, что и овцы целы, и волки сыты – пользователи могут работать с системой заявок, а руководство может получать необходимые им для принятия управленческих решений отчеты в любое удобное время.
Второй вид применения технологии CDC вытекает из первого – мы можем использовать эту технологию для поддержания идентичной копии базы данных на случай восстановления после катастроф. Реализуется это следующим образом – мы отслеживаем все изменения, происходящие с данными в базе данных в первом дата-центре и применяем их в режиме реального времени ко второй базе данных, находящейся во втором дата-центре. Таким образом, при наступлении катастрофы у нас всегда есть идентичная копия первой базы данных, с которой мы можем продолжить работу, не прерываясь на восстановления базы данных с резервной копии. Технологию CDC в таком же контексте можно использовать для миграции на новые версии СУБД или для миграции с платформы Big Endian на Little Endian и наоборот. Применение CDC тут обладает неоспоримыми преимуществами, в числе которых можно назвать исключение необходимости прерывать работу бизнеса для выполнения таких операций, как миграция на новую версию или новую платформу. Так как отслеживание изменений и переливание необходимых данных происходит в режиме реального времени, то после проведения необходимого тестирования мы можем мгновенное переключиться на СУБД новой версии или на новый сервер, не заставляя бизнес останавливаться.
Есть еще один интересный случай, где технология CDC может быть востребована. Представим себе, что у компании есть центральный офис и несколько филиалов, разбросанных по стране. И в центральном офисе, и в каждом из филиалов есть свой кадровый отдел, который принимает на работу, увольняет и ведет учет сотрудников. Руководство этой компании хочет знать в любое время, кто же у них работает и на какой позиции. Для этого принимают решение внедрить MDM – создать единое место, где будут храниться сведения о сотрудниках, работающих в этой компании. Создается база данных MDM_HR, в которую стекаются сведения из базы данных центрального офиса, а также из баз данных филиалов. Однако, для того, чтобы сведения в базе данных MDM_HR были актуальными, необходимо создать такой механизм, который при изменении данных о сотруднике (например, изменилась позиция, зарплата, фамилия или же сотрудник уволился, а на его место пришел другой) менял эти же данные или добавлял новые в базу данных MDM_HR. В качестве такого механизма идеально подходят решения по репликации данных, использующие CDC. Теперь руководство компании, а также кадровый отдел может получить в любое время корректный и актуальный отчет о работающих в компании сотрудниках. Применение CDC в подобном ключе может относиться не только к кадровому учету – оно может быть использовано для задач, где есть распределенные данные, которые, тем не менее, сгруппированы по какому-то логическому признаку и требуется формировать отчет или отслеживать какие-то характеристики на основе общих данных, а не только их отдельной части. Это могут быть распределенные территориально склады, различные информационные системы и тому подобные вещи, требующие интеграции и консолидации данных для формирования правильной отчетности.
Самую интересную сферу применения CDC я оставил напоследок. Допустим, ИТ-директор в компании сумел убедить руководство в необходимости внедрения полноценного BI в компании. Он долго и убедительно рассказывал, что бизнес анализ необходим компании для принятия правильных и своевременных решений в финансовой сфере, финансового планирования и контроля, BI необходим для отслеживания эффективности маркетинговых и рекламных компаний, нужен, как воздух для установки и наблюдения за различными KPI, работе с партнерами, снижение логистических затрат, управления рисками и т.д. В конце концов, совет директоров решил, что все звучит не так уж плохо и почему бы не попробовать? BI решено было внедрять в несколько этапов – построение корпоративного хранилища данных, наполнение его данными, формирование витрин данных на основе этого хранилища, визуализация данных. И вот, построили корпоративное хранилище данных, определили, какие данные необходимо в него поместить и стали думать над тем, как эти данные можно загрузить в хранилище данных. Тут есть два пути – первый использовать ETL инструменты для извлечения данных, трансформации на промежуточном сервере и загрузки в хранилище данных. Однако такой путь обладает существенными недостатками – ETL процесс непостоянен и выполняется время от времени, что, во-первых, создает нагрузку на источники данных, а во-вторых означает, что данные в хранилище данных большую часть своего времени не соответствуют последним данным в источниках. Это достаточно серьезно огорчает бизнес — конкуренты не спят, и завтрашние новости бизнес должен узнавать не завтра с утра, а буквально сегодня вечером, т.е. вечером бизнес уже хочет знать, что же будет завтра. Для подобного анализа необходима доступность данных в режиме реального времени, мы должны проводить анализ на основе последних данных, только так мы сможем успеть за постоянно меняющейся обстановкой. Поэтому есть второй путь – отслеживать изменения данных на источниках и оперативно, в режиме реального времени загружать их в корпоративное хранилище данных. Для этого и используется CDC – мы определяем, какие изменения и в каких таблицах нам интересны, отслеживаем их и загружаем в хранилище данных, после чего трансформируем их уже внутри хранилища – так получается быстрее и эффективнее. Такой подход к наполнению хранилища данных называется ELT – Extract-Load-Transform. Потребность доступа к данным в режиме реального времени постоянно растет среди компаний, особенно высокая потребность такого доступа наблюдается в финансовом и банковском секторе, так как конкуренция в этом секторе изначально высокая, следовательно, растут требования к получению данных с низкой задержкой.
Конечно, все варианты использования CDC не ограничиваются только вышеперечисленными. Есть и другие задачи и потребности, для которых CDC также востребован. Рассказывая про CDC, можно легко поддастся искушению и уйти в такие возвышенные дали, как построение корпоративного хранилища данных, MDM, формирование витрин данных, BI, интеграция и консолидация данных и т.п. не объясняя значения этих слов. Однако для бизнес людей все эти слова звучат подобно назойливому шуму и имеют для них смысла столько же, сколько выступление монгольского лидера перед народом на родном языке. Поэтому тут лучше всего перечислить использование CDC на конкретных примерах, как я попытался сделать это выше.
Подводя итог этой статье, а также встрече, я вижу все большую заинтересованность в технологии CDC со стороны бизнеса, когда он понимает, какие выгоды это может ему принести в будущем. Жестокая конкуренция диктует свои правила ведения бизнеса и если компания не может правильно расставлять приоритеты и оценивать свои силы, то она обречена на бессмысленное маневрирование, ведущее, в конце концов, к гибели компании. Если вы не работаете со своими данными, то вы теряете преимущество перед конкурентами, которые это делают.
Если посмотреть на CDC с технической точки зрения, то можно сказать, что это технология уже является зрелой и опробованной в ряде компаний. Она появилась не вчера и прошла достаточный путь для того, чтобы вырасти и использоваться в промышленных масштабах. Тем не менее, в настоящее время она до сих пор развивается – появляются новые подходы в использовании, учитываются современные требования, повышается быстродействие. Поэтому самое интересное – впереди!
ссылка на оригинал статьи http://habrahabr.ru/post/170267/
Добавить комментарий