亚马逊AWS官方博客

浅谈企业 BI 数据建模流程与指标定义的一些实践

背景：建模与指标概念

在商业智能（BI）项目中，数据建模常常采用宽表的方式，将多张事实表和维度表预先整合成一张「大宽表」。宽表包含了详细明细字段（供业务明细查看）、统计度量字段（供聚合计算）以及组合和过滤字段（作为统计条件）等。比如，我们需要按区域统计商品在某个地区、某个时段、某个经销商的销售量，或者总销售额，那么就会把地区信息、经销商信息以及时段信息这些原来分散在多个表中的数据，拼接成一张「销量及销售额宽表」。这种模型通过牺牲范式化来换取查询便利，允许业务用户在前端自由拖拽维度和度量，快速组合分析视图。

在需求调研阶段，业务方往往会给出混杂的信息：既有希望展示的指标（如销售额、用户数等需要汇总或计算的值），也有维度细分（如地区、时间段）和特定过滤条件。这就需要数据团队将需求加以拆解：区分哪些是维度，哪些是指标，哪些是需要应用的过滤条件。通常来说，「指标」指的是需要计算或汇总的度量值及算法，例如总和（SUM）、平均值（AVG）、同比/环比、窗口期平均等，这些往往由 BI 前端的聚合功能来完成。而「维度」（如产品类别、地区）用于分类汇总，过滤条件用于限定数据范围。当然，一层的指标，又可能会变成下一层的维度，比如「按经销商统计销售额」，此时「经销商的销售额总值」是一个指标，但是如果我要再「统计销售额超过 100 万的经销商」，此时「经销商的销售额总值」就变成了一个过滤条件。我们没有必要执着于定义，能明白传达意思即可。只需要知道一个数据统计需求一定包含了「指标」和「维度」两个因素，前者是「怎么算」，后者负责回答「拿哪些数据算」。

在宽表模型中，维度和基础明细指标字段预先准备好，但具体汇总计算（如求和、平均）通常由 BI 工具在前端触发执行，以保持灵活性。值得注意的是，在建模时我们通常并不会仅围绕某个特定指标来构建宽表。宽表往往设计为涵盖业务领域内尽可能全面的原子细粒度数据，以支持各种潜在的统计指标分析。换言之，宽表提供原始明细和可直接聚合的基础度量，至于选取哪些度量进行何种计算，则由前端分析需求来决定。这种模式确保了只要数据存在于宽表，业务用户就可以任意组合维度和度量进行分析，而无需频繁改动数据模型。

问题：指标逻辑拆分的挑战

理想情况下，宽表提供了统一的一版数据，所有报表都基于相同的数据源制作，从而保证了指标口径的一致性。宽表的核心逻辑下沉意味着大部分业务计算逻辑都已在数据层实现，同一指标在不同报表中天然保持一致。

然而在实际项目中，我们常会遇到一些超出 BI 工具前端能力的需求场景，例如非常复杂的过滤条件组合、需要跨行计算的窗口函数（如移动平均、累计去重计数等）、复杂的业务口径定义等等。这类指标由于计算逻辑复杂，BI 可视化界面的拖拽配置或简单公式往往无法直接支持。

结果就是，开发人员被迫在前端编写自定义的 SQL 查询或脚本来实现这些复杂指标，在 BI 工具中以自定义数据集方式加载。这种做法导致同一个指标的实现被拆分：一部分依赖宽表提供的基础数据，另一部分逻辑通过前端的 SQL 临时计算完成。而这个 SQL 通常只存在于报表配置中，并没有沉淀回数据仓库或模型层。

这种前后端割裂的实现方式带来了多方面的挑战：

• 指标定义不统一：由于特殊指标逻辑没有在数据层统一实现，不同报表或不同人员可能各自编写 SQL 计算，容易产生口径不一致的风险；缺少集中管理的指标定义，长远看会让数据治理变得困难。
• 维护困难：前端 SQL 隐藏在报表中，版本管理和复用性差。如果业务逻辑改变，必须逐个修改报表中的 SQL，增加了维护成本。数据模型和报表配置脱节，也让问题排查变得复杂。
• 性能与稳定性：复杂计算如果每次都由前端实时 SQL 执行，可能影响查询性能。而且数据侧无法感知前端的这些逻辑，难以及时优化。例如窗口函数计算大量数据时，交互性能会变差。
• 协同低效：需求方、数据建模人员和BI开发人员在这种情况下需要频繁沟通：数据模型是否需要扩充？前端实现是否正确？边界不清晰使协作流程变得混乱。

