KISS 数据架构：让数据系统回归简单

Keep It Simple, Stupid（保持简单，别整那些没用的）

在数据工程的世界里，我们常常被各种新潮工具、复杂框架和“高大上”的架构方案所吸引。但现实是：越复杂的系统，越容易出问题；越简单的架构，越能扛住业务压力。

本文将带你拆解两个核心原则（DRY 和幂等性），并揭示六大“简洁杀手”——那些看似合理、实则拖垮团队效率的陷阱。最后，通过两个真实场景对比，你会明白：真正的技术成熟，不是堆砌工具，而是敢于做减法。

第一部分：技术原则

1. “别重复自己”（DRY）原则

“Don’t Repeat Yourself”（DRY）是软件开发中的黄金法则：每个知识片段，在系统中必须有且仅有一个权威、清晰、无歧义的表达。

但在实际数据管道中，这条原则经常被忽视。比如，“总营收”（Total Revenue）这个指标，可能同时出现在：

• Python 脚本里（用于数据清洗）
• Airflow 编排逻辑中（用于条件判断）
• SQL 数仓模型里（主逻辑）
• 语义层（Semantic Layer）中（用于仪表盘展示）

结果？当 CEO 问：“为什么仪表盘上的数字不对？”你得像侦探一样，横跨五六套工具，逐行排查哪一行代码出了问题。

这就是 DRY 原则被破坏的代价：业务逻辑碎片化，信任崩塌，响应迟缓。

✅ 正确做法：把业务逻辑集中在一个地方

我们可以把整个数据流程分为两类逻辑：

• 非业务逻辑（数据搬运工）

  • Extract/Load（抽取/加载）：只负责把数据从 A 搬到 B，不做任何处理。越“傻”越好。
  • 建模（Modeling）：用 dbt、Dataform 等工具，对原始数据做标准化处理——去重、补空值、展开嵌套结构等。这一步仍不涉及业务含义。

• 业务逻辑（核心价值所在）

  • 集中式语义层（Centralized Semantic Layer）：所有指标定义（如“活跃用户数”“净收入”）都放在这里，只定义一次，并在高性能数仓（如 BigQuery、Snowflake）中执行。

这样，当 CEO 再问数字问题时，你只需打开一个文件、一个仓库，就能定位问题。其他环节只负责“搬砖”，不掺和业务判断。

语义层的关键价值：它大幅缩小了故障排查范围。在生产事故中，时间就是信任——你没有时间翻遍整个技术栈。

现代语义层（如 dbt Semantic Layer、Looker 的建模层）是“虚拟层”：它们不复制数据，而是直接调用数仓的计算引擎生成查询。这意味着：

• 一致性高：所有报表看到的是同一个数字。
• 治理强：指标定义可版本控制（Git）、可审计。
• 分工明确：数据工程师专注搬运，分析师专注业务，互不干扰。

小提醒：即使在语义层内部，也要避免重复定义。如果“活跃用户”已有标准定义，请复用它，而不是另写一个。否则，你只是把混乱从“跨系统”转移到了“系统内”。

2. 幂等性：终极简化器

幂等性（Idempotency） 是指：一个操作无论执行一次、十次还是一百次，最终结果都一样。

在数据管道中，这意味着：失败后只需重跑，无需人工干预。

❌ 复杂做法：依赖状态 + 时间戳

很多团队用复杂的 MERGE 或 UPDATE 语句，靠时间戳判断是否要插入/更新记录。一旦任务中途崩溃，就可能出现：

• 主键重复
• 部分更新（一半成功一半失败）
• 数据不一致

这时，恢复不是“点一下重跑”，而是一场灾难排查。

✅ 简单做法（KISS）：原子覆盖

更好的策略是：以原子粒度（如按天分区、按批次 ID）完全重新计算，并整体覆盖。

例如：今天处理的是 2025-12-22 的数据？那就把这一天的所有结果重新算一遍，然后一次性写入。这样：

• 结果一定正确：因为完全基于源数据重建。
• 恢复极其简单：任务失败？直接重跑。没副作用。

如果你半夜被叫醒修数据，却不敢点“重跑”，怕把销售额翻倍——那你建的不是数据管道，而是一颗技术定时炸弹。

第二部分：简洁的六大敌人

3. 小心“个人 agenda”

有些工程师或顾问会故意把系统搞复杂，原因很现实：

• 简历驱动开发（Resume-Driven Development）：为了在 LinkedIn 上写“精通 Kafka + Spark + Kubernetes”，强行引入这些技术，哪怕业务根本不需要。
• 顾问过度设计（Consultant Overkill）：外部顾问推荐定制化、难维护的方案，只为绑定长期服务合同。

记住：复杂性应该是规模的代价，而不是存在的入场券。

✅ 自查清单：“这真的必要吗？”

• 流处理 vs 批处理
  如果高管每天只看一次报表（比如早上 9 点），那用夜间批处理就够了。它更简单、便宜、稳定。流处理（如 Kafka + Flink）只有在业务需要秒级响应时才值得投入。

• NoSQL vs 结构化存储
  NoSQL（如 MongoDB）适合真正无结构、海量、快速变化的数据。但如果你的数据是订单、用户、交易——请用关系型或列式数据库（如 Postgres、BigQuery）。Schema 是第一道数据质量防线。

