7月份，阿里的数据技术及产品部的同学们出了一本书，大数据之路-阿里巴巴大数据实践，号称全面系统的介绍了阿里巴巴的大数据系统架构。

这很好，阿里的同学们在对外交流这一块，感觉管得是越来越严了，加上人多部门多，平台的整体情况，估计也很难有哪个同学一个人能说得清的，很多事情问一圈也不知道找谁交流合适，既然出了书，正好学习一下，顺便结合我司的情况思考思考，看看有哪些地方可以见贤思齐的。

整体来说，这本书的前半部分介绍了大数据处理链路上主要环节（采集，计算，查询，展示）和相关技术和组件，后半部分侧重介绍阿里在数据模型建设和数据管理／应用方面的实践。

至于具体内容嘛，写得很概括，基本上没有涉及到任何底层技术组件的内部细节，即使画个架构图也是很标准，很粗旷的那种，估计和写书的团队，定位略微偏上层一点也是有些关系的。不过，这样也好，这本书最大的价值是告诉你阿里在大数据实践环节中，都遇上过哪些问题，大致的产品形态和解决思路是怎样的。具体的技术方案细节，其实倒不太重要，毕竟各家自己的实际情况：技术储备，基础组件环境，业务需求都是千差万别的，照搬其实也没什么意义，有哪些坑需要留心，哪些思路和方向可以借鉴，才是最重要的

下面分章节，记录一下重点内容和个人的理解及思考吧。

日志采集

日志采集，这玩意，绝对难度未必有多高，但是的确很繁琐，有很多细节和流程要考虑，不同的客户端如何采集，格式怎么统一，各种用户行为怎么跟踪，如何减少对业务代码的侵入，怎么保证性能和实时性等等。

Web端使用Aplus.js，APP端使用UserTrack SDK

标准做法都是这样，Web端嵌入一个统一的JS去采集页面信息，尽可能减少对业务代码的侵入，APP端通过SDK封装底层组件的差异和日志Log方式的具体实现，降低开发难度。

但是在具体实现中，采集方案做的好坏，更多的还是体现在流程上，日志的埋点，是否有统一的注册，管理，监控，测试流程。业务侵入程度的高低，能否自动生成代码，能否动态无痕埋点等等。

页面PV类日志，指定数据格式规范，业务方按规范填充，有自定义字段可以填充自定义日志内容

说起来简单，但实际上，大家的日志都是从不规范到规范的过程，下游的清洗／计算任务等对上游的数据格式往往也是耦合的，规范格式的过程会是一个漫长而繁琐的过程，要保证业务不受影响，就需要保持兼容，可能要采取日志双跑，线上格式转换，历史数据清洗，具体业务改写等各种措施。

交互类日志通过“黄金令箭”采集：业务方注册采集点，系统生成代码模版，业务方植入代码，采集。

所谓的交互类日志，就是比如用户点个收藏按钮啊，加个购物车啊之类的不涉及页面跳转行为或者无法从页面跳转行为中得到足够信息的操作。

这类日志最麻烦的地方是他们往往和业务逻辑是强相关的，需要采集额外的信息，所以往往无法自动嵌入标准的代码。所以如何Hook进各个业务流程，尽可能的屏蔽日志交互流程的细节，但是又暴露足够的接口给业务方自定义数据内容，甚至做到自动动态埋点，就是难点所在了。但无论如何，从大的流程上来说模版化加注册管理是一定要优先做到的。

页面日志服务端清洗和预处理：数据补全和订正（比如登陆前后用户信息补全）

清洗和预处理的流程，总是要做的，只是在哪个环节实现，扔给下游业务方自己处理，还是在日志采集框架中实现，是统一逻辑实现，还是提供插件或通过接口自定义逻辑实现，系统做得越规范，管理越集中，对整体链路的质量就越有保障，但是代价的高低当然也不一样。越靠前越通用，需要考虑的问题也就越多，开发实现代价当然也就越高（对于开发框架的同学来说，对于整体业务来说倒不一定）。

特殊场景处理：曝光日志预聚合，用户页面回退行为识别

曝光日志，是电商场景下很特殊的一类日志，具体来说：比如商品图墙列表上有多少商品给用户展示过就是一种典型的曝光日志，一般用来作为推荐算法的输入信息或者广告展示计费用途。曝光日志一般是点击日志的几十到几百倍，而一页内的曝光信息又大致雷同，所以一般都会做聚合。

