数据建模已死，真的吗？

1. 为什么说数据建模已死？

近日，Substack.com 上一篇名为 The Death of Data Modeling（数据建模之死）的博客引起了行业热议，许多数据从业者发现曾经经典的数据建模流程可能已不再契合企业当下的数据分析需求。

本文将详细阐述为什么说数据建模已死，并分析当前数据建模存在的痛点和挑战，最后介绍数据建模 2.0 方案将如何帮助企业真正实现自助式数据分析，希望对大家有所启发。

1. 1 数据指标有歧义，口径对不齐

数据建模的核心功能是把数据组织成更容易被业务用户使用的形式，其中一部分流程是将业务用户需要使用的指标固化在模型中。但现实情况是由于数据模型的混乱，业务用户拿到的数据指标有歧义、口径对不齐，难以达到预期的作用。

假设企业使用了一个中等规模以上的 BI 或者是数据仓库的技术栈，每次需求都单独创建 ETL 任务和聚合表，就会导致数仓中有大量的聚合表，对应也就需要创建成百上千张报表；每张报表如果有十个以上的指标，那就意味着有几万甚至几十万的业务指标。这些口径是否统一？这些数据是否被人使用？这些问题都值得我们去思考。

 1.2 数据交付流程时效性差，开发成本高

对于分析师而言，传统围绕数据模型的数据交付流程时效性差，只能用加工好的已知数据进行分析，但不能就未知数据给出洞察，难以满足当今的业务需求；而对于工程师来讲，重复开发工作多，成本还居高不下，工作成就感低。

传统的围绕数据模型的交付模式，通常需要经过需求提出、需求澄清、数据探源、数据开发、再到创建仪表盘、UAT 验收等一系列开发环节，这样的数据交付上线时间通常需要 12 天。

此外，由于数据工程团队通常需要集中服务多个团队，往往缺乏对数据模型背后业务的理解，也缺少充足人力去持续跟进不断变化的业务需求。这就导致围绕数据模型的开发交付周期长，还需要业务和数据工程团队的深度介入才能够实现数据需求的上线。

1.3 业务人员数据分析被动

业务人员经常在需要使用数据的关键时刻，面临不知道在哪里获取数据、甚至没数据可用的窘境，在工作中处于被动状态。

随着越来越多数据模型表的产生，没有经过治理的数据模型存在着大量的数据任务和聚合表，数据的消费者很快就不知道在数据仓库中应该使用哪些数据来回答业务问题了，本应供大家获取数据价值的数据模型沦为了只有少数专家数据工程师才能访问探查的“数据沼泽”。

例如，一家使用公有云搭建 IT 基础设施的公司，其管理层每月会定期审核云成本数据报表，查看公司内各个项目在多家公有云平台上的消费是否超出预算，并制定下一步云上费用的投入计划。但是每次管理层审核时，都只能从现有报表中找问题，却无法分析出背后深层次的原因。因此，只能提出对报表的修改意见，问题会遗留到下次审核，再到下下次审核，如此循环往复...... 那么，当管理层看到项目 A 占用云成本过高，下一步应该增加投入还是要求项目组缩减开支呢？因为缺少更具体的数据支撑，管理层难以快速决策，只能会后处理，并要求下次开会时在报表添加项目组云资源使用的更多数据结果。

2. 理想中的数据建模

面临这些挑战，我们勾划出了数据建模理想中的样子。我们希望数据建模可以真正成为数据赋能业务的基石，实现数据分析平民化，那么“理想中的数据建模”应是怎样的呢？

• 工程师把模型建好，业务就能自助使用，同时数据工程团队可以统一管控，保证数据口径的一致性；
• 数据工程团队可以更加敏捷地交付业务需求，而不需要经过一个漫长的需求沟通流程；
• 业务人员可自助使用数据，无需过度依赖工程师，整个数据建模过程就能得到有效的管理。

数据建模真的死了吗？

数据建模真的死了吗？事实上，数据建模仍旧存在且有其价值，企业的数据平台建设仍离不开好的数据建模。我们认为“死掉”的是混乱无序的传统数据建模，企业真正需要的是能够平衡集中的数据治理和敏捷的自助式分析的数据建模 2.0。

 使用统一的模型作为宽表和指标的“收纳箱”

在经典数仓的理论中，大家常常使用雪花模型来刻画业务过程及其关联维度，我们可以借助雪花模型对各个数据域、各个业务过程进行严格的建模。并且可以起到“数据模型收纳箱” “指标收纳箱”的作用：

• 相同数据域、相同业务过程的数据模型表，归属到同一个雪花模型之中，同一个模型负责不同数据模型表的计算、存储、迭代；
• 所有的业务指标归属到唯一确定的模型；
• 模型可以在指标开发的过程中被自动推荐生成，但是需要得到管理员审批同意，防止因模型的过度开发造成的混乱。

