品《阿里巴巴大数据实践-大数据之路》一书（上）

7月有人推荐阿里巴巴刚出的这本书《阿里巴巴大数据实践-大数据之路》，到亚马逊一看才是预售状态，拍下直到8月才拿到。

翻看目录一看，欢喜的很，正好出差两天就带在身边，由于在机场滞留超过12个小时，就把它读完了。

用“品”字有以下几个原因，一是市面上充斥着太多的大数据平台技术的书，诸如hadoop，spark等占据了大部，但对于如何管好大数据却缺乏真知灼见，二是这本书的确干货很多，诚意实足，明显来自阿里实操人员的经验，从作者是阿里巴巴数据技术与产品部就可知道，三是内容跟笔者的专业相符，里面提到的任何一方面笔者都有实操或管理经验，想来自己有资格去品评这本书，最后，阿里巴巴的数据量在那里，其大数据平台历经考验，突然透露一些技术秘密，对于任何有志于搞大数据的企业或个人，都应该去学习一下。

因此用“品”，不能像看一般的书那样一目十行，要能发现里面的先进理念，结合企业或自身的实际看到差距，从中找到可以借鉴的地方，指导后续的大数据工作。

大数据博大精深，正如这本书也是集体创作一样，受限笔者的水平，读书笔记也只能浮光掠影的走一遭，如果你觉得有启示，可以去买一本，自己来品一品。

首先是一张镇楼图，阿里巴巴的大数据系统的体系架构图，划分为数据采集、数据计算、数据服务及数据应用四层，后面的内容就是围绕这张图展开的，技术含量有多高，大家都懂的，如果读到后面迷失了，可以重新回过头来理解这张图。

笔者这里选取的内容，主要是与自身企业对标后感觉有特点的，一般的内容就不提了，当然这仅是笔者的看法，因此建议读完本文后自己去看看原书，不定会获得更多的启示。

一、数据采集

1、线上主动采集工具

阿里巴巴针对web和app端有两个专门的采集工具Aplus.Js和UserTrack，大多传统公司由于长期经营线下，对于web，app等的主动采集能力是偏弱的，一般数据管理部门对于web或app端的采集基本是源端推送过来的文件，对于采集没有实际主导权，内容丰富程度大打折扣，同时无论是web的js脚本还是app的sdk,实际上都是有一定的技术门槛，企业app源端由于受限于合作伙伴的能力，往往采集能力不够，数据质量参差不齐。

互联网源端的日志留存，到底哪些是源端本身的要求，哪些是大数据管理的要求，需要想清楚，大数据管理部门如果想获得更好的数据，是否考虑要往前走一步，毕竟OLAP和OLTP对待数据的角度不一样，人家没必要为你留你所需要的数据。

企业的大数据管理部门，能否适应互联网的新的形式，打破条线分割，在常规的数据库，文本，消息等采集基础上，新增线上的主动采集工具，是巨大的挑战。

当前一些企业提供的企业级大数据采集工具，是缺了这条腿的，以后企业往线上走，这个PaaS能力的确是要具备的。

2、数据同步

阿里巴巴实现了诸如oracle的归档日志的增量采集，应该是比较成熟的，自己企业也采用过类似的OGG技术，虽然可行，但开销很大，新增和存量的合并代价很高， DSG希望能雄起。

现在分库分中心的表越来越多，对于数据同步的配置越加复杂，阿里巴巴的tddl分布式数据库引擎可以通过建立中间逻辑来整合统一分库分表的访问，的确值得借鉴。

很多企业的抽取数据源种类繁多，管理复杂，阿里搞了IDB来实现数据库的统一管理，基于这个元数据能力，在数据同步时，阿里可以采用oneclick来实现数据采集的一健配置和批量化同步，管理的深度和厚度可见一般。

阿里针对数据漂移也给出了解决建议，其实数据漂移问题在每个企业都大量存在，比如运营商计费话单的记录更新时间，日志时间，业务时间和抽取时间往往不一致，这会导致业务的逻辑问题，你可能在上月底12点未到打的电话，业务记录却会在本月的话单里。

二、数据计算

1、MaxCompute离线计算引擎

阿里的MaxCompute离线计算引擎弥补了hadoop的很多缺陷，它提供了一个集成管理方案，包括统一的授权，资源管理，数据控制和权限分配等，并提供一个易用的客户端，支撑Web、SDK、CLT、IDE等4种访问模式，集群数量可以到几万台，安全控制能力加强，这些都是当前很多商用hadoop版本难以做到的。

其计算核心就是网传的飞天内核，包括Pangu(盘古分布式文件系统)、Fuxi（伏羲资源调度系统）、Shennong（神农监控模块）等。

2、统一开发平台

笔者的企业也有这类平台，但跟阿里的还是有差距，它其实是一个工具集，功能更完备，体系化程度更好。

（1）在云端（D2）

D2是集成任务开发、调试及发布、生产任务调度及大数据运维，数据权限申请及管理功能的一站式数据开发平台，并能承担数据分析工作台的功能。