除此之外，在实际与企业的交流中，我们也会遇到业务所在垂直领域过于复杂，而数据团队尚沉淀不足，导致很多统计逻辑，业务团队觉得不该自己写，但是数据团队去写又总是容易写错的问题。这些都是非常常见，不可避免的问题，我们只能尽量用工程化的方式和流程来缓解和适应它，而没办法完全消除，因为这是这件事的天然复杂度的一部分。

接下来，我们将探讨这个问题，讲解一些实际工作中遇到的，前后端协同的优化流程。

指标定义的实践：统一管理与后端下沉

根据企业的人力、能力以及预算不同，我们可以通过下面一些手段，不同程度地缓解上述问题。

建立指标库/指标体系

有些企业会把指标做成一个像百科全书一样的「指标库」，对指标的计算公式、粒度、过滤口径进行元数据管理。例如定义每个指标的指标 ID、名称、业务定义、计算方式（汇总维度、过滤条件、计算类型等）。这样所有人引用指标时都清楚其含义和算法，这有助于口径统一。

每次需求到来时，大家都到指标库里面查询，确认找不到了，再新建所需的表，否则就修改或者服用现有的表。如果有逻辑变动，也应该同步修改到指标库中。有了这样一个工具，大家就有了一个类似普通话的语言，所有人在指代指标的时候，都会是同一个，不会产生任何歧义。

当然，越是看上去美好的东西越可能隐藏问题。指标库带来的问题，和我们把业务流程写成白皮书一样——太慢了。每一次的需求开始都需要找指标库，修改也需要同步指标库，逻辑变化也需要同步，修 bug 也需要同步。可想而知这个指标库会越来越庞杂，其中会蕴含非常复杂，甚至可能是很核心的业务统计逻辑。这会给它的维护带来诸多的问题，最后可能和祖传代码一样，大家就都不愿意再动它了，宁愿绕开。

这个时候就需要我们判断一下，我们的企业处于哪个阶段和类型。举例来说：如果一个需求用方法 A 需要 20 天做完，正确率 95%，而用方法 B 只需要 5 天做完但是有 50% 的几率做错。你的企业会选择哪种呢？

有的企业可能会坚定地选择 A。比如，因为业务和技术相隔甚远，甚至可能都不是同一家分公司，导致业务和技术不可能非常频繁的交流，成本太高。也可能这家公司是实业公司，IT 仅仅是支持部门，而业务处于非常强势的地位，IT 部门纵然担心做得慢，却更害怕做错了失去信任和信心。还有很多企业的业务性质就不允许「做错」，一旦做错就可能造成重大的经济损失和后果。这些都是促使企业形成坚实的流程制度的动机。

不过也有的企业会选择 B。可能这些企业本身就是 IT 为主，技术和业务其实是一体的，或者说没有那么大的分隔。做东西目标核心是快，先做出来，然后有问题慢慢再改。即便是统计错误或者不准确，往往影响面也不会太大，只需要调整即可。这类公司通常会比较轻文档和流程，有的可能文档和流程都处于洪荒阶段，一盘散沙到处都是。反而是在不断试错的过程中，这些经验知识都累积到了个人脑子里，第一次可能 50% 做错，做到后面可能就降到 20% 也可能。

所以这里没有一个通用的建议，大家可以按照需要来取舍。

预计算关键指标

对于复杂的统计指标，可以考虑在数据仓库中预先计算好结果并存储。典型的方法是在数仓模型中加入汇总层，将明细数据按需求汇总生成指标结果表。当用户查询时直接使用预聚合结果，大大减少前端计算压力。这种方式适用于固定的窗口统计、周期汇总等复杂指标计算。

