Сэмплирование данных

Материализованные представления ускоряют вопросы, которые знаешь заранее. Но аналитик часто задаёт новый вопрос: какая доля пользователей iOS ищет еду после десяти вечера? Готовых итогов под такой вопрос нет, а сырых событий миллиарды. Если ответ «примерно 12%» устраивает так же, как «12,37%», можно посчитать его по малой доле данных.

Ложка супа

Повар не съедает всю кастрюлю, чтобы понять, хватает ли соли. Он помешивает и пробует ложку. Ложка маленькая, но если суп перемешан, она честно говорит о вкусе всей кастрюли.

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

Ключ сэмплирования

Чтобы выборка была честной и повторяемой, ClickHouse выбирает строки не наугад, а по ключу сэмплирования. Его задают при создании таблицы, и он обязан входить в ключ сортировки:

CREATE TABLE events_sampled (...)
ENGINE = MergeTree
ORDER BY (intHash32(user_id), ts)
SAMPLE BY intHash32(user_id);

intHash32(user_id) превращает номер пользователя в псевдослучайное число от 0 до 4 миллиардов. SAMPLE 0.1 в запросе означает: возьми строки, у которых это число попадает в первые 10% диапазона.

Почему хеш пользователя, а не просто номер строки? Потому что тогда в выборку попадают все события выбранных пользователей. Ответы про поведение пользователей (сколько раз открывал, дошёл ли до оплаты) остаются честными. Если бы выборка брала случайные события, у пользователя мог оказаться заказ без поиска, и воронка развалилась бы. И ещё: одно и то же число даёт одну и ту же выборку при каждом запуске, ответ не прыгает.