Какой должна быть моя стратегия разделения улья и стратегия просмотра, чтобы запрос мог эффективно выполняться и возвращать результаты в течение 10 секунд

Question

Мой пример использования: у меня есть два источника данных: 1. Source1 (как скоростной слой) 2. Улей внешний стол сверху S3 (как пакетный слой)

Я использую Presto для запроса данных из обоих источников, используя представление. Я хочу создать представление, которое будет объединять данные из обоих источников, например: "создать тест представления как выбрать * из Source1.table union all select * from hive.table"

Мы храним данные за 24 часа в Source1, и через 24 часа эти данные будут перенесены в s3 через улей.

Столбцы для таблиц Source1: timestamp, logtype, company, category

Пользователь будет запрашивать данные, используя диапазон отметок времени (может запрашивать данные за последние 15/30 минут, последние x часов, последние x дней, последние x месяцев и т. Д.) пример: "выбрать * из теста, где отметка времени> (now () - интервал '15' минута)", "выбрать * из теста, где отметка времени> (now () - интервал '12' часа)", "выбрать * из теста, где отметка времени> (now () - интервал '1' day) "

Чтобы удовлетворить пользовательский запрос, мне нужно разделить таблицу кустов, а также пользователь не должен знать о лежащем в основе состоянии, т. Е. Если пользователь запрашивает данные последних минут , ему / ей не следует беспокоиться что если presto читает данные из Source1 или куста.

Какой должна быть моя стратегия разделения улья и стратегия просмотра, чтобы запрос мог эффективно выполняться и возвращать результаты в течение 10 секунд?

Answer 1

Для улья следует использовать столбец раздела, который запрашивается в фильтре.
В вашем случае это метка времени.Однако, если вы используете метку времени, она будет создавать раздел для каждой секунды (или миллисекунды) в зависимости от данных в столбце.
Лучшим решением будет создание столбцов, таких как year, month, day, hour (из отметки времени) и использовать их в качестве столбцов разделов.

Та же стратегия будет работать для Kudu, однако следует помнить, что она может создать горячую точку, поскольку все вновь поступающие записи будут идти к одному и тому же (самые последние) это ограничит производительность вставки (и может быть запросом).
Для преодоления используйте один дополнительный столбец в качестве хеш-раздела вместе со столбцами, производными от метки времени.
Например, year, month, day, hour, logtype