Шумные данные

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

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

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

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

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

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

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

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

История, и не только

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

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

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

Что делать

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

Для всех остальных видов шума все не так прозрачно. Отдельная большая проблема — лишние данные, которые как бы не связаны ни с чем (из того, с чем они должны быть связаны), то есть возникает ситуация нарушения внутренней целостности базы данных. Как правило, их просто удаляют, принимая риск того, что однажды запрошенная выборка окажется неполной или искаженной. И здесь, как ни странно, помогает дублирование одних и тех же данных в различных системах: например, есть условно «старая» и «новая» CRM. Если предположить, что в результате некоего происшествия (программная ошибка, перезагрузка и т. д.) в «старой» системе потеряны некоторые данные, то наличие какого-то количества данных в «новой» позволит хотя бы частично решить коллизию.

Отдельно стоит вспомнить про бекапы и резервирование. Это, с одной стороны, дело хорошее, с другой — бекапы сами могут стать чудесным источником цифрового шума. Кроме того, работа с бекапами особенно больших данных — это вечный поиск компромисса между производительностью, объемами и простотой работы. Те же инкриментные бекапы требуют достаточно «хитрых» алгоритмов реализации, вычислительных ресурсов. Бекап «в лоб», то есть «всего, что можно», — требует хорошей локальной сети и достаточных объемов хранилища... В общем, как не кинь — везде клин.

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

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

В общем, как всегда — требуется найти компромисс. Никто его не видел?