Все, я пытаюсь найти наиболее эффективный способ хранения данных в моей таблице Hive, который позволяет механизму запросов наилучшим образом использовать фильтры Блума и индекс хранилища.В этой таблице миллиарды строк, и она разбита на лучшее, что мы можем на данный момент
У меня есть таблица ORC Hive с фильтром Блума, определенным в поле customer_id со структурой ниже высокого уровня
Таблица Имя Транзакции Поля customer_id.,,180 + столбцы
Разделены на бизнес-единицы
Чтобы наилучшим образом использовать фильтр Блума и индекс хранения ORC, я хочу, чтобы данные в таблице сохранялись в файлах, где каждый файл содержиттолько определенный инкрементный набор customer_ids и все эти записи упорядочены по customer_id
Существует также промежуточная таблица с той же структурой, но без какого-либо разбиения или упорядочения, которую можно использовать в качестве источника для загрузки этой таблицы.
Я нашел способ сделать это, но перекос данных отбрасывает мой запрос и заставляет его выполняться в течение долгого времени.Допустим, я хочу разделить свои идентификаторы на 127 сегментов
Вот мой псевдопросмотр
-- getting the range of id's which i will use later to create a bucket for each id
with customer_id_range as (
select max(customer_id) - min(customer_id) as range_customer_id,
business_unit
from transactions_staging
group by business_unit
)
select t.* from transactions t
inner join customer_id_range cr on t.business_unit = cr.business_unit
distribute by floor(t.customer_id / ( cr.range_customer_id / 127))
sort by customer_id
В конце мои данные распределяются по 127 редукторам для сохранения вывода в 127 файлах икаждый файл будет иметь непересекающийся набор идентификаторов клиентов и отсортирован в каждом файле.Таким образом, если запрос приходит с идентификатором клиента или для целей объединения, он может наилучшим образом использовать индексы и фильтры Блога ORC Storage
Все хорошо, как я думал, как бы там ни было огромный перекос данных в этой таблицеоснованный на customer_id.Таким образом, запрос застревает на нескольких редукторах на несколько часов до его завершения.Он распределяет много строк в эти редукторы, потому что в таблице непропорционально большое количество строк с определенными диапазонами customer_id
Есть ли другой способ достичь того, чего я пытаюсь достичь?Как я могу обрабатывать данные более эффективно?