Что делать с хаосом данных?

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

Рис. 1. Оценка значения хаоса данных как основного барьера на пути развития новых приложений

В компьютерах, способных перемалывать огромные объемы данных, как и в автомобилях, обнаружилась скрытая опасность, суть которой в отсутствии системного подхода к оперированию данными как корпоративным ресурсом. Данные сегодня порождаются неподконтрольно, следствием чего стала проблема, которую назвали «хаосом данных». Хаос проявляется в том, что на предприятиях данные хранятся где угодно, как угодно, на чем угодно, что, с одной стороны, вызывает сложность доступа и ненужное дублирование, а с другой, допускает двусмысленность в трактовке данных. Пока данных было относительно немного, предпринимались определенные защитные меры и проблема не была критичной, поскольку каждый из фрагментов данных использовался независимо от других. Большие Данные все изменили. Объектом анализа могут стать все корпоративные данные в их полном объеме и в любых сочетаниях, необходимых для анализа, однако теперь хаос становится серьезным препятствием (рис. 1). Показательно, что в примерах, где демонстрируется эффективность анализа Больших Данных, используются действительно большие, но простые по структуре и логике массивы, однако в реальной жизни не меньше, если не больше пользы приносит анализ больших и сложных данных, позволяющий найти неочевидные связи и корреляции. Таким образом, с ростом потребностей в аналитике Больших Данных задачи интеграции приобретают особое значение.

Тридцать лет интеграции данных

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

Первые попытки решения задач интеграции данных были предприняты еще в 60-е годы создателями сетевых и иерархических баз данных. Особое место среди них занял Чарльз Бахман, который еще в 1963 году разработал интегрированные хранилища данных (Integrated Data Store, IDS), получив за свою деятельность премию Тьюринга. С высот нынешнего времени понятно, что идеи Бахмана были чрезвычайно перспективны, но опережали время, а их дальнейшему развитию помешала реляционная модель, предложенная Эдгаром Коддом и лучше соответствующая доступному на тот период аппаратному обеспечению и актуальным, преимущественно транзакционным, задачам. На какое-то время создалось впечатление, что кроме реляционных СУБД ничего и не нужно, хотя уже тогда были данные, не укладывавшиеся в эту модель. Тем не менее реляционная модель была поддержана основными производителями (IBM, Oracle, Sybase, Microsoft и др.), однако модель IDS работала быстрее на больших объемах данных, а наследие сетевой модели можно было обнаружить в Document Object Model, World Wide Web, Wikipedia и в графовых СУБД, ставших впоследствии платформами для баз данных NoSQL.

Следующий шаг на пути интеграции данных — классические хранилища данных с их триадой ETL (Extract, Transform, Load — «извлечение, преобразование, загрузка»). Это направление формировалось в постоянной конкуренции Билла Инмона с Ральфом Кимбалом. Первый в 1970 году предложил сам термин Data Warehouse и считал, что правильно идти от общего к частному, то есть иметь одно хранилище и из него формировать витрины данных, а второй, начав позже, считал, что, наоборот, следует идти от частного к общему и собирать конгломерат из витрин в одну базу. Из ныне действующих компаний наиболее заметную роль на первых этапах становления хранилищ данных сыграла Teradata.

Последнее десятилетие ХХ века было бедно на события, связанные с интеграцией, — заметны всего два, вызванные подъемом интереса к качеству данных (Data Quality) и возникновением направления интеграции приложений предприятий (Enterprise Application Integration, EAI). Под EAI обычно понимают набор технологий и сервисов, образующих связующий слой, который объединяет разрозненные приложения и подсистемы. Таким образом интеграция распространилась на бизнес-процессы, и сложились предпочтительные топологии: звезда с интеграцией в центре (Hub-and-Spoke) и шина (Bus), из которой позже выросла сервисная шина предприятия (Enterprise Service Bus, ESB). Основными поставщиками этих технологий стали IBM (WebSphere MQ), TIBCO, Vitria, SeeBeyond и WebMethods.

