仓库建模

1. 恩门：自顶向下，根据实体建设仓库，构建成本比较高，适用于应用场景比较固定的业务，比如金融领域，冗余数据少。
2. 金博尔：拆分维度和事实（指标），适合高速发展互联网业务，变化快。

什么样的企业适合建数据中台？

数据中台的构建需要非常大的投入：一方面数据中台的建设离不开系统支撑，研发系统需要投入大量的人力，而这些系统是否能够匹配中台建设的需求，还需要持续打磨。另外一方面，面对大量的数据需求，要花费额外的人力去做数据模型的重构，也需要下定决心。

所以数据中台的建设，需要结合企业的现状，根据需要进行选择。我认为企业在选择数据中台的时候，应该考虑这样几个因素。

1. 企业是否有大量的数据应用场景： 数据中台本身并不能直接产生业务价值，数据中台的本质是支撑快速地孵化数据应用。所以当你的企业有较多数据应用的场景时（一般有3个以上就可以考虑），就像我在课程开始时提到电商中有各种各样的数据应用场景，此时你要考虑构建一个数据中台。
2. 经过了快速的信息化建设，企业存在较多的业务数据的孤岛，需要整合各个业务系统的数据，进行关联的分析，此时，你需要构建一个数据中台。比如在我们做电商的初期，仓储、供应链、市场运营都是独立的数据仓库，当时数据分析的时候，往往跨了很多数据系统，为了消除这些数据孤岛，就必须要构建一个数据中台。
3. 当你的团队正在面临效率、质量和成本的苦恼时，面对大量的开发，却不知道如何提高效能，数据经常出问题而束手无策，老板还要求你控制数据的成本，这个时候，数据中台可以帮助你。
4. 当你所在的企业面临经营困难，需要通过数据实现精益运营，提高企业的运营效率的时候，你需要构建一个数据中台，同时结合可视化的BI 数据产品，实现数据从应用到中台的完整构建，在我的接触中，这种类型往往出现在传统企业中。
5. 企业规模也是必须要考虑的一个因素，数据中台因为投入大，收益偏长线，所以更适合业务相对稳定的大公司，并不适合初创型的小公司。

数据中台本质上是要实现公共计算逻辑的下沉和复用，目标就是要实现高效率、高质量、低成本。

OneData OneService

OneData

所有数据只加工一次

1. 分主体域管理，好的主题域划分，是相对稳定，尽可能地覆盖绝大多数的表。
2. 命名规范定义，对表的命名进行规范化统一， 表的名称中最好能够携带表的主题域、业务过程、分层以及分区信息
3. 指标一致，构建全局的指标字典，确保所有表中相同指标的口径必须一致。构建全局维表。
4. 数据模型复用
5. 数据完善

OneData 体系的目标是构建统一的数据规范标准，让数据成为一种资产，而不是成本。资产和成本的差别在于资产是可以沉淀的，是可以被复用的。成本是消耗性质的、是临时的、无法被复用的。

数据分层

为了实现模型的复用，数据中台适合采用分层的设计方式，常见的分层包括：

1. ODS（operational data store） 原始数据层/操作数据层：在这层是简单的数据接入，原封不动地接入原始数据即可。
2. DWD （data warehouse detail）明细数据层：在这层不是简单的数据接入，而是要考虑一定的数据清洗，比如异常字段的处理、字段命名规范化、时间字段的统一等。
3. DWS （data warehouse service）轻度汇总数据层：DWB与DWD的主要区别在于二者的应用领域不同，DWD的数据来源于生产型系统，并未满足一些不可预见的需求；轻度综合层则面向分析型应用进行细粒度的统计和沉淀。
4. ADS/DM 应用数据层/数据集市层：应用层是根据业务需要，由前面三层数据统计而出的结果，可以直接提供查询展现，或导入至oracle/mysql中使用。

最后，数据中台的数据必须尽可能的覆盖所有的业务过程，数据中台中每一层的数据也要尽可能完善，让数据使用者尽可能的使用汇总后的数据。

数据模型

数据模型可复用，完善且规范。

完善度

1. DWD 层完善度：
   衡量DWD层是否完善，最好看ODS层有多少表被DWS/ADS/DM层引用。因为DWD以上的层引用的越多，就说明越多的任务是基于原始数据进行深度聚合计算的，明细数据没有积累，无法被复用，数据清洗、格式化、集成存在重复开发。
   跨层引用率：ODS层直接被DWS/ADS/DM层引用的表，占所有ODS层表（仅统计活跃表）比例。跨层引用率越低越好，在数据中台模型设计规范中，我们要求不允许出现跨层引用，ODS层数据只能被DWD 引用。
