1. Мы рассматривали несколько вариантов, в том числе использование внутреннего sql-совместимого языка для аналитики YQL (про него есть публичные статьи если интересно почитать), но некоторые внутренние особенности решаемой задачи не очень хорошо на него ложились. Хотя в целом тут прогресс не стоит на месте и возможно мы это место пересмотрим.
2. Clickhouse очень хорош в задачах частых чтений данных с набором определенных агрегаций над ним, но чуть менее хорош в задачах частого обновления данных и частого расширения агрегаций.
3. Это хороший поинт, да, мы тоже с такими проблемами сталкиваемся. В целом мы решаем это тем, что имеем большое факторное пространство (сильно больше, чем используется на проде), доступное аналитикам, на тестовом/нагрузочном контуре. Но понятно, что этого не всегда достаточно, в таком случае мы храним все необходимые данные на MapReduce и гипотезы можно проверить достаточно быстро по ним (зная возможности и ресурсы, которые у нас есть в проде для реализации нужных фичей). Тут правда может быть разница между тем, что посчитано таким образом, и потом будет посчитано в проде, но в целом мы не часто натыкаемся на то, что различие сколько-нибудь существенное.
2. Clickhouse очень хорош в задачах частых чтений данных с набором определенных агрегаций над ним, но чуть менее хорош в задачах частого обновления данных и частого расширения агрегаций.
3. Это хороший поинт, да, мы тоже с такими проблемами сталкиваемся. В целом мы решаем это тем, что имеем большое факторное пространство (сильно больше, чем используется на проде), доступное аналитикам, на тестовом/нагрузочном контуре. Но понятно, что этого не всегда достаточно, в таком случае мы храним все необходимые данные на MapReduce и гипотезы можно проверить достаточно быстро по ним (зная возможности и ресурсы, которые у нас есть в проде для реализации нужных фичей). Тут правда может быть разница между тем, что посчитано таким образом, и потом будет посчитано в проде, но в целом мы не часто натыкаемся на то, что различие сколько-нибудь существенное.