这个算是典型的「空间换时间」的办法，预计算的结果可能是指标，也可能作为其他进一步计算的维度。当然，这里有几个点需要注意。第一，空间换时间其实就是把缓存换了一种说法，而缓存就一定会有失效的问题，如果你的计算需要非常实时的结果，那么可能需要考虑使用流式计算。第二，提前计算通常意味着维度已经被固化，这类预计算的表是不能像原始表那样随意组合和修改维度的。第三，因为缓存表基本就是把原来的逻辑写入了某个表或者物化视图，所以原始逻辑变化的时候，一定不要忘记同步更新。

虽然预计算可以在很多时候达到「秒出结果」的效果，但我还是建议尽量只在关键、反复出现、非常常用或基础的指标上使用，切勿滥用，导致无法维护。

逻辑下沉到 ETL

如果某些指标需要非常复杂的过滤或窗口计算，而业务又高度依赖这些指标，那么建议在 ETL 过程中提前实现这些逻辑。

例如，可以在宽表生成时加入相应的计算：窗口平均值、累计去重值等作为宽表的一个字段储存。如果指标逻辑涉及复杂的分组过滤，也可以通过在明细表中增加标志位或预分类字段来支持。例如「活跃用户数」需要定义 7 天内有登录行为，则 ETL 时为每个用户打上活跃标志，然后宽表聚合时直接使用该标志计数。通过这些核心逻辑下沉，宽表就能直接支持这些指标的前端展示，无需报表层再写 SQL。换句话说，就是宽表设计倾向于将核心业务逻辑提前实现，报表直接基于宽表出数时，各种指标天然保持一致。这是保证数据口径统一的有效手段。

当然需要注意的是，这里的「核心业务逻辑」，最好是真的和业务强相关的特定逻辑，而不是普通意义上的统计方法。比如「活跃用户」这个定义，就是业务强相关，不同行业和业务的需求明显会不同，而「销量总数」这种简单的逻辑则完全可以也应该在上层实现，避免下层又堆积很多无意义的统计。任何创造，添置任何新的东西，最后都会有维护成本，这点一定要小心。

数据开发流程

通过以上措施，我们可以更接近「单一事实来源」的指标体系：每个指标都在指标库中有定义，它要么在数据仓库汇总层统一实现，要么在 ETL 过程中处理，而不是散落在多个报表的自定义 SQL 中。虽然我们永远也无法达到这种理想状态，但也有一些方法可以帮团队进行磨合，达到一个适合团队的相对高效的工作模式。这里介绍一些方法，权作抛砖引玉。

因地制宜的数据流程

根据我的经验，很多实践落实不了，很重要的一个原因是，提出来了一些角色，但是又没有明确提出这些角色具体要做什么，负责什么部分，拿到方法的人也不知道怎么对应，就选了一个自己团队最像的来负责，结果导致效果不佳。

比如，我们可以说：在项目之初，业务需求方（产品经理或业务分析师等）应与数据团队充分沟通，明确所需指标的业务含义、计算口径和分析维度。针对每个需求中的指标，数据团队要判断其是否属于已有标准指标，抑或是全新且复杂的指标。如果是新指标，应当在指标库中进行定义，形成清晰的计算规则说明。这样一来，建模人员和 BI 开发都有共同的指标规范可参考。

这里就可能造成很多误解。比如，「业务需求方」具体是哪一方？有相当多的企业，最终的业务需求是管理层或者高层直接口述提出，而承接这个想法的是中层，中层直接传递或者再找实际业务团队传递，最后给到数据团队，实现完成后，最后确认是否 OK 的，却是管理层或高层。这里面，谁是需求方呢？是管理层，还是中层，还是最后实际传递需求的业务团队？也需你会说，需求方当然是管理层，或者全部都是需求方，但是我们既不可能把所有人都拉一起不停确认讨论，管理层通常也根本说不清楚自己想要什么，只有看到结果了，才说这个不是自己想要的。