只是如何聚合，由客户端采集框架聚合还是由业务自身聚合（比如曝光日志设计为一条可以直接记录一批商品），这会是需要权衡考虑的。

用户回退行为的识别，也是比较棘手的，因为跟踪用户浏览行为的目的，主要是为了分析链路转化率，用来优化业务或分析活动效果等。而页面回退行为对这些行为分析是一种干扰。在下游数据分析过程中再识别这种行为往往很难，在采集端会有更充分的信息进行识别。但具体实现也并不是总能万无一失，而且有些特殊情况下，你可能还需要保留这种回退行为的数据。我司实践中，对这种行为也做了识别，实际记录过程还保留了不同的记录。

H5 和 native日志统一：H5日志通过JS接口传给Native的方法，转换成native的格式统一输出

H5越来越流行，Hybrid的应用越来越普及，用户并不关心你的页面是native的还是H5的，但是日志的采集方案在Web端和Native端通常却是两套架构，后续采集传输流程等等很可能也不在一条链路上。如果不加处理，对于用户行为的链路分析会带来很大的麻烦。

具体怎么处理，不外乎是要自动识别H5页面的运行环境，打通H5跳转到Native和Native跳转到H5两个方向的页面数据传递，加上各种回退之类行为要处理，安卓和IOS的方案要兼容等等，真的实现起来，还是要费不少力气处理好各种细节的。

日志分流：根据页面业务类型的不同，采用不同的URL Log记录地址，将分流工作从客户端开始做起

日志分流的目的，自然是为了增加日志链路水平拓展的能力，然后降低后续流程具体业务的计算代价，所以理论上来说，分流得越早，分流得越彻底，这方面的收益越高。

但是，与此同时，分流也有代价，比如阿里的这种做法，从客户端采集阶段就开始分流，那就要考虑如何合理的拆分业务。客户端分流，目的当然是在采集落盘的时候，不同日志就落在不同的消息／文件上，带来的问题是，这些日志的采集进度很可能无法完全一致，如果链路跟踪需要串接不同业务的数据，那么不管需要Join数据，还会有数据时间同步问题需要考虑，会给后续处理流程带来一定的难度。这方面的权衡，不知道阿里具体的分流在业务实施中，是按什么粒度来进行的，有时间可以跟一下淘宝Web端的各个页面分析一下。

我司目前在客户端对于主要的用户行为类日志，还没有根据页面所属业务类型，再做进一步的分流工作，而是在后续数据清洗端实施的分流，这么做对于一些业务的计算代价自然就会高一点。客户端分流，之前也不是没有考虑过，只是需求不太强烈，不过后续还是应该适当考虑一下。

大促保障：主要使用缓存部分日志先不发送，以及日志采样等

日志分流以后，当然可以做开关，缓存，采样等工作，这也是分流的收益之一，也是我们后续改进的动力之一

整体看下来，和之前其它途径了解到的信息差不多，很多问题的解决思路和我司目前的实现也大致相当，不过，整体规划性方面做得比我们好很多，一些方案在我司还停留在可以优化，但并没有真的去实施的阶段。

数据同步

数据同步其实也是大数据平台整体工作流程的重点环节之一，不过书中的内容比较标准，所以我记下来的点不多，主要是一些我们原计划中也打算改进的部分。

DataX 在任务层面拆分job，并发执行数据交换

阿里的数据交换，底层是通过DataX来实现的，这个稍微了解过的同学应该都清楚。我司也是仿的DataX的思路，自主开发的星型结构，插件式的数据交换组件。不过，单个作业的分布式化执行的工作一直没有提上议程。分布式一个数据交换业务的方式有很多，但是要做到对所有类型的输入输出组件都普遍适用，就不那么简单了。

阿里采取的这种前端在作业层面就将数据按范围分片成不同任务的方式，固然粗暴，倒也是实用的。虽然对一些特定的数据源未必可行，效率可能也未必最高，但是可以覆盖多数的场景，其它搞不定的场景定制化一下，也是一种合理的解决思路。

根据同步速度期望值，自动估算和调整同步需要的并发数

配置再完善，不管由于什么原因，用户配得不合理那也没用，提升资源利用率，应对数据量变化等等工作，如果能靠程序自动判断调整，当然是最好的了。阿里的具体估算方案其实不重要，用QOS的思想来解决问题才是关键。

数据时间漂移的处理：多获取一部分第二天的数据（比如跨日以后的15分钟），然后根据可以判断业务时间的字段，过滤，排序等方式来得到需要的数据

