Learning Platform
Глоссарий Troubleshooting
Урок 14.04 · 28 мин
Продвинутый
Semantic Layer APIMCP serverAI agentsGraphQLJDBC

SL API и MCP server: JDBC, GraphQL, AI agents

В предыдущих уроках мы разобрались с MetricFlow internals — как metric queries компилируются в SQL. Теперь — как получить метрики из вне dbt CLI. Это API surface: JDBC, GraphQL, Python SDK, и новинка 2025-2026 — dbt MCP server для AI agents.

Этот урок:

  1. Architecture dbt Semantic Layer API.
  2. JDBC, GraphQL, Python SDK — для каких сценариев.
  3. Apache 2.0 open source с 2025 — что это значит для self-hosting.
  4. dbt MCP server — Model Context Protocol toolkit для AI agents (Claude, GPT-4, etc.).
  5. Production patterns для каждого API.

Semantic Layer API и BI integrations (dbt II)

Architecture overview

                   ┌─────────────────────────────┐
                   │ dbt Cloud SL OR self-hosted │
                   │   semantic_manifest.json    │
                   │       MetricFlow engine     │
                   └─────────────────────────────┘

              ┌───────────────┼────────────────┬────────────────┐
              │               │                │                │
              ▼               ▼                ▼                ▼
         ┌────────┐    ┌──────────┐     ┌─────────────┐   ┌────────────┐
         │  JDBC  │    │ GraphQL  │     │ Python SDK  │   │ MCP Server │
         │ driver │    │   API    │     │   client    │   │   (2025+)  │
         └────────┘    └──────────┘     └─────────────┘   └────────────┘
              │               │                │                │
              ▼               ▼                ▼                ▼
         BI tools         Web dashboards   Data scientists   AI agents
         (Tableau,        (Hex, custom     (Jupyter,        (Claude,
         Power BI,        web apps)        Pandas)          GPT-4 via MCP)
         Looker)

Один Source of Truth — semantic_manifest.json + MetricFlow engine. Множество API на top.


JDBC API

JDBC use cases

Пример connection string:

jdbc:dbt-sl://semantic-layer.cloud.getdbt.com:443
  ?account=my-account
  &project_id=12345
  &environment_id=67890
  &api_token=SL_TOKEN

Или для self-hosted:

jdbc:dbt-sl://sl.mycompany.com:8080
  ?manifest_path=/var/dbt/target/semantic_manifest.json

Tableau / Power BI просто подключаются через standard JDBC и видят:

  • Tables = semantic_models.
  • Columns = dimensions.
  • Measures = computed columns.

Queries через SQL — но MetricFlow интерпретирует и transforms в правильный warehouse SQL.


GraphQL API

GraphQL — более flexible для custom web apps и modern SDK integrations.

# Query metrics через GraphQL
query GetRevenue($groupBy: [String!]!, $where: [String!]) {
  metrics(metrics: ["revenue"]) {
    name
    description
    type
    
    query(
      groupBy: $groupBy,
      whereFilter: $where,
      orderBy: ["-revenue"],
      limit: 100
    ) {
      data {
        revenue
        country
        order_month
      }
      sql                    # compiled SQL для debugging
      compileTime           # сколько потратил MetricFlow
      executeTime           # сколько потратил warehouse
    }
  }
}

Variables:

{
  "groupBy": ["customers__country", "metric_time__month"],
  "where": ["order_date >= '2025-01-01'"]
}

Response:

{
  "data": {
    "metrics": [{
      "name": "revenue",
      "query": {
        "data": [
          {"revenue": 1500000, "country": "USA", "order_month": "2025-01-01"},
          {"revenue": 800000, "country": "UK", "order_month": "2025-01-01"},
          ...
        ],
        "sql": "WITH ... SELECT country, SUM(amount) AS revenue FROM ...",
        "compileTime": "0.5s",
        "executeTime": "1.2s"
      }
    }]
  }
}

GraphQL преимущества:

  • Strongly typed schema — IDE auto-completion.
  • Single endpoint — GET/POST одинаковый URL.
  • Subqueries — get metric + dimensions + compiled SQL в одном request.
  • WebSocket subscriptions — real-time updates (experimental).

Use cases:

  • Custom web dashboards (Hex, Streamlit, custom React).
  • Data discovery UIs.
  • Internal admin panels.

Python SDK