然后，产品经理和业务分析师又都是谁呢？有的业务线有一个极其强势的大产品经理，所有业务的细枝末节都了然于心，其他的产品都看不到全貌，只能拿到自己负责部分的零碎需求去执行。我们这时候可以事无巨细地跟这个大产品经理详细沟通吗？值得打个问号。还有的业务，比如优惠券、红包，发展了非常多年，有无数条相互交织的规则，几乎没有人能完全说得清楚，有业务分析师但是每个人只熟悉一类优惠券，真的要横跨来分析整体销售效果，怎么来抽象，谁来抽象呢？是数据侧来抽象，因为这是一个统计需求？但是人家发展了几年十几年的领域知识和细节，你一个非实际业务人员，能学会还能融会贯通吗，新的业务来了，你是自学，还是别人天天没事在那里免费教你呢？所以就应该业务侧来做抽象？业务侧说我根本就没这需求啊！我这天天还有很多开发任务要做，哪有时间去做这些呢？再说了公司搞这个数据团队不就是让你们做这个，我们都做了，你们做啥呢？

所以，大家可以看到，纵然是看上去几乎是「逻辑完全正确的一句废话」，真的要落地的时候，都会发现，里面问题真的太多了，大部分团队根本就落地不了。为了解决这个问题，我们需要理解下面两点。

第一个，就是承认没有一个通用的方法，可以一蹴而就，一次成型地解决数据的问题。所有的问题，都必须在发展过程中暴露出来，然后来解决。如果我们发现一个方法不好用，推行不下去，就面对它，然后再想原因在哪，怎么解决。只要我们在做的事情，确实是有价值的，那这个过程中的所有问题，终究会被解决掉或者被绕过、被缓解，但这个急不来。只有一种情况是完全解决不了的，就是确实这个事情没价值。这也很常见。很多管理者提出需求来的时候，并没真的觉得想要达到一个什么目的，或者解决什么问题，就只是拍脑袋而已。真的需要他来配合动脑子的时候，他可能就觉得好像这个需求也没必要。结果可能就是，管理者很少或者几乎不参与需求探讨，价值不明确事情就已经大举开动，然后做完了管理者反馈这也不是自己想要的，这种恶性循环，每时每刻都在发生。所以话说回来，我们无法选择环境，只能根据公司和团队的情况，来一步步尝试出最适合的策略。

第二个，岗位是说不清楚的，但是能力相对来说还是比较清楚。比如说，我们说数据分析能力，可以明确为，能够把业务语言，转换成 SQL 语言的能力。业务的人不知道什么窗口计算，分组对接，什么 JOIN，什么是 Ranking，但是具备数据分析能力的人应该知道并且熟悉。不管谁负责业务梳理，最后都会需要转换成数据的语言来建模。那么我们就可以说，我们需要这样一个能力的人，这个能力的人有可能是在业务方，他有能力并且也有意愿，那么他就可以加入到数据的项目里面，大家一起来做数据建模，甚至由他主导也可以。这其实也是很常见而且很高效的做法，就是我们并不以这个人是哪个团队什么岗位，而是说有这个能力，有这个意愿，也有时间（或者能排开时间），那么就参与进来。数据和统计本身就是横跨很多业务线和组织的工作，做这个的人要么就有很强的动员能力，要么就有很强的通识能力，如果两个都没有，是不可能做得好数据的。所以，我们应该尽量关注我们需要什么能力。

在有了这些基本的理解之后，我们才能说，流程该怎么做。

流程参考

通常来说，IT 公司的数据团队要好做很多。一来业务比较简单，二来业务（研发）团队和数据团队的墙相对来说可能没那么高。这里说业务简单，倒并不是说逻辑简单，而是说因为 IT 公司一开始就以软件作为平台，那么不管多复杂的业务，都已经强制用 IT 系统来描述，这就省去了很多事情。

所以，我们在说企业的数据研发协作流程，更多关注的是相对传统的企业，比如零售、餐饮、汽车、制造等等。即便现在有「什么公司归根结底都是 IT 公司」的舆论倾向，但还是有很多公司在数字化转型的初期，还有很多没有用 IT 完整描述的流程，有一个基本的协作流程就更加重要。

在开始构建数据平台的时候，我们需要先拆分开「核心类需求」和「优化类需求」。

