背景介绍:
在这里，从数据的源头，到指标的整理，到数据模型，到指标输出，数据质量，一直和产品形成闭环，我会用kimball建模和one data,one service方法论和技术结合在一起，来如果构建我们的数据中台。
- 熟悉业务
- 元数据
- 指标整理
- 模型开发
- 数据质量
- 提供服务
- 数据产品闭环
- 结果
熟悉业务
数据总台，必须要非常熟悉我们的业务，因为指标的整理，模型的创建都离不开我们的业务，如果对业务了解的不够彻底，那么在后面的数据建模上面必然会出现各种疑惑，以及指标的整理，对业务如果不够熟悉，那么对指标的业务口径就定义的不够清晰，导致算出来的指标和计算逻辑到底是否一致，数据是否可信的问题。
元数据
在熟悉了业务后，那么我们就需要知道我们有哪些数据，以及这些数据的含义。在现在的企业系统中，通常会有多个数据源，如何梳理这些不同数据源的元数据，这里有两种方案。
1: 构建不同数据源的元数据系统。比如我们有mysql,hive,hbase,kafka,oss以及更多的数据源的时候，我们可以通过自己的程序获取到所有的系统的元数据，这样我们就可以知道我们有哪些数据了。
2: 上面说的这种方案，还会有一个问题，就是数据孤岛的问题。数据孤岛，就是数据分布到了不同的系统上，即使我们知道了这些元数据信息，该怎么用。比如对于某个操作，一部分数据存在kafka中，一部分数据存在mysql中，即使我们有了这个信息的数据，由于分布在不同的系统中，所以造成了数据无法发挥出它的价值。这里第二种方案就是基于hdfs构建数据湖。hdfs可以存放结构数据和非结构数据，我们可以将数据库的数据和用户产生的日志数据都存放在hdfs中，使用hive将数据进行结构化。这样的话我们只需要把不同的源数据系统的数据全部都同步到hdfs中，使用hive对外提供元数据信息，再使用spark,mr,flink来处理我们的数据。这样我们就可以彻底打通我们的源数据，解决数据孤岛的问题，而且通过atlas来同步hive中的历史元数据信息和实时更新元数据信息。
指标整理
如果我们已经找到了所有的指标，使用指标拆分的方法对这些指标进行拆分，这样就很方便管理我们的指标。这里管理指标可以使用主题域的方式来管理我们的指标。主题域，可以理解成是不同的部门分析的不同的领域。比如老板比较看重利润，那么我们可以划分出一个交易域，而开发可以划分出流量域等等。划分完主题域后，下一步就是确定业务过程，业务过程可以理解成是一个最小的不可再拆分的事件，比如在交易域中，可以有下单，支付，抢购等等。每个业务过程又可以派生出原子指标，派生指标和复合指标。
原子指标：原子指标只是一个抽象的指标，实际上是不存在的，比如昨天的下单人数，这里的院子指标就是下单人数，这个指标是抽象化的，但是无法求出，下单人数，是什么时候的下单人数，是男性还是女性，这些都没有给出，所以原子指标只是一个抽象的指标。
派生指标：现在常见的一些指标都是派生指标，比如，昨天各个省18岁以下的下单人数，这个指标可以看成是一个派生指标，可以是一个具体的值，可以通过数据库的数据得到唯一的指标值。而派生指标=原子指标+业务限定+统计粒度+统计周期。就拿刚才的案例举例，原子指标就是下单人数，业务限定就是18岁以下的人，统计粒度就是省份，统计周期就是昨天。所有的派生指标都可以按照这种形式来进行划分。
复合指标：复合指标就比派生指标稍微麻烦一些，比如同环比这些，类似于这种的可以使用复合指标来管理。
模型开发
模型开发就是基于业务来划分事实表和维度表。首先，应该如何划分？所以，这里我们也可以使用主题域的方式来划分我们的模型。我们划分的主题域可以和前面使用指标划分的主题域保持一致。划分主题域，确定业务过程，确定从哪些维度来进行分析，我们常见的维度有地区，时间，人，商品等等都可以作为我们分析的维度。所以，为了确保指标的准确性，我们需要构建全局统一维度表。业务过程就可以派生出事实表，基于业务过程和全局一致性维度构建总线矩阵，我们从总线矩阵来确定我们从哪些维度来分析我们哪些业务过程。有了总线矩阵，就可以开发事实表和维度表。
数据质量
通过中台完成了我们的指标，通过连通线上的数据形成一个闭环。某天，运营反应我们算出来的数据有问题，于是从修复-重置下游-发送邮件，这样一天的时间就过去了，效率很低。所以，我们应该做到早发现，早修复，这里又设计到了一个数据质量的问题。我们可以通过每天跑一些定时脚本来检测我们的数据有没有问题。而这个脚本可以基于我们的业务来设置不同的业务规则。比如，贷款项目中，一个人的授信金额不可能达到100w, 我们通过脚本，select * from tb where money>1000000,通过这个脚本每天跑完了离线任务来检测我们的数据，一旦发现有问题的数据，马上发送邮件，这样我们就可以第一时间去修复这条数据以及这些数据设计到的所有下游和指标。除了这种基于业务规则来开发我们的脚本，还可以通过指标和指标之间的依赖性来检测我们的指标，比如库存=总进货-总出货，那么我们就可以开发这种规则来判断这些数据能不能对的上。
对于数据算出来的指标对不对，设计到的数据质量我们只有做到早发现，早修复，避免带来更大的损失。因为数据会随着时间的变化而变的越来越不值钱，及其的发现数据问题也是企业中必须重视的一环。
提供服务
one data,one service体系是阿里提出来的数据中台系统，one data可以理解成是同一维度的度量只处理一次，one service就是向外提供服务了。现在常用的就是基于api的形式向外提供服务。首先我们需要知道为什么需要使用api的形式向外提供服务，为什么不知道让别人访问我们的报表或者ads呢？数据中台快，准，省，这里说一下省的问题。比如线上现在有1000个任务每天都在执行，这些任务是否算出来的数据每天都会被访问呢？不管是数据血缘还是直接访问，我们无法得到哪些报表被哪些人访问了。所以我们可以使用基于api的形式，凡是得到数据中台的数据必须通过该形式获取，通过给不同的部门分发不同的令牌，这样我们就可以在代码中添加不同的指责很方便的统计到哪些报表被访问。再基于数据血缘，得到这些报表来自于哪些上游任务，这样就可以下线很多任务，从而来节省我们的资源。
数据产品闭环
数据中台开发完成后，可以实时的监控线上的业务过程，来判断运营的这个抉择是否可可靠的，带来了更好的收益。数据中台应该随着产品的迭代而迭代，通过与产品形成闭环，及时发现产品中的问题。到此，数据中台第一阶段差不多已经完成
通过one data,one service体系，我们将之前的700个指标去重得到了300多个指标，开发成本下降一半，并且实现了指标的服用。在成本方面，使用one service检测到了有50%的报表在45天内没有人访问，我们对这些报表以及上游任务进行下线，节省了大概20%的机器成本。通过kimball建模，使得开发速度从以前一个指标可能需要一天的时间，现在只需要半天的时间就可以完成，并且数据正确性大幅度提升。