Следующее десятилетие уже можно назвать прорывным, принесшим практически все известные на сегодняшний день технологии интеграции данных: XML (eXtensible Markup Language); веб-сервисы и SOA; шина ESB, впервые предложенная компанией Sonic в продукте SonicMQ, стала общепринятой технологией; технологии федерализации (Data Federation) и виртуализации, в отличие от других не предполагающие физического перемещения данных; интеграция в реальном времени (Real-time Integration), включающая такие подходы, как федерализация, анализ изменений (Change Data Capture) и репликация данных (Data Replication); Master Data Management — работа с данными, которые представляют наибольшую важность для ведения бизнеса, но относительно редко меняются и не являются транзакционными.

Уровни интеграции

При всем своем разнообразии, архитектуры современных информационных систем строятся по трехуровневой модели, состоящей из приложений, ПО связующего слоя и поддерживающей системы управления данными. Есть еще два уровня сверху и снизу — получение данных из систем хранения и выдача результатов. Опираясь на эту модель, можно классифицировать технологии интеграции, распределив их по уровням и исключив сравнение несравнимого. Например, встречаются публикации, где авторы обсуждают достоинства и недостатки интеграции приложений по отношению к интеграции данных, что лишено смысла — это не разные уровни одной системы, и вопрос не в том, что лучше или хуже, а что целесообразнее в определенных обстоятельствах. Итак, теоретически возможны шесть уровней интеграции (рис. 2), на каждом из которых могут использоваться принципиально разные технологии интеграции:

• интеграция вручную предполагает самостоятельное взаимодействие пользователей с информационными системами и оперирование данными через различные языки запросов (пользователь должен знать место нахождения данных, их логическое представление и семантику данных);
• интеграция через общий пользовательский интерфейс (Common User Interface) мало отличается от ручного способа, но проще, поскольку используются стандартные средства, например поисковые машины;
• интеграция, построенная на том, что все приложения решения получают доступ к различным источникам данных, эффективна тогда, когда источников не слишком много (в противном случае приложения будут перегружены интерфейсами);
• интеграция средствами ПО связующего слоя более универсальна, но заставляет включать интерфейсы в приложения;
• универсализация доступа к данным, или логическая интеграция доступа к данным без перемещения (федерализация, виртуализация и т. п.), очень разумна с системной точки зрения, но требует значительных ресурсов и сложна в случае работы в режиме реального времени;
• физическая интеграция в хранилищах данных предполагает перемещение данных в общий пул, что может быть реализовано быстро и удобно, но дорого и требует постоянного отслеживания текущих изменений в данных.

Рис. 2. Уровни интеграции

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

Новые факторы влияния

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

Большие Данные. Фундаментальное отличие платформ для работы с Большими Данными от классических СУБД состоит в необходимости обеспечивать высокую производительность на фоне высоких требований к масштабированию и разнообразию данных (структурированных и неструктурированных). Компонентами новой экосистемы становятся новые технологии, начиная от Hadoop до NoSQL DB, MongoDB, Cassandra и HBase, каждая из которых использует свои собственные подходы к экстрагированию и загрузке данных. В этих условиях резко повышается важность задач интеграции, и хотя сами эти задачи усложняются, основные принципы интеграции остаются теми же. Поэтому сегодня пока наблюдается адаптация традиционных интеграционных инструментов к работе с большими, чем прежде, объемами и скоростями. Например, появляются такие средства, как Apache Sqoop (обмен данными между Hadoop и структурированными хранилищами типа реляционных СУБД) или Scribe (для динамической интеграции приложений Microsoft). Но одних технологий недостаточно — работа с большими объемами данных из разных источников требует больше усилий, поскольку нужно: учитывать происхождение данных, их источники, особенности, состав и другие свойства; разрабатывать системы сервисов для получения полной и доверительной картины данных; организовывать рациональную систему управления данными. Иначе говоря, работа с данными превращается в отдельный вид деятельности, в связи с чем на ряде предприятий уже появляется новая служба, возглавляемая директором по данным (Chief Data Officer, CDO).

Необходимость управления данными. В современных условиях, когда данные превращаются в один из наиболее важных активов, особое внимание уделяется управлению информацией предприятия (Enterprise Information Management, EIM), а точнее — управлению данными (Data Management), служащему для обеспечения требуемого качества данных и для руководства данными (Data Governance). Согласно одному из самых точных определений, Большие Данные — это все доступные данные, отражающие картину происходящего во всей ее возможной полноте. Пока же картина весьма фрагментарна и складывается из различных, в том числе медийных, файлов, результатов обработки на кластерах Hadoop, хранения в NoSQL и традиционных СУБД, выборок из хранилищ, создаваемых инструментами ETL, витрин данных, из систем бизнес-аналитики и т. д. Для работы в этих условиях даже предложен термин — data blending, то есть «смешивание» или «купажирование», предполагающее получение не смеси вообще, а обладающей определенными свойствами, что, как и купажирование вина, требует знаний и умения. Термин был впервые использован компанией Tableau.

