C момента своего возникновения в середине 90-х годов отрасль хранилищ данных и бизнес-аналитики смогла накопить большой опыт и разработать набор оптимальных методик и рекомендаций (best practice). Хотя не все заказчики подходили к этой тематике равнозначно требовательно, общее состояние наработанных методик и практик, связанных с управлением данными (качеством данных, управлением жизненным циклом данных, безопасностью и приватностью данных), достигло к настоящему времени достаточно зрелого уровня.

Однако с возникновением феномена больших данных и появлением новых платформ разработки аналитических приложений, поддерживающих работы с информацией самого разного типа (таких, как Hadoop), появился очевидный вопрос — актуально ли применение этих накопленных методик в новых условиях? По общему признанию, не все варианты применения Hadoop были предназначены для аналитиков, однако, возможно, трудности с ранним внедрением этой платформы заслуживают их внимания. Проблема приобретает значительную остроту, если проанализировать, как большинство крупнейших ИТ-поставщиков платформ данных позиционировали Hadoop: EMC Greenplum, HP Vertica, Teradata Aster Vertica и другие рисуют картину, в которой Hadoop является лишь расширением вашего [SQL] корпоративного хранилища данных.

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

Существенно, что с концентрацией внимания на объеме и разнообразии данных, из фокуса исчезла проблема их качества. Вопрос в том, насколько важным остается значение качества данных при работе с информацией разного типа и масштаба? Можете ли вы позволить себе очищать (проверять и в случае необходимости — восстанавливать) множество терабайтов данных? И являются ли “плохие данные” действительно плохими?

Ответы на эти вопросы не очевидны. Традиционные хранилища данных трактовали “плохие” данные как нечто, что необходимо очистить и выверить. Несмотря на то что принцип “мусор на входе — мусор на выходе” сопутствует нам с самого начала компьютерной эры, проблема качества данных обострилась лишь тогда, когда хранилища данных предложили нам возможность агрегировать большое количество самых разнообразных источников данных, необязательно совместимых друг с другом с точки зрения структуры, полноты и точности. Выход из положения заключался в чистке одной записи за другой, на основе предположения, что для бизнес-аналитики требуется сравнение [данных] строго по принципу “яблоки с яблоками”.

Однако объем и разнообразие данных, поддерживаемых Hadoop, ставят под сомнение практичность традиционных методик очистки данных. Исправление ошибок по принципу “запись за записью” займет вечность, и в любом случае просто будет нецелесообразным (или не оправдывающим затрат) делом чистить журналы данных, сильно различающиеся между собой по сути и содержащие весьма мало содержательной информации. Разнообразие данных, не только по структуре, но и по источникам, осложняет задачу классификации и понимания корректной структуры и формы для каждой отдельной записи. А если учесть, что информация с каждого конкретного компьютера большей частью зашифрована и часто не несет большого смысла сама по себе, пока не проанализирована в большом масштабе, то традиционные методики еще больше теряют смысл.

Поэтому Hadoop представляет собой особый случай. Однако поскольку Hadoop поддерживает различные подходы к аналитике, данные также должны обрабатываться по-разному.

Точная картина или огромная картина?

Качество данных в Hadoop определяется скорее широкими возможностями отбора, зависящими от природы приложения и характеристик данных, особенно — обозначаемых аббревиатурой 4V (“Volume, Variety, Variation, Visibility” — объем, разнообразие, изменение и доступность для потребителей). Ваше приложение критически важно для работы организации? Это может предвещать более строгие методики обеспечения качества данных, в реальности это будет зависеть еще и от того, требуются ли для этого приложения строгие аудиторские проверки, и должно ли это приложение соответствовать правилам и стандартам регулирующих организаций. В этих случаях в вопросе корректности данных лучше перестраховаться. При этом веб-приложения, такие как поисковые машины или системы онлайн-рекламы, также могут относиться к разряду критически важных, однако отсутствие 100% корректности данных для этих систем не обязательно повлечет какие-либо последствия для всей компании.

Поэтому вам необходимо спросить себя: вы хотите получить полную картину или абсолютно точную? В некоторых случаях они могут различаться.

Природа данных, в свою очередь, определяет целесообразность применения той или иной стратегии их чистки. Большие объемы говорят против традиционного подхода “запись за записью”, большое разнообразие данных делает чистку более трудной, а требование высокой скорости процесса делает ее практически невозможной. Например, приложения высокопроизводительной обработки сложных событий (complex event processing — CEP) или обработки потоковых данных обычно используются для поиска определенных образцов, служащих для принятия определенных операционных решений. Необходимость предварительной чистки данных, поступающих в такие системы, приведет к значительной перегрузке компьютеров, особенно для приложений с требованиями высокой скорости работы и отсутствия задержек с передачей результатов. И затем возникает вопрос ценности данных: в записи о покупателе, созданной в результате индивидуального ввода, может содержаться более корректная информация, чем в результате работы системы.

Спектр подходов к чистке данных

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

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

Еще одна идея заключается в полномасштабном использовании теории данных — не только для анализа событий, но и для их корректировки. Мы не предлагаем вам перевести дорогих (и весьма редких) специалистов по анализу данных на должности техников по контролю качества информации, мы говорим о применении тех же самых исследовательских методов к динамическому контролю качества. Другие возможные варианты заключаются в применении методик, использующих логику очистки данных, но не в точке их ввода, а в момент получения результатов. Это может быть крайне важным, например, для строго регулируемых процессов, таких как оценка рисков контрагента при работе на рынках капиталов. В одном таком случае инвестиционный банк использовал для оценки исходных данных семантическую модель на основе правил, использующую спецификацию Common Warehouse Modelорганизации Object Management Group (OMG).

Плохие данные могут быть хорошими

Большие данные в Hadoop могут содержать разнообразную информацию и анализироваться по-разному. Та же логика может быть применима и к “плохим данным”, которые в обычных терминах описываются как посторонние, неполные или просто неверные. Вопрос, почему данные могут попасть в категорию плохих, может принести столько же пользы, как и анализ заведомо верных данных из “комфортной зоны”. Это инверсия анализа периодических колебаний корректных данных. Когда плохих данных накапливается достаточно много, появляется почва для проверки трендов: не отклонились ли от заданных значений какие-либо компоненты системы или узлы инфраструктуры, и не изменились ли критерии, по которым условия их работы классифицируются как “нормальные”. Например, показатели средней дневной температуры испытывают периодические перепады, подобно изменению уровня моря. Подобные подходы могут применяться и к читаемым людьми данным, где воспринимаемая часть отражает недостатки предположения о смысле информации, подобно тому, как это происходит при проведении поведенческого анализа. В Hadoop плохие данные могут оказаться полезными.