查询与治理选型

查询服务要回答的两个问题

1. 重计算去哪跑？ 看板查询归 Doris；临时 JOIN、探索式分析归 Spark，但不能让每个人自己起 Spark。
2. 取数谁管权限？ 应用和外部系统不能裸连数据库，必须有一个统一出口做认证、限流、脱敏、审计。

一、Kyuubi：SQL 服务化

问题：开发和分析师经常要跑临时 SQL（多表 JOIN、窗口、抽样），这类查询不适合放 Doris——Doris 适合固定规则的看板查询，临时大查询会把 BE 打满，影响线上。

方案：Kyuubi 把 Spark SQL 做成多租户服务：

• 用户通过 JDBC/ODBC 连 Kyuubi，提交 SQL；
• Kyuubi 按队列/租户动态申请 Spark Executor；
• 查询结束，资源释放；
• 认证接 LDAP/Kerberos/SSO，权限可接 Ranger。

即查即用，不占常驻资源，这是它相对"给每个人发一个 Spark 集群"的核心价值。

落地要点：

• 引擎类型选 Spark（也可接 Flink/Trino，但本栈只需要 Spark SQL）；
• 开动态资源分配，设最大 Executor 上限，防止一个大查询吃光集群；
• 结果集大小限制 + 超时，避免把结果拉爆客户端；
• 查询日志落 Loki，审计可查。

二、受控网关：怎么落，选什么

很多方案只强调“对外只暴露网关一个地址”，但没有指定用什么做 SQL 层的脱敏与行级过滤。这是常见的设计空白。结论先说：不引入独立的 SQL 代理产品，把“网关”拆成三个执行点，各管一段。

推荐架构

BI / 内部报表  ──JDBC(MySQL)──►  Doris FE（只读账号 + 行/列权限）
分析师 / 数仓  ──JDBC──────────►  Kyuubi（Spark SQL，多租户 + Ranger 策略）
应用 / 外部系统 ──HTTPS────────►  Envoy Gateway ──► 取数 API（参数化查询/字段白名单/限流）──► Doris / Kyuubi

执行点	负责	不负责
Doris FE	BI 看板、MySQL 协议接入、库表/行列权限、审计日志	临时大查询、跨源 JOIN
Kyuubi	临时分析、Spark SQL 多租户、队列隔离、Ranger 行列策略	看板高并发点查
Envoy Gateway + 取数 API	应用/外部取数：认证、限流、字段白名单、参数化查询、审计	通用 SQL 代理

为什么不上独立 SQL 代理

方案	能力	问题	结论
Doris 内置 RBAC + 行/列权限	对 Doris 直连生效，开箱即用	只管 Doris，管不了 Spark/Kyuubi	BI 侧主推
Kyuubi + Ranger	统一行列级策略、审计、队列	多一套 Ranger（DB + Solr），策略要维护	SQL 侧主推
ShardingSphere Proxy	MySQL 协议、SQL 改写、脱敏	多一跳、SQL 方言兼容要压测、运维成本高	备选，非必要不上
自研 SQL 网关	完全贴合业务	长期维护成本高，SQL 解析是坑	不推荐
Envoy Gateway 当 SQL 网关	能做 L4 转发和 TLS	看不懂 SQL，做不了列脱敏	只能管 HTTP

多一个 SQL 代理，就多一层 SQL 方言兼容和性能瓶颈。Doris 本身说 MySQL 协议、有行/列权限；Kyuubi 本身是多租户 SQL 服务、能接 Ranger。把职责放到执行点上，比造一个"万能网关"稳。

三段权限怎么落

1. 身份：所有入口接统一 OIDC/LDAP，禁匿名；Doris/Kyuubi 各自校验，网关只做 HTTP 侧的令牌校验。
2. 表级：Polaris 管 Iceberg 表授权，Doris 管内表授权；引擎用 service principal，人用个人身份。
3. 行/列级：BI 场景用 Doris 行/列权限；Spark/Kyuubi 场景用 Ranger 的 row filter / column mask；应用取数在 API 层做字段白名单，不把 SQL 暴露给调用方。
4. 审计：Doris audit log + Kyuubi 查询日志 + 网关访问日志，统一进 Loki，按用户/表/时间可查。

测试阶段怎么做

• 不装 Ranger、不装 SQL 代理。Ranger 要带 DB + Solr，短期测试不值当。
• Doris 建一个只读账号，只在内网用；Kyuubi 可不装（用 spark-sql 代替）。
• 外部取数不开放；如果一定要演示，写一个 20 行的 REST 服务，只执行参数化查询 + 字段白名单。
• 把"生产要补 Ranger"写进验收清单，别把测试期的简化当成最终方案。

