共计 3539 个字符，预计需要花费 9 分钟才能阅读完成。
1. 为什么说数据建模已死？
近日，Substack.com 上一篇名为 The Death of Data Modeling（数据建模之死）的博客引起了行业热议，许多数据从业者发现已经经典的数据建模流程可能已不再符合企业当下的数据分析需要。
本文将具体论述为什么说数据建模已死，并剖析以后数据建模存在的痛点和挑战，最初介绍数据建模 2.0 计划将如何帮忙企业真正实现自助式数据分析，心愿对大家有所启发。
1. 1 数据指标有歧义，口径对不齐
数据建模的外围性能是把数据组织成更容易被业务用户应用的模式，其中一部分流程是将业务用户须要应用的指标固化在模型中。但现实情况是因为数据模型的凌乱，业务用户拿到的数据指标有歧义、口径对不齐，难以达到预期的作用。
假如企业应用了一个中等规模以上的 BI 或者是数据仓库的技术栈，每次需要都独自创立 ETL 工作和聚合表，就会导致数仓中有大量的聚合表，对应也就须要创立成千盈百张报表；每张报表如果有十个以上的指标，那就意味着有几万甚至几十万的业务指标。这些口径是否对立？这些数据是否被人应用？这些问题都值得咱们去思考。
1.2 数据交付流程时效性差，开发成本高
对于分析师而言，传统围绕数据模型的数据交付流程时效性差，只能用加工好的已知数据进行剖析，但不能就未知数据给出洞察，难以满足当今的业务需要；而对于工程师来讲，反复开发工作多，老本还居高不下，工作成就感低。
传统的围绕数据模型的交付模式，通常须要通过需要提出、需要廓清、数据探源、数据开发、再到创立仪表盘、UAT 验收等一系列开发环节，这样的数据交付上线工夫通常须要 12 天。
此外，因为数据工程团队通常须要集中服务多个团队，往往不足对数据模型背地业务的了解，也短少短缺人力去继续跟进一直变动的业务需要。这就导致围绕数据模型的开发交付周期长，还须要业务和数据工程团队的深度染指才可能实现数据需要的上线。
1.3 业务人员数据分析被动
业务人员常常在须要应用数据的关键时刻，面临不晓得在哪里获取数据、甚至没数据可用的困境，在工作中处于被动状态。
随着越来越多数据模型表的产生，没有通过治理的数据模型存在着大量的数据工作和聚合表，数据的消费者很快就不晓得在数据仓库中应该应用哪些数据来答复业务问题了，本应供大家获取数据价值的数据模型沦为了只有多数专家数据工程师能力拜访探查的“数据沼泽”。
起源：https://dataedo.com/cartoon/d…
例如，一家应用私有云搭建 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 等技术领导者达成寰球合作伙伴关系。目前公司曾经在上海、北京、深圳、厦门、武汉及美国的硅谷、纽约、西雅图等开设分公司或办事机构。
