разработка схемы данных временных рядов для Google Bigtable или любого предложения Google

Question

Я работаю над проектом, в котором мне приходится ежедневно хранить события, связанные с пользовательской активностью, для последующего анализа. Я буду получать поток событий с метками времени, а позже буду запускать задания потока данных на этих данных для аналитики, чтобы получить статистику по пользователям. Я изучаю большую таблицу для хранения этих данных, где отметка времени будет выступать в качестве ключа для каждой строки, позже я выполню запрос диапазона, чтобы получить данные за один день и обработать их. Но после просмотра нескольких ресурсов выяснилось, что при использовании ключей строк с метками времени большая таблица может попасть в горячую точку проблема . Невозможно продвинуть ID пользователя как ключ в ключе строки, чтобы избежать этого. Любой альтернативный подход к решению этого или любого другого механизма хранения, который может помочь в этом случае использования.

вариант использования: вариант использования заключается в том, что у меня есть данные об активности пользователя, такие как показы и клики в потоках. Основываясь на правилах, я должен собирать данные из этих потоков в течение определенного периода времени, сохранять их и обслуживать как можно скорее для восходящего сервиса. Данные будут обрабатываться в режиме переворачивающегося окна по состоянию на 24 часа, но могут увеличиваться или уменьшаться. Выбор, который я должен сделать, заключается в том, как хранить необработанные события (большой запрос или большой запрос или прямой анализ потоков), вычислительный механизм (запросы лучей или агрегации) и окончательное хранение (на основе идентификатора пользователя). Отношение ч / б пользователя и агрегированных данных одно к многим.

Answer 1

Если вам необходимо хранить большие объемы данных и иметь их в наличии по метке времени или дате для последующего анализа, вам следует использовать BigQuery вместо BigTable.

BigQuery предлагает возможность разбивать таблицы по временным меткам / датам .

Каждый раздел в секционированной таблице даты / времени можно рассматривать как диапазон где начало диапазона - начало дня, а интервал диапазона - один день. Для секционированных таблиц даты / времени не требуется псевдостолбец _PARTITIONTIME. Запросы к разделенным таблицам даты / времени могут указывать фильтры предикатов на основе столбца разделения, чтобы уменьшить объем проверенных данных.

Answer 2

Учитывая, что вы не можете получить доступ к идентификатору пользователя во время запроса, вам придется где-то сделать компромисс. Похоже, что вы будете делать больше записей, чем читать здесь, потому что вы пишете данные в течение дня для каждого пользователя, а затем выполняете только чтение, возможно, один раз в день для анализа данных? Поправь меня, если моя интерпретация неверна.

Я бы сказал, что хорошо, если сканирование в задании потока данных не так эффективно, чтобы избежать горячих точек для записи.

Вы можете повысить идентификатор пользователя в вашем ключе строки до чего-то подобного userid#date, а затем выполнить сканирование с помощью фильтра регулярных выражений rowkey, который действительно ищет *#YOUR_DATE.

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

Не стесняйтесь предоставлять больше информации о вашем конвейере и ожидаемом случае использования базы данных, если мои предположения не соответствуют вашим целям.