Для data scientists и Python-based applications:

from dbt_sl import SemanticLayerClient

# Инициализация
client = SemanticLayerClient(
    host="semantic-layer.cloud.getdbt.com",
    api_token=os.environ["DBT_SL_TOKEN"],
    project_id="12345",
    environment_id="67890",
)

# Query метрику
result = client.query(
    metrics=["revenue", "order_count"],
    group_by=[
        "customers__country",
        "metric_time__month"
    ],
    where=["order_date >= '2025-01-01'"],
    order_by=["-revenue"],
    limit=100,
)

# Возвращает pandas DataFrame
df = result.to_pandas()
print(df.head())
#    revenue  order_count  country  order_month
# 0  1500000  10000        USA      2025-01-01
# 1  800000   5000         UK       2025-01-01
# ...

# Or as Arrow table (zero-copy для downstream tools)
arrow_table = result.to_arrow()

# Доступ к compiled SQL для debugging
print(result.compiled_sql)

Python SDK builds на top of GraphQL API. Это просто convenient Python wrapper.

Use cases:

  • Jupyter notebooks (data scientists).
  • ETL pipelines, который consumes metrics.
  • Custom Python applications.

Apache 2.0 lib, можно contribute (github.com/dbt-labs/dbt-sl-python).


Apache 2.0 open source (2025+)

Это strategic change dbt Labs:

Pre-2025: dbt Cloud SL = commercial. JDBC, GraphQL, Python SDK — closed source.
2025+:    dbt Cloud SL продолжает commercial, но всё что **на top of semantic_manifest.json** — Apache 2.0.

Что Apache 2.0:
  [x] MetricFlow engine (github.com/dbt-labs/metricflow)
  [x] JDBC driver (github.com/dbt-labs/dbt-sl-jdbc)
  [x] GraphQL server (github.com/dbt-labs/dbt-sl-graphql)
  [x] Python SDK (github.com/dbt-labs/dbt-sl-python)
  [x] MCP server (github.com/dbt-labs/dbt-mcp)

Что НЕ open source:
  [ ] dbt Cloud SL hosting infrastructure (managed service)
  [ ] dbt Cloud SL access controls, billing, monitoring

Strategic implication: self-hosted SL viable. Setup:

# 1. Run dbt parse -> generates semantic_manifest.json
dbt parse

# 2. Run open source SL services
docker run -d -p 8080:8080 \
  -v $(pwd)/target:/target \
  dbtlabs/dbt-sl-server:latest

# 3. Connect через JDBC/GraphQL/Python к localhost:8080

Pros self-hosted:

  • No SaaS dependency.
  • Data sovereignty.
  • Cost control.
  • Customization.

Cons:

  • Need to operate (monitoring, scaling, updates).
  • No managed support.
  • Authentication / authorization — нужно построить.

Choice — typical buy vs build tradeoff. Apache 2.0 даёт opportunity for self-hosting, не obligation.


dbt MCP server (новинка 2025-2026)

Model Context Protocol (MCP) — standard от Anthropic для AI agents общаться с tools. dbt MCP server делает dbt SL доступным для AI agents (Claude, GPT-4, etc.).

Что MCP делает

AI Agent (Claude)         dbt MCP Server         dbt SL Engine
       │                          │                      │
       │  "show me revenue by    │                      │
       │   country"              │                      │
       ├─────────────────────────►│                      │
       │                          │                      │
       │                          │  metric_query()      │
       │                          ├──────────────────────►│
       │                          │                      │
       │                          │   results            │
       │                          │◄──────────────────────┤
       │                          │                      │
       │   formatted response    │                      │
       │◄─────────────────────────┤                      │
       │                          │                      │

AI agent делает natural language query. MCP server разбирает intent, делает SL query, returns structured results. AI agent formats для user.

MCP toolsets

dbt MCP server exposes 8 toolsets:

1. list_metrics          # узнать какие метрики доступны
2. describe_metric       # описание метрики (definition, dimensions)
3. query_metric         # выполнить query
4. list_dimensions       # доступные dimensions для group_by
5. describe_dimension    # описание dimension
6. list_semantic_models  # все semantic_models в проекте
7. describe_semantic_model
8. list_saved_queries    # pre-computed saved queries

Каждый toolset — это MCP tool definition с JSON schema. AI agent видит:

