Вопросы использования современных цифровых технологий для хранения и обработки «больших исторических данных»

Бучацкий Игорь Валерьевич кандидат технических наук инженер-программист, ООО "Гриднайн Системс" 115054, Россия, г. Москва, наб. Космодамианская, 52, оф. 1 Buchatskii Igor Valerievich PhD in Technical Science programmer engineer at OOO (LLC) Gridnine Systems  115054, Russia, Moscow, nab. Kosmodamianskaya, 52, of. 1 ivbuchatsky@gmail.com

Исследование выполнено при финансовой поддержке РГНФ в рамках проекта № 13-31-11003 «Разработка междисциплинарной информационно-аналитической платформы «История современной России».

Стремительный научно-технический прогресс, рост населения, глобализация рынков - факторы, способствующие лавинообразному росту информации. Согласно прогнозам IDC (InternationalDataCorporation — аналитическая фирма, специализирующаяся на исследованиях рынка информационных технологий), количество данных на планете будет, как минимум, удваиваться каждые два года вплоть до 2020 г. ^[1]. Поскольку проблемы хранения и анализа все возрастающих объемов разнородной информации становятся чрезвычайно актуальными для всех наук, включая историю, возникает настоятельная потребность в создании усовершенствованных технологий обработки «больших данных» (BigData), ориентированных на исследовательские задачи специалистов социальных и гуманитарных наук. В настоящей статье исследован ряд современных информационных технологий с точки зрения оценки их пригодности для решения указанной проблемы.

Любое историческое исследование базируется на тщательном анализе многообразных исторических источников. Как отмечал в своих трудах по методологии исторической науки академик Александр Сергеевич Лаппо-Данилевский (1863-1919), «исторический источник – это реализованный продукт человеческой психики, пригодный для изучения фактов с историческим значением» ^[2]. Фактически, историческим источником является любой аутентичный объект, содержащий информацию о жизни людей, все многообразие документов и предметов материальной культуры, которые в той или иной степени отражают различные исторические факты и процессы.

Важной особенностью исторических источников является их чрезвычайно широкая вариативность. Ученые-методологи исторической науки не раз предпринимали попытки классифицировать исторические источники, основываясь на выделении тех или иных типов. В России одним из первых свой вариант классификации предложил известный историк, географ, экономист и государственный деятель XVII-XVIII вв. Василий Никитич Татищев, который выделил всего лишь три типа исторических источников: летописи, «дипломатические грамоты» различных архивов, исторические источники частного происхождения ^[3]. Другой отечественный историк Лев Никитович Пушкарев (род. в 1918) подразделял исторические источники на три типа с родами и видами – письменные, вещественные, этнографические ^[4], а Сигурд Оттович Шмидт (1922-2013) в середине 1980-х гг. выделил уже шесть типов: вещественные, изобразительные, словесные, конвенционные, поведенческие и звуковые ^[5].

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

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

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

Согласно определению, данному американской компанией Gartner (одна из наиболее авторитетных исследовательских и консалтинговых структур, специализирующихся на рынках информационных технологий), Big Data («большие данные») характеризуются исключительным объемом, разнообразием и скоростью доступа, с которым структурированные и неструктурированные данные поступают по сетям передачи в процессоры и хранилища и преобразуются затем в ценную для бизнеса информацию ^[6]. Исследователи обычно выделяют ^[7] такие основные свойства «больших данных»:

- Колоссальный объем. Количество данных, поступающих в систему, растет экспоненциально. К примеру, объем хранилища крупнейшей социальной сети Facebook ежедневно увеличивается на пятьсот терабайт, в то время, как фондовая биржа Нью-Йорка генерирует «только» около одного терабайта данных в день.

- Высокая вариативность. Информация Big Data чрезвычайно разнообразна, изменчива, часто не структурирована, что значительно усложняет процесс анализа таких данных традиционными способами. Примером подобной сложности является классификатор исторических источников, приведенный выше, который включает не только текстовые документы, но также фото-, аудио- и видеоисточники, цифровые копии трехмерных артефаков и пр. Вся содержащаяся в этих источниках информация может и, в идеальном случае, должна быть проанализирована.

- Скорость. Речь может идти как о скорости поступления данных в систему, так и о скорости их обработки. Но в любом случае подразумевается высокая скорость обработки на любом этапе. Чем больше время отклика, тем менее ценной становится система. Таким образом, при работе с большими объемами данных производительность системы выходит на первый план.