核心类需求是业务的核心 KPI 的统计。比如各种销量数据，销售额数据，流转情况数据，异常销售数据，以及各种收支的数据。这类需求通常会以固定报表的形式存在，有明确的价值，有明确的时效、准确性要求。有可能这些都是人力在统计，或者在线下流转。我们应该尽量以最高优先级来解决这类问题。

优化类需求包含核心需求之外的统计需求。这种通常是探索类的需求。也许某个销售领导突然想到要看某个区域的人购买 A 商品之后多久时间又购买 B 商品，或者到底我们的商品在南北省份的销售淡旺季有没有具体差别。或者某些做风控和监察的同事，翻看现在的问题数据的时候，突然意识到可以通常某几个因素来识别一种新型的骗局。当然，还有一些别的临时起意的需求。领导突然去参加某个会议之后看到别人拿出来一个花哨的数字，自己也突然想搞一个。或者一定要在某个地方摆一个「总经理驾驶舱」纵览全局，好看但是没人知道具体有什么用。

接下来我们来说下流程的逻辑。

第一步，判断需求类型。

对于数据团队，我们需要先明确我们要做的是核心需求，还是优化需求。因为核心需求代表业务方的明确诉求，如果做不出来业务不能完成，新业务不能走通，或者会造成明确的影响，所以业务方的配合度，价值的梳理，都会相对容易。优化需求则要困难一些，很多时候需要反复的沟通，多次的试错才能完成。

第二步，明确业务价值。

很多数据团队并不愿意真的深入去了解某个数据需求背后的业务动机，只是希望能做一个「翻译」的角色，业务说什么，自己就原封不动按照业务说的来落地。做出来之后，业务突然发现自己想错了，或者做出来的结果不对，然后又改，双方都很沮丧。有时候为了避免业务「反悔」，数据团队还会让业务团队写文档、走流程，拉着业务不停确认，最后签字画押，似乎这样就能杜绝返工，但其实也杜绝不了。究其根本，还是因为不了解「为什么」业务想要这个指标。

比如，业务方说，我要今年 A 地区每个经销商的白酒在外地开瓶的比例，然后分析师就让签字画押，然后就直接照办了。结果一端出来发现，诶这个数据，明显好像有问题。然后发现，不对，分析师理解的「外地」是城市之外，但实际上「外地」指的是这个经销商负责的区域之外，经销商的负责区域可能跨好几个省市。那好，改。改完发现，好像还是哪里不对，一看，原来一个省的边缘有两个紧挨着的城市，两边来往密切，但是又是两个经销商负责，不行，得排除这个。那好，再改。改完又发现，还是有些地方不太对，一看，发现原来经销商的区域划分有时候有变化，还必须考虑这个动态，回头一看，这个变化只有最近一两年才有保存，之前的都只有改完的了。那好，继续改。改完一看，好像还是哪里不对，一看，原来某个区域因为历史原因有两个经销商负责，但是系统又不支持，所以做了一些特别的操作来处理。如此这般，无穷尽也。

这种例子，相信做企业的读者都经常会遇到。其实要避免，也不难，遇到这个需求，我们应该首先问：为什么需要这个比例？这个比例代表了什么？可能业务方就会说，哦，这个我是想判断经销商有没有在违规串货。怎么算是串货，怎么又算是违规呢？可能就会梳理出负责区域问题，然后把地图拿出来一看，有些区域是在省市边缘，然后引出区域变化等等，如此这般，因为提前知道了业务意图，分析师就可以提前考虑。

这种密切的合作，其实才是真正避免返工和双方龃龉的办法，比签合同都有用。和用户界面设计一样，95% 甚至更多的人，都没办法在没有界面的时候想象一个界面，甚至没办法在看到一个草图的时候就去想象这个界面，就更别说看着冷冰冰的文字描述去确认需求了。只有深入沟通，搞明白意图，做出可以用的草稿，才能真正磨合。

第三步，数据建模。

从这一步开始，其实业务方能帮上忙的就不多了。分析师需要重点考虑：

