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

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

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

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

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

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


hadoop hive apache-pig
person user699324    schedule 08.04.2011    source источник

Ответы (2)


arrow_upward
0
arrow_downward

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

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

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

person Dean Wampler    schedule 09.04.2011
comment
Спасибо, Дин. Например, для таких систем, как Hadoop, я хочу иметь возможность определять запросы MapReduce для выполнения анализа таких наборов данных. Однако обновление записей в файлах в HDFS не представляется возможным. Постоянная передача больших объемов данных в файлы HDFS также не кажется эффективной. HBase — единственный ответ для Hadoop? - person user699324; 14.04.2011

arrow_upward
0
arrow_downward

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

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

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

person Justin Swanhart    schedule 08.05.2011