如果把指标比作树上的果实，那么模型就是树的树干。结实点。一个真实场景的例子：大部分公司的分析师都会结合业务做一些数据分析（需要大量的数据），通过报表为业务部门的运营服务。然而，在数据中心建成之前，分析师往往发现自己没有可复用的数据，不得不使用原始数据进行指标的清洗、处理和计算。由于他们大多是非技术出身，所以写的SQL质量比较差，甚至见过5层以上的嵌套。这种SQL消耗资源大，会造成队列阻塞，影响其他数仓任务，引起数据开发的不满。数据开发会要求分析师收回原来的数据读取权限，分析师会抱怨数仓数据不完善，求之不得。一个需求往往要等上一周甚至半个月。分析师和数据开发之间的冲突就从这里开始了。这个矛盾的根源是数据模型不能复用，数据开发是烟囱式的。每次遇到新的需求，都要从原来的数据重新计算，自然是比较费时的。为了解决这个矛盾，我们必须弄清楚我们的数据模型应该是什么样子。什么是好的数据模型设计？我们来看一组数据。这两张表是根据元数据中心提供的血缘关系信息，统计大数据平台上运行的任务和分析查询（Ad-hoc）。表1：表2：下图是数据仓库的层次结构图，方便回忆数据模型分层的设计结构：表1表1中有2547个无法识别的层次表，占40%总表6049张。他们基本上不可能被重用。重点是，在已识别的抄表任务中，ODS:DWD:DWS:ADS的抄表任务分别为1072:545:187:433，直接读ODS层的任务占到了47.9%这四层的总任务。这说明大量任务都是基于原始数据处理，中间模型的复用性差。表2在识别出的分层查询中，ODS:DWD:DWS:ADS命中查询分别为892:1008:152:305，37.8%的查询直接命中了ODS层的原始数据，说明DWD、DWS、TheADS层数据建设严重缺失。尤其是ADS和DWS，查询的底层表越低，查询扫描的数据量越大，查询时间越长，查询的资源消耗越大，使用人群的满意度越低数据。最后，对ODS层读取的704张表进一步分解后发现，这382张表的下游输出为DWS、ADS，特别是ADS达到了323张表，占ODS层表的45.8%。%，表示物理处理了大量的ODS层表。通过以上分析，我们似乎找到了一个理想的数据仓库模型设计应该具备的因素，即“数据模型是可重用的、完备的、标准化的”。如何衡量DWD层的完善程度：衡量DWD层的完整性，最好看ODS层中有多少表被DWS/ADS/DM层引用。因为DWD上面引用的层越多，基于原始数据深度聚合计算的任务就越多。详细数据没有积累，无法重复利用，在数据清洗、格式化、整合等方面反复开发。因此，我建议用跨层参考率指标来衡量DWD的完善程度。跨层引用率：ODS层DWS/ADS/DM层直接引用的表占ODS层所有表的比例（只统计活跃表）。跨层参考率越低越好。在数据中心模型设计规范中，要求不允许跨层引用，ODS层数据只能被DWD引用。DWS/ADS/DM层完整性：评估汇总数据的完整性，主要看汇总数据能直接满足多少查询需求（即以汇总层数据的查询率来衡量）。如果汇总数据还不够，那么使用数据的人必须使用详细数据，甚至是原始数据。汇总数据查询率：DWS/ADS/DM层查询占所有查询的比例。需要明确的是，这与跨层引用率不同。不可能做到100%的汇总查询率，但数值越高，说明上层数据建设越完善。对于使用数据的人来说，查询速度和成本都会降低，使用起来会更愉快。如何衡量复用度数据中心模型设计的核心是追求模型的复用和共享。通过元数据中心的数据关系图，我们可以看出一个糟糕的模型设计是自下而上的是一条线。而一个理想的模型设计应该是一个交织的发散结构。以模型参考系数为指标，衡量平台模型设计在数据中的复用性。参考系数越高，数据仓库的复用性越好。模型参考系数：读取一个模型，直接输出下游模型的平均数。比如一个DWD层表被5个DWS层表引用，则这个DWD层表的引用系数为5，如果对所有DWD层表（有下游表）的引用系数取平均值，则为DWD平均模型层表参考系数一般低于2比较差，大于3比较好（经验值）。如何衡量规范程度在表1中，超过40%的表没有层级信息，这在模型设计层面显然是不规范的。除了检查表是否有层次外，还需要检查是否属于主题域（如事务域）。如果不属于主题域，就很难找到这张表，无法重用。其次，看表的命名。以股票的命名为例。当你看到这张表时，你知道它是哪个主题域和业务流程吗？是全量数据的表，还是每日增量数据？总的来说，通过这个表名得到的信息太有限了。标准化的表命名应包括主题域、分层以及表是完整快照还是增量表等信息。另外，如果A表中用户ID的名称为UserID，而B表中用户ID的名称为ID，则会给用户带来麻烦。这是一件事吗？所以我们要求同一个字段在不同的模型中命名一致。经验和建议：1.你可以用这些指标来评估你的数据仓库的现状。2、然后制定一些有针对性的改进方案，比如剔除这些命名不规范的表，将主题字段覆盖的表比例提高到90%以上。3、在尝试模型重构优化一段时间后，拿这些指标来测试是否真的有提升。模型重构对数据构建有多大帮助？有没有可以衡量的量化指标？基于以上知识，这两个问题就可以很好的回答了。如何将数据中心从烟囱式的小型数据仓库建设到共享数据中心。多路数据中心。一是接管ODS层，源头把控。ODS是业务数据进入数据中心的第一站，是所有数据处理的源头。只有控制源头，才能从根本上杜绝重复数据系统的出现。数据中心团队要明确职责，全面接管ODS层数据，从业务系统的源库权限入手，保证数据从业务系统产生进入数据仓库时，只能保留一份在数据中心。这个可以和业务系统的数据库管理员约定好，只有中台团队的账号才能同步数据。ODS图层表的数据必须与数据源的表结构和表记录数一致，且高度无损。ODS层表的命名采用ODS_业务系统数据库名_业务系统数据库表名的方式，如ods_warehous_stock，warehous为业务系统数据库名，stock为库下表名。二是划分学科领域，构建总线矩阵。主题域是业务流程的抽象集合。这么说可能有点抽象，但实际上，业务流程是企业业务流程中不可分割的行为事件。例如在仓库管理中，有入库、出库、发货、收货等，都是业务流程，抽象出来的主题域就是存储域。主题域的划分应尽可能覆盖所有业务需求，保持相对稳定，并具有一定的可扩展性（增加新的主题域不会影响已经划分的主题域的表）。划分完主题域后，需要开始构建总线矩阵，明确各主题域下业务流程的分析维度。例如：第三，构建一致性维度。售后团队的投诉量有区域的分析维度，送货团队的配送延迟也有区域的分析维度。您想分析配送延迟导致的投诉增加，但两个地区的分析维度包含不一致的内容，最终会导致无法分析某些区域。因此，我们构建一个全局一致的维表，保证维表只保存一份。维度统一最大的难点在于维度属性的整合（如果维度是商品，那么商品的商品类别、商品品牌、商品尺寸等属性，我们称之为维度属性）。是否所有的维度属性都应该整合到一张大维度表中，这个不一定。我会给你一些建议。1.将公共维度属性和唯一维度属性拆分成两个维度表。在自营平台中，通常会有一些第三方商家，但数量很少。事实上，大多数产品都没有店铺属性。这种情况下，不建议将店铺和商品的其他维度属性，如商品品类、品牌等设计到维度表中。2.将输出次数大的维度属性拆分到单独的维度表中。比如有的维度属性的输出时间是凌晨2:00，有的维度属性的输出时间是早上6:00。可以拆分成两个维表，保证核心维表尽快产生。3.考虑到维表的稳定输出，可以拆分频繁更新和变化缓慢的维表，拆分频繁访问和访问较少的维表。对于维度表的规范命名，推荐使用“dim_subjectfield_description_segmentationrules”方式。表分区可以这样理解：一张表存储了上千亿条记录，太大了，需要把一张表分成很多小分区。每天或每周，随着任务的安排，一个分区。常用分区规则（时间查询）。第四，事实表集成。事实表集成最基本的原则是统计粒度必须一致，不同统计粒度的数据不能出现在同一个事实表中。举个例子：在数据中心建设之前，供应链部门、仓储部门、市场部门都有一些重复的事实表。我们需要去掉这些重复的内容，按照交易域和仓储域以及主题域进行整合。对于仓储部和供应链部的库存清单，由于仓储部的统计粒度是商品加仓库，而供应链部只有商品，原则上两张表不能合并，但应该独立存在。对于市场部和供应链部的两张订单明细表，由于统计粒度是订单级别的，都属于交易域下的下单业务流程，所以可以合为一张事实表。此外，还应考虑填写不完整的数据。对于ODS层直接引用产生DWS/ADS/DM层的任务，通过血缘关系找到任务列表，一一拆解。如果没有对应ODS的DWD，则需要生成一个DWD表。对于现有的，应该迁移任务并使用DWD层表。DWD/DWS/ADS/DM的命名规则适合采用“[级别][主题][副主题][内容描述][切分规则]”的命名方式。第五，模型开发。模型设计完成后，进入模型开发阶段。注意事项：1.所有任务必须严格配置任务依赖。如果没有配置任务依赖，之前的任务将不会正常产生数据。一个任务根据错误的数据被调度空运行，浪费资源，增加排错的复杂度；2.任务中创建的临时表在任务结束前删除。如果不删除，将会有大量的临时表存在并占用空间；3、任务名称要与表名一致，方便查找和关联；4、生命周期管理，对于ODS和DWD，一般尽量保留所有历史数据，对于DWS/ADS/DM，需要设置生命周期，7-30天不等；5、DWD层表要采用压缩方式存储，可以通过lzo进行压缩。第六，应用迁移。最后一步是应用程序迁移。这个过程的核心是注意数据比对，确保数据完全一致，然后进行应用迁移，删除旧数据表。总的来说，数据中心平台的建设并不是一个可以一口气吃完的胖子。它的建造往往是滚雪球的方法。随着应用的迁移，中台的数据也越来越丰满，发挥的价值越来越大。数据仓库建模工具EasyDesign的上述步骤的实现，离不开好用工具的支持。为了规范数据模型的设计，开发了EasyDesign的模型设计产品，使这些过程得到系统化的管理。EasyDesign的设计思路和功能：网易有几个：https://bigdata.163yun.com/product/easydesignEasyDesign是建立在元数据中心之上，通过API调用元数据中心的数据边缘接口。结合数据仓库模型设计指标，给出了模型设计指标。EasyDesign以主题域、业务流程和分层方式管理所有模型。它还提供维度、度量和字段库字典的管理，以及模型设计批准过程的控制。总结本文主要了解数据中心的模型设计。从设计目标的确立，通过一系列步骤，将分散、杂乱、烟囱状的小型数据仓库逐步组织成可重复使用、可共享的数据中心，最后通过产品化实现系统化管理。最后再强调几点：1.完备性、可重用性、标准化构成衡量数据中心模型设计的衡量体系，可以帮助大家评价数据仓库设计的好坏。2、维度设计是维度建模的灵魂，是数据平台模型设计的基础。维度设计的核心是建立一致的维度。3、事实表的统计粒度必须一致，不同统计粒度的数据不能出现在同一个事实表中。数据中心的建设往往需要半年甚至一年以上的时间，但数据中心建成后，提升研发效率的效果是非常明显的，数据需求的平均交付时间从一周缩短至3天以内，需求响应速度的提升为企业运营效果的提升提供了数据支持。