2. DWS/ADS/DM 层完善度：
   考核汇总数据的完善度，我认为主要看汇总数据能直接满足多少查询需求（也就是用汇总层数据的查询比例衡量）。如果汇总数据无法满足需求，使用数据的人就必须使用明细数据，甚至是原始数据。
   汇总数据查询比例：DWS/ADS/DM层的查询占所有查询的比例。你要明确的是，这个跟跨层引用率不同，汇总查询比例不可能做到100%，但值越高，说明上层的数据建设越完善，对于使用数据的人来说，查询速度和成本会减少，用起来会更爽。

复用度

数据中台模型设计的核心是追求模型的复用和共享，一个比较差的模型设计，自下而上是一条线。而一个理想的模型设计，它应该是交织的发散型结构。
模型引用系数：一个模型被读取，直接产出下游模型的平均数量。
比如一张DWD层表被5张DWS 层表引用，这张DWD层表的引用系数就是5，如果把所有DWD层表（有下游表的）引用系数取平均值，则为DWD层表平均模型引用系数，一般低于2比较差，3以上相对比较好（经验值）。

OneService

数据即服务，强调数据中台中的数据应该是通过API接口的方式被访问。API 接口一方面对应用开发屏蔽了底层数据存储，使用统一标准的API接口查询数据，提高了数据接入的速度。另一方面，对于数据开发，提高了数据应用的管理效率，建立了表到应用的链路关系。

1. 屏蔽异构数据源：支撑类型丰富的查询引擎，满足不同场景下数据的查询需求，常见的有MySQL、HBase、Greenplum、Redis、Elasticsearch等。
2. 数据网关：要实现包括权限、监控、流控、日志在内的一系列管控能力，哪个应用的哪个页面访问了哪个模型，要做到实时跟踪，如果有一些模型长时间没有被访问，应该予以下线。
3. 逻辑模型：屏蔽底层的模型设计的实现，面向用户提供逻辑模型。逻辑模型可以类比视图，它可以帮助应用开发者屏蔽底层的数据物理实现，实现相同粒度的数据构造一个逻辑模型，简化了数据接入的复杂度。
4. 性能和稳定性：由于数据服务侵入到用户的访问链路，所以对服务的可用性和性能都有很高的要求，数据服务必须是无状态的，可以做到横向扩展。

数据中台组织架构和职责边界

1. 数据产品部门：负责数据中台、数据产品的体系规划、产品设计、规范制定、应用效果跟进，指标口径的定义和维护（有的部门是由分析师管理）。
2. 数据平台部门：负责研发支撑数据中台构建的产品，例如指标系统、元数据中心、数据地图等。
3. 数据开发团队：负责维护数据中台的公共数据层，满足数据产品制定的数据需求。
4. 应用开发团队：负责开发数据应用产品，比如报表系统、电商中的供应链系统、高层看板、经营分析。

数据地图

每个主题域下有哪些表，每个表什么含义；每个主题域有哪些指标、其含义和数据血缘；地图可以根据主题域或者表、血缘查到对应的表和指标元数据。

数据血缘

数据血缘是指一个表是直接通过哪些表加工而来（上游表），数据血缘一般会帮我们做影响分析和故障溯源。比如说有一天，你的老板看到某个指标的数据违反常识，让你去排查这个指标计算是否正确，你首先需要找到这个指标所在的表，然后顺着这个表的上游表逐个去排查校验数据，才能找到异常数据的根源。

元数据

元数据应该包括数据字典、数据血缘和数据特征。

指标

指标是一种特定类型的元数据，公司的运营会围绕它进行工作，可以说，它是业务和数据的交汇点。

整个数据中台需要一个全局统一的指标字典。

规范命名

对于原子指标，指标名称适合用“动作+度量”的命名方式（比如注册用户数、购买用户数），标识的命名用英文简写或者汉语拼音缩写比较好。

对于派生指标，指标名称应该严格遵循“时间周期+统计粒度+修饰词+原子指标”的命名方式，标识命名要用“修饰词_原子指标_时间周期”的方式。

如何从烟囱式的小数仓到共享的数据中台

1. 第一，接管ODS层，控制源头。
2. 第二，划分主题域，构建总线矩阵。主题域划分要尽量涵盖所有业务需求，保持相对稳定性，还具备一定的扩展性（新加入一个主题域，不影响已经划分的主题域的表）。
3. 第三，构建一致性维度。公共维度属性与特有维度属性拆成两个维表；产出时间相差较大的维度属性拆分单独的维表，比如有些维度属性产出时间在凌晨2点，有些维度属性产出时间在凌晨6点，那2点和6点的就可以拆成两个维表，确保核心维表尽早产出；出于维表稳定性产出的考虑，你可以将更新频繁的和变化缓慢的进行拆分，访问频繁的和访问较少的维表进行拆分。
4. 第四，事实表整合。事实表整合遵循的最基本的一个原则是，统计粒度必须保持一致，不同统计粒度的数据不能出现在同一个事实表中。

