Упаковка для больших данных
Библиотека как источник и хранилище данных
Если вместо этого использовать «Имя» и «Фамилия», мы задаём не только структуру, но и формат данных. Оба имени вводятся с заглавной буквы. Например, Донателла Мохова. Элементарно? Нет. Имя может быть полным, сокращенным, неофициальным, вторым, вариантом. Что делать в этом случае? Сделать выпадающий список (словарь) имён, чтобы исключить некорректный ввод? Идеально, но слабо реализуемо. Решение — привлечь сторонний «верификатор», например, паспорт или водительские права. Тогда «введите ваше имя» превращается в «Имя: Донателла», «Фамилия: Мохова», «Документ (выбрать из списка): паспорт». В этом случае мы получаем не только достоверные данные об имени, но и схему их представления (паспорт).
Не со всеми текстовыми данными можно работать подобным способом. Возьмем Twitter. У каждого поста-твита есть (всегда) сам пост и его создатель (тот, кто его разместил). И если с создателем все понятно, то твит — блок неструктурированных данных (в котором могут, однако, присутствовать элементы схем # и @). Значит ли это, что их не надо хранить? Надо. Если есть пара «ключ — значение» (для твита — создатель и его пост), — есть минимальная структура, есть база для анализа. Если пары нет, получается куча. Вероятность превращения её в информацию очень мала. Почему? Потому что непонятно, как хранить кучу. Какой контейнер выбрать и каким образом упаковать. Хотя почти всегда можно найти что использовать в качестве ключа, например, время.
Немного об упаковке. Первобытный человек не паковал НИЧЕГО, потому что ничего не хранил. Сорвал ягоду, съел. Подошел к речке — попил воды. Но если для ягод не сезон и речки рядом нет? Или детей кормить надо? Тогда и возникла необходимость упаковки. Дальше всё происходило эволюционно: пустотелые плоды или скорлупа, плетеные корзины, деревянные и глиняные сосуды, и … понеслась цивилизация. Данные прошли абсолютно тот же путь от памяти в голове, засечек на дереве, табличек из глины и до … шарманки, — цилиндра с булавками и скобами разной длины, установленными через определенные промежутки времени требуемые музыкой. Концепция возникла в Нидерландах в 15 веке. Искусство подтолкнуло научно-технических прогресс. Сын французского музыканта Василий Бушон (Basile Bouchon) в 1725 году перенес идею на программирование ткацкого станка с помощью бумажных карточек (куда без них). Однако успех пришел только в 1804, когда Жозеф Мари Жаккард (Joseph Marie Jacquard) заменил карточки перфолентой.
В библиотеках карточки стали единицей хранения информации об объекте. Их функцию лучше всех сформулировал в 1904 году великий американский библиотекарь Чарльз Каттер (Charles Cutter):
1. Чтобы позволить человеку найти книгу, у которой либо
(a) автор
(b) название
(c) предмет
известен.
2. Показать, что есть в библиотеке
(d) данного автора
(e) по заданной теме
(f) в данном виде литературы (поэзия, драма, художественная литература).
3. Содействовать выбору произведения
(g) по изданию (библиографически)
(h) по характеру (литературное или тематическое).
Ещё один вжух! машины времени и перенесёмся во вторую половину 20 века.
1972, компания 3M представляет 1/4 дюймовую кассету (упаковку) для записи информации. Пятью годами раньше (1967) появилась первая дискета, в 1982 — компакт-диск. В 1987 — флэш-память.
В 1968 году Библиотека Конгресса США опубликовала итоговый отчет пилотного проекта MARC, подготовленный Генриеттой Аврам. В 1975 в штате Огайо появился первый OPAC. К моменту появления персональных компьютеров (1980 — IBM, 1984 — Apple) онлайн каталоги уже существовали в количестве, достаточном для того, чтобы говорить о цифровых данных.
По состоянию на июль 2020 года в самом большом каталоге WorldCat хранится 500 миллионов библиографических записей на 483 языках, представляющих более 3 миллиардов физических и цифровых библиотечных ресурсов, а набор данных о людях, добытый из WorldCat, включает более 100 миллионов человек.
Библиотеки сегодня собирают данные не только о книгах и читателях, но и о запросах, скорости их обработки, времени чтения (для электронных библиотек) и о массе других вещей, в зависимости от настроек библиотечной системы. Большинство данных хранится в SQL — базах или по-простому, в таблицах на серверах библиотеки. Это если данные структурированы и есть мощности для их хранения. А если нет?
Почему библиотеки медленно и неохотно поворачиваются в сторону хранения данных научных исследований? Почему не собирают и не хранят свои собственные данные за исключением электронных каталогов? Наши данные могут дать не меньше информации, чем поисковые системы и социальные сети. Но почему соцсети эти данные хранят и используют, а библиотеки нет? Потому что мы не знаем, как их упаковать и куда положить. Библиотечные сервера заполнены и схемы у нас есть только для традиционных процессов: комплектование, каталогизация и т.п. В поиске задействована вся огромная база библиотечной системы. Чем больше электронный каталог, тем медленнее он работает.
А что делают наши «конкуренты»? Объемы данных в них больше любого электронного каталога и даже самой большой электронной библиотеки. Берем много компьютеров и храним на каждом небольшую порцию данных. Понятно, что это будет работать быстро. Задача «главного» компьютера, на который приходит запрос, заключается в том, чтобы перенаправить его туда, где лежат нужные данные. А как? Методом «ключ - значение». Помните, мы говорили про пары. Возьмем к примеру, данные об инопланетянах. «Иноплянетянин1» будет ключом, а данные — «6х8, синий, 27%, alien.jpg, etc.» — значением. Вот так просто. Прелесть этого подхода в том, что данные могут быть совершенно разнородными и не нужно заранее определять схему. Сколько нужно элементов, столько и будет.
Поскольку библиотеки преимущественно имеет дело с данными (или информацией) в некоторых стандартных форматах или кодировках, для таких случаев лучше работает немного иная концепция хранения ключей и значений. Она называется документно-ориентированной. Центральное понятие базы хранилища документов — это «документ». Документы адресуются в базе данных с помощью уникального ключа, который представляет этот документ. Различные реализации предлагают разные способы организации и / или группировки документов: коллекции, теги, невидимые метаданные, иерархии каталогов. Причем документы в коллекции могут иметь разное количество совершенно разных полей и даже в разной кодировке (например, JSON и XML).
В хранилище “ключ-значение” данные считаются непрозрачными для базы данных, а система, ориентированная на документы, работает глубже, извлекая метаданные, ориентируясь на внутреннюю структуру документа.
Обе эти концепции являются примерами архитектуры базы данных NoSQL.
Я попыталась рассказать об упаковке больших данных максимально просто, но как всегда всё немного сложнее, чем на самом деле ).
В науке о данных нет понятия «правильное решение», но есть статистика:
80% данных являются неструктурированными и 80% анализа больших данных — работа по их сбору, организации и хранению. Библиотеки призваны служить прогрессу и если сегодня он требует больших данных, стоит подумать о том, как мы можем помочь.
Ольга Барышева