На какой СУБД построен Data Warehouse (DWH) на вашем текущем проекте?

На моём последнем проекте DWH был построен на Google BigQuery. Это полностью управляемое облачное хранилище данных (Data Warehouse-as-a-Service).

Почему был выбран BigQuery:

• Бессерверная архитектура: Не нужно управлять инфраструктурой, кластерами или тонкой настройкой. Мы могли сосредоточиться на логике данных, а не на администрировании.
• Высокая производительность на больших данных: Использование колоночного хранения (Capacitor) и разделения (sharding) позволяло выполнять аналитические запросы к петабайтам данных за секунды.
• Тесная интеграция с экосистемой GCP: Данные легко загружались из Cloud Storage, обрабатывались в Dataflow (Apache Beam) и визуализировались в Looker Studio. Мы использовали bq CLI и Python-библиотеку для автоматизации.
• Эффективная модель стоимости: Оплата за обработанные терабайты и за хранение, что было выгодно для нашей модели использования с пиковыми нагрузками в конце дня.

Архитектура загрузки данных (ELT):

1. Extract: Сырые данные из различных источников (логи приложений, транзакционная БД PostgreSQL, SaaS-сервисы) выгружались в Cloud Storage в формате Parquet.
2. Load: С помощью Airflow DAG'ов данные инкрементально загружались в сырой слой (raw layer) BigQuery.
3. Transform: Внутри BigQuery выполнялись SQL-трансформации для построения витрин данных (data marts) в консумационном слое. Мы активно использовали представления (views) и материализованные представления (materialized views) для баланса между актуальностью и производительностью.

Пример задачи: Ежедневное обновление витрины для анализа поведения пользователей.

-- В консумационном слое DWH
CREATE OR REPLACE TABLE `project_id.analytics.user_activity_daily`
PARTITION BY date
CLUSTER BY user_segment
AS
SELECT
  DATE(timestamp) as date,
  user_id,
  COUNT(DISTINCT session_id) as sessions,
  SUM(revenue) as daily_revenue,
  CASE ... END as user_segment
FROM `project_id.raw.events` -- сырой слой
WHERE DATE(timestamp) = CURRENT_DATE() - 1
GROUP BY 1, 2;

Такой подход позволил нам создать масштабируемый и производительный DWH с относительно низкими операционными затратами.