Как бороться с таблицей данных BIG DATA/Fact Table? (240 миллионов строк)

Question

У нас есть клиент BI, который каждый месяц генерирует около 40 миллионов строк в своих таблицах базы данных продаж, созданных в результате их транзакций продаж. Они хотят построить Sales Data Mart со своими историческими данными за 5 лет, что означает, что эта таблица фактов будет иметь около 240 миллионов строк. (40 х 12 месяцев х 5 лет)

Это хорошо структурированные данные.

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

Это взяло меня, чтобы взглянуть на Hadoop, но после прочтения некоторых статей я пришел к выводу, что Hadoop не самый лучший вариант (даже с Hive) для создания таблицы фактов, поскольку в моем понимании подразумевается работа с неструктурированными данные.

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

Answer 1

Вы можете рассмотреть упакованное решение NoSQL/Analysis, такое как DataStax Enterprise, в котором используется Apache Cassandra в паре с Hadoop и другими полезными инструментами анализа. Вы правы, что файловая система HDFS от Hadoop хорошо подходит для неструктурированных данных, но интеграция с хранилищем данных NoSQL (например, Cassandra или HBase) позволит вам более легко анализировать ваши структурированные данные с помощью MapReduce.

Answer 2

hadoop абсолютно подходит для таких больших данных. Вы можете использовать его с hbase, что позволяет нам расширяться до миллионов строк и миллиардов столбцов, а также обеспечивает отличную горизонтальную масштабируемость ... это подходит для случайных случайных читайте доступ на запись ... с другой стороны, улей хорош для пакетной обработки, поэтому вы можете запускать задания на улей на заднем плане для других задач. Мы не должны ошибаться в качестве альтернативы традиционным РСУБД, но это действительно полезно при работе с огромными наборы данных. Вы можете использовать другой проект apache «sqoop», который позволяет нам без особых проблем импортировать нашу базу данных из существующих баз данных в кластер hadoop.

Answer 3

сначала я буду считать его 240 м не 2400 м.

Во-первых, посмотрите на ssd.analytical-labs.com

Демонстрационная ФКК таблицу фактов в 150m записи, работающие на Infobright, я подозреваю, что на VW было бы еще быстрее.

Ключ в том, что он прост, возникнут вопросы, которые заставляют его падать медленнее, но при этом очень приятно реагировать.

Я предлагаю вам подумать об агрегатах, о том, как вы запрашиваете и что важно, что вы запрашиваете.

Например, разделите его на Martes на производительность, по продукту, по марке, по годам и т. Д. Если пользователь хочет просто сделать запрос на < данных за 1 год (что чаще встречается в большинстве случаев хотелось бы думать), они могли бы использовать гораздо меньшую таблицу фактов.

Хранение является чистым, поэтому неважно, если вы дублируете данные, если они сохраняют его отзывчивость.

Конечно, если вы работаете с OLAP, вы можете использовать встроенные таблицы агрегатов, чтобы убедиться, что большинство запросов работают на гораздо более приемлемом уровне при условии, что они свернули.

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

Дизайн схемы также важен, современные базы данных хранилища столбцов предпочитают, по возможности, денормализованную таблицу с 0 соединениями, которые я нашел в прошлом, имея 1 денормализованную таблицу для 90% запросов, а затем несколько таблиц соединения (date dim например) для особых случаев учитывается для большинства случаев использования.

В любом случае это мои 2 цента. Пинг меня на твиттере, если вы хотите скайп об этом или что-то в этом роде.

Том

Edit:

Кроме того, здесь это не научная репер, чтобы поддержать то, что JVD говорил:

• твердотельный накопитель на физической коробке: 175,67 Мб/сек
• шата на физический ящик: 113,52 МБ/с
• ec2: 75,65 МБ/с
• ec2 ebs raid: 89.36 MB/s ec

Как вы можете видеть, существует большая разница в скорости чтения.

Answer 4

Еще одна комбинация технологий, которые я успешно использовал для очень большого хранилища данных - Hadoop + Hive. Данные обрабатывались с использованием Map/Reduce jobs и представлялись Hive в качестве внешних таблиц. Обновления выполнялись путем замены разделов между площадками и хранилищами данных.

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

Answer 5

Я думаю, что есть несколько подходов здесь,

1) Вы должны попробовать агрегированные таблицы на Мондриане, недостаток таблиц AGG является то, что вам нужно знать заранее прецеденты для большинства повторяющихся запросов, если вы не тогда это не так просто настроить, и у вас будет длительное время отклика для запросов, которые вы не оптимизировали таблицу агрегатов.

2) Еще один вариант - разбить данные таблицы фактов, возможно, на год, создать разные схемы для каждого года и виртуальный куб на протяжении всей истории. Если у вас есть правильное программное обеспечение, вы также можете создать материализованное представление (если у вас есть Oracle) или индексированный вид, если у вас есть MS SqlServer.

Поздний подход работал очень хорошо для меня, с заметными улучшениями в запросах. Кроме того, мой ETL-процесс не был затронут (в опции 1 вам нужно будет создать дополнительный процесс для создания и обслуживания таблиц агрегации), поскольку RDMBS заботится о процессе обновления данных на каждом разделе.

Answer 6

Вы проверили Google BigQuery (Paid Premium Service), который подойдет вашим потребностям.Это просто, как

1. Загрузите данные в CSV (с разделителем на новую строку для записи или настраиваемый символ для поля). Файл может быть в формате gzip. Вы также можете добавить существующую таблицу.

2. Начать запрос с использованием оператора SQL (ограниченный оператор sql), а результаты возвращаются в секундах многомиллионных строк.

3. Извлечение данных в CSV или другую таблицу (по аналогии с уровнем агрегации)

Проверьте здесь. https://developers.google.com/bigquery/

Первый 100GB для обработки данных является бесплатным. Таким образом, вы можете начать работу, а также интегрироваться с Google Spreadsheet, что позволит вам создавать визуализацию, такую ​​как диаграммы и графики и т. Д. Для управления. Вы можете экспортировать электронную таблицу Google как Microsoft Excel/PDF.

Состояние Google может масштабироваться до нескольких терабайтов и обеспечивает запрос в реальном времени (несколько секунд ответа).