в моем проекте BigQuery я храню данные о событиях, интегрированные из Firebase.Гранулярность и размерность таковы, что при попытке быстро представить необработанные данные в Data Studio отчет становится ОЧЕНЬ медленным (1-2 минуты на страницу / взаимодействие).
Затем я начал думать, как создать предварительные данные.агрегированные таблицы в BigQuery, чтобы ускорить все, но быстро поняли метрики COUNT DISTINCT будут проблемой с этим подходом.Позвольте мне объяснить:
SELECT user, date
FROM UNNEST([
STRUCT("Adam" AS user, "20190923" AS date),
("Bob", "20190923"),
("Carl", "20190923"),
("Adam", "20190924"),
("Bob", "20190924"),
("Adam", "20190925"),
("Carl", "20190925"),
("Bob", "20190926")
]) AS website_visits;
+------+----------+
| User | Date |
+------+----------+
| Adam | 20190923 |
| Bob | 20190923 |
| Carl | 20190923 |
| Adam | 20190924 |
| Bob | 20190924 |
| Adam | 20190925 |
| Carl | 20190925 |
| Bob | 20190926 |
+------+----------+
Выше приведена таблица посещений веб-сайтов.
Очевидно, что создание предварительно агрегированной таблицы, такой как
SELECT date, COUNT(DISTINCT user) FROM website_visits GROUP BY date
, имеет ограничение, заключающееся в том, чтосчет не может быть агрегирован далее (или даже меньше, динамически), чтобы получить итоговое значение, так как выполнение SUM вернет 8 уникальных пользователей, что неверно, есть только 3 уникальных пользователя.
В BigQuery этоисправлено с помощью HLL_COUNT, который, несмотря на приближение, работает нормально для меня.
Теперь большой вопрос:
Как сделать то же самое, чтобы результат отображался в Data Studio????
HLL_COUNT.EXTRACT недоступен как функция, и в отчетах я всегда должен помнить, что диапазон дат устанавливается пользователем, однако ему (ей) нравится сохранить предварительно агрегированный результат для ВСЕХ дел ...
РЕДАКТИРОВАТЬ 1: APPROX_COUNT_DISTINCT
Согласно ответу Боббиланка,Я пытался использовать APPROX_COUNT_DISTINCT.Тем не менее, я обнаружил, что это, кажется, просто сдвинуло проблему с мертвой точки.Я виноват в том, что не объяснил, что там.Несмотря на то, что производительность приемлема, мне не представляется возможным смешать источник данных с этим вычисленным показателем.
Пример: после отображения количества уникальных пользователей за выбранный период (, который теперь работает ), Я также пытаюсь отобразить средний доход на пользователя (ARPU) в Data Studio, как это делает Firebase.
Чтобы сделать это, мне нужно SUM (REVENUE) / APPROX_COUNT_DISTINCT (USER)
Очевидно, REVENUE работает нормально с предварительной агрегацией и доступна в необработанных данных.Затем я попытался смешать необработанные данные с таблицей, содержащей только посещения пользователей.Однако APPROX_COUNT_DISTINCT нельзя использовать в определении смешанных данных, так как вычисляемые метрики не допускаются.
Даже при попытке использовать поле USER в качестве метрики с агрегацией Count Distinct, несмотря на возвращение правильных цифр при отображении дохода и пользователясчитать отдельно, когда я пытаюсь разделить их, проблема становится агрегацией (применить SUM или AVG к полю, и в основном результат будет AVG (REVENUE / USERS) для каждого дня).
Затем я также попытался сохранитьREVENUE непосредственно в таблице посещений, но Data Studio напомнила мне, что я не могу создать вычисляемые метрики и не могу смешивать измерения и метрики в вычисляемом поле.