Комментарии 3
Спасибо, очень интересно.
И сразу есть несколько вопросов
- Почему все же не была сделана ставка на хотя-бы частично SQL-совместимый DSL, чтобы аналитики могли быстро входить в тему? Как я понимаю, наработки по парсингу SQL в компании есть.
- Чем не подошёл Clickhouse, как основной рантайм? ЕМНИП, там есть структуры как раз под задачу накопительной аггрегации.
- Мой опыт построения подобной системы говорит, что возможность дата саентистов быстро тестировать гипотезы на истории важнее оптимального рантайма. Когда есть понимание, какие фичи нужны и как их использовать, то рантайм реализовать несложно (даже на миллионах событий в минуту). Сложно за час протестировать идею на истории за год. Ведь надо за час выполнить вычисления, которые в проде выполняются за год да ещё и в случае рантайма можно потратить пару дней девелоперов на оптимизацию, имея спецификацию факторов, а для проверки гипотез этого времени просто нет. Интересно, как у вас с этим?
1. Мы рассматривали несколько вариантов, в том числе использование внутреннего sql-совместимого языка для аналитики YQL (про него есть публичные статьи если интересно почитать), но некоторые внутренние особенности решаемой задачи не очень хорошо на него ложились. Хотя в целом тут прогресс не стоит на месте и возможно мы это место пересмотрим.
2. Clickhouse очень хорош в задачах частых чтений данных с набором определенных агрегаций над ним, но чуть менее хорош в задачах частого обновления данных и частого расширения агрегаций.
3. Это хороший поинт, да, мы тоже с такими проблемами сталкиваемся. В целом мы решаем это тем, что имеем большое факторное пространство (сильно больше, чем используется на проде), доступное аналитикам, на тестовом/нагрузочном контуре. Но понятно, что этого не всегда достаточно, в таком случае мы храним все необходимые данные на MapReduce и гипотезы можно проверить достаточно быстро по ним (зная возможности и ресурсы, которые у нас есть в проде для реализации нужных фичей). Тут правда может быть разница между тем, что посчитано таким образом, и потом будет посчитано в проде, но в целом мы не часто натыкаемся на то, что различие сколько-нибудь существенное.
2. Clickhouse очень хорош в задачах частых чтений данных с набором определенных агрегаций над ним, но чуть менее хорош в задачах частого обновления данных и частого расширения агрегаций.
3. Это хороший поинт, да, мы тоже с такими проблемами сталкиваемся. В целом мы решаем это тем, что имеем большое факторное пространство (сильно больше, чем используется на проде), доступное аналитикам, на тестовом/нагрузочном контуре. Но понятно, что этого не всегда достаточно, в таком случае мы храним все необходимые данные на MapReduce и гипотезы можно проверить достаточно быстро по ним (зная возможности и ресурсы, которые у нас есть в проде для реализации нужных фичей). Тут правда может быть разница между тем, что посчитано таким образом, и потом будет посчитано в проде, но в целом мы не часто натыкаемся на то, что различие сколько-нибудь существенное.
используется ли гипотеза об интересах рекламодателей? — скажем издательство книги как фича, или разница между появлением книги в магазине и первыми отзывами?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Расчет факторов в антифроде. Доклад Яндекса