每当用户需要创建新的指标时，可以根据图形界面的引导，优先选择复用已有模型，或是定义新模型，系统会在其完善模型定义的过程中不断识别和推荐可以复用的模型。这就实现了模型层面的重复性检查和复用，遏制了数据聚合表的无序生长。

在这里，我们可以看到这样的模型层就像一个“收纳箱”，可以有效地吸收、组织、去重原本需要数以千计的、零散的数据建模表层表。在资源层面，模型可以组织数据主题之间的血缘关系。在治理层面，模型层的出现大大降低了指标平台底层的数仓表的数量，显著降低了治理的复杂度。

利用指标驱动业务需求向数据模型的沉淀

在数据建模 2.0 的模式中，数据建模的过程仍始于维度表和事实表。在中间我们会构建一些数据集市，供上层应用去使用。数据工程团队管理好了原子指标之后，业务人员就可以基于这些原子指标不断地去创建、衍生所需的业务指标。通过不断创建衍生业务指标，业务人员其实就自主完成了业务逻辑向数据模型的沉淀。

在这个过程中，数据工程团队也可以通过推动指标治理来做到更好的数据治理。因为只有指标被使用、被消费，数据才能发挥更大的价值。基于数据模型的指标中台可以帮助企业管理口径的规范，比如重复的指标、异动的指标，还有一些异常的空值分布等。通过在指标层面上的应用，数据工程团队可以更有针对性地帮助业务用户去治理指标背后的数据，做到有的放矢。

新的数据建模方式将高效赋能业务人员进行自助数据分析，业务人员可以复用基础指标去自行创建并分析衍生指标，而无需数据工程团队的介入。数据工程团队只需要在有全新基础指标的开发需求时，参与需求分析和指标的开发，这样通过指标驱动业务反向将需求沉淀到数据模型的方式。在 Kyligence 真实的客户案例中，数据交付时间可从过去的 12 天缩短到 0 天 （对于分析可复用基础指标的衍生指标）和 5 天 （对于需要新创建基础指标的场景）。

数据建模 2.0 ：包含技术和业务两个层次

数据建模 2.0 不再仅仅是数据模型，还应具备指标中台能力。理想中的数据建模 2.0 不仅仅包含数据的技术层面，即通过建立表和表之间的关联，将数据库中的表组织为数据模型，也包含数据模型的业务层面，通过数据字段到业务指标的翻译，让业务人员真正使用熟悉的业务语言来进行自主的数据分析。

3.总结

部分人在唱衰数据模型，认为数据建模已死。但我们认为数据建模并不会死，企业需要的是新的数据建模模式。在这种新的模式中，企业可以使用统一的模型作为数据建模和指标的“收纳箱”，新的数据建模 2.0 包含业务和技术的两个层次，业务人员利用指标驱动业务需求向数据模型的沉淀。

作为这种理想的数据建模 2.0 以及指标驱动业务数据分析的理想载体的呈现，Kyligence 推出了智能指标驱动的管理和决策平台 Kyligence Zen，该产品基于 Kyligence 核心 OLAP 能力打造，利用 AI 增强引擎和预计算技术优势，提供指标目录、指标自动化、API 集成等功能，以便捷、易用、直观的产品，为用户带来高效协同管理、业务敏捷提升、数据口径一致、开发成本降低等价值，助力领先企业构建指标体系，驱动业务和管理目标。欢迎大家点击「Kyligence Zen 指标平台」开启免费试用。

关于 Kyligence

上海跬智信息技术有限公司 (Kyligence) 由 Apache Kylin 创始团队于 2016 年创办，致力于打造下一代企业级智能多维数据库，为企业简化数据湖上的多维数据分析（OLAP）。通过 AI 增强的高性能分析引擎、统一 SQL 服务接口、业务语义层等功能，Kyligence 提供成本最优的多维数据分析能力，支撑企业商务智能（BI）分析、灵活查询和互联网级数据服务等多类应用场景，助力企业构建更可靠的指标体系，释放业务自助分析潜力。

Kyligence 已服务中国、美国、欧洲及亚太的多个银行、证券、保险、制造、零售等行业客户，包括建设银行、浦发银行、招商银行、平安银行、宁波银行、太平洋保险、中国银联、上汽、Costa、UBS、MetLife 等全球知名企业，并和微软、亚马逊、华为、Tableau 等技术领导者达成全球合作伙伴关系。目前公司已经在上海、北京、深圳、厦门、武汉及美国的硅谷、纽约、西雅图等开设分公司或办事机构。