• 怎么描述这个指标？这个是经典问题，所谓的程序员两大灵魂问题之一的「命名问题」。好的命名可以更好地传达意思，但是有时候一个事情本身就有复杂度，也不必强求一定要多清楚。重点是，在任何场景下，我们都应该统一使用统一的指标名称和定义。
• 数据是否充分？我们先不必考虑数据的处理和计算有多复杂，先确定，数据有没有？够不够？如果没有，是从哪里获取，什么方式，大概需要的时间和精力是多少？如果目前有数据，数据的质量、时效是否能满足需求？
• 如何拆分业务逻辑和简单统计逻辑？按照前文所述，我们应该区分业务逻辑和简单统计逻辑：业务逻辑是和业务强相关的某个定义的计算方式，比如「近期热销商品」的定义，是最近 15 天总销量比前 15 天总销量增加 25% 的商品，「高频访问用户」是过去 7 天至少有 4 天有 50 个页面点击的用户等等；简单统计逻辑则是「总计」、「平均值」、「按 X 排行」、「按 X 分组」等等，可以在 BI 侧实现的操作。注意简单逻辑虽然是在 BI 侧实现，但是有时候我们需要把这些统计维度提前设计到里面。

第四步，图形化设计。

严格来说，图形化只是一种结果的展现形式，逻辑上是放到最后来做的，但是根据我的经验，绝大部分的人都是视觉痛恶，必须要先看到图形化的界面和展示，才能确认需求——即便我们已经认真梳理并确认了价值和细节。这个也非常正常，所以我们可以根据实际情况，把这一步和建模同步来做。

在设计 BI 报表和图形展示的时候，我们也应该多考虑「为什么」。「统计数字会撒谎」这本书，有个理念我很赞同，就是所有对数据的解读，都是人为对数据的一种「扭曲」，这种扭曲代表了解读的人对数据的一种「意见」。同样一个图，用不同的图表、不同的设计、不同的颜色，展示的效果是完全不一样的。

比如我们熟悉的饼图，通常就是为了夸大展示比例。虽然大饼切两半，看得很清楚，但大家可以看下饼图的三分之一、五分之一等等，其实人是很容易误判的。所以饼图通常就是需要展示夸张比例的时候使用。同样的，我们可以用一个条形图来展示比例，但是横着放和竖着放，效果都会有不同。

颜色也是如此。比如，一个图上有 10 种颜色，我们还能真的分清楚吗，还能看出个一二吗？如果一个柱状图，每个的分类都不重叠，数字也各种差异，导致颜色都变来变去，还有意义吗？这些都值得我们认真考虑。如果我们真的要突出某个业务重点，比如「是否有异常」或者「是否有违规」，那么我们就应该选择一个重点颜色来突出，其余的弱化。

第五步，效果演示和后续改进。

很多时候我们没考虑「演示」这个事情的分量，但其实很多时候，结果只是一部分，而对结果的演绎占了很重的戏码。

比如，拿到新手机的时候我们总觉得平平无奇，但是官网通常充斥着各种关于手机的设计的细节，甚至生产制造过程中的各种高精尖技术，以及手机背后的各种工程故事，这些其实都会大大提升我们对手机的感官。而演示也是如此，优秀的演示，除了演示这个结果，还应该演示我们如何深入理解了业务方的诉求，背后的动机，并且我们还帮业务方考虑到了各种细节，各种他们自己可能都忽略的设计问题，最后通过设计，得出一个非常优秀的结果，如此云云。这种使用业务方能听懂的语言，站在业务方立场来做的演示，通常效果会更好，也能得到更有建设性的反馈，从而为后续的改进做铺垫。

最可怕的就是只是流水账似的把功能罗列一二三，用的又是纯技术语言，被业务方牵着鼻子走，被问到问题也无法回答，最后也只能是个不欢而散。

以上是整个数据设计的流程，供大家参考，实际运用的时候，还需按照实际情况来做优化取舍。

结论

这篇文章讲解了两个主题：指标逻辑的拆分实践，以及数据开发的流程实践。前者主要是指标拆分的一些细节，而后者这主要关注在数据开发的逻辑流程。希望这些内容能对正在做企业数据项目的读者所有帮助。

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。