Cloud, DataOps & CI/CD — DE Interview PrepCloud, DataOps & CI/CD — Подготовка к DE-интервью

One-line definitionОпределение одной строкой

DataOps = applying DevOps + Agile + Lean manufacturing ideas to the data lifecycle so that analytics and data products ship fast, repeatably, and with quality guarantees. It is the union of four pillars applied to data:

DataOps = применение идей DevOps + Agile + Lean manufacturing к жизненному циклу данных, чтобы аналитика и дата-продукты выкатывались быстро, воспроизводимо и с гарантиями качества. Это объединение четырёх столпов, примененных к данным:

• CI/CD — automated build, test and deploy of pipelines, transforms and infra.
• Automated testing — code tests and data tests (freshness, volume, schema, business rules).
• Observability / monitoring — freshness, volume, distribution, lineage and incident alerting (the "data downtime" idea).
• Collaboration & governance — version control, code review, environments, catalog, documentation, ownership.

• CI/CD — автоматизированные сборка, тестирование и деплой пайплайнов, трансформаций и инфраструктуры.
• Автоматизированное тестирование — тесты кода и тесты данных (свежесть, объём, схема, бизнес-правила).
• Наблюдаемость / мониторинг — свежесть, объём, распределение, lineage и алертинг при инцидентах (концепция «data downtime»).
• Коллаборация & governance — контроль версий, code review, окружения, каталог, документация, ownership.

Why it matters for an econ-data team

Почему это важно для команды экономических данных

Economic indicators (CPI, payrolls, GDP) are high-trust, point-in-time series consumed by clients and trading systems. A bad revision, a late landing, or a silent schema change is a credibility incident. DataOps is how you make correctness and timeliness systematic rather than heroic.

Экономические индикаторы (CPI, payrolls, GDP) — это высокодоверенные, точечные во времени серии, которые потребляются клиентами и торговыми системами. Плохая ревизия, задержка поступления или тихое изменение схемы — это инцидент доверия. DataOps — это способ сделать корректность и своевременность систематическими, а не героическими.

DevOps vs DataOps — the key differenceDevOps vs DataOps — ключевое отличие

Git workflow for data teamsGit-процесс для дата-команд

Everything that defines the pipeline lives in git: dbt models, SQL, Airflow DAGs, Terraform, schema/contract files, tests, docs. Common lightweight flow:

Всё, что определяет пайплайн, живёт в git: dbt-модели, SQL, Airflow DAG-и, Terraform, файлы схем/контрактов, тесты, доки. Типичный лёгкий процесс:

# trunk-based with short-lived feature branches
git checkout -b feat/cpi-seasonal-adjust
# ... edit dbt model + add tests ...
git commit -m "[econ_de] Add seasonally adjusted CPI model + freshness test"
git push origin feat/cpi-seasonal-adjust
# open PR -> CI runs lint + unit + data tests on a sandbox/CI schema
# review (enforced standard) -> squash merge to main -> auto-deploy to stage

Environments: dev / stage / prod

Окружения: dev / stage / prod

• dev — engineer's sandbox; dbt builds into a personal schema (dbt_amal), cheap, fast, dirty.
• stage — production-shaped, fed by main branch, full test suite, used for validation and integration tests.
• prod — only reached by promoted, tested, reviewed code. No manual edits.

• dev — песочница инженера; dbt строит в личную схему (dbt_amal), дёшево, быстро, грязно.
• stage — как продакшн, питается из main-ветки, полный набор тестов, используется для валидации и интеграционных тестов.
• prod — доступен только для промоушен-кода, протестированного и пройденного ревью. Никаких ручных правок.

"Version control for data" — three flavours«Контроль версий для данных» — три вкуса

Branching for data

Ветвление для данных

Modern pattern: each feature branch gets an isolated data environment. In Snowflake you zero-copy clone prod into a branch schema (instant, cheap, no storage duplication) so CI tests run against realistic data without touching prod. Iceberg/lakeFS expose git-like branch/merge on the data itself.

Современный паттерн: каждая feature-ветка получает изолированное окружение данных. В Snowflake ты делаешь zero-copy clone прода в ветку-схему (мгновенно, дёшево, без дублирования хранилища), так что тесты CI идут на реалистичных данных без касания прода. Iceberg/lakeFS предоставляют git-подобное ветвление/слияние на самих данных.

