《大数据之路-阿里巴巴大数据实践》拆书稿以及数仓架构的思考
《大数据之路-阿里巴巴大数据实践》拆书稿以及读后感
总体分为三个部分
第一部分：数据技术
数据采集，数据同步，离线和实时计算，数据服务以及数据应用
第二部分：数据模型
维度模型设计
第三部分：数据管理
元数据管理，计算管理以及生命周期管理
以上各部分在逻辑上所处的位置如下图可见：
第一部分、数据技术
数据采集与数据同步属于数据仓库的输入手段，数据采集大部分是数据主动触发程序将数据流向数据仓库，大部分的落地方式可以是以server/agent或者通过网络协议直接发送数据。实时性较高； 而数据同步大部分落地方式是数据被动的被抽取程序获取并流向数据仓库。数据同步的方式应用场景多用于离线批量的数据同步。采用远程访问权限，直接将数据提取出来并存入数据仓库。
《大数据之路》这本书中介绍的数据技术内容脑图如下：
在个人的从业经验中，数据仓库的输入部分应用最多的场景就是：Sqoop/DataX 完成数据同步，数据采集一般使用 Kafka+ Flume/Spark Streaming 。数据同步和采集部分是数据仓库的数据源头，程序的稳定性和准确性都应该保持相当高的水平，才能给后续的数据仓库打好基础。另一方面，数据仓库的计算层，牵扯到数据仓库的分层策略问题。完善的数据仓库基本上应该会包含：数据操作层（近源层）、明细数据层（DWD）、数据汇总层/多维方阵、数据集市/应用。每一层对应的数据粒度不同，满足的数据需求也不相同。
数据分层在一定程度上能够解决以下问题：
- 1 降低数据统计方面的耦合度
- 2 便于数据追根溯源，查找问题
- 3 便于数据的血缘分析
- 4 不同分层对应不同粒度，满足不同的数据需求
数据应用/服务：
针对数据应用方面个人认为数据产品是以后的发展趋势，每个行业在各自领域已经积累了大量的行业数据，目前的场景已经不是销售市场去”打天下“的模式了。而要比的是服务，要将数据产品转化成服务，和自身的业务深度契合。要从数据中发掘价值，体现价值，产生价值效益。现在的企业间合作已经不能停留在表面上的服务层面，而是要深耕业务场景，提供行业解决方案，与合作方深度合作。达到无法替代层次。否则，如果停留在表面的服务合作，无法解决企业痛点问题，终将被竞争激烈市场所淘汰
第二部分、数据模型
维度建模现在的应用越来越频繁，并且基本上演变到最后都是星型模型和雪花模型的混合模型。
维度建模的具体方法论可以看我往期博客，这里再度重申以下建模过程中最重要的几点：
1. 数据规范和标准
- 数据分类标准
- 编码规则标准
- 命名规范（词根清单，表命名，字段命名，作业命名必须规范，见名知意）
2. 创建一致性维度
整个数据仓库，在主题域中某一个维度的命名和含义有且只能有一个，不能出现二义性。并且必须保证其完整性（事件表中出现的维度编码在维度表中一定要能找到含义）
3. 创建一致性事实
1）确定好事实表的粒度和维度，粒度是否可继续下钻（细分），维度是否可以再拆分和补全。
2）事实表的统计维度是否全面（可支撑此业务的所有数据需求），可适当的添加衍生维度
《大数据之路》这本书中介绍的数据模型内容脑图如下：
第三部分、 数据管理
数据管理在 《大数据之路》这本书中介绍了比较多的内容， 这里只侧重于以下三点进行说明：
- 元数据管理
- 计算管理
- 生命周期管理
其实，数据管理的反馈机制存在着整个数据流转过程，元数据管理能够把控数据同步逻辑，数据清洗/统计规则，数据服务的逻辑规则等。计算管理能够反馈作业的执行效率，数据提供服务的质量，集群的性能等。生命周期管理能够反馈数据的迭代更新，集群的存储空间，数据服务的广度和深度等。
《大数据之路》中这三方面的思维导图如下：
其中，在元数据管理方面，个人还没有找到非常适合自己的工具，各位网友有这方面储备的希望给我留言，给一个学习的机会，谢谢！
在元数据管理方面这本书中介绍了阿里的SmartDQ元数据管理模型，看完之后有非常大的触动，在数据服务或接口方面可以参照此模型进行封装服务。并且根据之前的工作经验来看，这种模型的管理方式较为灵活，可以应对不同的主题需求，也具有很强的扩展性。其模型的具体示意图如下：
由上图可以看到，可以在数据服务层构建一系列的虚拟主题，每个虚拟主题就类似与视图，没有实体表和数据，而是通过元数据管理，将主题下所有的物理表进行整合。在提供主题服务时并没有产生数据表的冗余计算和存储空间的消耗。另外完全实现了灵活可配置。
整本书的思维导图如下：