这个其实非常类似笔者企业的DACP，但由于DACP要能对接各类源系统，因此底层的逻辑其实更复杂，实施难度更大，而D2基本只要对接MaxCompute，这其实也是自主研发的一个好处，功能可以做的更强大，体验更好，但相对比较封闭。

（2）SQLSCAN

SQLSCAN将在任务开发中遇到的各类问题，如用户编写的SQL质量差、性能低、不遵守规范等，总结形成规则，并通过系统及研发流程保障，事前解决故障隐患，避免时候故障。

这个功能对于将平台推到一线至关重要，我们的DACP在推广过程中，碰到大量的SQL优化问题，但无论是通过培训还是其他方式，其实都远没有系统中固化规则的好，阿里的实践很好，开发平台一定要记住不可能人人都是代码专家，要用系统化的方式解决问题，这是平台能够规模化的一个核心要素。

关于DACP功能过于庞大的问题，笔者其实也明显感觉到了，阿里的关于开发平台拆分为多个产品的一些思路给了启示，这是有利于小步快跑的原则的，为每个模块取不同的名字，也有利于专项资源的投入。

（3）DQC

DQC（数据质量中心）主要关注数据质量，通过配置数据质量校验规则，自动在数据处理任务过程中进行数据质量方面的监控。

其主要有数据监控和数据清洗两大功能，数据监控主要是设置规则并报警，有强规则和弱规则之分，强规则可以阻断任务执行，数据清洗的方式跟我们的大致类似，在引入过程中不进行清洗，入库后，再基于配置的规则进行清洗。

（4）在彼岸

主要将通用的、重复性的操作沉淀在测试平台中，避免人肉，提高测试效率，笔者所在企业的大数据自动化测试虽然也有一些，但功能不够强大，在彼岸的功能包括数据对比（支持不同集群、异构数据库的表做数据对比，比如数据量、字段统计值SUM，AVG等）,数据分布等

从阿里的统一开发平台可以看出来，其不仅提供了从任务开发到运维的整套工具，还特别注重体系的完整性和规则的沉淀，这类平台工具实际很难由第三方公司提供，而传统企业除了自身研发力量不够，往往由于业务需求的压力导致在IT这类基础平台层面的研发投入不足，一味靠资源和人力的投入去解决一些其实无解的问题，同时将报表取数人员和产品开发人员混编在一起，造成疲于应对需求的局面，这是值得深思的。

3、实时技术

阿里巴巴基于TimeTunnel来进行实时数据的采集，原理和Kafka等消息中间件类似，采用StreamCompute进行流式处理，跟Storm，Stream也类似，对于实时统计的问题，它提的些方案值得借鉴。

在商业智能统计类实时任务中，对于资源消耗有一类是非常高的，那就是去重指标，实时任务为了追求性能，计算逻辑一般在内存完成，在计算去重时，势必要把去重的明细数据保留下来，当去重的明细数据达到上亿时，内存中放不小，怎么办？

精确去重可以通过数据倾斜来进行处理，把一个节点的内存压力分到多个节点，在模糊去重的前提下，可以采用相关的去重算法，把内存使用量降到千分之一甚至万分之一，布隆过滤器就是一种，其简单来讲就是不保存明细数据，只保留明细数据对应哈希值的标记位，当然会出现哈希值碰撞的情况。

实时任务在运行中会计算很多维度和指标，这些数据如何存呢？由于实时任务大多是多线程处理的，意味着数据存储必须能够较好的支持多并发读写，并且延时需要在毫秒级才能满足实时的性能要求，一般使用Hbase，Tair等列式数据存储系统。

当然诸如HBASE等系统缺点也比较明显，必须使用rowkey, 而rowkey的规则限制了读写的方式，显然没有关系型数据库那么方便，但对于海量数据的实时计算和读写，一般还是适用的，针对HBASE阿里提供了表名和rowkey设计的一些实践经验。

比如rowkey可以采取MD5+主维度+维度标识+字维度+时间维度+子维度2，例如卖家ID的MD5的前四位+卖家ID+app+一级类目+ddd+二级类目ID，以MD5的前四位作为rowkey的第一部分，可以把数据散列，让服务器整体负载均衡，避免热点的问题。

笔者一直觉得对于实时数据是不需要建模的，看来还是太天真了，也许主要是实时应用在当前很多企业场景不多所致，但阿里显然不一样，其实时统计能力至关重要，无论是双11大屏还是阿里的生意参谋，都把实时统计指标作为一个卖点，实时模型跟离线模型的建模理念是一致的，比如阿里的流式模型分为五层，ODS层、DWD层、DWS层、ADS层及DIM层，关于每层的含义在笔者后续的文章中会介绍，这里就不再描述了。

本文简要谈了阿里的数据采集和数据计算，下一篇还会谈到数据服务、数据挖掘、数据建模、数据管理及数据应用等，非常精彩，虽然对于很多企业来讲，这些平台和工具可能过重，但思想是先进的。

对于在做类似产品的大公司或者致力于大数据运营的大企业，则要好好研究一下， 它山之石，可以攻玉。