Как улучшить процесс создания преагрегатов cube js? (создание преаггов занимает слишком много времени даже при использовании PartGranularity)

Question

У нас проблемы с производительностью создания преагрегаций. В настоящее время у нас есть специфицированные c фильтры для данных для каждого из наших клиентов, и мы генерируем разные кубы для каждого из них, расширяя базовый куб (называемый Metrics) и определяя сегмент, который представляет эти фильтры.

Подводя итог, у нас есть Metrics базовый куб, и мы генерируем динамические c кубы MetricsA, MetricsB, MetricsC для клиентов A, B, C. Каждый из этих кубов имеет сегмент, который мы называем z, который содержит специфический c SQL запрос для каждого из наших клиентов. Данные для построения сегмента извлекаются из нашего API с использованием asyncModule, а затем мы расширяем куб Metrics для генерации всех клиентских кубов c, переопределяя сегмент z клиентским filter. Таким образом, когда клиент запрашивает службу куба, извлекаемые данные поступают из его указанного c куба с уже отфильтрованными данными (принудительным сегментом z).

Этот куб Metrics построены путем объединения больших таблиц, поэтому мы также добавили partitionGranularity (ежемесячно), чтобы уменьшить размер преагрегаций, но их сборка все еще занимает слишком много времени (> 10 минут).
Нам нужно отредактировать спецификацию c запрос, который служба куба отправляет для создания таблиц предварительной агрегации, поэтому мы сохраняем только строки с z сегмент = 1 (потому что это релевантные данные), или, по крайней мере, мы хотим иметь возможность переставить / изменить запрос для повышения производительности. Какое место лучше всего сделать для таких изменений? или какова рекомендуемая практика вмешательства в этот процесс?

Answer 1

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

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`
    },

    // ...
  }
});