{
  "name": "query_metric",
  "description": "Run a metric query на dbt SL",
  "parameters": {
    "metrics": {"type": "array", "items": {"type": "string"}, "required": true},
    "group_by": {"type": "array", "items": {"type": "string"}},
    "where": {"type": "array", "items": {"type": "string"}},
    "order_by": {"type": "array", "items": {"type": "string"}},
    "limit": {"type": "integer"}
  }
}

AI agent generates правильный JSON для tool call, MCP server executes, returns structured response.

Production setup

# Install
pip install dbt-mcp

# Start
dbt-mcp serve --port 5000 --target-path ./target

# Configure AI client (e.g., Claude Desktop)
# Edit ~/Library/Application Support/Claude/claude_desktop_config.json:
{
  "mcpServers": {
    "dbt-sl": {
      "command": "dbt-mcp",
      "args": ["serve", "--target-path", "/path/to/dbt/target"]
    }
  }
}

Claude Desktop теперь видит dbt SL как доступный tool. Можно спросить:

“Show me total revenue by country for 2025.”

Claude generates tool call:

{
  "name": "query_metric",
  "parameters": {
    "metrics": ["revenue"],
    "group_by": ["customers__country"],
    "where": ["order_date >= '2025-01-01'", "order_date < '2026-01-01'"]
  }
}

MCP server executes, returns:

{
  "data": [...],
  "compiled_sql": "...",
  "execution_time_ms": 1200
}

Claude formats для user:

“Total revenue by country for 2025:

  • USA: $1.5M
  • UK: $800K
  • …”

Use cases AI + SL

AI agents + SL: реальные сценарии

MCP server architecture

dbt-mcp-server:
├── transport layer       # JSON-RPC over stdio или HTTP
├── tool implementations  # 8 toolsets
├── SL client            # connects к dbt SL (через GraphQL внутри)
├── auth & rate limiting # production controls
└── observability        # metrics, logs

github.com/dbt-labs/dbt-mcp — Apache 2.0. Можно contribute (новый toolset, лучше handling, etc.).


Choosing the right API

Сценарий                          API
─────────────────────────────────────────────────
Tableau / Power BI / Looker       JDBC
Embedded analytics в web app      GraphQL
Jupyter notebook / Python ETL     Python SDK
AI assistant (Claude, GPT)        MCP server
Data discovery UI                 GraphQL (для metadata)
Custom SDK (Go, Rust, etc.)       GraphQL (HTTP-based)
Real-time dashboards              GraphQL + subscriptions

Production patterns

Pattern 1: BI + dbt SL (most common)

BI tool (Tableau) ─JDBC─► dbt Cloud SL ─► Snowflake

                          semantic_manifest.json
                          (built daily by dbt)

Single source of truth — semantic_manifest. BI users queries normally через JDBC. dbt SL gives unified definitions.

Pattern 2: Self-hosted SL для data sovereignty

Internal app ─GraphQL─► dbt-sl-server (self-hosted) ─► Postgres / DuckDB

                                  semantic_manifest.json
                                  (generated by dbt parse)

No SaaS dependency. Для financial / healthcare сектора, где data sovereignty critical.

Pattern 3: AI-powered analytics

End user ──► Claude (Anthropic) ─MCP─► dbt MCP server ─SL─► Snowflake

                                                            semantic_manifest.json

AI translates natural language -> structured SL queries. Power user-friendly.