底线：不要让外部系统直连 Doris。宁可只开 HTTP 取数，也不要留一个没有脱敏的 JDBC 口子。

三、OpenMetadata：元数据与血缘

对比

维度	OpenMetadata	DataHub	Apache Atlas
部署与运维	单体服务 + PostgreSQL + 可选搜索索引，栈内组件即可承载	依赖消息队列、搜索、图库等多个组件	依赖 HBase / Solr，技术栈老旧
连接器覆盖	内置数十种连接器，Iceberg / Doris / Kafka / PostgreSQL 直接接入	连接器较多，Iceberg 血缘需额外配置	以 Hadoop 生态为主
血缘能力	表级与列级血缘，可从 Iceberg 快照与 OpenLineage 事件自动采集	采集链路更长	以手工登记为主
质量与治理	内置数据质量测试	质量能力需外接	无质量模块
AI 侧接口	原生提供面向 AI 应用的元数据上下文接口	需自行封装	无
许可	Apache-2.0	Apache-2.0	Apache-2.0

结论：OpenMetadata 部署轻、连接器覆盖广、原生带质量模块与 AI 侧接口；DataHub 仅作为备选。

落地要点

1. 先接三类源：Iceberg（Polaris）、Doris、Kafka，把核心链路的表先纳管。
2. 血缘靠事件，不靠手工：Spark/Flink 作业开 OpenLineage 上报，OpenMetadata 消费事件生成血缘；手工登记只用于外部系统。
3. 质量测试从关键表开始：主键唯一、空值率、行数波动、枚举值域，不要一上来铺全表。
4. 搜索索引可重建：ES 挂了不影响元数据本身，重建索引即可。

四、可观测：指标、日志、告警

组件分工

组件	职责
Prometheus	拉取/接收指标，存 TSDB
Alertmanager	告警分组、抑制、按级别路由
Grafana	统一看板，指标与日志同一界面
Alloy	采集日志（也支持指标），替代 Promtail
Loki	日志存储，按标签索引

标签规范（必须先定）

cluster, env, namespace, app, component, instance

指标和日志共用同一套标签，才能"从告警点进日志"。标签别放高基数字段（用户 ID、SQL 文本），否则 Loki 会爆。

告警分级

级别	定义	响应	例子
P1	业务不可用	15 分钟内	Doris FE 全挂、Kafka 不可写、Polaris 不可用
P2	功能降级	1 小时内	入湖延迟 > 30 min、BE 磁盘 > 85%
P3	需要关注	次日	快照未过期、证书 30 天内到期

必须有的看板

1. 链路健康：CDC 延迟、Kafka lag、Flink checkpoint 时长与失败数、入湖文件数。
2. 查询健康：Doris QPS / P99 / 慢查询、Kyuubi 队列等待。
3. 存储健康：S3 容量与请求错误率、Ceph OSD 状态、PG 连接数与慢查询。
4. 平台健康：节点 CPU/内存/磁盘、Pod 重启次数、证书过期时间。

许可提醒

Grafana、Loki、Alloy 都是 AGPL-3.0。内部部署不触发分发义务；如果这套平台要作为产品交付给客户，需要法务复核，或换成 Apache-2.0 的替代（如 OpenSearch Dashboards + Fluent Bit + VictoriaMetrics 的组合）。

结论

决策点	结论	备选	备注
临时 SQL	Kyuubi	直连 Spark Thrift Server	多租户、动态资源
HTTP 出口	Envoy Gateway	APISIX / Traefik	认证、限流、审计
SQL 出口（BI）	Doris 只读账号 + 行/列权限	—	MySQL 协议，接入成本最低
SQL 出口（分析）	Kyuubi + Ranger	Spark Thrift Server + Ranger	行列级脱敏、审计
应用取数	REST 取数 API	GraphQL / 预计算宽表	参数化查询、字段白名单
独立 SQL 代理	不引入	ShardingSphere Proxy	多一跳、兼容性风险
元数据	OpenMetadata	DataHub	部署轻、血缘自动
血缘采集	OpenLineage	手工登记	作业侧埋点
指标	Prometheus + Alertmanager	VictoriaMetrics	云原生标准
日志	Alloy + Loki	Fluent Bit + ES	与指标同标签
看板	Grafana	—	注意 AGPL