Наука о данных - Брендан Тирни

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

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

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

Мир гибридных баз данных

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

В мире гибридных баз все данные связаны между собой и работают вместе, что позволяет эффективно обмениваться ими, обрабатывать и анализировать их. На рис. 8 показано традиционное хранилище данных, но при этом большая часть данных находится не в базе или хранилище, а перемещена в Hadoop. Между базой данных и Hadoop создается соединение, которое позволяет специалисту запрашивать данные, как если бы они находились в одном месте. Ему не потребуется запрашивать отдельно данные из базы и из Hadoop. Гибридная база автоматически определит, какие части запроса необходимо выполнить в каждом из местоположений, затем объединит результаты и представит их специалисту. Точно так же по мере роста хранилища часть данных устаревает, и гибридное решение автоматически перемещает редко используемые данные в среду Hadoop, а те, что становятся востребованными, наоборот, возвращает обратно. Гибридная база данных сама определяет местоположение данных на основе частоты запросов и типа проводимого анализа.

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

Интеграция данных включает в себя их получение из разных источников и последующее объединение с целью получения единого представления данных по всей организации. Разберем это на примере медицинской карты. В идеале у каждого человека должна быть одна медицинская карта, чтобы каждая больница, поликлиника и врач могли использовать один и тот же идентификатор пациента, единицы измерения, систему оценок и т. д. К сожалению, почти в каждой больнице имеется собственная независимая система учета пациентов и то же справедливо в отношении внутрибольничных медицинских лабораторий. Представьте себе, как трудно бывает найти историю болезни и назначить правильное лечение пациенту. Такие проблемы возникают в рамках одной больницы. Когда же несколько больниц обмениваются данными пациентов, проблемы их интеграции становятся еще существеннее. Именно поэтому первые три этапа CRISP-DM занимают до 70–80 % общего времени проекта, причем бо́льшая часть этого времени уходит на интеграцию данных.

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

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

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