• 专有工具 vs 开放标准
  警惕那些要求你用私有语言、私有格式、私有 API的方案。它们制造“锁定效应”，让你离不开某个厂商或顾问。
  优先选择支持 ANSI SQL、Parquet、Iceberg、Delta Lake 等开放标准的技术，确保未来可迁移。

4. 别拿冷门框架当“量身定制”

有些工程师故意用冷门框架（比如用 Scala UDF 写 Spark 函数，尽管 SQL 就能搞定），目的很简单：制造高“巴士因子”（Bus Factor）。

巴士因子：指一个项目在多少关键人员“被巴士撞了”（离职）后会瘫痪。因子越低，风险越高。

当唯一懂那段代码的人走了，整个团队就卡住了。这不是能力，这是职业绑架。

✅ 负责任的团队应坚持：

• 使用通用语言（SQL、Python）
• 遵循清晰、自解释的建模范式
• 让任何人接手都能快速理解

5. 工具泛滥（Tool Sprawl）

“现代数据栈”（Modern Data Stack）听起来很酷，但不是每个公司都需要 Fivetran + dbt + Snowflake + Airflow + Looker 全家桶。

每多一个工具，就多一个：

• 供应商
• API 接口
• 安全边界
• 故障点

结果？集成成本飙升，开发速度变慢。

✅ 更聪明的做法：先榨干现有云平台的能力。AWS、GCP、Azure 都提供了从 ETL 到 BI 的全套服务。能用原生功能解决的，就别急着加新工具。

6. 别被“无服务器”忽悠了——它可能带来更多运维负担

很多人认为：“自己搭 Kafka 集群比用 Pub/Sub 便宜”、“自建 Airflow 比用 Cloud Composer 省钱”。

但别忘了：总拥有成本（TCO）包括人力！

• 自建集群 = 要人监控、调优、打补丁、处理故障
• 这些时间，本该用来写业务逻辑

更讽刺的是：外部顾问往往鼓吹 DIY，因为他们靠维护这些复杂系统赚钱。

✅ KISS 思维：把“无差别重型劳动”外包给云厂商。你付钱给 AWS/GCP/Azure，让他们管硬件、扩缩容、高可用。你的团队，只专注 SQL 和业务逻辑。

你的公司卖的是产品或服务，不是 Kafka 运维服务。

实战对比：两种架构，两种命运

方案 A：号称“厂商无关”的鲁布·戈德堡机器 🤯

鲁布·戈德堡机器：用极其复杂的方式完成一件简单事。

流程：

1. 数据存在 BigQuery（好好的）
2. 用 Airflow 调 Python 脚本，从 BigQuery 抽全量数据
3. 通过公网传到外部云（产生高昂出口流量费）
4. 插入 MS SQL Server（还要管索引、容量、备份）
5. 在 SQL Server 里建视图定义基础指标
6. Power BI 导入数据
7. 因为视图不够用，再在 Power BI 里写复杂 DAX 补逻辑

问题：

• 逻辑分散：基础指标在 SQL，时间智能在 DAX → 违反 DRY
• 延迟高：每天全量同步，数据永远不是最新的
• 脆弱：任一环节失败，整个报表瘫痪
• 成本高：VM、网络、SQL Server 许可、人力维护

你买了一辆法拉利（BigQuery），却用骡子（SQL Server）拉着跑，只为证明“我不依赖法拉利”。

方案 B：“Just use LookML” 的极简之道 ✅

流程：

1. 数据留在 BigQuery
2. 用 LookML（声明式语言）定义所有指标、维度、时间智能
3. LookML 代码存 Git，版本可控
4. 任何 BI 工具（Power BI、Tableau、Excel）通过语义层查询
5. 用户点击报表时，Looker 自动生成最优 BigQuery SQL 并执行

优势：

• 单一事实来源：指标只定义一次，所有工具看到相同数字
• 实时性：无需每日同步，数据始终最新
• 高效：计算在 BigQuery 内完成，利用其分布式能力
• 零运维：无 VM、无 Airflow DAG、无数据搬运、无出口费

BigQuery 负责算力，LookML 负责治理，Power BI 负责画图——各司其职，简单可靠。

终极真相：“厂商锁定”是个伪命题

方案 A 声称“避免厂商锁定”，结果却陷入了 “复杂性锁定”：

• 想换云？得重写 Airflow、VM 脚本、SQL Server 视图、DAX 公式……

方案 B 虽然用了 Looker + BigQuery，但：

• 语义层（LookML）是可移植的资产
• 换 BI 工具？只需新连接器
• 换数仓？虽然成本高，但至少指标定义是统一的，迁移更快

真正的自由，不是不用某个厂商，而是你的核心逻辑不被任何工具绑架。

结语

KISS 不是偷懒，而是对复杂性的敬畏。

在数据架构中，简单 = 可靠 = 可维护 = 可扩展。

下次当你想引入一个新工具、写一段炫技代码、或设计一个“灵活”但模糊的指标体系时，请问自己：

“这真的让事情更简单了吗？还是只是让我看起来更厉害？”

保持简单，才能走得更远。