Late数据的处理，从来都是一件头痛的事，数据库其实还好了，毕竟数据都是自己生成的，同步延迟一般也都有监控手段，通常不是做得特别烂的话，延迟也还相对可控。就怕业务上没有用于更新时间判定的字段，存粹的依靠入库时间和读取时间来分日，这种业务流程，一旦发现，还是要尽量改造掉的。

此外，阿里的上述方法，涉及到排序，其实代价也是有点高的，如果没有标准的处理模块，自己写起逻辑来也是有些麻烦。很多情况下，如果数据稍微差一点关系不大的业务，我们都选择不做处理，所以我比较好奇，阿里内部有多少比例的链路使用了这种方式来处理数据同步过程中的时间漂移问题。

离线数据开发

离线数据开发，抛开底层各种存储计算组件，剩下的工作量大头，就是开发平台了。阿里内部的离线开发平台，对外几乎找不到任何资料，甚至有些组件的资料，内部了解的人也不多，有些之前想交流，都不知道找谁交流，到底是人多啊。。。至于阿里云上的数加，倒是有些资料，但很多产品形态还是有些简单粗糙的。毕竟和内部产品不同，要考虑数加面对的主流用户的需求和环境。

统一开发平台: 在云端D2, 回归测试平台：在彼岸

这两个就属于基本找到不到资料的。虽然，怎么做大家基本都是类似的想法，不过如果有更详细的资料，还是可以看看各家的完善程度的。

代码提交环节，先过SQLSCAN模块，进行规则校验：包括代码规范规则：入表命名规范，生命周期等等；代码质量规则，代码性能规则等。分强弱两类规则，强规则打断执行，弱规则只是提示

离线开发平台上，SQL代码校验的工作，我司的Xray平台也做了一部分工作，不过，做得还比较零散，还没有模块化，体系化的去搞。主要是针对性能和资源问题做了一些强规则校验，再辅助以Hive Strict模式的强制设定。后续还是需要更系统化的以框架和插件的形式，做好代码扫描的工作。

在彼岸: 一是提供一键测试流程，二是提供数据验证手段，包括两种类型类验证方式：数据对比（包括数据量和全文对比，字段统计值，枚举值，空值等。评估数据分布，提取各类统计值，和预期值对比等；还有个脱敏的功能，不知道为什么放在这个模块里，和测试数据的获取有关?

所谓一键测试流程，就是脚本测试的工作对业务方要尽可能透明，同时不影响线上业务。比如如果你需要业务方修改脚本替换读取的表和写出的表，来避免对线上业务的干扰，那显然是不透明的。你最好做到同一份脚本，用户点测试，就走测试流程，点发布就进入线上流程，实现脚本无差别运行。但是对于大数据平台来说，要克隆一份完整的线下集群和数据来供业务方测试，抛开技术不谈，从成本代价上来说显然也是不现实的。所以怎么才能做到呢？书里当然不会说，我司在这方面也有一些实践，以后再细谈吧。

测试流程，方便任务的运行固然重要，但提供验证结果的手段同样重要，能够做到自动化那就更好了。上述书中提到的验证手段就是很好的例子。虽然很多情况下，结果的判定标准并不能预先制定，所以没有办法覆盖到所有的场景。不过通过模版化的方式简化一些标准的测试用例的开发，还是很有必要的。

我司也有自动测试的辅助工具，不过还没有和开发脚本，上线发布等流程有机的整合在一起，近期需要考虑将这部分功能融合进完整的开发流程中，一方面提高开发效率，另一方面加强质量管控。

调度系统：分为调度引擎（phoenix Engine）和执行引擎（Alisa）两个子系统，调度引擎负责工作流规划，管理任务管理到任务就绪状态（只差安排资源）为止，执行引擎则负责后面的具体任务执行动作，管理包括执行，成功，失败重试等等状态变化

说实话，这两个调度系统都没有太听说过，之前和阿里内部各种做资源调度系统（比如伏羲），分片调度系统（比如SchedulerX）的同学也打听过，貌似也没有人知道相关信息。。。

从书上非常简单的介绍内容来看，这两个系统的整体结构貌似有点复杂。通常调度系统中，作业调度和作业执行两个环节的确是分开的，不过一般也就是master和worker的分工，整体系统还是一个系统。这种拆成两个系统的实现方式，不知道最初的出发点是什么，是否是因为有历史遗留系统的原因。如果说是为了复用执行引擎逻辑，并不一定要通过这种方式实现，有很多种方法。