- Ценность. Хранение информации без ее обработки не представляет большой ценности для исследования. Только обеспечив систему удобными инструментами анализа и достигнув высокой скорость обработки, такая система может быть полезна. С точки зрения Сета Година (Godin, Seth) эксперта в области Big Data, «неоднородный массив данных, независимо от его размера не несет в себе никакой пользы до тех пор, пока эти данные не превращены в информацию, т.е. превращены в продукт потребления пользователями». Необработанные данные он рассматривал лишь как сырье для получения полезной информации ^[8].

Развитие технологий для работы с «большими данными» привело к появлению специальной научной дисциплины DataScience. Этот термин был предложен в начале 2000-х гг. профессором американского университета Пердью (PerdueUniversity, USA) Вильямом Кливлендом (Cleveland, William). Он определил Data Science как дисциплину, объединяющую в себе различные направления статистики, «поиск знаний в базах данных» (Data Mining), машинное обучение и применение баз данных для решения сложных задач, связанных с обработкой данных ^[9]. Однако такое определение не отражает сути Data Science, поскольку является простым перечислением набора разрозненных и зачастую несвязанных методов и технологий для извлечения, обработки и анализа данных больших объемов. При этом, ассоциация методов Data Science с методами теории статистики представляется не совсем корректной, поскольку последняя оперирует исключительно «очищенными» (data cleansing) и обработанными данными, на основании которых ведется поиск неких зависимостей. Что касается Data Science, то эта дисциплина нацелена не только и не столько на статистическое исследование данных, сколько на извлечение этих данных из огромного массива источников.

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

Во-первых, строгая согласованность данных (consistency, т.е. точное соответствие данных некой логической схеме) делает затруднительным и крайне неэффективным хранение неструктурированных объектов, а именно эта характеристика является одной из важных особенностей Big Data. Жесткая типизация и строгое определение моделей данных невозможны при постоянно меняющихся структурах объектов хранения. Отчасти проблему можно решить, если сознательно отказаться от нормализации логической структуры (правил проектирования отношений и связей между ними) в пользу денормализованных отношений. Однако в этом случае разработчики лишаются одного из главных преимуществ реляционных СУБД - гарантированной целостности данных в любой момент времени.

Во-вторых, как представляется, насколько бы мощным инструментом не был язык структурированных запросов SQL, включая различные дополнения к нему (расширения, процедурные языки программирования, вроде PLSQL у Oracle и PostgreSQL, а также T-SQL у Microsoft SQL Server, используемые в современных СУБД), его возможности серьезно проигрывают в сравнении с современными языками программирования высокого уровня (Java, C++, Python). Поэтому построить эффективную систему, ограничившись только лишь SQL и PSQL запросами, невозможно. С ростом энтропии системы разработчики рано или поздно столкнутся с серьезными проблемами, связанными с отсутствием гибкости избранного решения.

В-третьих, постоянно растущие запросы к уровню производительности систем хранения и обработки данных, накладывают дополнительные требования к возможности быстрого и экономичного с финансовой точки зрения масштабирования системы. В случае использования традиционных реляционных СУБД такая задача решается в прямом смысле слова дорогой ценой. Необходимость строгой типизации, нормализации, использования внешних ключей, атомарность операций делают масштабирование системы труднодостижимой целью. Даже если речь идет всего лишь о горизонтальном масштабировании, то есть расширении числа однотипных узлов, этот процесс будет связан с серьезным усложнением (а значит, удорожанием) администрирования системы и ростом стоимости добавления новых узлов.

Начиная с 2009 г. набирает популярность новое направление в реализации систем хранилищ данных, так называемые NoSQL-базы данных ^{[10, 11]}. В отличие от традиционных реляционных СУБД, где целостность данных была основой основ, NoSQL-хранилища сознательно отказываются от части так называемых требований ACID, сформулированных еще в 1970-х гг. и описывающих функциональные требования к системе хранилища данных для обеспечения прозрачности и стабильности работы в условиях многопользовательского использования (акроним ACID составлен из первых букв английских слов «Atomicity, Consistency, Isolation, Durability») ^[12]. Так, характеристики атомарности (atomicity, объединение нескольких операций с данным в единую транзакцию) и целостности данных (dataconsistency) в модели NoSQL уже не являются обязательными, что позволяет эффективно преодолеть проблемы реляционных СУБД, связанные с недостаточными возможностями масштабируемости системы (scalability - увеличение производительности системы путем добавления новых компонентов в систему), а также доступности данных (availability – характеристика возможности стабильного доступа к данным системы, независимо от ее нагрузки, включая крайние пиковые значения).

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

