📖 Best for: Super admins / data teams — anyone who wants business users to query data themselves (with sources attached) without copying raw data into the platform.
📖 Reading time: 9 minutes
📖 In one sentence: Data Platform is a built-in data-asset and query layer above YingClaw. Connect five types of sources (SQL / API / file / NoSQL / document) and query them via federated direct connection (raw data stays in place by default); the model turns natural-language questions into queries, returns structured answers with source tags, and lets you promote frequent calculations into shared assets — data catalog, unified metrics, tags, profiles, audiences. Access from the top nav "Data Platform" (route /data-center) — super admin only.
How it differs from Knowledge Graph: Data Platform answers "how much, how is it changing, is it abnormal"; Knowledge Graph answers "who, who is connected to whom, why, and what is impacted". Both are wired into the NLQ page; the model picks the route based on intent.
Function Overview
1. Core Value
- Query data without moving it: Federated direct query across five source types, raw data stays in place by default — detailed rows remain on the customer side, the platform only materializes processed assets.
- Natural-language queries with evidence: Business users ask in plain language; the model turns it into a query and returns structured answers with source tags (which source/table, masked or not, how long it took). No more waiting on the data team.
- One canonical definition for every metric: Promote any repeatedly asked calculation (e.g. "active user") into a metric and publish it. Every report now references the same definition — no more "three reports, three algorithms".
- Sensitive data — controlled and traceable: The field authorization matrix decides pass-through / mask / hidden by company × role × sensitivity level. Every query leaves a plaintext / masked / denied trail — you can trace any field back to whoever saw it.
- Unified multi-source governance: Lineage (table + column level), classification (L1–L4), quality rules, alerts and incidents, GDPR / China MLPS compliance — all in one place.
2. Main Capabilities
The left menu has four groups of 17 pages plus 8 cross-cutting capabilities.
Asset Catalog (4 pages)
| Page | Route | Capability |
|---|
| Catalog | /data-center/catalog | Asset catalog + stat cards + multi-dim search |
| Data Sources | /data-center/source | Register 5 source types: Test Connection / Discover Datasets / Refresh |
| Dataset Dict | /data-center/dataset | Fill in field Chinese names / sensitivity / primary key; LLM auto-fill / batch suggest |
| NLQ | /data-center/ask | Natural-language query + feedback + Save as Metric |
Data Governance (6 pages)
| Page | Route | Capability |
|---|
| Lineage | /data-center/lineage | Table + column level lineage / upstream & downstream / impact analysis |
| Classification | /data-center/security | Rule-based auto L1–L4 grading + manual correction + grading report |
| Data Quality | /data-center/quality | 5 rule types (completeness / uniqueness / validity / timeliness / accuracy) + quality dashboard |
| Auth & Audit | /data-center/governance | Field authorization matrix + per-query log + audit health + trace by field |
| Usage Analytics | /data-center/usage | Group by person / dataset / field / entry, with masked / denied / plaintext counts and failure rate |
| KB Scope by Company | /data-center/role-scope | Bind knowledge bases to companies; out-of-scope KBs get 403 on GraphRAG import |
Metrics & Tags (4 pages)
| Page | Route | Capability |
|---|
| Metric Platform | /data-center/metric | CRUD + state machine (draft → pending → published → deprecated) + compute / materialize + lineage |
| Tag Platform | /data-center/tag | CRUD + state machine + compute + materialized wide table + lineage |
| Audience | /data-center/audience | Tag combination to select people + estimated count + export CSV |
| User Profile | /data-center/profile | 360° per-user view across Basic / Behavior / Value / Predicted |
Intelligence & Ops (3 pages)
| Page | Route | Capability |
|---|
| AI Copilot | /data-center/copilot | Data Q&A agent + anomaly detection (Z-Score) + root cause analysis |
| DataOps Monitoring | /data-center/dataops | Monitoring dashboard + alert rules (metric / quality / query / source) + incident report with MTTR |
| Security & Compliance | /data-center/compliance | GDPR data subject rights (export / delete) + MLPS 2.0 + cross-border data transfer assessment |
Cross-cutting Capabilities (8)
- Federated direct query: Adapter-per-source-type direct connection to external sources — raw data never lands in the platform.
- Read-only hard constraint: Forced read-only validation (reject non-SELECT, force LIMIT, blacklist interception).
- Query masking: Phone / email / ID card / bank card masked by policy; every historical action preserved verbatim.
- Audit tri-state: Every SQL execution logs plaintext / masked / denied in three columns — mutually exclusive and exhaustive.
- Materialization: Only the assets that must be persisted — metric results, tag wide tables, audience members.
- Scheduled tasks: Quality rules / alerts / source liveness checks / metric & tag materialization.
- Machine-only read surface: Other internal services (e.g. Marketing Center) can read dataset dictionary and limited query results for sensitivity pre-checks.
- MCP tool publication: Exposes 23
dh_* read-only tools for external agents.
3. Typical Use Cases
- Self-service data queries: When ops asks "what was last month's repurchase rate in East China?", they use the NLQ page in plain language and get an answer with source tags — no waiting for the data team.
- Unified metric definitions: When "active user" means three different things across three reports, define it as a metric, publish it, and let every report reference the same definition.
- Sensitive data with control: When a phone number must be queryable but never visible in clear text, the field authorization matrix marks it as "mask" — results are auto-masked, and plaintext access is fully traceable.
- Data leak investigation: Use Trace by Field to see all 7 access states (plaintext / masked / denied / not returned / unknown / system-computed / failed) for a given field, and combine it with the per-query log to reconstruct "who, through which channel, asked what, got what".
4. Usage Guide
1. Entry & Permissions
- Top-level nav Data Platform (database icon), click to enter
/data-center, default route is /data-center/catalog
- Super admin only. The backend enforces admin check on every management endpoint; metric write operations have an additional permission bit
- The server resolves three roles: super admin → Administrator; company role binding → Data Owner; otherwise → Analyst
- In Data Sources click Add (5 types: SQL / API / File / NoSQL / Document) → Test Connection → Discover Datasets → Refresh
- Delete confirmation text: "This will delete all discovered datasets and fields, and cannot be recovered; external source data and uploaded files will NOT be deleted."
- In Dataset Dict use LLM auto-fill / batch suggest to fill field Chinese names — the better the dictionary, the better the NLQ results (the model relies on Chinese names to understand field semantics)
- In Classification click Auto-grade to get the L1–L4 draft, then always review manually (it knows "phone" but probably not "cust_tel_no")
- In Auth Matrix always set the default row (
company = *) first as a catch-all, then add per-company / per-role exceptions — otherwise you'll see "forgot to set it, nothing got blocked"
- In KB Scope by Company bind knowledge bases that should participate in GraphRAG import first; unbound KBs get 403 (this is by design, not a bug)
- Two tabs: Query / Audit Log
- Input placeholder: "Please enter a natural-language question, e.g. query sales by region for the last 30 days"
- Result panel shows: View generated SQL / Masked / Source / Dataset / Duration / Truncated / Agent execution trace
- Click "Wrong answer" + provide the corrected SQL → feedback is stored as a future reference sample
- Click "Save as Metric" on a verified query → it directly becomes a metric draft, no need to regenerate next time
4. Quality, Alerts, Governance
- Data Quality: attach 5 rule types (completeness / uniqueness / validity / timeliness / accuracy), run on schedule; if quality drops, alerts fire automatically — don't wait for business users to notice a misaligned report
- DataOps alerts: types include metric anomaly / quality failure / query latency / source unavailable; leaving the receiver empty falls back to the creator — set the receiver explicitly when creating the rule
5. Exception Handling & Rollback
| Exception | Handling |
|---|
| Auth matrix changed, but query still shows old data | Permission cache has a 30-second delay — current process picks it up immediately, but independently deployed MCP services may take up to ~30 seconds |
| Accidentally deleted datasets when removing a source | The delete prompt explicitly says "will delete discovered datasets and fields, cannot be recovered" — it does NOT delete external source data or uploaded files; re-discover to restore |
| CDC configured but data still not real-time / cross-tenant data leak in tag wide table | CDC is currently a registration flag only, it does NOT actually sync; the tag materialized wide table is the highest cross-tenant risk surface — there is a known historical issue with missing company-isolation columns, confirm isolation before going multi-tenant |
5. Best Practices
- Connect sources first, then enrich the dictionary: Auto-discover populates field names, but Chinese names and descriptions need LLM auto-fill. The richer the dictionary, the better the NLQ.
- Always grade sensitive fields: Rule-based auto-grading is only a starting point — "phone" it knows, "cust_tel_no" probably not — manual review is mandatory.
- L1 is the MOST sensitive — don't flip it: L1 = highest sensitivity, L4 = public. This direction has been inverted historically and reversed once — it's an easy mistake when configuring the auth matrix.
- Default row first in the auth matrix:
company = * is the global catch-all row. Set the default row first, then add exceptions — otherwise you'll see "forgot to set it, nothing got blocked".
- Materialize results, not raw data: Raw data flows through federated direct query (does not land), materialization only covers cross-source processed asset results (metric values, tag wide tables, audience members). Raw data stays with the customer, assets live in the platform.
- Promote frequent questions into metrics: When the same question gets asked a second time, make it a metric. Don't regenerate the query every time. Only published metrics are scheduled for materialization and watched by anomaly detection.
- Read the audit correctly: Plaintext / masked / denied are mutually exclusive and exhaustive; only the "plaintext" column answers "who got the real data" — don't be misled by "call count".