今天继续谈阿里的这本书，包括数据服务平台、数据挖掘平台、数据建模、数据管理及数据应用，希望于你有启示。
1、数据服务平台
数据服务平台可以叫数据开放平台，数据部门产出海量数据，如何能方便高效地开放出去，是我们一直要解决的难题，在没有数据服务的年代，阿里的数据开放的方式简单、粗暴，一般是直接将数据导出给对方，我想，现在大多公司的开放应该也是如此吧，虽然PaaS喊了这么多年，但真正成就的又有几个？
即使如阿里，在数据开放这个方向上的探索和实践，至今也有7个年头了，任何关于数据开放毕其功于一役的做法都将失败，任何一次数据开放的改进都是伴随着对于业务理解的深入而成长起来的。
阿里的数据开放经历四个阶段，DWSOA、OpenAPI、SmartDQ和OneService：
DWSOA：是数据服务的第一个阶段，也就是将业务方对数据的需求通过SOA服务的方式暴露出去，由需求驱动，一个需求开发一个或者几个接口，编写接口文档，开放给业务方调用。
这种架构简单，但接口粒度很粗，灵活性不高，扩展性差，复用率低，随着业务需求的增加，接口的数量大幅增加，维护成本高企，同时，开发效率不高，一个接口从需求开发到上线，按阿里说法至少1天，其实远远不止，如果要变更1-2个字段，也要走一整套流程，这应是大多数公司的常态。
OpenAPI：DWSOA的明显问题是烟囱式开发，很难沉淀共性数据，OpenAPI将数据按照统计粒度进行聚合，同样维度的数据，形成一张逻辑表，采用同样的接口描述，针对某一类的查询，只需要调用一个接口即成，这种形式可以有效收敛接口，笔者公司对外服务很多也是这种形式，比如通过封装几十个位置服务API，统一对外提供灵活查询能力，但其实复杂逻辑的接口还是需要采用一事一议的方式，即第一种方式。
SmartDQ：数据维度是非可控的，随着数据的深度使用，OpenAPI显然会急剧增加，维护映射的压力会很大，阿里于是再抽象一层，用DSL（Domain Specific Language,领域专用语言）来描述取数需求，支撑标准的SQL，至此，所有的简单查询服务减少到另一个接口，这降低了数据服务的维护成本。
传统的方式查问题需要查源码，确认逻辑，而SmartDQ只需要检查SQL的工作量，并可以开放给业务方通过写SQL的方式对外提供服务，SmartDQ封装了跨域数据源和分布式查询功能，通过逻辑表屏蔽了底层的物理表细节，不管是HBASE还是MySQL，是单表还是分库分表，这极大简化了操作的复杂度。
其实中国移动经营分析规范很早就提出了即席查询、伪代码等的封装方式，笔者企业也通过自助取数的方式在实践，阿里在落地上做的比较好，其是集大成者，传统企业的大数据类产品往往只能在单点实现突破，无法用一只团队始终如一的坚持做一个产品，比如企业的自助取数平台在设计时没想到需要支撑大数据时代的跨异构数据库，由于当初的自助取数团队和当前的DACP的团队完全是两拨人，很难实现既有能力的传承。
阿里的思路说不上很超前，但它不仅落地了，而且在不停演进，这也许就是企业自主研发的价值，它的产品始终流着同样的血液。
OneService：SQL显然无法解决复杂的业务逻辑，SmartDQ其实只能满足简单的查询服务需求，正如我们的自助取数也仅能满足50-60%的临时取数一样，企业遇到的场景还有以下几类：个性化的垂直业务场景、实时数据推送服务、定时任务服务，OneService主要是提供多种服务类型来满足客户需求，分别是OneService-SmartDQ、OneService-Lego、OneService-iPush、OneService-uTiming。
Lego被设计成一个面向中度和高度定制化数据查询需求，支持插件机制的服务容器，笔者理解就是提供定制环境和暴露接口，你要怎么做就怎么做。
iPush应用产品是一个面向TT、MetaQ等不同消息源，通过定制过滤规则，向Web、无线等终端推送消息的中间件平台。
Utiming是基于在云端的任务调度应用，提供批量数据处理服务，支撑用户识别、用户画像、人群圈选三类服务的离线计算以及服务数据预处理、入库，这个感觉是非常个性化的一个应用。
2、数据挖掘
阿里构建了一套架构于阿里云MaxCompute、GPU等计算集群之上，汇聚了阿里大量优质的分布式算法，包括数据处理、特征工程、机器学习算法、文本算法等，可高效完成海量、亿级维度数据的复杂计算，同时提供一套极易操作的可视化编辑页面，大大降低了数据挖掘的门槛，提高了建模效率。
其选择的计算框架是MPI，其核心算法都是基于阿里云的MaxCompute的MPI实现的。
其算法平台也集成了绝大部分业界主流的机器学习算法。
让笔者有点吃惊的是阿里还搞了数据挖掘中台，这个笔者以前也想做过，但后来发现跟数据仓库的融合模型（比如宽表）有很多类似之处，因此没坚持下去。
阿里将数据中台分为三层：特征层（FDM）、中间层和应用层（ADM）,其中中间层包括个体中间层（IDM）和关系中间层（RDM），如下图所示：
FDM层：用于存储在模型训练常用的特征指标，这个跟融合模型的宽表类似，笔者很好奇阿里的数据仓库的DWS仅仅是汇聚层还是包括了宽表，否则跟这个FDM是有很大雷同的。
IDM层：个体挖掘指标中间层，面向个体挖掘场景，用于存储通用性强的结果数据，其实在笔者看来就是通用标签库的源表，那个ADM就是个性标签的源表，不知道有没理解对。
数据挖掘这一章很短，缺乏一些细节，想来跟部门的定位有关，数据挖掘一般应用导向，核心的东西大多可能掌握在各类业务部门的挖掘师手中，笔者对于数据挖掘中台的实际价值还是有疑问的，毕竟挖掘千变万化，数据仓库建模好理解，但数据挖掘搞中台如何能跟得上变化？
3、数据模型
数据建模在这本书占据了三分之一篇幅，可见其重要性，首先谈谈阿里数据模型的历史吧，其实跟笔者还有很多渊源，因为2005-2007年间为公司服务的某合作伙伴大量BI人员跳槽到了阿里，据说构建了阿里的一代数据仓库系统，这些人员很多跟笔者共事过，现在读来，还是有点感慨。
（1） 历史发展
第一阶段：完全应用驱动的时代，数据完全以满足报表需求为目的，将数据以与源结构相同的方式同步到Oracle，这跟笔者当年刚进公司的情况类似。
第二阶段：随着阿里业务的快速发展，数据量飞速增长，性能成为一个较大问题，需要通过一些模型技术改变烟囱式的开发模型，消除数据冗余，提升数据一致性，来自传统行业的数据仓库工程师开始尝试架构工程领域比较流行的ER模型+维度模型方式应用到阿里巴巴集团，构建出一个四层的模型架构，即ODL（数据操作层）+BDL（基础数据层）+IDL（接口数据层）+ADL（应用数据层）。ODL与源系统一致，BDL希望引入ER模型，加强数据的整合，构建一致的基础数据模型，IDL基于维度模型方法构建集市层，ADL完成应用的个性化和基于展现需求的数据组装，这个对应笔者所在企业的当前的ODS，DWD，DWA/DWI及ST层，但阿里在构建ER时碰到了较大的挑战，主要是业务快速发展，人员快速变化、业务知识功底的不够全面，导致ER模型产出困难。
阿里得出了一个结论：在不太成熟、快速变化的业务层面，构建ER模型的风险很大，不太适合去构建ER模型，说的有点道理，比如运营商业务相对比较稳定，国际上也有一些最佳实践，从概念-领域-逻辑-物理的全局把控上还能应对，但面对变化，的确有其限制。
第三个阶段：阿里业务和数据飞速发展，迎来了hadoop为代表的分部署存储计算的快速发展，同时阿里自主研发的分布式计算平台MaxCompute也在进行，因此开始建设自己的第三代模型架构，其选择了以Kimball的维度建模为核心理念的模型方法论，同时进行了一定的升级和扩展，构建了阿里巴巴集团的公共层模型数据架构体系。
阿里模型分为三层：操作数据层（ODS）、公共维度模型层（CDM）和应用数据层（ADS），模型层包括明细数据层（DWD）和汇总数据层（DWS）。
ODS：把操作系统数据几乎无处理的存放到数据仓库系统中。
CDM：又细分为DWD和DWS，分别是明细数据层和汇总数据层，采用维度模型方法作为理论基础，更多采用一些维度退化方法，将维度退化至事实表中，减少事实表和维表的关联，提高明细数据表的易用性，同时在汇总数据层，加强指标的维度退化，采取更多的宽表化手段构建公共指标数据层，提升公共指标的复用性。
ADS：存放数据产品个性化的统计指标数据，根据CDM与ODS加工生成。
具体见如下模型架构图：
关于模型的分层每个行业都可以基于自己的实际去划分，没有所谓的最佳实践，比如笔者所在的企业，源端维度一致性非常好，DWD主要做标准化工作，屏蔽ODS变化导致的上层改动，关于维度建模的理念更多体现在DWA/DWI层中。
（2） 模型实施
OneData是阿里的模型设计理论，我觉得写得很好，你看完这个过程，基本会搞清楚维度建模的各个步骤，强烈建议结合后面的维度和事实表建模进行精读，主要步骤如下：
数据调研：业务调研需要对业务系统的业务进行了解，需求分析则是收集分析师运营人员对数据或者报表的需求，报表需求实际是最现实的建模需求的基础。
架构设计：分为数据域划分和构建总线矩阵，数据域划分是指面向业务分析，将业务过程或者维度进行抽象的集合，业务过程可以概括为一个个不可拆分的行为事件，如下单、支付等。构建总线矩阵需要明确每个数据域下游哪些业务过程，业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。
规范定义：规范定义主要定义指标体系，包括原子指标、修饰词、时间周期和派生指标，关于指标的规范定义阿里有单独的一节描述，大家可以好好学习一下，很多时候细节决定成败。
模型设计：模型设计主要包括维度及属性的规范定义、维表、明细事实表和汇总事实表的模型设计。
最后，用一张图镇楼，这张图可值回书价哦。
本书后面用两大节来介绍维度设计和事实表设计，由于过于细节，笔者就不再展开了，如果你是建模人员，一定要好好看看，也可以参考《数据仓库工具箱-维度建模权威指南》这本书，一般在建模过程中你碰到的很多问题它都有解决策略，你未来可能碰到的建模问题，这本书也提及了很多，是建模人员的宝贵的实战参考材料。
4、数据管理
数据管理涉及的东西很多，这本书具体提到了元数据、计算管理、存储和成本管理和数据质量，相对内容比较单薄，我挑两点说一下：
一直听说阿里财大气粗，所有数据都永久保留，其实是谬传，人家也是节约过日子的，看下图你就知道了：
应对层出不穷的数据和应用，数据工程师其实很难确认哪些数据是最重要的，需要优先保障，阿里巴巴提出了数据资产等级的方案，旨在解决消费场景知晓的问题，其将数据划分为五个等级，毁灭性质、全局性质、局部性质、一般性质及未知性质，代号从A1到A5。
那么如何个每份资产打上等级标签呢，就是借助强大的元数据能力，了解哪些表服务于哪些数据产品，基于血缘分析可以讲整个消费链路上打上某一类资产的标签，假如将阿里巴巴生意参谋定位等级A2,则所有相关链路的表的等级都是A2，从而启动对应的保障措施,这个跟笔者企业的大数据保障方法类似，从应用重要程度确定表的保障等级。
5、数据应用
阿里主要介绍了对外的数据产品平台生意参谋和服务于内部的数据产品平台。
生意参谋本质上就是为自己的渠道提供的增值服务，是很成功的一款决策支持产品，体现了一个产品如何从小做起，逐步长成一个庞然大物的过程：
对内数据产品的演进几乎是每一个公司BI系统的发展翻版，但显然它已经长成大树了，从临时取数阶段，到自动化报表阶段（比如BIEE），再到自主研发BI阶段（第三方满足不了自己了），最后到数据产品平台（更加体系化）。
当前阿里的数据产品平台，包括PC和APP版本，共有四个层次，即数据监控、专题分析、应用分析及数据决策。
到这里，基本就读完了，整本书都是经验之谈，读下来闪光频现，建议可以多读几遍。
这本书也引发了笔者一些思考，为什么他们能做成？我们传统企业大数据的差距在哪里？是机制流程问题？数据产品的传承问题？合作伙伴的问题？核心能力自控问题？业务对于数据产品的驱动力问题？小步快跑落地问题？企业产品的规划问题？
有些遗憾的是，这本书更多是就技术谈技术，鲜有数据内容方面的深度阐述，跟直接的价值创造还有距离，比如标签库的管理，核心算法研究，DMP怎么做的等等，当然这个可能跟阿里的大数据管理组织分工有关系，也涉及企业的一些商业秘密。
其实要想了解的东西还有很多，包括机制流程，团队分工，部门协同，中台战略在大数据的落地等等，希望有机会学习。
期盼有更多的企业能分享他们在大数据方面的实践经验，这对提升国内整体大数据管理水平很重要。