CI/CD-for-data pipeline (ASCII)CI/CD-пайплайн для данных (ASCII)

   DEV                          CI  (on Pull Request)                       CD (on merge)
 ┌───────┐    git push   ┌──────────────────────────────────┐    merge   ┌──────────────────────┐
 │ branch│ ────────────► │ 1. LINT     sqlfluff / dbt parse │ ─────────► │  build artifacts     │
 │ +tests│               │ 2. UNIT     macro / py unit tests│            │  (dbt manifest, DAG, │
 └───────┘               │ 3. BUILD    dbt build --select   │            │   docker image)      │
      ▲                  │             state:modified+      │            └──────────┬───────────┘
      │ fix              │ 4. DATA     dbt test (not_null,  │                       │ deploy
      │                  │             unique, accepted_*,  │                       ▼
      │                  │             relationships, fresh)│            ┌──────────────────────┐
      │   FAIL ◄─────────│ 5. CONTRACT schema/contract check│            │  STAGE  full run +   │
      │                  │ 6. INTEG    e2e on cloned prod   │            │  full test suite     │
      └──────────────────│             schema (zero-copy)   │            └──────────┬───────────┘
                         └──────────────────────────────────┘                       │ promote (green)
                                                                                     ▼
                                                                          ┌──────────────────────┐
                                                                          │  PROD   blue/green or │
                                                                          │  canary; auto-rollback│
                                                                          │  on data-quality gate │
                                                                          └──────────────────────┘
      

   DEV                            CI  (при Pull Request)                      CD (при merge)
 ┌───────┐    git push   ┌──────────────────────────────────┐    merge   ┌──────────────────────┐
 │ branch│ ────────────► │ 1. LINT     sqlfluff / dbt parse │ ─────────► │  сборка артефактов   │
 │ +tests│               │ 2. UNIT     macro / py unit tests│            │  (dbt manifest, DAG, │
 └───────┘               │ 3. BUILD    dbt build --select   │            │   docker image)      │
      ▲                  │             state:modified+      │            └──────────┬───────────┘
      │ fix              │ 4. DATA     dbt test (not_null,  │                       │ deploy
      │                  │             unique, accepted_*,  │                       ▼
      │                  │             relationships, fresh)│            ┌──────────────────────┐
      │   FAIL ◄─────────│ 5. CONTRACT schema/contract check│            │  STAGE  full run +   │
      │                  │ 6. INTEG    e2e на клоне прода   │            │  полный набор тестов │
      └──────────────────│             (zero-copy)          │            └──────────┬───────────┘
                         └──────────────────────────────────┘                       │ promote (green)
                                                                                     ▼
                                                                          ┌──────────────────────┐
                                                                          │  PROD   blue/green   │
                                                                          │  / canary; auto-     │
                                                                          │  rollback на DQ gate │
                                                                          └──────────────────────┘
      

What runs in CI (and why)Что запускается в CI (и зачем)

• Lint / static checks — sqlfluff, dbt parse, ruff/black for Python DAGs. Catches style + parse errors in seconds, free.
• Slim / state-aware builds — dbt build --select state:modified+ only builds models that changed and their downstream. Fast PRs, low compute cost.
• Unit tests — dbt unit tests (mock inputs → assert outputs) and Python unit tests for custom logic / operators.
• Data tests — generic + singular dbt tests run against the built models.
• Contract checks — fail the build if output schema/types drift from the declared contract.
• Integration / e2e — full DAG/dbt run on a cloned-prod CI schema to catch cross-model and dependency issues.

• Lint / статические проверки — sqlfluff, dbt parse, ruff/black для Python DAG-ов. Ловят стиль + parse-ошибки за секунды, бесплатно.
• Slim / state-aware сборки — dbt build --select state:modified+ строит только изменённые модели и их downstream. Быстрые PR-ы, низкая стоимость вычислений.
• Unit-тесты — dbt unit tests (мок входов → проверка выходов) и Python unit-тесты для кастомной логики / операторов.
• Тесты данных — generic + singular dbt-тесты на построенных моделях.
• Проверки контрактов — фейлить сборку, если выходная схема/типы отклоняются от декларированного контракта.
• Интеграционные / e2e — полный DAG/dbt run на клоне прода CI-схемы для выявления кросс-модельных и dependency-проблем.

