大数据实践之路-[读书笔记]

     最近因为工作的原因和数据打交道比较多，尤其最近几年提出了数据也是企业的一种资产，数据对于企业的重要性也是逐渐体现出来，通过数据驱动业务已经不是一种空想，而是在逐步落地中，在此基础上，发现了一本关于数据中台的书，读完感受颇深，特此整理成读书笔记，各位有兴趣也可以去阅读原书整体再看一遍。

开篇-困局

    书籍开篇就提到了数据的质量问题，主要是数据部门和业务部门之间合作产生的一些合作意见，比如指标不统一，数据延迟，数据不准确等等，这个在实际面客过程中也基本遇到了同样的问题，看到这里不禁想到传统的IT和业务部门合作产生的问题，IT不能很好的响应业务部门的需求，比如业务部门想要做一个活动，IT部门就要提前评估好可能产生的资源，而且由于之前是物理资源，扩展起来也比较麻烦，所以产生了上云，利用云的弹性伸缩以及快速性完成扩容动作，而后又有了微服务，容器，devops等一系列技术，核心诉求就是快，快速响应市场变化。现在需要数据来驱动业务，同样会面临这个问题，传统的报表都是T+1的方式，刚开始接触数据报表的时候还有点新鲜感，时间一长不免觉得有点慢，能否再快一点？但是还要保证数据准确性，所以文章里提到了评估数据质量高低的几种方法。

If they are fit for their intended in operations， decision making and plannin(根据这些数据做出的操作、决策和规划符合之前的预期，那么这些数据是高质量的)

定性的角度考虑：

数据的完整性、数据的准确性、数据的一致性、数据的规范性及数据的时效性。

注意点：我们在关注完整性等指标的时候也需要注意法律法规的影响，比如出台的一些数据安全法，个人隐私保护法，欧洲GDPR等。这部分是目前很多企业都需要特别关注的。

中篇-破局

面对上面提出的这么多的问题，引出了数据中台破局的思路。

数据中台定义：

数据中台起初只是作为一套架构理论和指导思想被提出的，但是经过摸索和实践，数据中台在业内已经逐渐演变成一个完整的系统性工程，在组织架构、数据架构、技术选型、流程规范等方面都具有明确的设计思路与执行细节。建设数据中台的主要目的是解决企业在发展的过程中，由于数据的激增与业务的扩大而出现的统计口径不一致、重复开发、指标开发需求响应慢、数据质量低、数据成本高等问题。通过开发一系列数据工具（元数据中心、数据指标中心、数仓模型中心、数据资产中心、数据服务中心），规范数据供应链的各个环节，以一种标准的、安全的、统一的、共享的、服务化的方式支撑前端的数据应用。

之后分别介绍了数据中台的几个组成元素，元数据建设， 数据指标设计，数据仓库模型，数据资产中心，数据服务中心，从这里可以看到数据中台的建设并不是一个简单的事情，而是一个系统性的工程。

目前市面上比较成型的工具：阿里云的maxcompute+dataworks可以作为参考。

1）元数据：

元数据实际上是对数据的描述，一个数据，一张表是什么样的，总是需要一些描述，否则对于一堆的数据，只能两眼懵圈，之前遇到的一个客户选择上云的原因是他们无法管理好每个门店的服务器运行情况，甚至不知道服务器还在不在，数据也一样，你有好多张表，但是却不知道这些表是做什么的，表和表的关系是什么，数据想要充分用起来也会很难，所以对于元数据需要实现三大功能，（1）数据整合。（2）数据管理。（3）数据地图。

整合就是数据采集，把各端数据采集过来，工具的有flume，datax, kettle等。

管理就是表的名称，字段，依赖关系等。针对不同的元数据，可以分成：数据属性，数据字典，数据血缘。

数据地图就是搭建起来的数据资产列表，可以在里面对表进行搜索。搜索的时候可以将结果进行排序。

2）数据指标中心

数据部门的核算数据与运营部门的数据不一致，不少客户都会出现这种情况，出现这种情况的主要是因为大家对于一个指标的定义不一致，比如新用户数这个指标，有的部门认为用户启动了APP算是新用户，有的部门对新用户的定义是首次下单并完成支付的用户，于是统计上就有差异了，因此指标管理是一个很重要的过程。

1、指标拆分成了原子指标与派生指标，并归集到主题域上，方便管理，派生指标主要是在原指标的基础上上加上更细粒度的维度看数，比如下单金额，可以加上周期和业务属性，形成A门店8月5日下单金额数。

2、指标命名规范，语义明确，需要让人看到这个指标能够知道这个指标代表的是什么意思。

3）数仓建设

数据从产生到最终应用，会经过一系列的处理，很少有数据采集到之后能立刻使用，比如做一些去重，不合理的字段替换等等，但是如果每次使用数据都要对原始数据做处理，那么对资源也是一种极大的消耗，而且会产生所谓的重复开发的问题，所以引申出了分层的概念。

一般市面上常见的分层为：

ODS【操作存储层】：ODS层存放的数据应尽量与原数据保持一致。

CDM【公共维度模型层】(DIM,DWD,DWS)：DIM是纬度层，主要是纬度表，DWD是根据业务过程作为依据，构建明细的事实逻辑表，DWS是一些汇总层，主要存放一些派生指标数据。

ADS【应用数据层】：结合实际场景抽取CDM或者ODS层数据形成应用表。

主题域划分：主题域的划分可以根据业务过程，也可以根据部门情况，

在数仓建设完成后，需要对数仓做一些评估

1. 规范度
2. 完善度
3. 复用度

4）数据资产中心​

随着数据中台的投入运行，数据积累越来越多，同样资源消耗也会越来越多，此时需要考虑对于质量和资源的管理。

数据质量

数据从加工到最终应用会经过一些链路处理，同时数据会被用户驱动业务，用于决策依据，所以此时如果数据出错，那造成的影响可能是无法预估的，所以把控数据质量就显得特别重要。

为了更好的管理数据，此时可以对数据进行定级，就像等保一样，根据一旦数据出现问题可能造成的影响有多大来进行定级。

比如阿里云上的划分：

• 毁灭性质：数据一旦出错，将会引起重大资产损失，面临重大收益损失等。标记为A1。
• 全局性质：数据直接或间接用于企业级业务、效果评估和重要决策等。标记为A2。
• 局部性质：数据直接或间接用于某些业务线的运营、报告等，如果出现问题会给业务线造成一定的影响或造成工作效率降低。标记为A3。
• 一般性质：数据主要用于日常数据分析，出现问题带来的影响极小。标记为A4。
• 未知性质：无法明确数据的应用场景。标记为Ax。

同时需要对数据链路进行监控，主要考虑如下几个方面：

1）完整性 2）准确性 3）规范性 4）一致性 5）时效性

数据成本

一般会考虑存储成本，计算成本等，比如存储可以通过压缩存储节省资源，当然如果在云上的话还可以借助OSS等便宜的存储进行归档存储。而计算方面则可以优化就算资源，同时也可以借助现在云上的弹性计算，实现资源节省。

后篇-应用

系统建设好后，可以用来对接BI，用户画像，反欺诈，个性化推荐等等，这里就不详细写了，后续可以整理成单独的文章。

后记：

数据在企业中的作用越来越重要，国家十四五计划也提到了数字化转型，根据我们沟通交流的客户情况来看，有的企业已经在数字化上走了一段路了，而有的企业信息化建设都还没有完善，所以在真正建设数据中台之前，可以先整体的评估一下自身IT建设情况，以及整体人员认知情况，为数字化打好基础，而不是跟风建设。