Таким образом, ключевыми особенностями NoSQL-решений по сравнению с традиционными реляционными СУБД являются следующие:

- Высокая производительность. При использовании NoSQL-решении происходит заметный рост производительности системы за счет отказа от многих функций и фоновых процессов, связанных с поддержкой целостности данных, что является обязательным для реляционных СУБД (уровни изоляции транзакций, взаимоблокировки при многопользовательском режиме, разрешение конфликтов между одними и теми же данными разных версий, ведение undo-логов). При увеличении объема информации эти процессы резко снижают производительность системы, поэтому многие компании, делают свой выбор в пользу «отзывчивости» ресурса, жертвуя целостностью данных. В больших распределенных системах такое решение может приводить к ситуации, когда результаты деятельности одного пользователя становятся видимыми другим пользователям не моментально, с некоторой задержкой. Например, два клиента могут одновременно забронировать онлайн один и тот же последний доступный в системе номер отеля. Возникновение таких рассогласований считается нормальной ситуацией и обычно обрабатывается в ручном режиме (так называемая модель «согласованности в конечном счете» - eventualconsistency). Отзывчивость ресурса в данном случае имеет более важное значение, чем потенциально возможные конфликты из-за погрешностей в согласованности данных, поскольку «неповоротливость» системы может привести к потере реальных клиентов или важных данных.

- Высокая пропускная способность. Большинство NoSQL-решений обеспечивают не только повышенную производительность в сравнении с традиционными СУБД, но также позволяют эффективно осуществлять горизонтальное масштабирование системы. Современные NoSQL-решения успешно справляются как с горизонтальным масштабированием, так и с решением ряда сторонних задач, возникающих при использовании кластера серверов, включая процесс разделение данных между разными физическими серверами (т.н. «шардинг данных» – от англ. datasharding), репликацию (поддержание нескольких копий данных для увеличения производительности и безопасности системы), повышение отказоустойчивости (даже если один узел вышел из строя, система продолжает работать).

- Отказ от целостности данных. Как уже указывалось, в базах данных, основанных на модели NoSQL, не гарантируется целостность данных. Из этого следует, что разработчик системы должен либо самостоятельно решить эту задачу на уровне приложения (что не имеет особого смысла, поскольку, по сути, речь идет о дублировании функций реляционной СУБД), либо обеспечить корректную работу приложения в условиях негарантированной целостности данных. Отказ от целостности данных подразумевает, что структура данных в NoSQL-хранилищах слабо типизирована, то есть декларативный подход к описанию структуры таблицы, как правило, отсутствует. В итоге, отказ от принципа целостности данных обеспечивает практическую гибкость хранения слабоструктурированных объектов.

Сегодня известно уже несколько десятков различных NoSQL-решений, которые, согласно классификации, предложенной в 2011 году независимым консультантом по хранению данных, в прошлом известным исследователем корпорации Sun Microsystems Риком Каттелом (Cattel, Rick) ^[13], можно разделить на четыре группы в зависимости от принятой модели хранения данных:

1. Хранилища ключ-значение. Это самая простая модель хранения, которая представляет собой ассоциативный массив пар «ключ-значение», напоминающий словарь. Например, в модели хранения имен клиентов ключом словаря является логин пользователя, а значением – различная информация о человеке. Примеры реализации: Berkeley DB, Redis, MemcacheDB.

2. Документные хранилища. В этой модели множество пар «ключ-значение» объединяются в некую единую сущность, условно именуемую «документ», доступ к которой обеспечивается также по ключу. Такое решение позволяет работать с понятными абстракциями как с единым целым, что удобно, когда для работы требуется лишь одна сущность со всеми ее атрибутами. Например, при обработке заказа в интернет-магазине необходимо получить из хранилища данных всю информацию, имеющую отношение к этой покупке (о клиенте, о товаре, об оплате, об адресе доставки и пр.). Все зависимые ассоциации также хранятся в едином документе. Примеры реализации: Couchbase Server, Apache CouchDB, MongoDB.

3. Колоночные хранилища. Эта модель наиболее схожа с традиционными СУБД и подразумевает хранение значений как не интерпретируемых байтовых массивов, адресуемых особыми типами упорядоченных данных – так называемыми «кортежами» (ключ строки, ключ столбца, метка времени). В этом случае основой модели данных является колонка, причем число колонок для одной таблицы может быть неограниченным. Колонки по ключам объединяются в семейства, обладающие определенным набором свойств. Примеры реализации: Cassandra, Apache CouchDB, SimpleDB.