Build & deploy of DAGs and dbt models

Сборка & деплой DAG-ов и dbt-моделей

• dbt: CI produces the manifest.json artifact; CD deploys compiled models + runs them in the target env. The manifest also powers slim CI via state comparison.
• Airflow: DAG files are version-controlled; CI validates them (DagBag import test catches broken DAGs before they hit the scheduler); CD syncs them to the Airflow environment (git-sync / dags volume / image bake).

• dbt: CI производит артефакт manifest.json; CD деплоит скомпилированные модели + запускает их в целевом окружении. Manifest также питает slim CI через сравнение состояния.
• Airflow: файлы DAG-ов под контролем версий; CI валидирует их (тест импорта DagBag ловит битые DAG-и до того как они попадут в планировщик); CD синхронизирует их в Airflow-окружение (git-sync / dags volume / image bake).

Deployment strategies for dataСтратегии деплоя для данных

                /\            E2E / pipeline      (few, slow, expensive)
               /  \          full DAG run on cloned prod, output vs golden
              /----\
             /      \        Integration         (cross-model, sources, deps)
            /--------\
           /          \      Contract             (schema/type stability, freshness)
          /------------\
         /              \    Data-quality tests   (not_null, unique, ranges, ref-integ)
        /----------------\
       /                  \  Unit tests           (many, fast, cheap)
      /____________________\ dbt unit tests + py logic, mocked inputs
      

                /\            E2E / pipeline      (мало, медленно, дорого)
               /  \          полный запуск DAG на клоне прода, вывод vs эталон
              /----\
             /      \        Интеграционные      (кросс-модельные, sources, deps)
            /--------\
           /          \      Контракты            (стабильность схемы/типов, freshness)
          /------------\
         /              \    Тесты качества данных (not_null, unique, диапазоны, ref-integ)
        /----------------\
       /                  \  Unit-тесты           (много, быстро, дёшево)
      /____________________\ dbt unit tests + py-логика, моки входов
      

Data-quality gates in CIГейты качества данных в CI

# dbt schema.yml — declarative data tests + contract
models:
  - name: fct_cpi_monthly
    config: { contract: { enforced: true } }
    columns:
      - name: period
        data_type: date
        tests: [not_null, unique]
      - name: cpi_yoy_pct
        data_type: numeric
        tests:
          - not_null
          - dbt_utils.accepted_range: { min_value: -20, max_value: 50 }
    # freshness so a stale upstream feed fails CI/monitoring
sources:
  - name: bls_raw
    freshness: { warn_after: {count: 26, period: hour}, error_after: {count: 48, period: hour} }

• Block the merge on test failure — a failing data test is a red CI = no deploy.
• Severity: warn for soft anomalies, error for hard gates. Tune to avoid alert fatigue.
• Reconciliation tests — assert totals match the source-of-truth (e.g. sum of components = published headline).

• Блокировать merge при фейле теста — фейлящий тест данных = красный CI = нет деплоя.
• Severity: warn для мягких аномалий, error для жёстких гейтов. Настраивать, чтобы избегать усталости от алертов.
• Тесты сверки — проверять, что итоги совпадают с источником истины (например, сумма компонентов = опубликованный headline).

Infrastructure as Code (Terraform basics)Infrastructure as Code (основы Terraform)

IaC = declare infra in version-controlled config so environments are reproducible, reviewable, and diff-able. Terraform is declarative + cloud-agnostic.

IaC = декларировать инфраструктуру в версионированном конфиге, чтобы окружения были воспроизводимыми, reviewable и diff-able. Terraform декларативен + облачно-агностичен.

# declare a warehouse + dataset; plan -> review -> apply
resource "snowflake_warehouse" "transform" {
  name           = "WH_TRANSFORM"
  warehouse_size = "SMALL"
  auto_suspend   = 60          # suspend after 60s idle = cost control
  auto_resume    = true
}
resource "google_bigquery_dataset" "econ" {
  dataset_id = "econ_marts"
  location   = "EU"
}

• Core verbs: init → plan (preview diff) → apply. plan in CI on every PR = no surprise infra changes.
• State lives in a remote backend (GCS/S3) with locking, so the team shares one source of truth.
• Modules = reusable building blocks; workspaces/var files parametrise dev/stage/prod.
• Idempotent & declarative: you describe desired state, Terraform computes the delta.