Семантические технологии. Такие технологии позволяют извлекать значение или информацию из данных; в их число входят машинное обучение, автоматическое принятие решений, кластеризация, онтологии, таксономия, мониторинг и классификация контента, прогнозная аналитика, нейронные сети и ряд других. Еще недавно об использовании семантических подходов к интеграции говорили как о далеком будущем, а сегодня уже есть прогнозы, что с 2015 года начнется их широкое внедрение. Семантическая интеграция основывается на знании и учете природы данных (метаданных), и для автоматизации работы с данными семантика должна быть явным образом выражена и включена в эти данные. Семантическая интеграция сможет обеспечить объединение только данных, соответствующих или наиболее близких одним и тем же сущностям в окружающем мире. Первые попытки создания систем с семантической интеграцией датируются началом 90-х, когда впервые стали использовать понятие онтологии в приложении к компьютерным данным. А в 2001 году Тим Бернерс-Ли с соавторами опубликовал в журнале Scientific American Magazine статью «The Semantic Web». Предложенный в ней подход добавляет новое качество, позволяя пользоваться данными не «вслепую», а осознанно, определяя и связывая их таким образом, чтобы упростить поиск, автоматизировать работу с ними, перераспределять между приложениями и интегрировать.

Изменения в области интеграции данных скорее всего будут происходить под влиянием всех этих факторов по трем не пересекающимся на данный момент направлениям.

Интеграция Больших Данных

Перечисляя признаки Больших Данных, обычно говорят о четырех «V»: объем (Volume), скорость обработки (Velocity), достоверность (Veracity) и разнообразие (Variety). Невзирая на последнее, можно встретить огромное число утверждений, в которых Hadoop и родственные технологии представляют как универсальное средство для решения проблемы Больших Данных. Иногда Hadoop даже называют «ETL on steroids», указывая на сочетание технологий HDFS, Pig и Hive, якобы способных заменить хранилища данных и ETL. Такое представление является очевидным упрощением — данных становится не только больше, они все более усложняются. Увеличивается число и разнообразие их источников: Web (тексты, документы, регистрационные журналы), электронная коммерция, социальные сети, сенсорные сети, научные эксперименты и др. При объединении, в силу синергетического эффекта, ценность этих данных увеличивается, а отсюда следует актуальность задачи интеграции Больших Данных (Big Data Integration, BDI). Ее решение заметно отличается от традиционных задач, направленных на поддержку ETL, таких как виртуализация или хранилища данных. Решение данной задачи можно разделить на несколько шагов.

• Создание схемы данных (schema mapping). Любая интеграция начинается с создания такой схемы, которая может быть одноуровневой или многоуровневой с делением на глобальные и локальные данные. В традиционных условиях, с фиксированными источниками данных и их свойствами, эта схема остается статичной на некоторый заданный период. В случае BDI отягощающим фактором является изменяемость данных — источников много, и они так или иначе связаны с событиями во внешнем мире. В связи с этим в схему данных должна быть заложена возможность для эволюционного развития.
• Cцепление записей (record rinkage). Эта процедура предполагает выделение записей, близких по логике, но происходящих из разных источников. Отличие BDI от традиционной интеграции в динамике заключается в том, что при BDI должно сохраняться соответствие переменной природе данных. Дополнительную сложность создают разнообразные шумы, а помимо логического объединения необходимы процедуры обработки сложных событий и фильтрации.
• Сплав данных (data fusion). В отличие от двух предыдущих шагов, сплав данных — это новая процедура, и в традиционных системах интеграции в ней необходимости нет. Назначение сплава данных — разрешение конфликтов между данными и выделение тех, которые реально соответствуют картине окружающего мира.

Первые попытки реализации BDI предприняты в продуктах компаний Talend (Open Studio for Big Data), Syncsort (DMExpress), Pentaho (Data Integration) и ряда других.