整体来说，这种方式下，调度逻辑层次相当于又多了一层（因为Alisa也是集群，分主节点和工作节点），业务逻辑串联上应该会更加复杂一些，有些流程也需要通过异步机制来完成。不过，好处也有，调度系统的各类工作负担进一步拆分给不同的组件，有利于增大工作流这部分工作的吞吐率，降低调度引擎主节点的负载压力。这么做值不值得，还是要看系统的具体应用环境了。不过，以上都是个人猜测，没有看到这两个系统的实现细节，不好判断是否还有其它考量。

实时数据

多数公司的实时业务的处理流程，在业务模型规范化方面，相信是远没有离线数仓那么成熟的，多半处于具体业务各管各事的状态。而阿里在这方面，看起来还是做了不少努力的。

整体来说，业务模型同样采取了与离线类似的分层方式，数据主要存储在HBase等系统中，规范了表名和rowkey。需要复杂检索逻辑的放在DB里。

这个很自然的，大家都会想这么做，但是流式计算的特点，数据是连续生成的，流水作业式的进行处理的，所以，实际上，像ODS／DWD／DWS／ADS这种分层模型能否对应贯穿映射到整体实时计算的业务链路中去，其实还是值得怀疑的，起码，不能简单照搬。毕竟，这种分层模型还是以维度指标模型为基础的，在这种模型下，Join类型的操作无法避免，而在当前在实时计算流程中，不管各种流式计算框架如何宣称，Join逻辑实际执行起来还是有很大难度的。

不过，如果只是将最终的结果数据分层组织，后续的查询业务并不需要具备流式处理的能力，只是强调查询的时能得到最新的数据，那还是比较容易的。从书中没有看出阿里当前的模式，指代的是哪一种。不过从数据落在HBase中这一点来看，后者的可能性相当大。当然，也不排除利用HBase的Log机制再度将增量信息导出到消息队列中，下游继续通过流式模式进行处理的可能性。

ODS和DWD层尽量做到和离线链路的复用

这个不用说了，大家都希望实时链路和离线链路逻辑完全统一，不过目前真正做到这一点的公司，估计不多，我司？ 还没有做到，也是后续努力的方向吧。

实时计算过程中使用的维表，主要以T-2数据为准，少量用了T-1的数据

实际上，用T-2的数据纯属无奈，维表能否及时更新，取决于两点：数据量有多大，数据处理能有多快，调度系统的作业周期，依赖关系能否正确处理（比如是否支持小时级任务和日任务的相互依赖）

理想中，当然是维表能够实时更新，支持最新实时数据的计算任务。不过，这个能否做到，就需要具体案例具体讨论了。

数据服务

通过SmartDQ／OneService提供统一数据查询服务，SmartDQ建立逻辑表到物理表的映射关系，多张物理表通过同样的主键组合成逻辑表，底层数据源可以对接HBase／DB／搜索引擎等。数据发布方配置映射关系以及上层对外服务的SQL模版，SQL执行时拆分成不同的数据源子查询去执行

统一数据查询，又是一个理想中的服务模式，从技术层面到业务层面，都是有要求的，需要协同配合，即使阿里，也做了这么多版的迭代。说起来，目标，形态很简单，难度确是很大的，类比一下，好比DB的分库分表方案，大家都知道要做SQL改写，要实现跨库聚合能力。但实现起来，就不是一两句话那么轻松了。我司目前在这方面的工作做得还非常少，宽表类的应用也有，但是跨数据源类型的查询，聚合等能力还不具备。

通过分离不同响应速度的查询，缓存元数据，查询计划，查询结果等提升性能。提供Replace语法，用一个子查询结果（如果有）替换另一个子查询结果。（比如用来做离线数据对实时数据的优先替换）

这两点的设计蛮具体的，前者很标准，也很直观，出于系统性能考虑。后者，是为了降低业务方的使用成本，这个思路倒是挺有意思，值得琢磨一下。

总体来说，我们在统一数据查询服务这点上，差距还比较大，不过，目前倒也还不是最迫切需要改进的地方，先Mark一下。

维表／事实表

后半本书，仓库模型，维表，事实表设计这些，书里面的内容，多半都是标准的理论了，所以我摘录的内容不多。不过，还是有不少与具体业务实践相结合的点是值得借鉴的。