• Основные команды: init → plan (preview diff) → apply. plan в CI на каждом PR = нет внезапных изменений инфры.
• State живёт в remote backend (GCS/S3) с блокировкой, так что команда разделяет один источник истины.
• Модули = переиспользуемые строительные блоки; workspaces/var-файлы параметризуют dev/stage/prod.
• Идемпотентный & декларативный: ты описываешь желаемое состояние, Terraform вычисляет дельту.

Containerization + orchestration (high level)Контейнеризация + оркестрация (высокий уровень)

• Docker packages code + dependencies + runtime into one immutable image → "runs the same on my laptop, CI, and prod". For data: a pinned dbt/Python image kills "works on my machine" version drift.
• Image as artifact: CI builds and tags the image; CD deploys that exact tag → reproducible runs and easy rollback (deploy previous tag).
• Orchestration (Kubernetes / managed runners): schedules and scales containers, restarts on failure, handles secrets/config injection. Airflow's KubernetesPodOperator runs each task in its own container.
• Airflow itself is the workflow orchestrator (dependencies, schedules, retries, backfills, SLAs); Kubernetes is the container orchestrator underneath.

• Docker упаковывает код + зависимости + runtime в один неизменяемый image → «запускается одинаково на моём ноутбуке, CI и проде». Для данных: закреплённый dbt/Python image убивает «работает на моей машине» версионный дрейф.
• Image как артефакт: CI строит и тегирует image; CD деплоит этот точный тег → воспроизводимые запуски и лёгкий откат (деплой предыдущего тега).
• Оркестрация (Kubernetes / managed runners): планирует и масштабирует контейнеры, рестартует при падении, обрабатывает инъекцию секретов/конфига. Airflow KubernetesPodOperator запускает каждую задачу в своём контейнере.
• Сам Airflow — это оркестратор workflow (зависимости, расписания, ретраи, backfill-ы, SLA); Kubernetes — оркестратор контейнеров под ним.

The five layersПять слоёв

Snowflake sits cross-cloud as a managed warehouse/lakehouse that runs on top of GCS/S3/Blob — which is why my GCP→Snowflake migration was about moving the engine, not the storage paradigm.

Snowflake сидит кросс-облачно как управляемый warehouse/lakehouse, который работает поверх GCS/S3/Blob — поэтому моя миграция GCP→Snowflake была о переносе движка, а не парадигмы хранения.

Warehouse vs LakehouseWarehouse vs Lakehouse

Snowflake vs BigQuery at a glanceSnowflake vs BigQuery кратко

Metadata management & the data catalogУправление метаданными & каталог данных

Metadata = data about the data: schemas, owners, descriptions, freshness, quality scores, classifications (PII/sensitivity), usage. A data catalog is the searchable inventory of all that — so people can find, trust, and understand data without asking the original engineer.

Metadata = данные о данных: схемы, владельцы, описания, свежесть, оценки качества, классификации (PII/чувствительность), использование. Каталог данных — это поисковая инвентаризация всего этого — чтобы люди могли найти, доверять и понимать данные без обращения к исходному инженеру.

Tools: dbt docs (descriptions + auto DAG), Dataplex/Data Catalog, Snowflake's metadata views + Horizon, DataHub, OpenMetadata, Collibra, Purview.

Инструменты: dbt docs (описания + авто-DAG), Dataplex/Data Catalog, Snowflake metadata views + Horizon, DataHub, OpenMetadata, Collibra, Purview.

Data lineage — technical vs businessData lineage — технический vs бизнесовый

 bls_raw.cpi ─┐
              ├─► stg_cpi ─► int_cpi_seasonal ─► fct_cpi_monthly ─► dashboard / API / client export
 fred.weights─┘                                         │
                                                        └─► alert: if this breaks, ALL downstream is impacted
      

 bls_raw.cpi ─┐
              ├─► stg_cpi ─► int_cpi_seasonal ─► fct_cpi_monthly ─► dashboard / API / клиентский экспорт
 fred.weights─┘                                         │
                                                        └─► алерт: если это сломается, ВСЕ downstream затронуты
      

