Comments 9
Возможно, покажусь занудой, но мне в статье сильно не хватило конкретики.
Всевозможные "наши данные" и "наша аналитика", а можно пример? Как выглядит классический аналитический отчет, классический сценарий использования?
Данные, которые собираем "на всякий случай" - можно пример? Клики по кнопке "показать еще", или время сессии. Какого рода данные? Очень хочется знать, какой природы данные кликхаус из 15ТБ превратит в 4 (опыт-то уникальный!).
Опять же "недокументированные особенности которые приводили к потерям данных в краевых случаях" - можно пример, что является "краевым случаем".
Да, я видел схему, но там маловато информации... "Приходилось писать по 20 тысяч записей в минуту" может значить все что угодно. Я один раз отправил суммарно 1 ТБ данных с 20к машин по сети (в течение часа), которые принимались всего на 16-и серверах. Это положило свежесть данных для аналитики на неделю, но потом все доехало и нормально живет. В вашем случае 20к записей - это сколько в объеме, пики грозят задержкой в аналитике или потерями данных, во что упиралась производительность, если были проблемы? Какие (если есть) проблемы остались после перехода на CH?
Резюмируя: судя по всему вы обладатели некоего уникального опыта: вы можете сравнить две системы обработки данных на реальном и очень крупном проекте. С нетерпением жду нового, более детального рассказа о технической составляющей.
В основном мы работаем с данными продаж, которые позволяют сегментировать типы совершенных заказов, а так же click stream, все действия пользователей на сайте (клики, заходы на страницы, какие-то действия в интерфейсе) по которым в основном анализируются воронки посещаемость отдельных проектов. click stream в целом приметивен это как правило документ из нескольких полей обязательными там: имя события (с очень низкой кардинальностью, т.е. много событий которые имеют малое кол-во уникальных значений), время события на устройстве пользователя и идентификатор пользователя UUID, есть еще несколько технических обязательных параметров, но не думаю что это важно + все события имеют несколько сотен возможных параметров, по сути если это представить в виде таблички это очень широкая табличка с большим кол-вом колонок. Clickhouse очень хорошо жмет данные если вы их храните ввиде колонок скалярных типов (не используя массивы, структуры типа nested, строки с json и пр.)
Один из примеров потери данных - в некоторых случая мы замечали что при чтении данных из kafka терялись данные и не доходили до таблички.
На другие вопросы чуть позже отвечу
Как обещал отвечаю на оставшиеся вопросы (-:
ElasticSearch у нас использовался только для хранения информации о действиях пользователей (clickstream), в случае текущего кластера clickhouse - это уже data lake для хранения, обработки и объединения данных из всех источников, тут поток данных расширился сильно. Если вопрос про инсталляцию того ElasticSearch, то у нас средний размер записей около 400 байт на запись (размер уже в хранилище с некоторым коэффициентом сжатия).
Про решение проблем с пиками и скоростью разбора этих пиков это скорее уже тема для след. статьи про это мы тоже напишем в ближайшее время. Но сейчас кратко могу ответить что в целом проблему с пиками мы не испытывали и доставляли данные с задержкой до 2-ух минут. Зачет запись данных в хранилище пачками по несколько тысяч. До хранилища ранее у нас стоял redis где копились данные, сейчас мы перешли в большинстве мест на kafka, как накопительный буфер.
После перехода на CH у нас добавилось работы по поддержке этого хранилища, по крайней мере на текущем этапе, но это возможно из за того что запросов к хранилищу стало больше, но при этом задачи решаются быстрее, ранее аналитики выгружали куски данных в python + pandas и крутили уже сегменты данных в памяти, для 95% задач этого достаточно, но не удобно для использования. В целом мы ставили задачи которые решили переходом: повысить удобство использования хранилища аналитиками, эффективнее использовать ресурсы хранилища, уменьшить кол-во задач где аналитику приходится всю обработку данных строить на pandas и без использования BI инструментов.
До хранилища ранее у нас стоял redis где копились данные
Какой-нибудь журнал на случай отключения до дампа данных?
Про решение проблем с пиками и скоростью разбора этих пиков это скорее уже тема для след. статьи
Ну, тут каждый ответ - тема для статьи. Я про это и пытался сказать: уверен, там под капотом клондайк.
ранее аналитики выгружали куски данных в python + pandas
Сейчас вы сделали для них промежуточный интерфейс, или это превратилось в python + SQL?
таблички это очень широкая табличка с большим кол-вом колонок
Тут скорее вопрос был про содержание данных: много ли числовых полей и т.п. Судя по описанию - большая часть данных - enum-ы и числовые значения, преимущественно из ограниченного диапазона, верно?
Вцелом, я не думаю, что стоит продолжать разбор здесь: жду новых статей с интересными техническими деталями %)
И спасибо за ответы!
Какой-нибудь журнал на случай отключения до дампа данных?
Не понял вопроса, но думаю имеется ввиду "отключения для дампа", это отдельно рассмотрим в другой статье. Скорее стык между окружением с low latency и окружением которое может работать медленно потому что идет обслуживание или к нам вышел новый аналитики который по незнанию приложил хранилище )
Сейчас вы сделали для них промежуточный интерфейс, или это превратилось в python + SQL?
Многие запросы теперь не требуют написания python кода, но к сожалению пока нам удалось не везде исключить использование python, но мы работаем над этим. Исключить использование python конечно не цель, но продуктивнее когда аналитику не приходиться писать python код на любой чих.
Тут скорее вопрос был про содержание данных: много ли числовых полей и т.п. Судя по описанию - большая часть данных - enum-ы и числовые значения, преимущественно из ограниченного диапазона, верно?
Большинство enum + числа, но много datetime и основной прожорливый тип это конечно UUID, но в clickhouse для его хранения есть тоже достаточно эффективный тип колонок UUID.
>> Вам придётся приложить немало усилий, чтобы понять как эффективно применить ClickHouse для ваших задач
Altinity?
Про этих ребят знаем, если оглядываться назад, то в целом обратиться за поддержкой было бы разумным решением, но в моменте это был не беклог проблем, а итеративно появляющиеся, после каждой новой итерации и они все интереснее и интереснее. У нас очень динамично растет спрос на данных в этом хранилище. Так же нужно понимать что любая подобная поддержка с SLA в несколько дней и не всегда такого же качества как собственная экспертиза, мы отправляли запрос в altinity именно по части обучения уровня DBA наших ребят, но в тот момент такой услуги у них не было.
Но даже сейчас мы думаем о том чтобы воспользоваться консультацией по некоторым вопросам и возможно мы воспользуемся их услугами.
Если речь про cloud решения которые делает altinity, то тут исследований не проводили, мы пробовали использовать яндекс.облако и нам не понравилась эксплуатация этого решения, когда речь коснулась мониторинга и траблшутинга некоторых проблем, но возможно на текущий момент ситуация изменилась. Но как быстрый старт - это отличное решение!
>>> Если бы мы могли сформулировать заранее требования к хранению данных и их использованию точно — то наверняка взяли бы Vertica или продолжили использовать Exasol.
Оглядываясь назад - как удачно выбрано решение! ) Не пришлось замещаться )
ClickHouse: Путь джедая, искавшего дом для своих данных