3. 技术选型与架构设计：前端框架、后端服务、数据库的选型理由
做数据质量看板，技术选型这一步，我见过太多团队栽跟头。有的上来就堆微服务，结果三个月连原型都跑不起来。有的图省事全用低代码平台，最后发现自定义图表和告警逻辑根本写不动。
说白了，选型不是选「最火的」，而是选「最不后悔的」。这一章，我把我在几个企业级项目里的真实选型过程拆开来讲。你想想看，一个数据质量看板，核心就三块：前端展示、后端处理、数据存储。咱们一块一块说。
3.1 前端框架：为什么我选了 Vue 3 + TypeScript
前端框架的争论，说实话有点审美疲劳了。但落到数据质量看板这个场景，我的选择很明确——Vue 3 + TypeScript。
原因有三：
- 上手快，团队好招人：国内前端圈子，Vue 的普及率比 React 高不少。我上一个项目招了 6 个前端，5 个写过 Vue。培训成本几乎为零。
- 响应式系统天然适合看板：数据质量看板的核心是「数据变化驱动视图更新」。Vue 3 的 Composition API + reactive/ref，写起来比 React 的 useState + useEffect 要直观得多。尤其是实时数据流进来的时候，Vue 的依赖追踪机制几乎不需要手动优化。
- TypeScript 是必选项，不是可选项：数据质量看板里，字段类型、质量规则、告警配置，全是结构化数据。没有类型系统，维护到后期就是灾难。我在一个老项目里吃过这个亏——一个字段名拼错了，线上跑了两周才发现。
我的实际选型组合：Vue 3 + TypeScript + Vite + Pinia + ECharts
Vite 做构建工具，开发体验极好。Pinia 替代 Vuex，类型推导更友好。ECharts 做图表渲染，数据质量看板里常见的趋势图、分布图、热力图，它都有现成的组件。
一个小建议：如果你团队 React 更强，用 React 也没问题。但别在同一个项目里混用两个框架。我曾经见过一个团队，前端一半 Vue 一半 React，最后联调时接口对不上，互相甩锅。选一个，用到底。
3.2 后端服务：Python FastAPI 为什么比 Flask 和 Django 更合适
后端选型，我几乎没犹豫——Python FastAPI。
你可能要问：为什么不选 Flask？或者 Django？
嗯，我一个个说。
- Flask：太轻了。数据质量看板需要数据源管理、规则引擎、调度任务、告警推送。Flask 的生态虽然丰富，但很多功能得自己拼。拼到最后，你会发现你写了一个「Flask 版的 Django」。
- Django：太重了。ORM、Admin、Auth 全给你配好了。但数据质量看板的后端，核心是「高性能 API + 异步任务」。Django 的同步模型，在处理大量数据质量检查任务时，性能瓶颈很明显。
- FastAPI：刚刚好。异步原生支持，性能接近 Node.js 和 Go。Pydantic 做数据校验，天然适合定义质量规则和检查结果的数据结构。自动生成 OpenAPI 文档，前端对接接口时几乎不用额外沟通。
我记得在一个项目中，我们需要对 200 多张表做数据质量检查。用 FastAPI 的异步接口，配合 Celery 做任务队列，单台服务器就能扛住每分钟上千次的检查请求。换成 Flask 同步模型，同样的机器，CPU 直接打满。
避坑指南：我曾经在 FastAPI 里直接用同步的 SQLAlchemy，结果异步接口被阻塞，性能还不如 Flask。后来改用 asyncpg + SQLAlchemy 1.4 的异步模式，才把性能拉回来。记住：用了 FastAPI，就尽量别写同步代码。
3.3 数据库：PostgreSQL 和 ClickHouse 的分工
数据库选型，是这次架构设计里最值得聊的部分。数据质量看板，数据流向其实分两条线：
- 元数据与配置：数据源信息、质量规则、检查结果、告警记录。这些数据量不大，但关系复杂，需要事务支持。
- 时间序列指标：每张表、每个字段、每条规则，每次检查都会产生一条指标记录。一天下来，几百万条是常事。一个月就是上亿条。
一条数据库，搞不定。我的方案是：PostgreSQL 管配置，ClickHouse 管指标。
| 对比维度 | PostgreSQL | ClickHouse |
|---|---|---|
| 数据场景 | 元数据、规则、配置 | 时间序列指标、日志 |
| 写入模式 | 频繁更新、删除 | 批量追加，几乎不更新 |
| 查询模式 | 单条查询、关联查询 | 聚合查询、范围扫描 |
| 事务支持 | 强事务（ACID） | 弱事务（最终一致） |
| 存储引擎 | 行存 | 列存 |
| 压缩比 | 一般 | 高（5-10倍） |
你看这个对比就清楚了。PostgreSQL 负责「精确」，ClickHouse 负责「快速」。两者通过数据同步机制打通——我一般用 ClickHouse 的 PostgreSQL 表引擎直接查询，或者用 Kafka 做异步同步。
一个典型的查询场景：
用户想看「过去 30 天，订单表的非空率趋势」。
- PostgreSQL 里查「订单表」的规则配置
- ClickHouse 里查「过去 30 天，规则 ID = xxx 的每日非空率」
- 前端拿到数据，直接渲染 ECharts 折线图
整个查询，后端接口响应时间控制在 200ms 以内。
3.4 整体架构图
下面这张图，是我在一个数据质量平台项目里实际落地的架构。你看一眼，基本就明白数据是怎么流的了。
这张图里，数据从底层的数据源流入，经过后端服务处理，分别存入 PostgreSQL 和 ClickHouse。前端通过 API 网关统一查询，最终渲染成看板。每一层的职责都很清晰，出了问题也能快速定位。
3.5 选型总结
最后，我把这一章的核心选型结论整理成一张表，方便你以后做技术评审时直接参考：
| 层级 | 技术选型 | 核心理由 |
|---|---|---|
| 前端框架 | Vue 3 + TypeScript | 响应式系统适合看板场景，TypeScript 保证类型安全 |
| 后端服务 | Python FastAPI | 异步高性能，Pydantic 数据校验，自动生成 API 文档 |
| 配置数据库 | PostgreSQL | 强事务，适合元数据和规则管理 |
| 指标数据库 | ClickHouse | 列存高压缩，适合海量时间序列指标的聚合查询 |
选型这件事，没有银弹。但如果你做的也是数据质量看板，这套组合我亲自验证过，能扛住日均千万级指标数据的写入和查询。剩下的，就是落地细节了。