前言

在数据仓库开发的过程中，常常会遇到很多值得思考的问题，它们不仅关乎技术的深度，也涉及业务理解、个人的成长，甚至是数据行业未来的价值。回顾过去的经历，有很多问题反复出现，甚至成为绕不开的课题，我自己挑选了9个问题，将其分成了四类，重新进行回答。

关于数据建模的终极追问  

为什么建模？必须建模吗？

提起建模，大家都会说是为了规范数据存储，提升查询效率，支撑业务分析。但有时也会思考：如果业务需求足够简单，是否真的需要构建复杂的模型？

我的当前答案则是：数仓开发不一定必须建模，但大多数情况下，建模能够提升数据的可维护性、复用性和查询性能。是否需要建模，取决于业务需求、数据复杂度以及数据消费方式。大体的判断分类可以分为：

结论：建模不是目的，而是手段

• 如果数据需要标准化、优化查询、跨系统整合，那么建模是必要的。

• 如果数据规模小、变化快、或者是探索性分析，直接查询可能更适合。

怎么证明你建的模型就比别人的好？

既然要比较，必然先有评价标准的。

首先，一个“好”的模型应该具备 高质量（数据可用性）、高性能（查询优化）、高扩展性（支持未来需求）、高复用性（减少重复开发），但如何量化这些指标？是数据查询的速度？业务团队的满意度？还是系统的稳定性？

我自己想到可以从以下几个方面来看：

只有用数据说话，才能真正证明你的数据模型比其他团队的好。

当然，公司也有内部数仓建模规范2.0/3.0，对于建模选择都有明确的说明，可便于大家参考。

必须由数仓来做吗？业务系统不能做吗？

这个问题的本质是：数据处理的边界在哪里？业务系统和数据仓库如何分工？

我分3大点来尝试回答。

1、数据仓库的本质和核心价值

首先，先复习一下关于数据仓库的定义：

数据仓库之父比尔·恩门（Bill Inmon）在1991年出版的“Building the Data Warehouse”（《建立数据仓库》）一书中所提出的定义被广泛接受——数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making Support)。

所以，数据仓库的核心并非仅仅是存储或OLAP能力，而在于：

• 数据整合：跨业务系统的数据清洗、标准化、统一建模（如星型/雪花模型）

• 历史数据存储：长期存储业务系统通常不保留的历史数据（如10年交易记录）

• 复杂分析支持：优化查询性能应对大规模关联分析、时间序列分析

• 数据治理：元数据管理、数据血缘、权限控制体系

2、业务系统能否替代数仓

部分场景可以，但存在明显边界：

• 可行场景：单业务系统的简单报表、实时性要求高的OLAP查询（如PolarDB HTAP能力）

• 不可替代场景：对于跨多个业务系统、跨时间周期长、大规模的数据查询分析

3、传统数仓 VS 现代数仓的演变

随着存储和计算等新技术的发展，对于原本的数仓开发也带来了一定的改变，具体的比较见下，虽然在某种程度上，双边的界限会存在一定的模糊，但是 两者还是有所不同。

技术演进的影响：

• PolarDB等HTAP数据库确实模糊了OLTP/OLAP的硬件层边界

• 但数仓的核心逻辑（数据整合、建模、治理）仍需通过架构设计实现

• 未来可能形成“业务系统负责实时分析，数仓负责跨系统深度分析”的互补架构

结论：由上面的3点，数仓 ≠ 业务数据库，只是数据仓库的适用场景不同。对于面向复杂分析的很多数据不应该放在业务数据库里，而应该交给数仓做统一管理、优化查询、支撑决策分析。

数据研发的价值证明体系

需求已经写得那么明确了，你的建模体现在哪里？

在真实的开发场景中，有些时候数据bp比研发人员还要更加的了解数据的全流程以及具体的使用，这种场景下，还有所谓的建模吗？

这个问题的本质是：数据建模的价值在哪里？是否只是简单地“翻译”需求？

如果数据开发只是“翻译”需求，那和直接写 SQL 计算数据没区别。AI不就可以干了么。但真正的建模价值体现在：

(1) 数据整合

• 通过数仓分层（ODS → DWD → DWM → APP），把零散的业务数据整合为统一数据资产。

• 例如：“用户登录、支付、订单”分散在不同系统，数仓建模后可快速计算用户生命周期指标。

(2) 数据标准化

• 例如：在“GMV 计算”中，不同业务线的“GMV”定义可能不同（是否包含退款、税费等）。

• 通过数仓建模，制定统一的GMV口径，所有报表和数据产品使用相同的计算方式。

(3) 提高查询性能

• 例如：一个业务查询需要跨 5 张表进行 Join，查询时间很长。

• 通过建模，将计算结果提前写入宽表（DWM层），查询时只需直接查询宽表，大幅提升性能。

(4) 数据复用

• 例如：多个团队都需要“日活用户数 (DAU)”，如果不建模，每个团队都要重复计算。

• 建模后，所有人都可以直接使用，避免重复开发。

但是，在实际情况中，比如，在之前开发中对于财务数据这种专业性较强的建设，可能会感觉建模的效果没有体现出来。说明可能以下几点没有做好：

只是简单写 SQL，没有建立数据资产。

没有考虑数据复用，导致相同数据多次计算。

没有优化数据结构，查询性能低下。

缺乏业务理解。

所以，即使需求已经很明确，建模仍然是数据开发的核心价值。

它决定了数据的组织方式、计算性能、可复用性，影响整个数据架构的可持续发展。