对于一些缓慢变化的维度表，历史信息又是有用的，需要能够获取到历史上每一天的快照信息，采用拉链表的形式来节省维表快照的存储量。通过Hook Hive语法解析模块，修改查询语法，实现业务方查询拉链表的透明化

拉链表是解决这类问题的标准理论模型之一了，但怎么把拉链表这种形式用好，如何简化使用的成本，看起来阿里的同学还是有不少的深入实践的。我司么，还停留在靠业务同学自行处理拉链表的阶段，为人民服务做得还不够彻底 ；） 不过，人少志短，后续看业务需求程度和优先级再考虑吧。

使用周期快照事实表和累积快照事实表来处理一些通过事务事实表需要长时间范围聚合才能得到的数据。 比如一个周期内的商品交易量（通过商品交易流水事务事实表聚合得到），买卖家星级，累计消费金额等等。

这部分也是标准的理论了，技术层面没有太多好说的，更多是依靠业务层面，模型建设相关同学的觉悟了，是不是凡是类似场景，都有去思考过能否用这种模式去优化业务流程。不过，话说回来，系统层面或许也能提供一些方式去监督和敦促相关业务的改造？Again，如何监督和敦促，有时间再看了。。。

计算和存储性能

HBO：基于任务运行的历史数据统计，自动调整任务运行参数，比如Map／Reduce数量等

基于历史信息进行优化，当然是对基于规则（RBO）／和基于代价（CBO） 两种优化模式的一种补充，也是专家系统的一种表现形式。

实际上，多数情况下，人肉的优化分析工作就是一种HBO的体现，但是人肉容易，要自动化的做就不容易了。个人觉得难点有两个：

• 一个是信息的收集，经验系统嘛，那当然首先要收集足够的经验数据，既要做到收集全面，又要具备识别有问题的数据能力。毕竟，如果通过系统来自动调整参数，输入信息的不准确带来的干扰相比人肉来说，还是要严重很多的。归根结底，HBO最后多半还是要通过规则来实现。你说人工智能？这代价暂时来看就有点高了 ；）

• 二是建立历史数据和现实状况的映射关系，也就是说当前的作业，如何根据历史信息进行调整。首先是相关的任务的运行参数能否动态调整？依靠人肉来做多半是可以的（否则，就不叫参数了是吧 ），如果要系统自动完成，就需要底层计算组件和开发平台相关工具链路的支持了。然后就是映射规则本身的积累，这个就需要靠经验沉淀了。

数据重分布：列式存储，为了提高压缩率，可以通过distribute by ，sort by之类的手段，将类似的数据聚合到一个区块，提高压缩率。

通过重新分布数据来提高压缩算法的压缩率，这个会去想到这么做，也是有点追求极致的意思了。不过，值不值得做，能不能带来足够的收益，必然还是和表格的具体内容相关的，比如，如果一张表有大量的字段，按照部分字段排序只能提高一小部分数据压缩率，对别的字段的压缩率或许还有反作用，那可能这么做就没有什么意义了。而业务逻辑上，是否适合这么做，可能也要考虑。不过，不管怎么说，针对字段少，重复概率高，有一定压缩潜力的大表，或许也是一种可以尝试的优化手段。

数据成本计费：除了定义存储成本和计算成本，还定义扫描成本（读取别人的表也有成本）

计费，对多数公司的内部平台来说，当然不是真的为了收费，说到底还是为了控制资源使用量，评估投入产出比。不过即使这个目标，也不见得是对每家公司都可行或着愿意做的，毕竟计费系统自身，也需要投入资源去开发。

而投入产出比，投入成本容易算，但是产出？没有量化的手段，就很难直接评估了，需要从最终的业务端一路量化下来才有可能做到，在业务关系错综复杂的环境中，这谈何容易。至于配额制什么的，更多的时候，在产出无法量化的情况下，也只是起到一个提示监督的作用。

所以，计费作为评估数据业务投入产出比的手段，大概只能起到一个参考的作用，不过，有总比没有好不是 ；）实际上，对我司来说，现阶段计费系统更重要的价值因该还不是评估投入产出比，而是起到监控业务流量，发现问题，及时沟通和敦促优化的作用，把它作为专家系统中收集信息的这部分基础设施来建设。

小结

话说，参与撰写这本书的那一大堆数据产品与技术部的同学，有没有哪位认识，可以介绍交流一下的 ；） 比如：王赛，王永伟，黄晓锋，王俊华等同学