Why lineage matters

Почему lineage важен

• Impact analysis — before changing a model, see every downstream table/dashboard/consumer that breaks. (dbt: dbt ls --select fct_cpi_monthly+.)
• Root-cause — when a number looks wrong, walk lineage upstream to find the bad source/transform.
• Governance & compliance — prove provenance of a published figure; trace PII propagation; audit "where did this number come from".
• Trust — column-level lineage + tests + freshness = a data product clients can rely on.

• Анализ влияния — перед изменением модели увидеть каждую downstream-таблицу/дашборд/потребителя, которые сломаются. (dbt: dbt ls --select fct_cpi_monthly+.)
• Root-cause — когда число выглядит неправильно, пройти lineage upstream, чтобы найти плохой source/transform.
• Governance & compliance — доказать происхождение опубликованной цифры; проследить распространение PII; аудит «откуда взялось это число».
• Доверие — lineage на уровне колонок + тесты + свежесть = дата-продукт, на который клиенты могут положиться.

Universal levers

Универсальные рычаги

• Incremental models (dbt incremental) — only process new/changed rows, not full refresh.
• Slim CI — only build changed + downstream models.
• Tag & attribute compute by team/pipeline for showback/chargeback.
• Monitor query/warehouse cost dashboards; kill runaway queries.

• Инкрементальные модели (dbt incremental) — обрабатывать только новые/изменённые строки, не full refresh.
• Slim CI — строить только изменённые + downstream модели.
• Тегировать & атрибутировать compute по команде/пайплайну для showback/chargeback.
• Мониторить дашборды стоимости запросов/warehouse; убивать убегающие запросы.

Promotion pathПуть промоушена

 commit ─► PR (CI: lint+tests on dev/CI clone) ─► merge ─► STAGE (full run+tests)
        ─► manual/auto gate (green only) ─► PROD (blue/green swap, monitored, rollback-ready)
      

 commit ─► PR (CI: lint+tests на dev/CI clone) ─► merge ─► STAGE (full run+tests)
        ─► ручной/авто-гейт (только зелёный) ─► PROD (blue/green swap, мониторится, готов к откату)
      

• Same code, different targets: dbt targets / Airflow connections swap the schema/warehouse/project per env — no code forks.
• Promotion = moving the artifact (manifest/image/DAG), never re-writing logic per env.
• Gate on green: a promotion can only happen if the prior stage's tests passed.
• Immutable artifacts: prod runs the exact image/manifest that passed stage.

• Тот же код, разные таргеты: dbt targets / Airflow connections меняют схему/warehouse/проект на окружение — никаких форков кода.
• Промоушен = перемещение артефакта (manifest/image/DAG), никогда не переписывать логику под окружение.
• Гейт на зелёном: промоушен возможен только если тесты предыдущего stage прошли.
• Неизменяемые артефакты: прод запускает точный image/manifest, прошедший stage.

Secrets managementУправление секретами

• Never in git or code. Use a secrets manager: GCP Secret Manager, AWS Secrets Manager, Azure Key Vault, Vault.
• Inject at runtime as env vars / mounted secrets / Airflow connections+variables (backed by a secrets backend).
• Least privilege service accounts per env; prod creds never reachable from dev.
• Rotation + audit logging; prefer short-lived/federated identity (workload identity, OIDC) over long-lived keys.
• Secret scanning in CI (pre-commit / detect-secrets) to block accidental commits.

• Никогда в git или коде. Использовать менеджер секретов: GCP Secret Manager, AWS Secrets Manager, Azure Key Vault, Vault.
• Инжектить во время выполнения как env vars / mounted secrets / Airflow connections+variables (backed секрет-бэкендом).
• Least privilege сервисные аккаунты на окружение; прод-креды никогда не достижимы из dev.
• Ротация + audit logging; предпочитать short-lived/federated identity (workload identity, OIDC) вместо long-lived ключей.
• Сканирование секретов в CI (pre-commit / detect-secrets) для блокировки случайных коммитов.

# dbt profiles use env vars, not literals
prod:
  type: snowflake
  account: "{{ env_var('SF_ACCOUNT') }}"
  user:    "{{ env_var('SF_USER') }}"
  password: "{{ env_var('SF_PASSWORD') }}"   # injected from Secret Manager at runtime