06 | 数据模型无法复用，归根结底还是设计问题
该思维导图由 AI 生成，仅供参考
什么才是一个好的数据模型设计？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了从烟囱式小数据仓库向共享数据中台的转变过程，并提出了数据模型设计的关键要点。作者强调了数据模型应追求可复用、完善和规范，并提出了衡量模型完善度、复用度和规范度的指标。此外，通过分析数据血缘图，强调了理想的模型设计应该是交织的发散型结构。规范的表命名和字段命名也被认为是衡量规范度的重要因素。文章还介绍了数据中台的模型设计步骤，包括接管ODS层、划分主题域、构建一致性维度、事实表整合、模型开发和应用迁移等。最后，文章提到了一个建模工具EasyDesign，以及数据中台建设的重要性和效果。总的来说，本文通过丰富的实践经验，为读者提供了建设数据中台的详细指导和实用建议。
《数据中台实战课》，新⼈⾸单¥59
全部留言(60)
- 最新
- 精选
大尾巴老猫1、先满足需求（活下去），再研发公共数据层（构建美好未来）。 2、获得高层领导的支持，以获得更多的研发资源。 3、在满足业务需求的过程中，根据业务需求不断对公共数据层进行迭代和优化。 4、随着时间的推移 ，越来越多的日常业务需求可以用公共数据层（中台来完成）。 5、日常业务需求开发和公共数据层构建是相互促进的循环。作者回复: 不错，总结的挺好的，其实我只想再补充一点，就是为了保障数据中台的推进速度，可以尝试成立专人团队，这些人的目标明确就是中台构建，模型的重构和整合，指标的梳理。这些人不接业务需求，这样可以避免日常业务需求对数据团队的中台建设的干扰。否则的话，数据中台的建设进度，经常会受到业务需求压力的干扰，而且如果没有明确的KPI，或者KPI权重不够大，中台建设的动力也会不足。 感谢你的阅读，总结的很棒！
2020-04-1534
夏天松老师，能否有一个比较全的各层的表命名及维度表命名、指标命名规范？作者回复: 你好，关于每一层的表的命名规范，我在文章中都有提到。 ODS: ODS_ 业务系统数据库名 _ 业务系统数据库表名 DWD/DWS/ADS/DM 的命名规则适合采用“[层次][主题][子主题][内容描述][分表规则]”的命名方式。 DIM:DIM_ 主题域 _ 描述 _ 分表规则 指标命名规范中，对于原子指标，指标名称适合用“动作 + 度量”的命名方式（比如注册用户数、购买用户数），标识的命名用英文简写或者汉语拼音缩写比较好。对于派生指标，指标名称应该严格遵循“时间周期 + 统计粒度 + 修饰词 + 原子指标”的命名方式，标识命名要用“修饰词 _ 原子指标 _ 时间周期”的方式。 感谢你的阅读~
2020-04-2322- 毛聪郭老师好，我想问个模型分层的问题，我计算的一个指标从dwd层到dws层后就可以直接给到应用层了，那这个汇总表到底算是dws层的表还是ads层的表？
作者回复: 你好，你问的问题，我估计很多人都有这样的疑问。 dws 并不是说一定要通过ads ，dws 也可以被应用直接访问的。在我们的数据中台建设中，一般只有一个应用专属的表，不能被其他应用使用的，才归入ads，如果可以被多个应用共享的，我们还是归入dws。 感谢你的阅读，也感谢你提的好问题，欢迎继续提问~
2020-04-2214 
麻婆豆腐郭老师好，请教一个小白的问题，运行任务和分析查询的统计是怎么统计的呢？我们现在的平台有用hive直接查的，有tableau连impala查询的，还有spark定时任务，各种各样的，怎么才能统计出像您这样的表格呢。也想做下自己的模型指标分析。十分感谢！作者回复: 你好，可以基于数据血缘来实现，一个表的产出任务以及它的下游引用任务，数据血缘都是有的。 对于分析查询，目前我们有两个平台，一个是网易有数，类似tableau，一个是自助分析平台，就是执行SQL的，我们把这两个平台的日志执行信息会拿出来进行离线的分析和统计，然后去看每个query查询了哪些表。 如果你是tableau，可能没这么方便，不过可以试试从impala入手，impala侧日志中是有SQL信息，可以抓出来分析统计。对于spark和hive，可以基于数据血缘来实现。 感谢你的阅读~
2020-04-15210
泡泡鱼大王首先高优先级需求一定是先开发。 我觉得压缩空间在中台项目本身， 1.尽早搭建共享数仓部分。 措施： 技术上把各个小数仓的元信息和数据模型 通过自动化采集到同一个数据库中，进行分析，提炼指标。分析复用率。 业务上拉上各个部门核心BA，进行指标砍伐和提炼。 优先共享数仓产出，同时也应该按照优先级顺序。 高优先级的共享数据仓尽快产出，这样能用上，大家都会觉得中台的重要性。 2.中台开发过程挑选技术能手和业务能手快速完成迭代。 3.中台结束应该由业务方发起验收，减少建模的链路提高易用性是核心，这样才能让人人都用上中台。 4.后期运维需要建立强大监控环节，自顶向下监控资源，减少成本开销。 总结：技术上按照数仓设计就可以，中台的难点是对人员的业务和技术能力要求极高，同时需要一个优秀的PM。作者回复: 说的好，中台对数据开发的要求真的是挺高的，当然，也需要一些好用的工具产品来降低他们的工作量和复杂度，一个优秀的PM当然也是必须的。 我一直强调一个观点，不要用技术的思维看待数据中台，要用管理的思维，数据中台它是一个系统性的工程，对整个数据建设是一次革命！ 感谢你的阅读，期待与你在留言区再次相遇，也期待你继续发表你的观点，很棒！
2020-04-169
Weehua郭老师这篇文章非常非常棒！和我们的工作内容非常match。我们刚开始也是被各个业务的报表需求压的喘不过来气，曾经一度全体人员全部做报表。这个过程中，我和高层沟通，建立了数据平台组，引入了相关人才，花了3个月的时间把调度平台，API平台搞了起来，现在想想这些就是中台的组建。马上大大提高了开发效率和稳定性。后续形成良性循环，平台建设不断完善，开发效率和质量逐步提高。但数仓怎么衡量好坏一直是高层的关注点，这篇文章给了我们很大启发，其中ods的查询使用占比确实是一个很好的指标，其他指标我会引入团队，加强数仓的建设。结合前面的几篇文章，虽然我们没有做中台这件事，但是组织架构和工作内容已经在隐形的做中台了。最后，再次感谢郭老师的文章，非常赞！作者回复: 感谢你的认可，也非常开心，我们的这些经验能够对你有所帮助。我真心觉得，数据建设，真的是磨刀不误砍柴工，工具能力的建设，可以起到事半功倍的效果，做任何一项工作，都要想着怎么让这项工作能够有积累，堆人往往能够解决一些前期的问题，但是不是长久的方案。
2020-05-218
louShang为什么要维度建模, 为什么要管理维度 ? 没有看到维度建模和管理维度的好处 在管理好数仓的业务线、主题域 、业务过程之后, 可以直接开展指标的建设和管理, 维度看起来更像一个辅助指标建设的一个可选项, 是否维度是有管理的, 貌似并不重要 , 在创建原子指标的时候, 只要能选取到事实明细表的维度就可以?作者回复: 你好， 维度建模只是模型设计的一种方法，当然你也可以选择其他的模型构建方法，之所以选择维度建模，是因为其是从业务需求场景出发，能够适应业务场景的快速变化。举个例子，在零售场景中，门店是一个维度，可以基于门店，分析销售额，原材料，如果又有一个新的场景，那维度本身还是门店。 维度建模还有一个好处，就是通过一致性维度，可以进行关联分析。比如门店的销售额和门店维度下的商品数量，可以做关联的分析。维度的管理很重要，核心是建立一致性维表。 指标的可分析维度的设计很重要，直接关系到后续模型的设计，需要哪些维度。所以在指标系统里面，必须有指标的可分析维度项。 提出指标需求的业务，需要先梳理出，你要的这个指标，需要哪些可分析维度，然后在模型设计阶段，需要把这些指标和可分析维度固化到模型中。 感谢你的提问~ 希望我们的交流可以帮助解决你的疑惑~祝好~
2020-05-216
你好老师，hive中数据压缩和分片是对立的，两者怎么进行实际使用？作者回复: 你好， 有一些压缩算法是支持split的，例如lzo，对于大文件来说比较合适，在保证压缩效率的前提下，有着相对稳定的压缩比。 我在第8讲中，会重点介绍通过数据压缩，优化存储成本的问题。欢迎你继续阅读~ 感谢你的阅读，我们下一次再见~
2020-04-264
北野豪横目前在做一个全新的领域，警务中台系统，跟原本的电商模式有着很大差别，本来一头雾水的项目，读了老师的课有点云开见月明的意思，提出一点个人的感想，不论是模型，还是输出的指标，个人感觉越来越多的应该从底层业务出发，自底向上来驱动整个业务中台，这里需要模型与业务与数据的多项循环反馈机制才能逐渐完善整个中台，如何将指标模块化，如何让各种模型即产中中间层结果，又产出直接结果，形成真正的积木式中台，让一线最懂业务的业务人员能够尽情发挥，搭建出自己想要的结果，形成逐层累积。 2.同时还要考虑这些模块和指标以及管理真的是我提了一个醒，目前是自己负责一个中台项目的指标模型建设，业务是自己，模型是自己，指标也是自己，但是当个多人参与进来要如果管理是我要学习的地方。 3.最后感慨一下，数据中台对从业人员的要求真的是高，要懂数据，懂运营，懂业务，懂模型，还要兼顾公司内过个部门的协同和沟通，不过也显示除了，未来人才的趋势就是全方位的人才才能真正立足于未来互联网。作者回复: 首先，感谢你的认可。看到对你的实际工作有所帮助和启发，我感到很高兴。 你说的非常正确，业务和数据中台之间本来就要相互反馈，业务人员经常去查一些明细表，那我们中台就要考虑，是不是需要完善汇总层的模型。 你说数据中台对从业人员要求高，我也非常赞同，数据中台从业务中来，最终必须要回到业务。数据中台团队独立于业务，但是绝对不能脱离业务。我在第13讲中，会详细的介绍，感谢你在留言区发表的想法，非常棒！ 期待与你再次相遇~
2020-04-1524
臧洪友郭老师,刚接触数据中台,提的问题可能还比较初级,维表是一个基于的事实表的维表吗?他们之间是什么关系?需要ID关联吗?还是放到一张大的宽表中?多谢了!作者回复: 你好，我来回到一下你的问题。 维表和事实表，可以通过ID关联，构建星型模型，甚至维度本身也可以构建有层次关系的星座模型。 在数据中台的集市层，或者汇总层，为了方便使用者使用，我们会做一些维度退化的设计，降低Join的次数，因为通过id关联，必须就会是涉及到join，join操作对计算引擎的性能要求比较高，所以会把一些常用的维度属性退化到事实表中，这个还是主要取决于业务场景和需求。 感谢你的阅读，期待与你再次相遇~
2020-04-163