如何提高数据质量

1.添加稽核校验任务

在数据加工任务中，对产出表按照业务规则，设计一些校验逻辑，确保数据的完整性、一致性和准确性，这是提升数据质量最行之有效的方法。

通常建议你在数据产出任务运行结束后，启动稽核校验任务对数据结果进行扫描计算，判断是否符合规则预期。如果不符合，就根据提前设定的强弱规则，触发不同的处理流程。

如果是强规则，就立即终止任务加工链路，后续的任务不会执行，并且立即发出电话报警，直到故障被认领；如果是弱规则，任务会继续执行。但是存在风险，这些风险会通过邮件或者短信的方式，通知到数据开发，由人来进一步判断风险严重程度。

稽核规则

1. 完整性规则：主要目的是确保数据记录是完整的，不丢失。常见的稽核规则有表数据量的绝对值监控和波动率的监控（比如表波动超过20%，就认为是异常）。还有主键唯一性的监控，它是判断数据是否有重复记录的监控规则，比较基础。除了表级别的监控，还有字段级别的监控（比如字段为0、为NULL的记录）。
2. 一致性规则。主要解决相关数据在不同模型中一致性的问题。商品购买率是通过商品购买用户数除以商品访问uv计算而来的，如果在不同的模型中，商品购买用户数是1W、商品访问uv10W，商品购买率20%，那这三个指标就存在不一致。
3. 准确性规则。主要解决数据记录正确性的问题。常见的稽核规则有，一个商品只能归属在一个类目，数据格式是不是正确的IP格式，订单的下单日期是还没有发生的日期等等。

2.建立全链路监控

基于数据血缘关系，建立全链路数据质量监控。

上图中，业务系统的源数据库表是起点，经过数据中台的数据加工链路，产出指标“黑卡会员购买用户数”，数据应用是链路的终点。

对链路中每个表增加稽核校验规则之后，当其中任何一个节点产出的数据出现异常时，你能够第一时间发现，可以快速判定整个指标加工链路上节点是否运行正常，产出任务是否有更新，提高了问题排查速度。

数据服务

数据服务，使数据中台暴露的不再是数据，而是接口，接口不再归属于某个数据应用，而是在统一的数据服务上。这就使接口可以在不同的数据应用之间共享，同时因为数据服务具备限流的功能，使接口背后的数据共享成为可能，解决了不同应用共享数据相互影响的问题。

避免烟囱式开发造成资源浪费。

数据服务打通了数据和应用的访问链路，建立了从数据应用到数据中台数据的全链路数据血缘关系

数据服务把数据应用和中台数据进行解耦，当中台数据表结构变更时，我们只需要修改一下数据服务上接口参数和数据字段的映射关系就可以了。不需要再修改代码，重新上线数据应用。

数据服务应具备的8个功能

1. 接口规范化定义：对各个数据应用屏蔽了不同的中间存储，提供的是统一的API。
2. 数据网关：必须要具备认证、权限、限流、监控四大功能，这是数据和接口复用的前提。
3. 全链路打通：负责维护数据模型到数据应用的链路关系。
4. 支持推和拉的数据交付方式。
5. 利用中间存储，加速数据查询：数据中台中数据以Hive表的形式存在，基于Hive或者是Spark计算引擎，并不能满足数据产品低延迟，高并发的访问要求。一般做法是将数据从Hive表导出到一个中间存储，由中间存储提供实时查询的能力。存储使用场景
6. 逻辑模型，实现数据的复用：可以在数据服务中定义逻辑模型，然后基于逻辑模型发布API，逻辑模型的背后实际是多个物理表，从用户的视角，一个接口就可以访问多张不同的物理表了。逻辑模型可以类比为数据库中视图的概念，相比于物理模型，逻辑模型只定义了表和字段的映射关系，数据是在查询时动态计算的。逻辑模型可以看作是相同主键的物理模型组成的大宽表。逻辑模型的存在，解决了数据复用的问题，相同的物理模型之上，应用可以根据自己的需求，构建出不同的逻辑模型，每个应用看到不同的列。
7. 构建API 集市，实现接口复用：应用开发者可以直接在API 集市发现已有的数据接口，直接申请该接口的API 权限，即可访问该数据，不需要重复开发。

数据中台基本流程

数据研发、数据分析以及资产管理是数据中台中三个基本流程