Проверка знанийKnowledge check
Senior architect выбирает между dbt Cloud SL и self-hosted SL для проекта в healthcare компании. Какие критерии important?
ОтветAnswer
Хороший architectural решение требует understanding tradeoffs deeply. Я разберу typical criteria для healthcare сценария. **Контекст healthcare:** - HIPAA compliance — protected health information (PHI). - Data residency requirements — данные не покидают определённую jurisdiction. - High security standards — auditing, access logs. - Long-term data preservation (often 7+ лет). - Mission-critical operations — downtime = patient impact. **Criteria для choice:** **Criterion 1: Data sovereignty.** *dbt Cloud SL:* - Hosted by dbt Labs (на AWS/GCP). - Data does pass through dbt Labs infrastructure (compute metric). - BAA (Business Associate Agreement) для HIPAA — dbt Cloud offers это, но требует premium tier. - Если правила (e.g., EU GDPR) require data в специфичных regions — может быть challenge. *Self-hosted SL:* - Running на вашей infrastructure (AWS/Azure/GCP/on-prem). - Data never leaves вашу network. - Полный контроль над data residency. - BAA не applicable (no third party). Для healthcare с strict residency requirements — self-hosted strong advantage. **Criterion 2: Compliance and audit.** *dbt Cloud SL:* - SOC 2 Type II — certified. - HIPAA — available для enterprise tier. - Audit logs — provided через dbt Cloud admin. - Penetration testing — done by dbt Labs. *Self-hosted:* - Audit logs — нужно настроить (Prometheus, Datadog, ELK). - Penetration testing — your responsibility. - Compliance certifications — your team to obtain (можно basis on AWS/GCP underlying). Если у вас уже compliance program — self-hosted fits. Если starting from scratch — dbt Cloud easier (already certified). **Criterion 3: Operational burden.** *dbt Cloud SL:* - dbt Labs operates: monitoring, scaling, upgrades, security patches. - 24/7 support (enterprise tier). - SLA (typically 99.9%+). - Cost: per-user или per-seat pricing. *Self-hosted:* - Your team operates everything. - 24/7 on-call rotation needed. - Monitoring (metrics, alerts). - Scaling (load balancers, replicas). - Backup и DR. - Security patching. - Upgrades. - Cost: infrastructure + people time. Often 2-5x of dbt Cloud price для same scale. Для small healthcare org — dbt Cloud usually wins on operational simplicity. Для large enterprises с existing data platform team — self-hosted may be cheaper и more controlled. **Criterion 4: Integration complexity.** *dbt Cloud SL:* - BI tools connect через documented JDBC. - Python SDK works out of box. - AI integrations (MCP) supported. *Self-hosted:* - Same Apache 2.0 libraries, но you setup endpoints. - Authentication (OAuth, SAML) — you implement. - Rate limiting, monitoring — you configure. For heavy integrations — self-hosted gives flexibility. For standard BI — dbt Cloud out of box. **Criterion 5: Cost.** Let's сравнить: *dbt Cloud SL Enterprise (estimated):* - $20-50/user/month for SL access. - Compute charged separately. - Predictable, OpEx. - For 100 users: $2000-5000/month = $24-60K/year. *Self-hosted estimated:* - Infrastructure: $500-2000/month (EC2 instances, load balancer, managed Postgres). - Engineering time: 0.5-1 FTE для operating = $80-150K/year. - Total: $86-176K/year. Breakeven: ~100-300 users dbt Cloud becomes cheaper. Below — self-hosted cheaper per-user-per-year. Above — dbt Cloud cheaper. For healthcare с 50-100 users — self-hosted may be cheaper. For healthcare с 500+ users — dbt Cloud likely cheaper. **Criterion 6: Vendor lock-in.** *dbt Cloud SL:* - Если dbt Labs пrice change или service degrades — migration cost. - API contracts может change (рамки). *Self-hosted (Apache 2.0):* - Полная contol. Если dbt Labs changes direction — keep using old version. - Can patch bugs in-house. - Easier to migrate away from dbt entirely if needed (you own the infrastructure). Для strategic infrastructure (healthcare data is strategic) — self-hosted reduces vendor risk. **Criterion 7: AI/MCP integration.** *dbt Cloud SL:* - MCP server hosted by dbt Labs. - AI agents connect through Cloud. - For HIPAA — sensitive queries pass через dbt Labs (BAA required). *Self-hosted:* - MCP server у вас. - AI agents connect к your endpoint. - Queries never leave your network. - Easier compliance — no third party for AI workloads. Для healthcare AI use case — self-hosted strongly preferred (data privacy). **Decision matrix for healthcare:** | Criterion | dbt Cloud SL | Self-hosted | Recommendation | |-----------|--------------|-------------|----------------| | Data sovereignty | Limited | Full | Self-hosted | | Compliance | Easier | Requires work | Tie (depends on existing program) | | Operations | Managed | DIY | dbt Cloud для small teams | | Cost (100 users) | $24-60K/year | $86-176K/year | dbt Cloud cheaper at this scale | | Vendor risk | Higher | Lower | Self-hosted | | AI integration | BAA required | Native control | Self-hosted (для PHI) | **My recommendation for healthcare:** - Small team (менее 50 users), не PHI sensitive: dbt Cloud SL Enterprise. - Mid-size with PHI: self-hosted SL. - Large enterprise с existing data platform team: self-hosted SL. - Регулатory-heavy (EU, China, etc.): self-hosted SL. **Hybrid possibility:** Use dbt Cloud для main project, self-hosted SL для PHI-sensitive sub-projects. dbt parse generates semantic_manifest, both deployments use it. Common architecture. **Главный урок:** Architecture decisions требуют evaluation **multiple dimensions**: data sovereignty, compliance, ops burden, cost, vendor lock-in. dbt SL's Apache 2.0 openness gives **choice** — neither approach is universally right. Healthcare-specific factors (PHI, BAA, residency) typically push toward self-hosted, но nuance important.

