Comments 28
Как впечатления от Tableau? Что можете подобного посоветовать?
Сейчас столкнулся с подобным кейсом когда GA слишком мало.
Есть внутренняя система распределения ads трафика (2кк юзеров в сутки, около 10кк событий), все хранится в ClickhouseDB. Пока были тугие попытки написать свой интерфейс отчетов, но хотелось бы чего-то гибкого и приятного вместо велосипедов.
Сейчас столкнулся с подобным кейсом когда GA слишком мало.
Есть внутренняя система распределения ads трафика (2кк юзеров в сутки, около 10кк событий), все хранится в ClickhouseDB. Пока были тугие попытки написать свой интерфейс отчетов, но хотелось бы чего-то гибкого и приятного вместо велосипедов.
PowerBI как альтернатива. Интересно есть ли open source аналоги…
Посмотрите metabase, пока это лучше что нашёл из open-source.
Есть, но разной степени open sourceсности и степени готовности. Есть kibana, симпатичная, но не хочет работать без elastiса. Есть занятный SuperSet от Airbnb, который гордо именует себя версией 0.26, что включает режим паранои на максимум и желание загружать это в продакшн стремительно тает. Если у вас cloudera, то там еще есть Hue dashboards, который работает с Solr Search. Это как эластик, только все на xml.
А можно очень сильно упороться и генерировать html/excel отчеты в pandas/R/shiny/plotly. Последний обладает очень смешной open source версией, выкатывая ваш BI во внейшний мир, будьте осторожны. Так что варианты вроде бы и есть, но у каждого есть свои недостатки :)
А можно очень сильно упороться и генерировать html/excel отчеты в pandas/R/shiny/plotly. Последний обладает очень смешной open source версией, выкатывая ваш BI во внейшний мир, будьте осторожны. Так что варианты вроде бы и есть, но у каждого есть свои недостатки :)
Не увидел сильного преимущества суперсета перед той же графаной. Может плохо искал?
Что-то в этом треде все в одну кучу смешали, grafana, kibana, metabase… Это все же инструменты под разные задачи, как мне кажется.
Очень сильно зависит от того, что для вас является преимуществом, а что недостатком. У нас кластер на cloudera и тащить туда или ставить отдельно elastic для kibana как-то не хочется. Суперсет подключается к любой базе данных и друиду, который в том же hortonworks можно поднять двумя кликами (впечатления коллег, сам не пробовал).
У суперсета мне нравится интеграция с Уберовским deck.gl и красивыми карточными визуализациями, но в вашем случае это может быть нерелеватно.
В общем «зависит».
Ну и дело вкуса, вам (вашему менеджеру) просто визуально могут нравиться больше те или иные графы :)
п.с. забыл еще о Zeppelin
У суперсета мне нравится интеграция с Уберовским deck.gl и красивыми карточными визуализациями, но в вашем случае это может быть нерелеватно.
В общем «зависит».
Ну и дело вкуса, вам (вашему менеджеру) просто визуально могут нравиться больше те или иные графы :)
п.с. забыл еще о Zeppelin
Ну, Графана в теории тоже подцепляется к любой БД. Суперсет, конечно, из коробки выглядит более серьезным и аналитическим инструментом. Но фактически — визуализации и там, и там богатые, но у графаны, такое ощущение, источников больше (включая различные TSDB).
Касательно друида — вообще сомнительно нужен ли он. Многие Clickhouse используют и не знают проблем.
Касательно друида — вообще сомнительно нужен ли он. Многие Clickhouse используют и не знают проблем.
Внимательно прочитал ваш комментарий, понял что ответил на вопрос, который мне не задавали :)
Графана мне показалась супер штукой (очень шустрый рендер), но я ее воспринимаю в первую очередь как инструмент мониторинга. Посмотрел на доступные плагины и в теории в ней можно сделать все то же самое что и в суперсете, но выглядит это скорее как костыль, чем изначально продуманное решение.
Так что кроме эстетического аспекта, функционально они и правда очень похожи. В конце выбрал бы суперсет, потому что больше пишу на питоне, чем на Java, так что при необходимости что-то допилить напильником, будет чуть легче.
Графана мне показалась супер штукой (очень шустрый рендер), но я ее воспринимаю в первую очередь как инструмент мониторинга. Посмотрел на доступные плагины и в теории в ней можно сделать все то же самое что и в суперсете, но выглядит это скорее как костыль, чем изначально продуманное решение.
Так что кроме эстетического аспекта, функционально они и правда очень похожи. В конце выбрал бы суперсет, потому что больше пишу на питоне, чем на Java, так что при необходимости что-то допилить напильником, будет чуть легче.
Есть еще redash.io. Умеет работать с 23 хранилищами, включая ClickHouse.
metabase, к сожалению, не поддерживет ClickHouse и Apache Cassandra.
metabase, к сожалению, не поддерживет ClickHouse и Apache Cassandra.
Ответ наших аналитиков:
От Tableau приятные впечатление (если вас не смущает цена), выбирали еще в 2013 сравнивая с QlikView. Основным преимущество на тот момент было наличие “Live connection” к Vertica ( -> объем рассчитываемых данных «неограничен»).
Еще из плюсов:
— Может работать как с оперативной памятью локальной машины, так и на сервере
— Имеет низкий порог входа для неподготовленного пользователя
— Красиво выглядит :)
К Clickhouse нативного коннектора не имеет, к сожалению, а будет ли работать по ODBC шустро — вопрос открытый.
От Tableau приятные впечатление (если вас не смущает цена), выбирали еще в 2013 сравнивая с QlikView. Основным преимущество на тот момент было наличие “Live connection” к Vertica ( -> объем рассчитываемых данных «неограничен»).
Еще из плюсов:
— Может работать как с оперативной памятью локальной машины, так и на сервере
— Имеет низкий порог входа для неподготовленного пользователя
— Красиво выглядит :)
К Clickhouse нативного коннектора не имеет, к сожалению, а будет ли работать по ODBC шустро — вопрос открытый.
Так в каком же регионе чаще промахиваются по зеленой кнопке?
При разработке удалось отделить задачу сбору событий из проектов и доставки в хранилище от задачи организации самого хранилища и построения отчётов. В итоге мне как разработчику мало приходилось видеть витрины в Tableau. Но я обязательно поинтересуюсь у аналитиков.
Могу предположить, что в регионах, где солнце ярко в монитор светит, по зелёной кнопке попасть гораздо труднее.
Могу предположить, что в регионах, где солнце ярко в монитор светит, по зелёной кнопке попасть гораздо труднее.
Интересный опыт! Как вы валидируете события и описываете структуру справочника — json schema, xml schema или что-то своё?
Фронтенд справочника — админка. Первичное хранилище конфигураций — постгрес. Json schema не используется. С помощью лангпаков удалось сдвинуть валидацию в проекты. В лангпаках генерируется нативный код, схема там не пригодилась.
Есть интересные случаи: события могут прилетать от фронтендов и других проектов. На нашей стороны для приёма таких событий есть прокси, старающиеся как можно меньше вмешиваться в данные, но умеющие сигнализировать об ошибках. В некоторых интеграциях мы использовали protobuf. Соответственно, пришлось генерировать proto-схему.
Есть интересные случаи: события могут прилетать от фронтендов и других проектов. На нашей стороны для приёма таких событий есть прокси, старающиеся как можно меньше вмешиваться в данные, но умеющие сигнализировать об ошибках. В некоторых интеграциях мы использовали protobuf. Соответственно, пришлось генерировать proto-схему.
Понравилась форма изложения. Кратко, по делу, информативно. Мне бы на то же самое понадобилось несколько статей.
Чуть-чуть вопросов:
Спасибо :)
Чуть-чуть вопросов:
- События только в Vertica лежат, или есть ещё cold storage для старых событий?
- Разные версии одного события приземляются в одну таблицу или в разные?
- Можно ли запустить запрос, затрагивающий несколько событий, и сделать между ними JOIN? Например, построить произвольный funnel (событие А, затем B, затем C или D)?
- Общие для всех событий «заголовки» (окружение, версия приложения, session_id, device_id) хранятся в одной таблице вместе с телом события или лежат отдельно?
Спасибо :)
По вопросам:
1. Есть cold storage с реализованной схемой подгрузки в быструю зону.
2. В Вертике? События раскладываются по множеству таблиц 6НФ. Новые версии попадают в те же таблицы, что и старые, но у новых новые атрибуты летят в новые таблицы. Про это большая статья тут есть, про грибницу: habr.com/company/avito/blog/322510
3. Конечно. Ради этого все и делается. funnel из полудюжины таблиц+данные из платежных систем+результаты прогнозов и результаты рекламных рассылок. Только так и получается нормальная аналитика.
4. Все отдельно. 6 нормальная форма, все описано в статье про грибницу.
1. Есть cold storage с реализованной схемой подгрузки в быструю зону.
2. В Вертике? События раскладываются по множеству таблиц 6НФ. Новые версии попадают в те же таблицы, что и старые, но у новых новые атрибуты летят в новые таблицы. Про это большая статья тут есть, про грибницу: habr.com/company/avito/blog/322510
3. Конечно. Ради этого все и делается. funnel из полудюжины таблиц+данные из платежных систем+результаты прогнозов и результаты рекламных рассылок. Только так и получается нормальная аналитика.
4. Все отдельно. 6 нормальная форма, все описано в статье про грибницу.
О, спасибо. Пропустил оригинальную статью про нормализацию, хоть и слышал об этом голосом. Почитал с удовольствием.
Ещё один вопрос: верно ли, что при таком подходе очень заметно увеличиваются требования к I/O? Ведь нужно намного больше и писать, и читать:
Насколько я помню, Vertica обычно читает HDD на select-запросы, и они конкурируют за ресурсы с ETL. А значит, при честной anchor-модели база намного быстрее упрётся в диски при увеличении нагрузки на том же оборудовании, чем в более «обычных» случаях.
Верно ли это?
Ещё один вопрос: верно ли, что при таком подходе очень заметно увеличиваются требования к I/O? Ведь нужно намного больше и писать, и читать:
- При импорте обязательный lookup на каждый атрибут, чтобы понять, нужно ли создавать новую запись;
- Много дополнительных суррогатных ключей и полей «load_date», которых не было бы в других моделях;
- По две проекции на «ties»-таблицы — храним двойной объём данных;
Насколько я помню, Vertica обычно читает HDD на select-запросы, и они конкурируют за ресурсы с ETL. А значит, при честной anchor-модели база намного быстрее упрётся в диски при увеличении нагрузки на том же оборудовании, чем в более «обычных» случаях.
Верно ли это?
Я бы сказал, что нет, и вот почему. В один год в нашу Вертику прилетает чуть больше 2Пб данных (метрика на кликстриме). И так уже больше 5 лет, а данных в итоге 176Тб в горячем слое + ~300Тб в архивной зоне.
Это происходит из-за логического сжатия: если произошло 10к событий с одного большого URL, мы сохраним его только раз, а дальше будем использовать INT ключ. И так почти со всем: мы добавляем в хранилище только действительно новые данные, только реально изменившиеся поля. Из-за этого записи намного меньше, а чтения — сначала больше, а потом тоже меньше. В реальности почти все запросы упираются не в диск, а в оперативку, в которой кешируются выборки для lookup.
Это происходит из-за логического сжатия: если произошло 10к событий с одного большого URL, мы сохраним его только раз, а дальше будем использовать INT ключ. И так почти со всем: мы добавляем в хранилище только действительно новые данные, только реально изменившиеся поля. Из-за этого записи намного меньше, а чтения — сначала больше, а потом тоже меньше. В реальности почти все запросы упираются не в диск, а в оперативку, в которой кешируются выборки для lookup.
Почему в качестве стореджа дорогущая Vertica, а не бесплатный ClickHouse?
Такими вопросами ведает azathot. Его комментарий:
1. Нет ANSI SQL. Поэтому Tableau с кликхаусом не работает. Обещают уже больше года
2. Нет ANSI SQL в смысле отсутствия нормальных join-ов. Только локальные джойны со словарями, а сджойнить две таблицы по 100 млрд. строк нельзя. Мы джойним десятки таких таблиц.
Т.е. кликхаус для задач ad-hoc аналитики не применим.
1. Нет ANSI SQL. Поэтому Tableau с кликхаусом не работает. Обещают уже больше года
2. Нет ANSI SQL в смысле отсутствия нормальных join-ов. Только локальные джойны со словарями, а сджойнить две таблицы по 100 млрд. строк нельзя. Мы джойним десятки таких таблиц.
Т.е. кликхаус для задач ad-hoc аналитики не применим.
Нет ANSI SQL в смысле отсутствия нормальных join-ов. Только локальные джойны со словарями, а сджойнить две таблицы по 100 млрд. строк нельзя. Мы джойним десятки таких таблиц.
Можно джойнить таблицы. Да, синтаксис у них специфичный, но если надо сджойнить несколько таблиц, ANY LEFT JOIN замечательно с этим справляется.
Конечно можно джойнить таблицы, если правая (словарь) маленькая.
Цитата из официальной документации ClickHouse:
The right table (the subquery result) resides in RAM. If there isn't enough memory, you can't run a JOIN.
И это только первая проблема. Вторая возникает, когда ClickHouse шардирован на несколько таблиц, и нужно сделать JOIN больших таблиц, шардированных по разному (нужна ресегментация данных). Эту проблему можно частично решить конструкцией Global, но только, опять же, для маленьких таблиц.
Цитата из официальной документации ClickHouse:
The right table (the subquery result) resides in RAM. If there isn't enough memory, you can't run a JOIN.
И это только первая проблема. Вторая возникает, когда ClickHouse шардирован на несколько таблиц, и нужно сделать JOIN больших таблиц, шардированных по разному (нужна ресегментация данных). Эту проблему можно частично решить конструкцией Global, но только, опять же, для маленьких таблиц.
Я согласен, что join с «особенностями», меня покоробило «Только локальные джойны со словарями»… Они есть, но да, исполняются в памяти и объединять в запросе несколько таблиц с выборками 100ММ скорее всего не получится, если памяти не очень много… В своих задачах объединял несколько таблиц, примерно таких объёмов: 600М, 50М, 1М, 100К, 10К… Для ускорения использовал 64-битный хеш от идентификатора записи (UUID), потому как он давал единичные коллизии на таких объёмах, что для моих задач допустимо.
Прошу прощения, у меня искаженное представление о нормальности :)… «Локальный джойн со словарем» в моем восприятии это JOIN, который может быть локализован в одной машине. Одна машина, в реалиях 18 года, может иметь 512Гб оперативной памяти и может быть весьма мощной. Там совершенно нормально может пройти локальный JOIN со словарем в 1 млрд. строк. Другое дело, когда нужно соединять несколько таблиц в десятки и сотни млрд. строк. Отвечая на вопрос, зачем платить за Вертику: чтобы соединять таблицы, не смотря на их размер. Все нужно уметь джойнить со всем.
UFO just landed and posted this here
Потому что хотели делать ad-hoc аналитику?
Вопрос про альтернативу в такой постановке я бы сначала предварил другим вопросом:
— а вы можете привести пример организации с сотнями 100Тб данных, которая успешно сделала ad-hoc аналитику на hdfs + spark sql, без MPP баз? Я бы с ними с радостью подискутировал.
Вопрос про альтернативу в такой постановке я бы сначала предварил другим вопросом:
— а вы можете привести пример организации с сотнями 100Тб данных, которая успешно сделала ad-hoc аналитику на hdfs + spark sql, без MPP баз? Я бы с ними с радостью подискутировал.
Sign up to leave a comment.
Ни GA, ни ЯМ. Как мы сделали собственный кликстрим