4. Хранилища на графах. Хранилища такого типа применяются в основном при работе с данными, которые естественным образом имеют структуру графов (социальные сети, карты геолокаций, маршруты движения). В таких хранилищах модель данных соответствует топологической модели графа и состоит из вершин и связей между ними. Набор операций соответствует типовым операциями при работе с графами: поиск вершин, обход дерева, сортировка дерева, поиск оптимальных маршрутов. Примеры реализации: Neo4J, AllegroGraph, InfiniteGraph.

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

Одним из признанных лидеров в области обработки «больших данных» на сегодняшний день является проект открытого программного обеспечения фонда Apache Software Foundation (ASF) под названием HadoopMapReduce^[14]. Наиболее значительной известной разработкой ASF является кроссплатформенное программное обеспечение HTTP-сервера Apache, которое на сегодня является самым распространённым в мире. Разработка платформы Hadoop началась в 2005 г., а уже к 2008 г. программный продукт достиг технологической зрелости и нашел успешное применение во множестве проектов. Например, одним из крупнейших пользователей и разработчиков Hadoop является компания Yahoo, активно использующая данную систему в своих глобальных поисковых сервисах (в частности, Hadoop-кластеру Yahoo, состоящему из 40 тысяч узлов, принадлежит мировой рекорд скорости сортировки данных объемом 1Тб). Другими известными пользователями этого программного продукта являются такие компании, имеющие мировую известность как Facebook, Twitter, LinkedIn, Last.fm, Ebay, Amazon.

Платформа Hadoop состоит из четырех базовых взаимозависимых компонентов:

- HadoopCommon (набор системных библиотек и утилит, отвечающих за реализацию базовых функции системы),

- HadoopDistributedFileSystem (распределенная файловая система, HDFS),

- YARN (система планирования заданий и управления кластером – от англ. Yet Another Resource Negotiator, «ещё один ресурсный посредник»),

- HadoopMapReduce (платформа выполнения распределенных вычислений).

Распределенная файловая система HDFS, используемая Hadoop, обеспечивает надежный обмен данными между узлами кластера, обладает высокой отказоустойчивостью и способностью к самовосстановлению ^[15]. HDFS превращает множество стандартных (порою самых заурядных) вычислительных машин кластера (узлов) в хорошо масштабируемую систему хранения данных. Изначально HFDS была специально разработана, исходя из требований для работы в высоконагруженном окружении, где вероятность выхода из строя компонентов достаточно высока. При хранении данных HFDS оптимизирует их для достижения максимальной производительности системы. Среди ключевых особенностей системы HFDS можно выделить следующие:

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

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

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

- Позволяет балансировать нагрузку, управляя потоком данных между узлами кластера для достижения максимальной производительности. Центральный узел (node) регулирует маршруты пакетов, чтобы обеспечить сбалансированную нагрузку всех узлов кластера.

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

Безопасность данных достигается также путем разграничения доступа к файлам пользователей и групп пользователей (модель основана на POSIX – Portable Operating System Interface for Unix – набор стандартов, описывающих интерфейсы между операционной системой и прикладными программами). Каждый пользователь и каждая группа пользователей получает свой набор привилегий доступа к объекту файловой системы. Это обеспечивает прозрачное и надежное регулирование доступа пользователей к данным системы.

В основе системы Hadoop лежит модель распределенных вычислений MapReduce. Согласно этой методологии крупная аналитическая задача может быть разбита на множество мелких задач для обработки в кластере. Идея MapReduce была изначально предложена инженерами корпорации Google в 2006 году, а в апреле 2010 года корпорация официально предоставила все права на открытое использование технологии MapReduce фонду ASF, который по сей день занимается разработкой и продвижением этой платформы на рынке. Позднее появились другие реализации методологии MapReduce, но лишь Apache Hadoop MapReduce сегодня считается признанным стандартом в данной области, с отрывом опережая своих конкурентов.