Проверка знанийKnowledge check
Команда внедрила dbt MCP server для AI assistant (Claude в Slack). После недели использования business users довольны, но senior data engineer обеспокоен. Какие риски и mitigation strategies?
ОтветAnswer
Это **production AI/data integration challenge**. Senior engineer's concerns are legitimate. Разбираем риски и mitigations. **Risk 1: AI may misinterpret queries.** AI translates natural language -> SL query. Mistakes possible: - "revenue за last month" -> AI выбирает wrong time dimension. - "топ customers" -> AI uses count_distinct вместо SUM revenue. - "по странам" -> AI confuses customers__country и suppliers__country. Real example: business user asks "what was revenue last week?" AI generates query с `metric_time__week BETWEEN ...`. Но в этом проекте `metric_time__week` undefined (only daily/monthly available). AI fails silently или returns wrong data. **Mitigation:** 1. **Validate semantic_manifest регулярно** — `mf validate`. Catch missing dimensions/granularities. 2. **Tool call logging** — log каждый AI-generated query: ```python # dbt-mcp logging config logging: log_tool_calls: true log_file: /var/log/dbt-mcp/tool_calls.log ``` Review weekly для anomalies. 3. **AI training/prompting** — дать AI clear instructions: ``` System prompt: - Always check available metrics через list_metrics before querying. - Check available time granularities через describe_metric. - If unsure about user intent, ask clarifying question. ``` 4. **Strict semantic_manifest** — добавить descriptions: ```yaml metrics: - name: revenue description: "Total revenue from completed orders only. Excludes refunds." type: simple ... ``` AI uses descriptions для intent matching. **Risk 2: PII exposure.** AI agent may return PII в response если SL exposes individual-level data. Example: query "customer with highest spend" -> AI returns specific customer name. If sensitive — leak. **Mitigation:** 1. **Restrict SL access** — не expose individual-level data: ```yaml semantic_models: - name: customers dimensions: - name: country # [x] ok type: categorical - name: email # [ ] remove - name: name # [ ] remove ``` Keep PII в underlying dim_customers, но не expose через SL. 2. **Row-level security** в warehouse — dbt user has only access к aggregated views. 3. **Aggregation enforcement** — semantic_model только aggregable. Если user asks for individual rows, MetricFlow errors. 4. **Compliance review** — для healthcare, finance, etc. — security team reviews exposed dimensions. **Risk 3: AI hallucinations.** AI может say "revenue was $500K" даже когда query returned $300K. LLMs sometimes confabulate. **Mitigation:** 1. **Force tool use** — system prompt: ``` NEVER answer revenue questions without calling query_metric tool. ALWAYS quote exact numbers from tool response. NEVER round or approximate without acknowledging. ``` 2. **Response validation** — middleware which compares AI response к raw tool output. Flag discrepancies. 3. **Citation в response** — AI должен include data source: ``` User: revenue по странам? AI: Revenue by country (source: dbt SL, query executed 2025-05-19 14:30): - USA: $1,532,841 - UK: $821,409 Doubt? Run `mf query --metrics revenue --group_by customers__country` to verify. ``` 4. **Audit trail** — store query + result + AI response triple. If user disputes, можно replay. **Risk 4: Cost runaway.** AI agents может делать expensive queries (scan terabytes, expensive joins) без user understanding cost. Example: business user asks "what's revenue forever?" AI generates query без time filter -> full table scan over 5 years of data. Warehouse cost spike. **Mitigation:** 1. **Cost limits в MCP server:** ```yaml limits: max_rows: 100000 max_query_time: 30s max_scan_bytes: 1GB ``` Queries exceeding limits — error из MCP server. 2. **Mandatory filters** в semantic_model: ```yaml semantic_models: - name: orders config: required_filters: - "order_date не меньше CURRENT_DATE - INTERVAL '1 year'" ``` All queries forced к use this filter unless explicitly overridden. AI cannot trigger full-history scan. 3. **Cost monitoring** — dashboard для AI-initiated queries vs total queries. Alert если AI-initiated cost > X% total. 4. **Rate limiting per user** — каждый user max 100 queries/hour. Prevents accidental loops. **Risk 5: Audit и compliance.** If company audited (HIPAA, SOX, etc.), need to answer "who queried what data, when?" **Mitigation:** 1. **Identity propagation** — каждый MCP request имеет user_id: ```json { "session": "[email protected]", "request": "query_metric", "params": {...} } ``` MCP server logs identity. Audit trail complete. 2. **Role-based access control** в MCP server: ```yaml rbac: - role: finance_team allowed_metrics: ["revenue", "refunds", "margin"] forbidden_metrics: ["payroll"] - role: marketing allowed_metrics: ["clicks", "impressions"] ``` User permissions enforced regardless of AI agent. 3. **Periodic access review** — list all users + queries quarterly. Compliance officer reviews. **Risk 6: Slack persistence.** AI responses в Slack saved indefinitely. Sensitive data в conversation logs. **Mitigation:** 1. **Don't return PII** (см. Risk 2). 2. **Slack data retention policy** — purge messages older than X days. 3. **Ephemeral responses** — AI uses Slack ephemeral message API для sensitive data. User sees, no one else, no persistence. **Risk 7: AI may hallucinate semantic_manifest details.** AI knows что revenue exists. Может invent: "you should also check 'profit_margin' metric." Но metric doesn't exist. User tries -> error. **Mitigation:** 1. **Force AI к list_metrics first** before suggesting. 2. **Restrict AI к known surface** — system prompt: ``` ONLY reference metrics returned by list_metrics tool. NEVER invent metric names. ``` **Operational excellence checklist:** - [x] Logging all tool calls. - [x] Monitoring (cost, query rate, error rate). - [x] Alerting (anomaly в AI queries). - [x] Cost limits configured. - [x] PII filtering. - [x] Identity propagation. - [x] RBAC. - [x] Compliance review process. - [x] Disaster recovery (что if MCP server fails — fallback к direct SL query?). - [x] User training (что AI may misinterpret, проверять numbers). **Главный урок:** AI + data = новый production interface. Все classic data security/cost/compliance concerns apply, plus новые AI-specific risks (hallucination, misinterpretation, prompt injection). Senior engineer должен **proactively address** через technical mitigations (limits, RBAC, monitoring) и organizational measures (training, review). Без этого "удобный AI assistant" becomes audit nightmare и cost runaway.

