Выполнение аналитических запросов на больших динамических наборах данных

Question

У меня есть требование, когда у меня есть большие наборы входящих данных в систему, которой я владею.

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

Требования следующие:

1. Большие наборы данных могут испытывать изменения состояния.Обновления должны быть быстрыми.
2. Я должен быть в состоянии агрегировать данные, объединенные по различным атрибутам.
3. В идеале - должен быть способ соотнести отдельные блоки данных с агрегированными результатами, т.е. я хочу углубиться в конкретные транзакции, которые привели к определенной агрегации.(Я знаю об условиях гонки здесь, таких как состояние блока данных, изменяющегося после выполнения агрегации; но это ожидается).
4. Все агрегации основаны на времени - то есть сумма x на оси y за день, 2 дня, неделю, месяц и т. Д.

Я оцениваю различные технологии для удовлетворения этих случаеви хотел бы услышать ваши предложения.Я взглянул на Hive / Pig, который подходит для случая использования аналитики / агрегации.Однако меня беспокоят большие всплески обновлений, которые могут появиться в системе в любое время.Я не уверен, как это работает с файлами HDFS по сравнению с индексированной базой данных (sql или nosql).

Answer 1

Вы можете рассмотреть возможность просмотра Flexviews . Он поддерживает создание постепенно обновляемых материализованных представлений для MySQL. Материализованное представление похоже на снимок запроса, который периодически обновляется с измененными данными. Вы можете использовать материализованные представления для суммирования нескольких атрибутов в разных сводных таблицах и поддерживать эти представления в транзакционном соответствии друг с другом. Вы можете найти несколько слайдов с описанием функций на slideshare.net

Существует также Shard-Query , который можно использовать в сочетании с разделами InnoDB и MySQL, а также с поддержкой распространения данных по многим машинам. Это удовлетворит как высокие скорости обновления, так и обеспечит параллелизм запросов для быстрой агрегации.

Конечно, вы можете объединить их вместе.

Answer 2

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

Это особый случай персистентной стратегии, называемой Multiversion Concurrency Control - MVCC. Исходя из вашего описания, MVCC, вероятно, является наиболее важной базовой стратегией для вас для выполнения запросов на определенный момент времени и получения согласованной информации о состоянии, даже когда обновления происходят одновременно.

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