Поддерживает ли Cube. js предварительную регистрацию при использовании переменных контекста внутри определения SQL куба?

Question

Согласно документации Cube. js , можно определить кубы, используя что-то, называемое переменными контекста, которое позволяет вводить фильтры (такие как электронная почта конкретного пользователя) при запросе этого куба. Я еще не пробовал, но я хочу знать, совместима ли эта функция с преагрегациями, а также обрабатывает ли пустые случаи фильтра.
Например, если я определю этот куб (такой же, как в примере из документов) :

    cube(`OrderFacts`, {
      sql: `SELECT * FROM orders WHERE ${FILTER_PARAMS.OrderFacts.date.filter('date')}`,

      measures: {
        count: {
          type: `count`
        }
      },

      dimensions: {
        date: {
          sql: `date`,
          type: `time`
        }
      }
    });

Смогу ли я определить предварительную агрегацию, такую ​​как эта?

  preAggregations: {
    date: {
      type: `rollup`,
      measureReferences: [someMeasure],
      dimensionReferences: [someDimension],
      timeDimensionReference: date,
      granularity: `month`
    }
  }

и могу ли я выполнять запросы без date фильтра измерений? (так что sql будет заканчиваться как SELECT * FROM orders WHERE;)?

Подводя итог: есть ли способ динамического внедрения фильтров в определение sql куба, но не во время запроса и вместо этого время компиляции схемы ?
Я спрашиваю об этом, потому что в настоящее время мы расширяем некоторые кубы информацией, полученной из нашего API, и мы перезаписывали поле segment из этих кубов, но из-за из-за проблем с производительностью мы бы предпочли перезаписать поле sql куба (чтобы отфильтровать ненужные данные с самого начала).

ПРИМЕЧАНИЕ. Мы используем asyncModule для выполнения запросов к нашему API. Нам также нужно построить разные кубы (для всех наших клиентов), ссылающиеся на общую таблицу, но с динамикой c SQL, которая будет меняться в зависимости от клиента.

Наш желаемый результат должен быть (для таблицы Orders и F1, ..., Fn клиентских фильтров из нашего API):
N кубов, расширяющих базовый Orders куб: OrdersC1, OrdersC2, ..., OrdersCn.
Каждый OrdersCi куб с измененной версией базы Orders sql, содержащей фильтр Fi.
Каждый OrdersCi куб с теми же определениями dimensions, measures и preAggregations, унаследованными от базового куба Orders.

Нам удалось реализовать все, что я говорил ранее, но вместо изменения sql поле, мы перезаписали segments поле.

Answer 1

Как правило, только разделенные накопительные пакеты проходят FILTER_PARAMS для разделенных временных измерений. Все остальные предварительные агрегации не позволяют передавать контекстные переменные. Существует два подхода, которые можно использовать для предварительного объединения в мультитенантных средах.

1. Переопределить sql для каждого клиентского куба, например OrdersC1, OrdersC2 и т. Д. c , В этом случае все предварительные агрегации, определенные в базовом кубе Orders, будут наследоваться. Каждый клиентский куб будет иметь свой собственный набор предварительных агрегаций. Это означает, что если существует N клиентов и M предварительных агрегаций, то должны быть построены N * M таблицы предварительной агрегации, что может быть дорогостоящим в некоторых случаях ios.

cube(`Orders`, {
  sql: `SELECT * FROM orders`,

  preAggregations: {
    date: {
      type: `rollup`,
      measureReferences: [someMeasure],
      dimensionReferences: [someDimension],
      timeDimensionReference: date,
      granularity: `month`
    },
    // ...
  }
});

cube(`OrdersC1`, {
  extends: Orders,
  sql: `SELECT * FROM orders WHERE customer_id = 'C1'`,
});

Использовать поле арендатора в качестве измерения свертки. Каждый сегмент может быть преобразован в измерение, что дает возможность использовать единую сводную таблицу для всех клиентов. Для маршрутизации запросов к нужным данным арендатора можно использовать queryTransformer .

cube(`Orders`, {
  sql: `SELECT * FROM orders`,

  // ...

  dimensions: {
    // ...

    customerId: {
      sql: `customer_id`,
      type: `string`
    }
  },

  preAggregations: {
    date: {
      type: `rollup`,
      measureReferences: [someMeasure],
      dimensionReferences: [customerId, someDimension],
      timeDimensionReference: date,
      granularity: `month`
    },

    // ...
  }
});