Итого

  1. dbt SL API surface: JDBC (BI tools), GraphQL (web/SDK), Python SDK (data scientists), MCP server (AI agents).
  2. Apache 2.0 open source с 2025: MetricFlow engine, JDBC driver, GraphQL server, Python SDK, MCP server — all open source. Self-hosting viable.
  3. dbt Cloud SL — managed offering, продолжает commercial. Open source layer on top — Apache 2.0.
  4. dbt MCP server — Model Context Protocol implementation. 8 toolsets (list_metrics, query_metric, etc.). Apache 2.0.
  5. AI integration — Claude/GPT-4/etc. может query metrics через natural language. Это новый interface к analytics.
  6. Production patterns: BI + dbt SL (most common), self-hosted для data sovereignty, AI-powered для exploratory analytics.
  7. Risks при AI + SL: misinterpretation, PII exposure, hallucinations, cost runaway, audit compliance. Mitigations: logging, RBAC, cost limits, validate semantic_manifest, system prompts.
  8. Decision criteria между Cloud / self-hosted: sovereignty, compliance, operational burden, cost, vendor risk, integration needs.

Это завершает модуль 13 — Semantic Layer internals. В модуле 14 переходим к capstone проекту: контрибьют в dbt-core, написать свой adapter, или large-project optimization case.

Проверьте понимание

Результат: 0 из 0
Концептуальный
Вопрос 1 из 5. Какие APIs предоставляет dbt Semantic Layer для разных consumer типов?

Закончили урок?

Отметьте его как пройденный, чтобы отслеживать свой прогресс

Войдите чтобы оценить урок

Прогресс модуля
0 из 4