Новая интеграция для решения старых проблем

Невзирая на очевидную актуальность, проблема интеграции данных до сих пор не решена — здесь по-прежнему царит хаос, что откровенно признают, например, аналитики компании Informatica, признанного лидера в этой области. В чем причины сохранения хаоса в корпоративных данных? Аналитики (в том числе TDWI, Gartner и Ventana Research) сходятся во мнении, что пока еще затраты на интеграцию слишком велики, а результаты низки — данные ненадежны и за время интеграции успевают устареть, а системы плохо масштабируются и не обладают достаточной способностью адаптации к увеличению объемов данных. Такое положение дел объясняется нехваткой квалифицированных кадров и неспособностью имеющихся увидеть все проблемы, связанные с данными, в комплексе, а также отсутствием технологий для работы с Большими Данными в реальном времени.

Специалисты компании Informatica лелеют надежду на то, что следующее поколение средств интеграции данных исправит текущее положение дел. Суть нового поколения определяется как собрание воедино существующих технологий с одновременным формированием команд профессионалов, способных удовлетворить все мыслимые потребности интеграции, а не только организовать работу с хранилищами. В такой набор технологий должны войти традиционные класса ETL и новые: интеграции и репликации в реальном времени, виртуализации данных, поддержки Больших Данных, обеспечения качества данных, управления мастер-данными, управления жизненным циклом информации, обмена сообщениями и обработки сложных событий. Все эти составляющие должны быть собраны в единую архитектуру таким образом, чтобы обеспечивать упреждающие действия в отношении потребностей бизнеса. Для работы с этими технологиями должны быть созданы команды из архитекторов корпоративных данных, аналитиков и тех, кого стали называть data steward, — специалистов, обслуживающих данные и находящихся в подчинении CDO. Ориентация на командную работу должна обеспечить комплексное решение проблем интеграции — общее дело, которым будет занята такая команда, называют data business, подчеркивая этим его важность для бизнеса предприятия.

Рис. 3. Топология интеграционной системы нового поколения

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

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

Виртуализация данных

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

Рис. 4. Виртуализация данных

На уровне общих рассуждений с DV все очевидно — для ее реализации требуется ядро DV (обязательный для любых систем сервер виртуализации), интегированная среда разработки и средства мониторинга, администрирования и обработки ошибок. Но данные более разнородны, чем все виртуализируемые технологии, — в данном случае мы имеем дело не с созданными человеком технологиями, о которых все известно, а с данными, так или иначе отражающими внешний мир во всем его многообразии. Возможно, DV можно распространить на какое-то ограниченное подмножество данных, но представить этот подход как универсальный — нельзя. К примеру, в своем видении будущего поколения интеграции в компании Informatica объединяют усилия команды специалистов в нескольких смежных областях, использующих серьезный набор инструментов, а те, кто говорит о виртуалиазции, предполагают возложить то же самое на некий гипотетический сервер виртуализации. Вряд ли такое возможно.

Семантическая интеграция

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

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

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

Проблема интеграции данных привлекла к себе внимание сообщества ученых, занимающихся искусственным интеллектом, примерно двадцать лет назад. Первые работы строились с привлечением аппарата описательной логики — то есть семейства языков представления знаний, позволяющих формально описывать понятия в предметной области и сочетающих в себе богатые выразительные возможности с хорошими вычислительными свойствами. В последующем исследования распространились на применение для интеграции данных методов машинного обучения и обработки естественного языка (Natural Language Processing, NLP). Судя по количеству публикаций и проводимых конференций, интерес к применению методов искусственного интеллекта к интеграции постоянно растет, но на коммерческий уровень результаты этих исследований еще не вышли.

Ручной подход предполагает, что описания данных создаются заранее, вручную и формируют общую модель данных (Common Data Model, или Canonical Data Model, CDM). Для этого применяется какой-либо язык моделирования, например UML, и задача состоит в описании на нем всех данных, используемых на предприятии или в индустрии в целом. В таком случае CDM служит при интеграции общим уровнем для обмена данными.

Как видно из рис. 5, CDM объединяет сервисы данных (Data Services) с источниками данных (Data Sources). Сервисы данных — это приложения, использующие и преобразующие данные, а источниками данных могут быть любые репозитории.

Рис. 5. Интеграция традиционная и с использованием CDM

***

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