数据模型能够促进业务与技术进行有效沟通。只要基于数据进行决策及拓展业务边界，好的数据模型必不可少。
那么，企业究竟该如何构建数据模型呢？
9月16日，「数智·泛零售」04课，奇点云高级数据模型架构专家天启结合实践经验分享的《泛零售数据中台实施之模型设计》解答了疑惑。
01 数据中台能解决什么问题？
我们用四个字总结「全、统、通、用」。
全：数据中台和数据仓库的区别，数据仓库是满足业务需求或业务主题的；而数据中台是一个大而全的概念，为企业提供战略性的数据中台服务。数据应收尽收，所有能沉淀到数据中台的数据都收集到数据中台，包括增量、全量、实时、离线的数据。
统：统一数据标准规范。从数据质量标准、安全标准、模型规范、开发规范统一起来形成数据资产。
通：打通人的身份ID、商品ID、媒介ID，消除数据孤岛。
用：体现在数据服务，用起来会有流共享、批共享及其他共享。总结起来：「全」是基础；「统和通」是途径；「用」是最终目的，最高境界是数据驱动业务创新和变革。数据中台=方法论+实施+工具
数据中台能落地的关键点：强大的数据中台理论体系支撑+大数据实施流程体系、业务团队能力+大数据建设产品工具集。
One Data方法论
One Data = One Model + One ID + One Service
One Model：统一数据模型，规范指标、标签，消除二义性，将数据从成本中心变成利润中心。One ID：实体ID的唯一性，数据打通后进行数据升维，将数据从孤立变为融通。One Service：统一数据服务，数据从过去的复制到一次开发，多次复用。
02 数据模型选择思考
熟悉数据仓库的同学都了解两位大师，一位是数据仓库之父——Bill Inmon，他提倡的顶层设计是自顶向下的，采用三范式的设计，非常严谨可减少数据的冗余。
另一位是维度建模大师——Ralph Kimball，维度建模更简单，执行起来更容易上手。顶层设计思路是自底向上的，从业务出发，从概念模型到逻辑模型再到物理模型，提倡先有数据集市，各个小的数据集市可以组成数据仓库。
这里仅列举两种模型：星型模型与雪花模型。星型模型是维度建模中比较经典的模型，也是目前用的较普遍的模型，星型模型是所有维度表都直接连接到事实表上，整个图解就像星星一样。
雪花模型是对星型模型的扩展。通过三范式建模，数据冗余比较少，更加规范、严谨，更有利于保持数据的一致性。
通常情况下，为了让下游能更好理解业务，快速提供数据服务，我们会选择星型模型；而在维度信息变化非常频繁，或者数据存储成本非常高的情况下，我们可以采用雪花模型。归根到底，数据模型没有好坏之分，只有能否解决业务问题。
那泛零售企业该如何选择数据中台模型？
从顶层设计、建模理论、业务场景三个大方向考虑。顶层设计：数据中台是大而全的概念，Inmon大师自顶向下的设计思路兼顾业务全局，比较符合数据中台理论。
建模理论：主要以维度建模为核心，结合多种建模百花齐放。
业务场景：如泛零售行业最主要的是「人货场」，从「人」：组织、客户；「货」：商品、服务；「场」:渠道、门店、商场等；「行为」:订单、营销、工单等考虑。
One Model
普遍情况下，一个大的集团可能有好多个大的业务板块，比如地产、金融、电商等。而一般的小公司业务比较单一的话就只分一个业务板块。
数据域是面向业务分析，将业务过程或者维度进行抽象的集合。
业务过程是指企业的业务活动事件，如下单、支付、退款都是业务过程。
维度设计是维度建模的灵魂，也是数据中台模型设计的基础，维度设计的核⼼是构建⼀致性维度。而粒度可以认为是维度的组合，如卖家和买家结合起来可以理解为两个维度，一个粒度。
03 数据模型最佳实践
好的数据模型最终都为业务而生。
具体来说，就是把业务抽象化，提炼成数据模型，再通过数据解决业务问题。
数据建模过程中有哪些常见问题？
数据域划分：可理解，全局考虑，数量适中。
业务过程：是一个逻辑的概念，需与度量关联。
一致性维度：做维度表的时候，有的公司有自己的主数据系统，但有些公司没有自己的主数据系统，需要将数据合并，因此诞生了桥接表，用逻辑的维度表，底层是多张表拼凑而成，且维度表每天都在变化。
明细事实表：分为多事实、单事实、无事实的事实表，很多人会误解为事实表一定要有度量值，但不一定，有的是行为的操作数据，甚至维度表和事实表之间可以相互转换，只有在粒度一致的情形下，才能将多个的事实进行合并。
数仓分层：从ODS-CDM-ADS。
了解维度和粒度之间的关系， 粒度是维度的组合。
数据模型过程中，有何设计心得？
数据不丢失，是最重要的一点。在ODS层的设计就需体现，要长期保留数据。
数据不重复，为保证数据治理的准确性，重复的数据需要提前剔除。
模型能共享，数据集市中的模型共享容易做到，数据集市是满足业务需求的，但是数据中台的模型共享，明细事实表和维度表都需要用到，但是业务会不断进行迭代和创新，所以也可能避免不了要从原始数据中取的可能。
空间换时间，为了能更大程度进行共享，可以做冗余的设计。
任务能重跑，保证后期的运维能力。
业务是爸爸，所有不考虑业务的数据模型都是耍流氓。即使数据模型设计得再好，若业务模型不认可，不满足业务的数据模型都是无效的。数据模型最终都是为业务服务的。不管是黑猫白猫，在一定的设计思想里满足之后都是可以进行创新的。
04 数据模型的前沿畅想
新方向=产品化+行业化+智能化
模型产品化盘点即上云：若对数据进行认真盘点，收集足够多的元数据，把表结构、字段类型、数据库类型，只要把元数据盘点完后一键导入，并可以一键生成头部任务，因此，数据开发人员只需要解决异常情况即可。
设计即开发：有了模型的设计，维度表、事实表、指标定义后，底层的代码是自动实现的，不必再担心SQL的优化、性能调优。
资产即服务：所有的数据进行模型设计后，所有的表都可以进行数据资产化，有了资产即有服务。
模型行业化每个行业有明显的特点，如泛零售行业对人货场的分析比较固定，因此建的模型固定的部分是可以通用的。
模型智能化模型设计越来越简单，容易上手，模型物理层的优化越来越智能，模型和智能应用结合，赋能业务。
标签：最终,业务,建模,维度,而生,数据,模型,数据模型 来源： https://www.cnblogs.com/StartDT/p/13728784.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。