Объединение массивов данных, опубликованных в форме инкрементного массива

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

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

Такой формат публикации называется публикацией инкрементным массивом. И пожалуй, тут же нам нужно уяснить один важный факт: в России, кажется, нет открытых данных, опубликованных в таком виде. Поиск ничего не даёт. Я знаю, что примеры есть: это, прежде всего, общероссийские классификаторы, такие как ОКТМО и ОКВЭД. Несколько раз в год, а для ОКТМО — почти каждый день, выходят изменения под порядковыми номерами. Но даже их невозможно скачать: на сайте федеральной службы статистики опубликованы только классификаторы целиком, уже с учётом этих изменений.

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

И самая очевидная задача — объединить эти файлы в один. Как это происходит? Основы баз данных: у строк есть уникальный ключ. Зная уникальный ключ, можно найти единственную строку, которую он адресует. Допустим, нам пришёл инкрементный файл, где добавили строки с ключами 9 и 10 — мы просто дописываем их в конец; удалили строку 4 и изменили название для ключа 5: находим эти записи по уникальному ключу и проставляем соответствующие атрибуты: что одна удалена, а другая поменяла название. В итоге получаем базу с наложенными правками, и нам не нужно качать всё целиком.

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

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

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

Интересен недавно появившийся вид инкрементных данных: данные в реальном времени. Это когда нет базового набора данных, только обновления, которые могут приходить тысячи раз в секунду. Разумеется, их не скачивают в виде файлов, а получают через интефейс API. Каждое обновление затрагивает только одну строку воображаемой таблицы: это, к примеру, один твит, или чекин в форсквере. Через фильтрацию и агрегацию этого потока можно получить данные для интересующего среза: например, разницу между типами заведений, в которых чекинятся мужчины и женщины, или карту твитов с расцвечиванием по хэштегам. Потоки данных в реальном времени предполагают полную автоматизацию, высокую скорость работы и, как следствие, полученные данные почти никогда не хранят, а сразу обрабатывают и забывают.

Среди открытых данных в реальном времени можно найти задержки рейсов, данные криптовалют, землетрясения, данные по общественному транспорту и погоде. Форматы файлов везде разные, но встречаются стандартизованные технологии, задействованные необычным способом. Например, USGS публикует ленту землетрясений в формате RSS, том же самом, что позволяет подписаться на блоги. А википедия оповещает о правках статей в реальном времени через каналы в IRC, которые обычно предназначены для общения людей. Наберите в гугле real-time open data, и найдёте несколько интересных примеров.

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

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