Работа над задачей делится на два последовательных этапа: Map (картирование -предварительная обработка входных данных) и Reduce (свёртка обработанных данных) ^[16]. На первом этапе главный управляющий узел (MasterNode) запускает реализацию алгоритма Map. Цель функции Map - разбить сложную входную задачу на множество «элементарных заданий», которые распределяются для обработки по узлам кластера. Рабочий узел кластера может в свою очередь разделить задачи на еще более мелкие единицы и распределить их по своим дочерним узлам, образуя подобие древовидной структуры. Такой алгоритм облегчает расширение системы и ее администрирование. После выполнения «элементарных заданий» рабочие узлы возвращают полученные результаты на управляющий узел. На втором этапе (Reduce) управляющий узел собирает результаты выполнения всех подзадач и формирует итоговое решение исходной задачи. Таким образом, платформа Hadoop позволяет выполнить почти любую задачу в параллельной среде, что значительно повышает производительность системы. А легкость горизонтального масштабирования делает возможности такой системы практически безграничными.

Одновременно с популяризацией технологии MapReduce совершенствовалась, и вся возникшая на ее основе программная экосистема. В частности, в результате усилий множества ученых, инженеров и обычных пользователей был разработан язык сценариев Apache Pig Latin, предназначенный для выполнения запросов к большим слабоструктурированным наборам данных с помощью платформы Hadoop и технологии MapReduce. В английской культурной традиции словосочетание Pig Latin («поросячья латынь») означает «тайный» шутливый английский язык, который часто используют дети. Это означает, что Apache Pig Latin позволяет применять простые языковые конструкции для решения большинства задач программирования, для которых прежде требовалось обращаться к сложным высокоуровневым языкам, типа Java, Ruby, Python. Интуитивно понятный сценарный язык Pig Latin не требует погружения пользователей в лишние, зачастую ненужные «программистские детали», что дает возможность достаточно быстрого обучения неспециалистов методологиям разработки сценариев решения тех или иных конкретных исследовательских задач, которые в свою очередь, благодаря слаженной инфраструктуре Hadoop будут затем автоматически распараллеливаться и распределяться между узлами информационной системы. Например, функция нахождения заданной строки в массиве данных, реализованная на языке Java, требует программного кода объемом порядка 100 строк, такой же функционал на языке Pig Latin занимает всего лишь три строки:

messages = LOAD 'data_files';

barns = FILTER data_files BY $0 MATCHES '.*BARN+.*';

STORE barns INTO 'warnings';

Очевидно, что данный подход, как и любое упрощение, имеет свою обратную сторону: в данном случае происходит уменьшение функциональных возможностей языка. Однако разработчики Apache Pig предусмотрели решение этой проблемы. Помимо наличия обширной библиотеки уже реализованных функций, Pig позволяет расширять язык с помощью функций, определяемых пользователями (User-DefinedFunctions, UDF). Это, в свою очередь, дает возможность полноценно использовать всю мощь высокоуровневых языков программирования для задач, которые не могут быть эффективно решены операторами языка Pig Latin.