你的建模是业界通用的吗？

还是你自己制定的？如果是业界通用的，那么你的特色体现在哪里？

这个问题翻译过来是：什么时候用通用模型？什么时候需要自定义模型，以及两者之间如何比较，有可量化的指标吗？

业界的通用建模方法大家都知道，有 Kimball、Inmon、Data Vault 等，那么在实际的开发过程中，如何选择更适合的模型呢？

个人认为是需要根据业务场景、技术栈特性和数据规模进行深度适配，形成通用底座+业务增强的特色模式。

常规上来说，一般的比对指标有以下几种：

但是呢，看起来依旧有点主观，所以，我在想，有没有一种什么方式可以将其量化，抽象为一个计算公式？

查了查，发现想法类似于字节的三维模型，因此，个人认为也可以抽象为「场景复杂度-技术约束-ROI」三维评估模型。（仅为初步想法，并未真实验证）

1、量化评估公式

模型适配度评分 =(业务契合度 × W1) + (技术适配度 × W2) + (经济性指数 × W3)；其中：

权重系数（W1+W2+W3=1）可以分阶段进行动态调整，比如：

• 业务导向型：W1=0.6, W2=0.2, W3=0.2

• 技术驱动型：W1=0.3, W2=0.5, W3=0.2

• 成本敏感型：W1=0.4, W2=0.3, W3=0.3

2、参数定义与计算方法

业务契合度 (0-10分)

业务契合度 = (场景覆盖度 + 查询效率增益)/2 + 敏捷性修正值  

• 场景覆盖度 = (当前业务需求匹配数 / 模型支持最大场景数) × 10

例：某模型支持5种促销分析模式，当前需覆盖3种 → 得分6分  

• 查询效率增益 = (基准模型延迟 - 候选模型延迟) / 基准模型延迟 × 10

例：从星型模型(8s)切换到宽表(1.2s) → 得分(8-1.2)/8×10=8.5分

• 敏捷性修正值： 

需求变更频率 ≤1次/月: +0  

1次/周: -1  

每日变更: -3  

技术适配度 (0-10分)  

技术适配度 = (工具链匹配度 + 团队能力指数)/2 *可维护性系数  

• 工具链匹配度 = (支持该模型的工具数 / 企业现有工具数) × 5 + (专用优化功能存在性 × 5) 

• 团队能力指数 = (团队成员平均建模经验年限 × 2) ，最高5分  

• 可维护性系数 = 1 - (模型复杂度指数 × 0.1)  

复杂度指数 = 表数量 × 0.3 + 关联层级 × 0.7

经济性指数 (0-10分)

经济性指数 = 可接受成本/(开发成本 + 三年运维成本)  

• 可接受成本 = 项目预算

• 开发成本 = 人力成本(人天×单价) + 资源消耗 

• 运维成本 = (日常维护工时 × 单价) + 存储费用 + 计算费用  

3、决策规则

分别计算出模型A和模型B的分数，如果差别不大，可以使用偏向通用模型。如果差异过大，可以使用自定义模型。

怎么证明数据的价值？

辅助决策，有具体的例子吗？

回顾ERP的项目，更多都是财务方向的建设，我们一直在说数据的建设是辅助管理层决策，但是，有没有办法直观的感受到或者量化这个决策的影响度。这个我也没有找到更好的量化方式，也期望得到大佬们的解答。

职业发展的本质思考

 除了技术本身，做数据仓库的这几年，也让我不断思考职业发展的问题。

对于职业发展的焦虑？

当一个行业或岗位无法提供新的挑战和成长空间时，很多人会选择寻找新的机会。对于我个人而言，最核心的问题是：对于职业发展的焦虑。

我所在乎的一般有3点

• 技术成长曲线（新技能突破）

• 业务贡献度（受认可，工作内容可以影响核心指标）

• 所在环境提供必要挑战（如团队不断有新的业务）

当感受不到技能成长的时候，会问自己，我的技能还能走多远？新的技术的出现，是不是会导致自己很快被淘汰？当衡量不出来价值的时候，会质疑自己存在的必要性，严重会上升到对于数仓开发的怀疑。

如果让你再做一次，你会怎么做？

如果重来一次，则要关注数据资产化治理，与业务方加强沟通，多多理解业务知识。让数据不仅是业务的支撑，而是成为业务的资产。同时，我会更注重数据治理，保证数据一致性、可复用性、可追溯性，而不是只关注“报表跑得快不快”。

面向未来的生存法则

技术环境变化太快了，按照自己现在的规划路线，还能走多远呢？

AI 时代，数据研发还值钱吗？

这是我最近思考最多的问题之一。AI 的发展让数据的价值进一步凸显，但同时也对数据研发提出了更高的要求。未来的数据工程师，不仅仅是建模、ETL，还需要具备数据治理、数据质量管理、流计算、AI 结合数据分析等能力。

AI 可以加速数据处理，但不能完全取代数据治理和数据决策。数据研发仍然重要，但角色正在进化，未来的数仓开发可能不只是建模，而是构建“智能数据平台”，让数据更好地服务于 AI 和业务。

总结

过去 4 年让我从一个数据开发者成长为一个更懂业务、懂建模、也懂数据价值的人。让我对数据的本质有了更深刻的理解，也让我意识到：数据的核心价值不在于使用了多么高大上的技术，而在于它如何影响决策，为业务带来价值。

欢迎大家对上述问题，展开探讨，留下你的想法，将抽取5位同学，送上“滴滴技术双肩电脑包”！