Статьи / Большие данные или хранилище данных: что выбрать?

16.07.2018 г., перевод статьи Vincent Rainardi

Предположим, что у нас есть 100 файлов, каждый из которых содержит 10 миллионов строк, и нам нужно загрузить их в репозиторий для того, чтобы мы могли проанализировать данные. Как лучше всего поступить? Воспользоваться Hadoop (HDFS) или реляционной СУБД (RDBMS)?

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

Рассмотрим 4 фактора:

Структура данных.
Объем данных.
Неструктурированные данные.
Schema-on-Read (схема при чтении).

1. Структура данных: простая или сложная

Если все 100 файлов имеют одинаковую структуру, например, все они состоят из одних и тех же 10 столбцов, то лучше поместить их в Hadoop. Затем мы сможем использовать Hive, Spark, Presto, R или Python * для анализа данных – например, для поиска закономерностей в данных, выполнения статистического анализа или создания прогнозов. Время разработки будет короче, потому что это только 1 слой.
* или Phoenix, Impala, BigSQL, Stinger, Drill

Если 100 файлов содержат 100 разных таблиц, лучше поместить их в базу данных, создать хранилище данных и использовать аналитический BI-инструмент, такой как Pentaho или MicroStrategy * для анализа данных. Например, чтобы получить срезы данных, найти процент или аномалии и провести анализ временных рядов. Да, нам будет необходимо создать 3 слоя (staging, 3NF, star schema), но это позволит анализировать каждый показатель по различным параметрам.
* или Looker, PowerBI, Tableau, QlikView, BusinessObjects, Cognos BI, Birt, Pentaho, Roambi, SAS, Sisense или другие инструменты BI

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

Используя Hadoop и Hive/Spark/Presto, мы также можем получить срезы данных, вычислить процент или аномалии, провести анализ временных рядов. Используя хранилище данных, мы можем выполнять машинное обучение и интеллектуальный анализ данных для поиска в них закономерностей, статистический анализ и создавать прогнозы. Таким образом, независимо от того, где мы храним данные – в Hadoop или в хранилище данных, мы все равно можем провести полный анализ.

Проблема заключается в хранении. Связывание 100 таблиц в Hadoop – сложно и неестественно. РСУБД, такие как SQL Server или Oracle, предназначены именно для этой задачи: связывания и объединения таблиц. Построение модели данных, связывающей 100 таблиц, очень подходит для РСУБД. Можем ли мы спроектировать модель данных, связывающую 100 файлов с различными структурами в Hadoop? Конечно, мы можем это сделать. Но это гораздо сложнее. Во-первых, это Schema-on-Read, поэтому столбцы в файлах не имеют типов данных. Schema-on-Read означает, что мы не пытаемся определить взаимосвязь между файлами при их загрузке в Hadoop. Так что да, мы можем загрузить 100 файлов в Hadoop, но мы сохраняем их как отдельные файлы, без связей между ними. То же самое происходит и в Data Lake, где также используется Schema-on-Read и HDFS.

2. Объем данных: маленький или большой

100 файлов, содержащих 10 миллионов строк каждый, составляют 1 миллиард строк в день. Если все 100 файлов имеют одинаковую структуру (скажем, все они состоят из одних тех же 10 столбцов), то у нас будет проблема с производительностью при загрузке их в базу данных SMP, например, SQL Server или Oracle. Всего за 3 года эта таблица разрастется до 1 триллиона строк и даже при секционировании и индексировании запрос будет выполняться медленно.

С другой стороны, при использовании Hadoop не будет проблем с хранением 1 триллиона строк и запросами к ним. Он предназначен именно для задач, связанных с хранением данных во множестве файлов и одновременной работы с ними с помощью Stinger, Drill, Phoenix, Impala или Spark.

Redshift, Azure SQL Data Warehouse, Exadata, Teradata, Greenplum и Netezza способны с легкостью справиться с этим, обладая отличной производительностью запросов. Однако MPP обходится дороже, чем Hadoop, поэтому компании предпочитают Hadoop для решения этой задачи. Использование MPP в этом случае похоже на стрельбу из пушки по воробьям. Это не только дорого и излишне, но и слишком громоздко.

Если 100 исходных файлов имеют сложную структуру (например, экспортированные данные из системы SAP), то да, MPP является подходящим решением, поскольку нам нужно создать связь между файлами/таблицами. Но если исходные файлы имеют простую структуру и нам просто нужно их объединить, то Hadoop для решения этой задачи более экономичен и подходит гораздо лучше.

Таким образом, если объем данных большой, например, 1 миллиард в день, а структура данных простая – поместите их в Hadoop. А если объем данных большой, а структура данных сложная – поместите их в MPP.

3. Неструктурированные данные

Если большинство из этих 100 исходных файлов – MP4 (видео) или MP3 (музыка), то Hadoop или Data Lake – идеальная платформа для их хранения. РСУБД, будь то SMP или MPP, не предназначены для хранения видео или музыкальных файлов. Они могут это делать (как blob, или как внешние файлы), но они созданы не для этого.

То же самое можно сказать, если исходные файлы имеют разное количество атрибутов (например, файлы Facebook или Twitter). Оптимальная платформа для хранения – Data Lake или Hadoop, РСУБД – предназначена для других целей.

Неструктурированные данные могут также поступать в виде текстовых файлов свободного формата, таких как электронные письма или документы (например, журналы и патенты). Опять же, Hadoop или Data Lake гораздо лучше подходят для их хранения, чем РСУБД. Но еще лучше для этого подойдут документоориентированные СУБД, такие как MongoDB, AWS DynamoDB или Azure CosmosDB.

4. Schema-on-Read (схема при чтении)

Одним из преимуществ использования Hadoop или Data Lake является то, что они используют Schema-on-Read. Это означает, что мы просто храним эти файлы, не определяя, являются ли столбцы числовыми или строковыми. Только когда нам понадобится сделать запрос, нужно будет указать тип данных.

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

Hadoop же – это Schema-on-Read. После того, как мы поместили эти 100 файлов в Hadoop, мы запрашиваем первый файл. И когда мы запрашиваем этот первый файл, мы указываем типы данных каждого столбца. Нам пока не нужно трогать остальные 99 файлов. Таким образом – уже есть какая-то выгода. Мы можем проанализировать данные сразу. В первый же день. Если другие 99 файлов имеют такую же структуру, то мы можем объединить их (без дополнительных усилий по разработке базы данных) и сразу же их запросить. Это гораздо проще: нам не нужна команда из 10 человек, разрабатывающая промежуточный, нормализованный или отчетный слой в течение многих месяцев. Мы можем сразу же приступить к анализу данных, и проект смогут завершить всего 3-4 человека в течение 2-3 месяцев. Намного дешевле, намного быстрее и намного гибче.

Заключение

Итак, мы рассмотрели 4 фактора при выборе между реализацией больших данных или хранилищем данных: структуру данных, объем данных, неструктурированные данные и Schema-on-Read (схема при чтении).