Междисциплинарная масштабная Интернет-платформа, посвященная современной отечественной истории, была реализована при участии автора в рамках поддержанного Российским гуманитарным научным фондом (РГНФ) проекта № 13-31-11003 «Разработка междисциплинарной информационно-аналитической платформы “История современной России”». В процессе создания информационно-аналитической платформы «История современной России» (URL: http://prohistory.ru) разработчикам потребовалось решить две содержательные научные задачи. Во-первых, это задача формирования объективного событийного каркаса изучаемого периода на основе сбора, оцифровки и размещения в ресурсе множества разнообразных документов, являющихся источниками по отечественной истории недавнего прошлого, а именно: нормативных правовых актов (конституции, законы, указы, постановления, распоряжения), архивных документов органов власти (доклады, декларации, стенограммы, рабочие записки, телеграммы, заявления), сообщений средств массовой информации (газет, журналов, информационных агентств), материалов личного происхождения и мемуарного характера. Уже сам факт создания масштабного комплекса аутентичных документов, содержащих информацию о жизни государства и общества конца XX-начала XXI вв., представляет огромный интерес для исследователей, изучающих этот важный исторический период. Во-вторых, перед разработчиками стояла задача создания удобных и эффективных для пользователя (клиент-ориентированный подход) инструментов, позволяющих аккумулировать всю эту разнообразную информацию в хранилище данных платформы и обеспечивать их машинную обработку.

По результатам сравнительных испытаний в функционале ресурса в итоге были использованы следующие технологические решения: клиент-серверная технология распределенной обработки данных, структура программной среды (framework) для разработки веб-приложений Ruby on Rails, свободная объектно-реляционная СУБД PostgreSQL, и открытая платформа поиска полнотекстовой информации Sphinx. В качестве веб-сервера традиционно был выбран HTTP-сервер Apache под управлением операционной системы Linux. При создании клиентской части также были использованы технологии веб-дизайна HTML5 и CSS3, что позволило обеспечить быстрый доступ к ресурсам Интернет-платформы с мобильных устройств всех типов ^{[17, 18]}.

Как уже отмечалось, количество данных, требующих обработки и анализа, сегодня растет огромными темпами, объективные физические ограничения вычислительной техники ведут к пересмотру всей системы хранения и обработки информации, а значит, повсеместное использование информационных технологий «больших данных» в качестве исследовательского инструмента представляется неизбежным ^[19]. Этот вывод относится и к перспективам расширения информационно-аналитической платформы «История современной России». За время существования ресурса (первая версия платформы, посвященная истории российского конституционализма, была открыта для свободного доступа в сети Интернет 20 сентября 2013 года, URL: http://constitution20.ru, основная версия – 12 июня 2014 года) в его хранилище был накоплен большой объем разнообразных исторических данных, документов, мультимедиа-объектов. Разумеется, на сегодняшний день этот информационный массив (количество записей порядка миллиона единиц) еще нельзя назвать в полном смысле слова «большими данными». Однако дальнейшая работа Интернет-портала, в том числе стимулирование ученых-гуманитариев и сторонних пользователей к размещению на платформе собственных документальных материалов, способны быстро привести к ситуации, когда существующие мощности вычислительной системы и возможности вертикального масштабирования окажутся практически исчерпанными. По этой причине в рамках упомянутого гранта РГНФ были проведены дополнительные исследования, связанные с поиском оптимальных технологических решений при масштабировании платформ в области Digital Humanities.

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

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

Во-первых, большая вариативность структур объектов приводит к затруднённому хранению такой информации в базе данных. Выделять под каждый тип документа отдельное отношение (таблицу) нерационально, так как их потенциально может быть десятки, сотни, и количество отношений будет постоянно расти. В случае, если же пойти по такому пути, то обработка такого набора отношений средствами языка SQL также будет крайне трудоемкой. Простые операции поиска и группировки данных в единую выборку будут сопряжены с рядом трудностей, решить которые средствами одного только языка SQL представляется малоперспективным.

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

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

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

Для проведения масштабирования Интернет-платформы по истории современной России предлагается использовать платформу параллельных вычислений ApacheHadoopMapReduce. По имеющейся статистике до 80% всех задач программирования могут быть решены с помощью технологии Hadoop, при этом наиболее эффективно решаются задачи анализа данных (DataMining), машинного обучения (MachineLearning) и индексирования неструктурированных данных и поиск по ним.

Для повышения аналитической мощности исследовательской платформы с помощью Hadoop необходимо решить несколько взаимосвязанных задач. Прежде всего, необходимо развернуть всю инфраструктуру HadoopMapReduce, включая создание кластера рабочих узлов. По мере увеличения нагрузки новые узлы могут быть свободно подключены, увеличив тем самым производительность системы. Другой важный момент, который направлен на повышение пользовательского удобства (usability) платформы состоит в создании необходимой инфраструктуры вокруг самого кластера Hadoop. Эта инфраструктура обязательно должна включать в себя язык ApachePig, упрощающий разработку сценариев PigLatin, которые в процессе работы транслируются в исполняемый код алгоритмов MapReduce, а также удобные средства загрузки сценариев в систему, их выполнения и анализа результатов. Отдельно стоит отметить важность предоставления возможности отладки загруженных сценариев, в частности, путем анализа исходных исторических данных.

Информационно-аналитическая платформа «История современной России» содержит в своих хранилищах большой объем исторических данных, который продолжает стремительно расти. Выбор платформы распределенных вычислений Hadoop для создания и совершенствования инструментов анализа этой информации может быть в этом случае эффективным решением, но при этом необходимо учитывать ряд ограничений (барьеров). Задачи, которые могут быть решены с помощью HadoopMapReduce, основаны на параллельной обработке данных. Это означает, что система способна эффективно работать только с теми пользовательскими задачами, которые принципиально могут быть «разобраны» на элементарные единицы с уникальными данными. Если данные пересекаются, то в этом случае их изолированная обработка становится практически невозможной. Другим барьером на пути внедрения технологии обработки данных на основе технологии MapReduce может стать излишняя сложность написания алгоритмов распределенной обработки исторических данных. Таким образом, вопрос целесообразности создания универсальной платформы распределенных вычислений в области DigitalHumanities нуждается в дополнительном исследовании.