第1章 总述
第2章 日志采集
第3章 数据同步
第4章 离线数据开发
第5章 实时技术
第6章 数据服务
第7章 数据挖掘

第1章 总述

2014年，马云提出，“人类正从IT时代走向DT时代”。如果说在IT时代是以自我控制、自我管理为主，那么到了DT(Data Technology) 时代，则是以服务大众、激发生产力为主。以互联网（或者物联网）、云计算、大数据和人工智能为代表的新技术革命正在渗透至各行各业，悄悄地改变着我们的生活。

数据作为一种新的能源，正在发生聚变，变革着我们的生产和生活 ，催生了当下大数据行业发展热火朝天的盛景。但是如果不能对这些数据进行有序、有结构地分类组织和存储，如果不能有效利用并发掘它，继而产生价值，那么它同时也成为一场“灾难”。无序、无结构的数据犹如堆积如山的垃圾，给企业带来的是令人咋舌的高额成本。

在阿里内部，数据工程师每天要面对百万级规模的离线数据处理作。阿里大数据井喷式的爆发，加大了数据模型、数据研发、数据质量和运维保障工作的难度。同时，日益丰富的业态，也带来了各种各样、纷繁复杂的数据需求。

如何有效地满足来自员工、商家、合作伙伴等多样化的需求 ，提高他们对数据使用的满意度，是数据服务和数据产品需要面对的挑战。如何建设高效的数据模型和体系，使数据易用，避免重复建设和数据不一致性，保证数据的规范性；如何提供高效易用的数据开发工如何做好数据质量保障；如何有效管理和控制日益增长的存储和计算消耗；如何保证数据服务的稳定，保证其性能；如何设计有效的数据产品高效赋能于外部客户和内部员工……这些都给大数据系统的建设提出了更多复杂的要求。

本书介绍的阿里巴巴大数据系统架构，就是为了满足不断变化的业务需求，同时实现系统的高度扩展性、灵活性以及数据展现的高性能而设计的。

阿里巴巴大数据系统体系架构，主要分为数据采集、数据计算、数据服务和数据应用四大层次。

图1.1 阿里巴巴大数据系统体系架构图

• 数据采集层

阿里巴巴是一家多业态的互联网公司，几亿规模的用户（如商家、消费者、商业组织等）在平台上从事商业、消费、娱乐等活动，每时每刻都在产生海量的数据，数据采集作为阿里大数据系统体系的第一环尤为重要。因此阿里巴巴建立了一套标准的数据采集体系方案，致力全面、高性能、规范地完成海量数据的采集，并将其传输到大数据平台。

阿里巴巴的日志采集体系方案包括两大体系： Aplus.JS Web日志采集技术方案； UserTrack APP端日志采集技术方案。在采集技术基础之上，阿里巴巴用面向各个场景的埋点规范，来满足通用浏览、点击、特殊交互、 APP 事件、H5 APP里的H5 Native日志数据打通等多种业务场景。同时，还建立了一套高性能、高可靠性的数据传输体系，完成数据从生产业务端到大数据系统的传输。在传输方面，采用TimeTunnel（TT），它既包括数据库的增量数据传输，也包括日志数据的传输； TT作为数据传输服务的基础架构，既支持实时流式计算，也支持各种时间窗口的批量计算。另外，也通过数据同步工具（DataX同步中心，其中同步中心是基于DataX易用性封装的）直连异构数据库（备库）来抽取各种时间窗口的数据。

• 数据计算层

数据只有被整合和计算，才能被用于洞察商业规律，挖掘潜在信息，从而实现大数据价值，达到赋能于商业和创造价值的目的。从采集系统中收集到的大量原始数据，将进入数据计算层中被进一步整合与计算。

面对海量的数据和复杂的计算，网里巴巴的数据计算层包括两大体系：数据存储及计算云平台（离线计算平台 MaxCompute和实时计算StreamCompute）和数据整合及管理体系（内部称之为“OneData”）。

阿里巴巴的大数据工程在这一体系下，构建统一、规范、可共享的全域数据体系 ，避免数据的冗余和重复建设，规避数据烟囱和不一致性，充分发挥间里巴巴在大数据海量、多样性方面的独特优势。借助这一统一化数据整合及管理的方法体系，我们构建了阿里巴巴的数据公共层，帮助相似大数据项目快速落地实现。

从数据计算频率角度来看，阿里数据仓库可以分为离线数据仓库和实时数据仓库。离线数据仓库主要是指传统的数据仓库概念，数据计算频率主要以天（包含小时、周和月）为单位；如T-1，则每天凌晨处理上一天的数据。但是随着业务的发展特别是交易过程的缩短，用户对数据产出的实时性要求逐渐提高，所以阿里的实时数据仓库应运而生。“双11”实时数据直播大屏，就是实时数据仓库的一种典型应用。

阿里数据仓库的数据加工链路也是遵循业界的分层理念，包括：
1、操作数据层（Operational Data Store, ODS）
2、明细数据层（Data Warehouse Detail, DWD）
3、汇总数据层（Data Warehouse Summary, DWS）
4、应用数据层（Application Data Store, ADS）
通过数据仓库不同层次之间的加工过程实现从数据资产向信息资产的转化，并且对整个过程进行有效的元数据管理及数据质量处理。

在阿里大数据系统中，元数据模型整合及应用是一个重要的组成部分，主要包含数据源元数据、数据仓库元数据 、数据链路元数据、工具类元数据 数据质量类元数据等。元数据应 主要面向数据发现、数据管理等 ，如用于存储、计算和成本管理等。

• 数据服务层

当数据已被整合和计算好之后，需要提供给产品和应用进行数据消费。为了有更好的性能和体验，阿里巴巴构建了自己的数据服务层，通过接口服务化方式对外提供数据服务。针对不同的需求，数据服务层的数据源架构在多种数据库之上，如MySQL和HBase等。后续将逐渐迁移至阿里云云数据库ApsaraDB for RDS（简称“RDS”）和表格存储（Table Store）等。

数据服务可以使应用对底层数据存储透明，将海量数据方便高效地开放给集团内部各应用使用。现在，数据服务每天拥有几十亿的数据调用量，如何在性能、稳定性、扩展性等方面更好地服务于用户：如何满足应用各种复杂的数据服务需求：如何保证“双11”媒体大屏数据服务接口的高可用……随着业务的发展，需求越来越复杂，因此数据服务也在不断地前进。

数据服务层对外提供数据服务主要是通过统一的数据服务平台（方便阅读，简称为“OneService”）。 OneService以数据仓库整合计算好的数据作为数据源，对外通过接口的方式提供数据服务，主要提供简单数据查询服务、复杂数据查询服务（承接集团用户识别、用户画像等复杂数据查询服务）和实时数据推送服务三大特色数据服务。

• 数据应用层

数据已经准备好，需要通过合适的应用提供给用户，让数据最大化地发挥价值。阿里对数据的应用表现在各个方面，如搜索、推荐、广告、金融、信用、保险、文娱、物流等。商家，阿里内部的搜索、推荐、广告、金融等平台，阿里内部的运营和管理人员等，都是数据应用方；ISV、研究机构和社会组织等也可以利用阿里开放的数据能力和技术。

阿里巴巴基于数据的应用产品有很多，本书选择了服务于阿里内部员工的阿里数据平台和服务于商家的对外数据产品一一生意参谋进行基础性介绍。其他数据应用不再赘述。对内，阿里数据平台产品主要有实时数据监控、自助式的数据网站或产品构建的数据小站、宏观决策分析支撑平台、对象分析工具、行业数据分析门户、流量分析平台等。

第1篇 数据技术篇

第2章 日志采集

2.1 浏览器的页面日志采集

2.1.1 页面浏览日志采集

此类日志是最基础的互联网日志，也是目前所有互联网产品的两大基本指标：页面浏览量（PageView, PV）和访客数（UniqueVisitors, UV）的统计基础。页面浏览日志是目前成熟度和完备度最高，同时也是最具挑战性的日志来集任务。

网页浏览过程：

• 用户在浏览器内点击淘宝首页链接
• 浏览器向淘宝服务器发起HTTP请求
• 服务器接收并解析请求
• 浏览器接收到服务器的响应内容，并将其按照文档规范展现给用户，完成一次请求

如果需要记录这次浏览行为，则采集日志的动作必然是附加在上述四个步骤中的某一环节内完成的。在第一步和第二步，用户的请求尚未抵达服务器；而直到第三步完成，我们也只能认为服务器处理了请求，不能保证浏览器能够正确地解析和渲染页面，尚不能确保用户已确实打开页面，因此在前三步是无法采集用户的浏览日志的。那么采集日志的动作，需要在第四步，也就是浏览器开始解析文档时才能进行。

根据前文所述，可以很自然地得出在这一模式下最直接的日志采集思路：在HTML文档内的适当位置增加一个日志采集节点，当浏览器解析到这个节点时，将自动触发一个特定的HTTP请求到日志采集服务器。如此一来，当日志采集服务器接收到这个请求时，就可以确定浏览器已经成功地接收和打开了页面。

2.1.2 页面交互日志采集

当页面加载和渲染完成之后，用户可以在页面上执行各类操作。

PY日志的采集解决了页面流量和流量来源统计的问题，但随着互联网业务的发展，仅了解用户到访过的页面和访问路径，已经远远不能满足用户细分研究的需求。在很多场合下，需要了解用户在访问某个页面时具体的互动行为特征，比如鼠标或输入焦点的移动变化（代表用户关注内容的变化）、对某些页面交互的反应（可借此判断用户是否对某些页面元素发生认知困难）等。因为这些行为往往并不触发浏览器加载新页面，所以无法通过常规的PV日志采集方法来收集。

业务方将交互日志采集代码植入目标页面，并将采集代码与需要监测的交互行为做绑定。当用户在页面上产生指定行为时，采集代码和正常的业务互动响应代码一起被触发和执行。随后可被业务方按需自行解析处理，并可与正常的PV日志做关联运算。

2.1.3 页面日志的服务器端清洗和预处理

在大部分场合下，经过上述解析处理之后的日志并不直接提供给下游使用。基于如下几个原因，在对时效要求较宽松的应用场合下，一般还需要进行相应的离线预处理。

• 识别流量攻击、网络爬虫和流量作弊（虚假流量）
  页面日志是互联网分析和大数据应用的基础源数据，在实际应用中，往往存在占一定比例的虚假或者恶意流量日志，导致日志相关指标的统计发生偏差或明显谬误。为此，需要对所采集的日志进行合法性校验，依托算法识别非正常的流量并归纳出对应的过滤规则集加以滤除。

• 数据缺项补正
  为了便利后续的日志应用和保证基本的数据统计口径一致，在大多数情况下，需要对日志中的一些公用且重要的数据项做取值归一、标准化处理或反向补正。反向补正，即根据新日志对稍早收集的日志中的个别数据项做回补或修订（例如，在用户登录后，对登录前页面日志做身份信息的回补）。

• 无效数据剔除
  在某些情况下，因业务变更或配置不当，在采集到的日志中会存在一些无意义、已经失效或者冗余的数据项。这些数据项不仅消耗存储空间和运算能力，而且在偶然的情况下还可能干扰正常计算的进行，需要对此类数据进行剔除。

• 日志隔离分发
  基于数据安全或者业务特性的考虑，某些日志在进入公共数据环境之前需要做隔离。

原始日志经过上述的清洗、修正，并结构化变形处理之后，Web页面日志的采集流程就算完成了。此时的日志已经具备了结构化或者半结构化的特征，可以方便地被关系型数据库装载和使用。

2.2 无线客户端的日志采集

无线客户端的日志采集通过采集SOK来完成。

2.2.1 页面事件

2.2.2 控件点击及其他事件

2.2.3 特殊场景

2.2.4 H5 & Native日志统一

2.2.5 设备标识

关于UV，对于登录用户，可以使用用户ID来进行唯一标识，但是很多日志行为并不要求用户登录，这就导致在很多情况下采集上来的日志都没有用户ID。PC端一般使用Cookie信息来作为设备的唯一信息，对于APP来说，我们就要想办法获取到能够唯一标识设备的信息。

对于只有单APP的公司来说，设备唯一标识不是需要攻克的难题，但对于像阿里巴巴这样拥有众多APP的公司来说，设备唯一标识就显得尤为重要。

2.2.6 日志传输

无线客户端日志的上传，不是产生一条日志上传一条，而是无线客户端产生日志后，先存储在客户端本地，然后再伺机上传。所谓伺机，就需要有数据分析的支持，如在启动后、使用过程中、切换到后台时这些场景下分别多久触发一次上传动作。当然单纯地靠间隔时间来决定上传动作是不够的，还需要考虑日志的大小及合理性（如单条日志超大，很可能就是错误日志）。另外，还需要考虑上传时网络的耗时，来决定是否要调整上传机制。

后续的应用可以是实时的应用来订阅TT收集到的消息，进行实时计算，也可以是离线的应用定时来获取消息，完成离线的计算。

2.3 日志采集的挑战

对于目前的互联网行业而言，互联网日志早已跨越初级的饥饿阶段（大型互联网企业的日均日志收集量均以亿为单位计量），反而面临海量日志的淹没风险。各类采集方案提供者所面临的主要挑战已不是日志采集技术本身，而是如何实现日志数据的结构化和规范化组织，实现更为高效的下游统计计算，提供符合业务特性的数据展现，以及为算法提供更便捷、灵活的支持等方面。

2.3.1 典型场景

• 日志分流与定制处理
  大型互联网网站的日志类型和日志规模都呈现出高速增长的态势，而且往往会出现短时间的流量热点爆发。这一特点，使得在日志服务器端采用集中统一的解析处理方案变得不可能，其要求在日志解析和处理过程中必须考虑业务分流（相互之间不应存在明显的影响，爆发热点不应干扰定常业务日志的处理）、日志优先级控制，以及根据业务特点实现定制处理。例如，对于电商网站而言，数据分析人员对位于点击流前端的促销页面和位于后端的商品页面的关注点是不一样的，而这两类页面的流量又往往同等重要且庞大，如果采用统一的解析处理方案，则往往需要在资源浪费（尽可能多地进行预处理）和需求覆盖不全（仅对最重要的内容进行预处理）两个选择之间进行取舍。这种取舍的结果一般不是最优的。

• 采集与计算一体化设计
  以PV日志为例，页面PY日志采集之后一个基础性操作是日志的归类与汇总。在早期的互联网日志分析实践中，是以URL路径，继而以URL（正则）规则集为依托来进行日志分类的。在网站规模较小时，这一策略还可以基本顺利地运转下去，但随着网站的大型化和开发人员的增加，URL规则集的维护和使用成本会很快增长到不现实的程度，同时失控的大规模正则适配甚至会将日志计算硬件集群彻底榨干。这一状况要求日志采集方案必须将来集与计算作为一个系统来考量，进行一体化设计。

在当前的互联网环境下，互联网日志的规模化采集方案必须具备一个与终端设备的技术特点无关，具有高度扩展弹性和适应性，同时深入契合应用需求的业务逻辑模型，并基于此制定对应的采集规范交由产品开发人员执行。若非如此，则不足以保障采集->解析->处理->应用整个流程的通畅。目前阿里已成功实现规范制定->元数据注册->日志采集->自动化计算->可视化展现全流程的贯通。通过一体化设计，用户甚至可以在不理解规范的前提下，通过操作向导式界面，实现日志来集规范的自动落地和统计应用。日志本身不是日志采集的目的，服务于基于日志的后续应用，才是日志采集正确的着眼点。

2.3.2 大促保障

日志数据在阿里系乃至整个电商系应该都是体量最大的一类数据，在“双ll”期间，日志必然会暴涨，近万亿的数据量对日志全链路来说，无疑是不小的挑战。从端上埋点采集，到日志服务器收集，经过数据传输，再到日志实时解析、实时分析，任何一个环节出现问题，全链路保障就是失败的。

图2.4 数据处理全链路

• 端上实现了服务器端推送配置到客户端，且做到高到达率
• 对日志做了分流，结合日志的重要程度及各类日志的大小，实现了日志服务器端的拆分
• 在实时处理方面，也做了不少的优化以提高应用的吞吐量
• 结合实时处理能力，评估峰值数据量，在高峰期通过服务器端推送配置的方式对非重要日志进行适当限流，错峰后逐步恢复

整个日志处理流程还是比较长的，对于对实时性要求极高的业务场景，如上链路显然不能满足需求。

• 从业务上进行改造，采用端上记录
• 在链路各环节做优化，如从采集服务器直接完成解码并调用业务API完成业务的计算（省去中间的传输和过多的处理）

在保证稳定的同时扩展功能，在稳定及业务深度之间做到很好的平衡。

在如上策略下，2016年的“双11”，日志采集浏览等核心用户行为日志均实现了100%全量及实时服务，支持天猫所有会场的实时推荐。在“双11”中，用户的浏览、点击、滚屏等每个操作行为，都实时影响到后续为其推荐的商品，很好地提高了用户体验。

第3章 数据同步

同类型不同集群数据库之间的数据同步：

• 主数据库与备份数据库之间的数据备份
• 主系统与子系统之间的数据更新

不同地域、不同数据库类型之间的数据传输交换：

• 分布式业务系统与数据仓库系统之间的数据同步

大数据系统：

• 数据从业务系统同步进入数据仓库
• 数据从数据仓库同步进入数据服务或数据应用

3.1 数据同步基础

源业务系统的数据类型多种多样：

• 来源于关系型数据库的结构化数据，如MySQL、Oracle、DB2,SQL Server等
• 来源于非关系型数据库的非结构化数据，如OceanBase、HBase、Mongo DB等
  （通常存储在数据库表中）
• 来源于文件系统的结构化或非结构化数据，如阿里云对象存储oss、文件存储NAS等
  （通常以文件形式进行存储）

数据同步需要针对不同的数据类型及业务场景选择不同的同步方式。总的来说，同步方式可以分为三种：

• 直连同步
• 数据文件同步
• 数据库日志解析同步

3.1.1 直连同步

直连同步是指通过定义好的规范接口API和基于动态链接库的方式直接连接业务库，如ODBC/JD BC等规定了统一规范的标准接口，不同的数据库基于这套标准接口提供规范的驱动，支持完全相同的函数调用和SQL实现。

这种方式配置简单，实现容易，比较适合操作型业务系统的数据同步。但是业务库直连的方式对源系统的性能影响较大，当执行大批量数据同步时会降低甚至拖垮业务系统的性能。如果业务库采取主备策略，则可以从备库抽取数据，避免对业务系统产生性能影响。但是当数据量较大时，采取此种抽取方式性能较差，不太适合从业务系统到数据仓库系统的同步。

图3.1 直连同步示意图.png

3.1.2 数据文件同步

数据文件同步通过约定好的文件编码、大小、格式等，直接从源系统生成数据的文本文件，由专门的文件服务器，如FTP服务器传输到目标系统后，加载到目标数据库系统中。当数据源包含多个异构的数据库系统（如MySQL、Oracle、SQLServer、DB2等）时，用这种方式比较简单、实用。另外，互联网的日志类数据，通常是以文本文件形式存在的，也适合使用数据文件同步方式。

由于通过文件服务器上传、下载可能会造成丢包或错误，为了确保数据文件同步的完整性，通常除了上传数据文件本身以外，还会上传一个校验文件，该校验文件记录了数据文件的数据量以及文件大小等校验信息，以供下游目标系统验证数据同步的准确性。另外，在从源系统生成数据文件的过程中，可以增加压缩和加密功能，传输到目标系统以后，再对数据进行解压缩和解密，这样可以大大提高文件的传输效率和安全性。

图3.2 数据文件同步示意图.png

3.1.3 数据库日志解析同步

目前，大多数主流数据库都已经实现了使用日志文件进行系统恢复，因为日志文件信息足够丰富，而且数据格式也很稳定，完全可以通过解析日志文件获取发生变更的数据，从而满足增量数据同步的需求。

以Oracle为例，可以通过源系统的进程，读取归档日志文件用以收集变化的数据信息，并判断日志中的变更是否属于被收集对象，将其解析到目标数据文件中。这种读操作是在操作系统层面完成的，不需要通过数据库，因此不会给源系统带来性能影响。

然后可通过网络协议，实现源系统和目标系统之间的数据文件传输。相关进程可以确保数据文件的正确接收和网络数据包的正确顺序，并提供网络传输冗余，以确保数据文件的完整性。数据文件被传输到目标系统后，可通过数据加载模块完成数据的导人，从而实现数据从源系统到目标系统的同步。

数据库日志解析同步方式实现了实时与准实时同步的能力，延迟可以控制在毫秒级别，并且对业务系统的性能影响也比较小，目前广泛应用于从业务系统到数据仓库系统的增量数据同步应用之中。

通过数据库日志解析进行同步的方式性能好、效率高，对业务系统的影响较小。但是它也存在如下一些问题：

• 数据延迟
  例如，业务系统做批量补录可能会使数据更新量超出系统处理峰值，导致数据延迟

• 投入较大
  采用数据库日志抽取的方式投入较大，需要在源数据库与目标数据库之间部署一个系统实时抽取数据

• 数据漂移和遗漏
  数据漂移，一般是对增量表而言的，通常是指该表的同一个业务日期数据中包含前一天或后一天凌晨附近的数据或者丢失当天的变更数据

图3.3 数据库日志解析同步示意图.png

由于数据库日志抽取一般是获取所有的数据记录的变更（增、删、改），落地到目标表时我们需要根据主键去重按照日志时间倒排序获取最后状态的变化情况。对于删除数据这种变更情况，针对不同的业务场景可以采用一些不同的落地手法。

下图是某源业务系统中某表变更日志流水表。其含义是：存在5条变更日志，其中主键为1的记录有3条变更日志，主键为2的记录有2条变更日志。

表3.1 某源表变更日志流水表.png

假设根据主键去重，按照流水倒序获取记录最后状态生成的表为delta表。

针对删除数据这种变更，主要有三种方式:

• 不过滤删除流水：不管是否是删除操作，都获取同一主键最后变更的那条流水（剩余流水号4、5两条记录）

• 过滤最后一条删除流水：如果同一主键最后变更的那条流水是删除操作，就获取倒数第二条流水（剩余流水号2、5两条记录）

• 过滤删除流水和之前的流水：如果在同一主键变更的过程中有删除操作，则根据操作时间将该删除操作对应的流水和之前的流水都过滤掉（剩余流水号5一条记录）

对于采用哪种方式处理删除数据，要看前端是如何删除无效数据的：

• 正常业务数据删除

• 手工批量删除：通常针对类似的场景，业务系统只做逻辑删除，不做物理删除，OBA定期将部分历史数据直接删除或者备份到备份库

一般情况下，可以采用不过滤的方式来处理，下游通过是否删除记录的标识来判断记录是否有效。如果明确业务数据不存在业务上的删除，但是存在批量手工删除或备份数据删除，例如淘宝商品、会员等，则可以采用只过滤最后一条删除流水的方式，通过状态字段来标识删除记录是否有效。

3.2 阿里数据仓库的同步方式

• 数据来源的多样性：来源于多个关系型数据库，数据高度结构化，易于被计算机系统处理

• 数据量巨大

需要针对不同的数据源类型和数据应用的时效性要求而采取不同的策略。

3.2.1 批量数据同步

对于离线类型的数据仓库应用，需要将不同的数据源批量同步到数据仓库，以及将经过数据仓库处理的结果数据定时同步到业务系统。

当前市场上的数据库系统种类很多，有行存储的和列存储的，有开源的和非开源的，每一种数据库的数据类型都略有不同，而数据仓库系统则是集成各类数据源的地方，所以数据类型是统一的。要实现各类数据库系统与数据仓库系统之间的批量双向数据同步，就需要先将数据转换为中间状态，统一数据格式。由于这类数据都是结构化的，且均支持标准的SQL语言查询，所以所有的数据类型都可以转换为字符串类型。因此，我们可以通过将各类源数据库系统的数据类型统一转换为字符串类型的方式，实现数据格式的统一。

阿里巴巴的DataX就是这样一个能满足多方向高自由度的异构数据交换服务产品。对于不同的数据源，DataX通过插件的形式提供支持，将数据从数据源读出并转换为中间状态，同时维护好数据的传输、缓存等工作。数据在DataX中以中间状态存在，并在目标数据系统中将中间状态的数据转换为对应的数据格式后写入。

3.2.2 实时数据同步

对于日志类数据来说，需要尽快以数据流的方式不间断地同步到数据仓库。另外，还有一些数据应用，需要对业务系统产生的数据进行实时处理，比如天猫“双11”的数据大屏，对所产生的交易数据需要实时汇总，实现秒级的数据刷新。这类数据是通过解析MySQL的binlog日志（相当于Oracle的归档日志）来实时获得增量的数据更新，并通过消息订阅模式来实现数据的实时同步的。具体来说，就是建立一个日志数据交换中心，通过专门的模块从每台服务器源源不断地读取日志数据，或者解析业务数据库系统的binlog或归档日志，将增量数据以数据流的方式不断同步到日志交换中心，然后通知所有订阅了这些数据的数据仓库系统来获取。

阿里巴巴的TimeTunnel（TT）系统就是这样的实时数据传输平台，具有高性能、实时性、顺序性、高可靠性、高可用性、可扩展性等特点。

3.3 数据同步遇到的问题与解决方案

3.3.1 分库分表的处理

随着业务的不断增长，业务系统处理的数据量也在飞速增加，需要系统具备灵活的扩展能力和高并发大数据量的处理能力，目前一些主流数据库系统都提供了分布式分库分表方案来解决这个问题。但是对于数据同步来说，这种分库分表的设计无疑加大了同步处理的复杂度。试想一下，如果有一个中间表，具备将分布在不同数据库中的不同表集成为一个表的能力，就能让下游应用像访问单库单表一样方便。

阿里巴巴的TDDL（Taobao Distributed Data Layer）就是这样一个分布式数据库的访问引擎，通过建立中间状态的逻辑表来整合统一分库分表的访问。

图3.7 分库分表处理.png

3.3.2 高效同步和批量同步

数据同步的方法通常是先创建目标表，再通过同步工具的填写数据库连接、表、字段等各种配置信息后测试完成数据同步。这也是DataX任务的配置过程，同步中心对DataX进行进一步封装，通过源系统元数据降低了数据库连接、表和字段等信息的配置复杂度，但在实际生产过程中我们仍然会遇到一些问题。

• 随着业务的发展和变化，会新增大批量的数据同步，相似并且重复的操作会降低开发人员的工作热情

• 数据仓库的数据源种类特别丰富，遇到不同类型的数据源同步就要求开发人员去了解其特殊配置

• 部分真正的数据需求方，如Java开发和业务运营，由于存在相关数据同步的专业技能门槛，往往需要将需求提交给数据开发方来完成，额外增加了沟通和流程成本

为了解决上述问题，网里巴巴数据仓库研发了OneClick产品：

• 对不同数据源的数据同步配置透明化，可以通过库名和表名唯一定位，通过IDB接口获取元数据信息自动生成配置信息

• 简化了数据同步的操作步骤，实现了与数据同步相关的建表、配置任务、发布、测试操作一键化处理，并且封装成Web接口进一步达到批量化的效果

• 降低了数据同步的技能门槛，让数据需求方更加方便地获取和使用数据

3.3.3 增量与全量同步的合并（重点！）

在批量数据同步中，有些表的数据量随着业务的发展越来越大，如果按周期全量同步的方式会影响处理效率。在这种情况下，可以选择每次只同步新变更的增量数据，然后与上一个同步周期获得的全量数据进行合井，从而获得最新版本的全量数据。

• 在传统的数据整合方案中，合并技术大多采用merge方式（update+insert）

• 当前流行的大数据平台基本都不支持update操作

现在我们比较推荐的方式是全外连接（full outer join）＋数据全量覆盖重新加载（insert overwrite），即如日调度，则将当天的增量数据和前一天的全量数据做全外连接，重新加载最新的全量数据。

在大数据量规模下，全量更新的性能比update要高得多。

此外，如果担心数据更新错误问题，可以采用分区方式，每天保持一个最新的全量版本，保留较短的时间周期（如3～7天）。另外，当业务系统的表有物理删除数据的操作，而数据仓库需要保留所有历史数据时，也可以选择这种方式，在数据仓库中永久保留最新的全量数据快照。

下面我们以淘宝订单表的具体实例来说明。淘宝交易订单表，每天新增、变更的增量数据多达几亿条，历史累计至今的全量数据则有几百亿条，面对如此庞大的数据量，如果每天从业务系统全量同步显然是不可能的。可行的方式是同步当天的增量数据，并与数据仓库中的前一天全量数据合并，获得截至当天的最新全量数据。

图3.9 淘宝交易订单同步示意图.png

3.3.4 同步性能的处理

数据同步任务是针对不同数据库系统之间的数据同步问题而创建的一系列周期调度的任务。在大型的数据调度工作台上，每天会运行大量的数据同步任务。针对数据同步任务，一般首先需要设定首轮同步的线程数，然后运行同步任务。

基于负载均衡思想的新型数据同步方案：核心思想是通过目标数据库的元数据估算同步任务的总线程数，以及通过系统预先定义的期望同步速度估算首轮同步的线程数，同时通过数据同步任务的业务优先级决定同步线程的优先级，最终提升同步任务的执行效率和稳定性。

3.3.5 数据漂移的处理（重点！）

通常我们把从源系统同步进人数据仓库的第一层数据称为ODS或者staging层数据。数据漂移是ODS数据的一个顽疾，通常是指ODS表的同一个业务日期数据中包含前一天或后一天凌晨附近的数据或者丢失当天的变更数据。

由于ODS需要承接面向历史的细节数据查询需求，这就需要物理落地到数据仓库的ODS表按时间段来切分进行分区存储，通常的做法是按某些时间戳字段来切分，而实际上往往由于时间戳字段的准确性问题导致发生数据漂移。

通常，时间戳字段分为以下四类，根据其中的某一个字段来切分ODS表，这就导致产生数据漂移：

• 数据库表中用来标识数据记录更新时间的时间戳字段（modified_time）
  在实际生产中这种情况最常见，但是往往会发生不更新modifiedtime而导致的数据遗漏，或者凌晨时间产生的数据记录漂移到后一天。

• 数据库日志中用来标识数据记录更新时间的时间戳字段（log_time）
  由于网络或者系统压力问题，log_time会晚于proc_time，从而导致凌晨时间产生的数据记录漂移到后一天。例如，在淘宝“双11”大促期间凌晨时间产生的数据量非常大，用户支付需要调用多个接口，从而导致log_time晚于实际的支付时间。

• 数据库表中用来记录具体业务过程发生时间的时间戳字段（proc_time）
  仅仅根据proc_time限制，我们所获取的ODS表只是包含一个业务过程所产生的记录，会遗漏很多其他过程的变化记录，这违背了ODS和业务系统保持一致的设计原则。

• 标识数据记录被抽取到时间的时间戳字段（extract_time）
  这种情况数据漂移的问题最明显。

理论上，这几个时间应该是一致的，但是在实际生产中，这几个时间往往会出现差异，可能的原因有以下几点：

• 由于数据抽取是需要时间的，extract_time往往会晚于前三个时间

• 前台业务系统手工订正数据时未更新modified_time

• 由于网络或者系统压力问题，log_time或者modified_time会晚于proc_time

处理方法主要有以下两种：

• 多获取后一天的数据

既然很难解决数据漂移的问题，那么就在ODS每个时间分区中向前、向后多冗余一些数据，保障数据只会多不会少，而具体的数据切分让下游根据自身不同的业务场景用不同的业务时间proc_time来限制。但是这种方式会有一些数据误差，例如一个订单是当天支付的，但是第二天凌晨申请退款关闭了该订单，那么这条记录的订单状态会被更新，下游在统计支付订单状态时会出现错误。

• 通过多个时间戳字段限制时间来获取相对准确的数据

（1）根据log_time分别冗余前一天最后15分钟的数据和后一天凌晨开始15分钟的数据，并用modifiedtime过滤非当天数据，确保数据不会因为系统问题而遗漏。
（2）然后根据log_time获取后一天15分钟的数据；针对此数据，按照主键根据log_time做升序排列去重。因为我们需要获取的是最接近当天记录变化的数据（数据库日志将保留所有变化的数据，但是落地到ODS表的是根据主键去重获取最后状态变化的数据）。
（3）最后将前两步的结果数据做全外连接，通过限制业务时间proc_time来获取我们所需要的数据。

下面来看处理淘宝交易订单的数据漂移的实际案例。我们在处理“双11”交易订单时发现，有一大批在11月11日23:59:59左右支付的交易订单漂移到了12日。主要原因是用户下单支付后系统需要调用支付宝的接口而有所延迟，从而导致这些订单最终生成的时间跨天了。即modified_time和log_time都晚于proc_time。

如果订单只有一个支付业务过程，则可以用支付时间来限制就能获取到正确的数据。但是往往实际订单有多个业务过程：下单、支付、成功，每个业务过程都有相应的时间戳字段，并不只有支付数据会漂移。

如果直接通过多获取后一天的数据，然后限制这些时间，则可以获取到相关数据，但是后一天的数据可能已经更新多次，我们直接获取到的那条记录已经是更新多次后的状态，数据的准确性存在一定的问题。

因此，我们可以根据实际情况获取后一天15分钟的数据，并限制多个业务过程的时间戳字段（下单、支付、成功）都是“双11”当天的，然后对这些数据按照订单的modified_time做升序排列，获取每个订单首次数据变更的那条记录。

此外，我们可以根据log_time分别冗余前一天最后15分钟的数据和后一天凌晨开始15分钟的数据，并用modified_time过滤非当天数据，针对每个订单按照log_time进行降序排列，取每个订单当天最后一次数据变更的那条记录。

最后将两份数据根据订单做全外连接，将漂移数据回补到当天数据中。

第4章 离线数据开发

从采集系统中收集了大量的原始数据后，数据只有被整合和计算，才能被用于洞察商业规律，挖掘潜在信息，从而实现大数据价值，达到赋能于商业和创造价值的目的。

面对海量的数据和复杂的计算，阿里巴巴的数据计算层包括两大体系：数据存储及计算平台（离线计算平台MaxCompute和实时计算平台StreamCompute）、数据整合及管理体系（OneData）。

4.1 数据开发平台

阿里数据研发岗位的工作大致可以概括为：了解需求->模型设计->ETL开发->测试->发布上线->日常运维->任务下线。

与传统的数据仓库开发（ETL）相比，阿里数据研发有如下几个特点：

• 业务变更频繁：业务发展非常快，业务需求多且变更频繁

• 需要快速交付：业务驱动，需要快速给出结果

• 频繁发布上线：迭代周期以天为单位，每天需要发布数次

• 运维任务多：在集团公共层平均每个开发人员负责500多个任务

• 系统环境复杂：阿里平台系统多为自研，且为了保证业务的发展，平台系统的迭代速度较快，平台的稳定性压力较大

通过统一的计算平台（MaxCompute）、统一的开发平台（D2等相关平台和工具）、统一的数据模型规范和统一的数据研发规范，可以在一定程度上解决数据研发的痛点。

4.1.1 统一计算平台

阿里离线数据仓库的存储和计算都是在阿里云大数据计算服务MaxCompute上完成的。

大数据计算服务MaxCompute是由阿里云自主研发的海量数据处理平台，主要服务于海量数据的存储和计算，提供完善的数据导入方案，以及多种经典的分布式计算模型，提供海量数据仓库的解决方案，能够更快速地解决用户的海量数据计算问题，有效降低企业成本，并保障数据安全。

MaxCompute采用抽象的作业处理框架，将不同场景的各种计算任务统一在同一个平台之上，共享安全、存储、数据管理和资源调度，为来自不同用户需求的各种数据处理任务提供统一的编程接口和界面。它提供数据上传/下载通道、SQL、MapReduce、机器学习算法、图编程模型和流式计算模型多种计算分析服务，并且提供完善的安全解决方案。

图4.1 MaxCompute体系架构图.png

4.1.2 统一开发平台

图4.2 开发工作流图.png

4.2 任务调度系统

现代信息化条件下的战争，从太空的卫星到空中的各类作战飞机，从地面的导弹到坦克火炮，从水面的大小舰艇到水下的潜艇，还有诸如网络、电磁环境等多种方式、多种维度的作战空间，各种武器装备、人员、作战环境纷繁复杂，如何能够准确、合理地调配这些资源，组织有序、高效的攻防体系赢得胜利，最关键的是需要有一个强大的指挥系统。

在云计算大数据时代，调度系统无疑是整个大数据体系的指挥中枢。

调度系统中的各类任务互相依赖，形成一个典型的有向无环图。

在传统的数据仓库系统中，很多是依靠Crontab定时任务功能进行任务调度处理的。这种方式有很多弊端:

• 各任务之间的依赖基于执行时间实现，容易造成前面的任务未结束或失败而后面的任务已经运行
• 任务难以并发执行，增加了整体的处理时间
• 无法设置任务优先级
• 任务的管理维护很不方便，无法进行执行效果分析等

任务状态机模型是针对数据任务节点在整个运行生命周期的状态定义，总共有6种状态，状态之间的转换逻辑如下图所示。

图4.9 任务状态机模型关系图.png

工作流状态机模型是针对数据任务节点在调度树中生成的工作流运行的不同状态定义，共有5种状态，其关系如下图所示。

图4.10 工作流状态机模型关系图.png

调度引擎（PhoenixEngine）基于以上两个状态机模型原理，以事件驱动的方式运行，为数据任务节点生成实例，并在调度树中生成具体执行的工作流。任务节点实例在工作流状态机、任务状态机和事件处理器之间转换，其中调度引擎只涉及任务状态机的未运行和等待运行两种状态，其他5种状态存在于执行引擎中。

4.2.3 特点及应用

• 调度配置：输入输出配置和自动识别相结合
• 定时调度：共有5种时间类型：分钟、小时、日、周、月，具体可精确到秒
• 周期调度：可按照小时、日等时间周期运行任务，与定时调度的区别是无须指定具体的开始运行时间
• 手动运行
• 补数据：在完成数据开发的发布以后，有些表需要进行数据初始化
• 基线管理：按优先级分类管理任务
• 监控报警：设置电话、短信、邮件等不同的告警方式，实现了日常数据运维的自动化

第5章 实时技术

在大数据系统中，离线批处理技术可以满足非常多的数据使用场景需求，但在DT时代，每天面对的信息是瞬息万变的，越来越多的应用场景对数据的时效性提出了更高的要求。数据价值是具有时效性的，在一条数据产生的时候，如果不能及时处理并在业务系统中使用，就不能让数据保持最高的“新鲜度”和价值最大化。（如“双11”实时成交量统计）

5.1 简介

业务诉求是希望能在第一时间拿到经过加工后的数据，以便实时监控当前业务状态并做出运营决策，引导业务往好的方向发展。比如网站上一个访问量很高的广告位，需要实时监控广告位的引流效果，如果转化率非常低的话，运营人员就需要及时更换为其他广告，以避免流量资源的浪费。在这个例子中，就需要实时统计广告位的曝光和点击等指标作为运营决策的参考。

按照数据的延迟情况，数据时效性一般分为三种：

• 离线：在今天（T）处理N天前（T-N,N>=1）的数据，延迟时间粒度为天
• 准实时：在当前小时（H）处理N小时前（H-N,N>0,如0.5小时、1小时等）的数据，延迟时间粒度为小时
• 实时：在当前时刻处理当前的数据，延迟时间粒度为秒

离线和准实时都可以在批处理系统中实现（比如Hadoop、Max Compute、Spark等系统），只是调度周期不一样而己，而实时数据则需要在流式处理系统中完成。

简单来说，流式数据处理技术是指业务系统每产生一条数据，就会立刻被采集并实时发送到流式任务中进行处理，不需要定时调度任务来处理数据。

流式数据处理一般具有以下特征：

• 时效性高：数据实时采集、实时处理，延时粒度在秒级甚至毫秒级
• 常驻任务：一旦启动后就会一直运行，直到人为地终止
• 性能要求高：如果处理吞吐量跟不上采集吞吐量，计算出来的数据就失去了实时的特性
• 应用局限性：实时数据处理不能替代离线处理

另外，由于数据源是流式的，在数据具有上下文关系的情况下，数据到达时间的不确定性导致实时处理跟离线处理得出来的结果会有一定的差异。

5.2 流式技术架构

在流式计算技术中，需要各个子系统之间相互依赖形成一条数据处理链路，才能产出结果最终对外提供实时数据服务。各个子系统按功能划分的话，主要分为以下几部分：数据采集、数据处理、数据存储和数据服务。

图5.2 流式技术架构图.png

在数据采集和数据服务部分实时和离线是公用的，因为在这两层中都不需要关心数据的时效性。这样才能做到数据源的统一，避免流式处理和离线处理的不一致。

5.2.1 数据采集

一般来自于各个业务的日志服务器（例如网站的浏览行为日志、订单的修改日志等），这些数据被实时采集到数据中间件中，供下游实时订阅使用。

数据采集是整个数据处理链路的源头，是所有数据处理链路的根节点，既然需要做到实时计算，那么自然就需要做到实时采集了。

• 数据库变更日志
• 引擎访问日志

不管是数据库变更日志还是引擎访问日志，都会在业务服务器上落地成文件，所以只要监控文件的内容发生变化，采集工具就可以把最新的数据采集下来。一般情况下，出于吞吐量以及系统压力上的考虑，并不是新增一条记录就采集一次，而是基于下面的原则，按批次对数据进行采集。

• 数据大小限制：当达到限制条件时，把目前采集到的新数据作为一批（例如512KB写一批）
• 时间阐值限制：当时间达到一定条件时，也会把目前采集到的新数据作为一批，避免在数据量少的情况下一直不采集（例如30秒写一批）

只要上面的其中一个条件达到了，就会被作为一批新数据采集到数据中间件中。这两个条件的参数需要根据业务的需求来设定，当批次采集频繁时，可以降低延时，但必然会导致吞吐量下降。

对于采集到的数据需要一个数据交换平台分发给下游，这个平台就是数据中间件。数据中间件系统有很多实现方式，比如开源的系统有Kafka，而阿里巴巴集团内部用得比较多的是TimeTunnel（原理和Kafka类似），还有MetaQ、Notify等消息系统。

5.2.2 数据处理

数据被采集到中间件中后，需要下游实时订阅数据，并拉取到流式计算系统的任务中进行加工处理。这里需要提供流计算引擎以支持流式任务的执行。

实时数据处理应用出于性能考虑，计算任务往往是多线程的。一般会根据业务主键进行分桶处理，并且大部分计算过程需要的数据都会放在内存中，这样会大大提高应用的吞吐量。当然，为了避免内存溢出，内存中过期的数据需要定时清理，可以按照LRU（最近最少使用）算法或者业务时间集合归类清理（比如业务时间属于T-1的，会在今天凌晨进行清理）。

下面就实时任务遇到的几个典型问题进行讲解：

• 去重指标

（1）精确去重：明细数据是必须要保存下来的，当遇到内存问题时，可以通过数据倾斜来进行处理，把一个节点的内存压力分到多个节点上。

（2）模糊去重：在去重的明细数据量非常大，而业务的精度要求不高的情况下，可以使用相关的去重算法，把内存的使用量降到千分之一甚至万分之一，以提高内存的利用率。

• 数据倾斜

数据倾斜是ETL中经常遇到的问题，比如计算一天中全网访客数或者成交额时，最终的结果只有一个，通常应该是在一个节点上完成相关的计算任务。在数据量非常大的时候，单个节点的处理能力是有限的，必然会遇到性能瓶颈。这时就需要对数据进行分桶处理，分桶处理和离线处理的思路是一样的。

（1）去重指标分桶：通过对去重值进行分桶Hash，相同的值一定会被放在同一个桶中去重，最后再把每个桶里面的值进行加和就得到总值，这里利用了每个桶的CPU和内存资源。

(2）非去重指标分桶：数据随机分发到每个桶中，最后再把每个桶的值汇总，主要利用的是各个桶的CPU能力。

• 事务处理

由于实时计算是分布式处理的，系统的不稳定性必然会导致数据的处理有可能出现失败的情况。比如网络的抖动导致数据发送不成功、机器重启导致数据丢失等。在这些情况下，怎么做到数据的精确处理呢？上面提到的几个流计算系统几乎都提供了数据自动ACK、失败重发以及事务信息等机制。

（1）超时时间：由于数据处理是按照批次来进行的，当一批数据处理超时时，会从拓扑的spout端重发数据。另外，批次处理的数据量不宜过大，应该增加一个限流的功能（限定一批数据的记录数或者容量等），避免数据处理超时。

（2）事务信息：每批数据都会附带一个事务ID的信息，在重发的情况下，让开发者自己根据事务信息去判断数据第一次到达和重发时不同的处理逻辑。

（3）备份机制：开发人员需要保证内存数据可以通过外部存储恢复，因此在计算中用到的中间结果数据需要备份到外部存储中。

上面的这些机制都是为了保证数据的幕等性。

5.2.3 数据存储

数据被实时加工处理（比如聚合、清洗等）后，会写到某个在线服务的存储系统中，供下游调用方使用。这里的写操作是增量操作，并且是源源不断的。

实时任务在运行过程中，会计算很多维度和指标，这些数据需要放在一个存储系统中作为恢复或者关联使用。其中会涉及三种类型的数据：

• 中间计算结果

在实时应用处理过程中，会有一些状态的保存（比如去重指标的明细数据），用于在发生故障时，使用数据库中的数据恢复内存现场。

• 最终结果数据

指的是通过ETL处理后的实时结果数据，这些数据是实时更新的，写的频率非常高，可以被下游直接使用。

• 维表数据

在离线计算系统中，通过同步工具导入到在线存储系统中，供实时任务来关联实时流数据。

前面提到实时任务是多线程处理的，这就意味着数据存储系统必须能够比较好地支持多并发读写，并且延时需要在毫秒级才能满足实时的性能要求。在实践中，一般使用HBase、Tair、MongoDB等列式存储系统。由于这些系统在写数据时是先写内存再落磁盘，因此写延时在毫秒级：读请求也有缓存机制，重要的是多并发读时也可以达到毫秒级延时。

但是这些系统的缺点也是比较明显的，以HBase为例，一张表必须要有rowkey，而rowkey是按照ASCII码来排序的，这就像关系型数据库的索引一样，rowkey的规则限制了读取数据的方式。如果业务方需要使用另一种读取数据的方式，就必须重新输出rowkey。从这个角度来看，HBase没有关系型数据库方便。但是HBase的一张表能够存储几TB甚至几十TB的数据，而关系型数据库必须要分库分表才能实现这个量级的数据存储。因此，对于海量数据的实时计算，一般会采用非关系型数据库，以应对大量的多并发读写。

下面介绍在数据统计中表名设计和rowkey设计的一些实践经验：

• 表名设计

设计规则：汇总层标识＋数据域＋主维度＋时间维度例如：dws_trd_slr_dtr，表示汇总层交易数据，根据卖家（slr）主维度+O点截至当日（dtr）进行统计汇总。

这样做的好处是，所有主维度相同的数据都放在一张物理表中，避免表数量过多，难以维护。另外，可以从表名上直观地看到存储的是什么数据内容，方便排查问题。

• rowkey设计

设计规则：MD5＋主维度＋维度标识＋子维度1＋时间维度＋子维度2

例如：卖家ID的MD5前四位＋卖家ID+app ＋一级类目ID+ddd ＋二级类目ID。

以MD5的前四位作为rowkey的第一部分，可以把数据散列，让服务器整体负载是均衡的，避免热点问题。在上面的例子中，卖家ID属于主维度，在查数据时是必传的。每个统计维度都会生成一个维度标识，以便在rowkey上做区分。

5.2.4 数据服务

在存储系统上会架设一层统一的数据服务层（比如提供HSF接口、HTTP服务等），用于获取实时计算结果。

实时数据落地到存储系统中后，使用方就可以通过统一的数据服务获取到实时数据（比如下面要讲到的OneService），其好处是：

• 不需要直连数据库，数据源等信息在数据服务层维护，这样当存储系统迁移时，对下游是透明的

• 调用方只需要使用服务层暴露的接口，不需要关心底层取数逻辑的实现

• 屏蔽存储系统间的差异，统一的调用日志输出，便于分析和监控下游使用情况

5.3 流式数据模型

数据模型设计是贯通数据处理过程的，流式数据处理也一样，需要对数据流建模分层。实时建模跟离线建模非常类似，数据模型整体上分为五层（ODS、DWD、DWS、ADS、DIM）。

由于实时计算的局限性，每一层中并没有像离线做得那么宽，维度和指标也没有那么多，特别是涉及回溯状态的指标，在实时数据模型中几乎没有。

整体来看，实时数据模型是离线数据模型的一个子集，在实时数据处理过程中，很多模型设计就是参考离线数据模型实现的。

5.3.1 数据分层

• ODS层

操作数据层，是直接从业务系统采集过来的最原始数据，包含了所有业务的变更过程，数据粒度也是最细的。在这一层，实时和离线在源头上是统一的，这样的好处是用同一份数据加工出来的指标，口径基本是统一的，可以更方便进行实时和离线间数据比对。例如：原始的订单变更记录数据、服务器引擎的访问日志。

• DWD层

DWD层是在ODS层基础上，根据业务过程建模出来的实时事实明细层，对于访问日志这种数据（没有上下文关系，并且不需要等待过程的记录），会回流到离线系统供下游使用，最大程度地保证实时和离线数据在ODS层和DWD层是一致的。例如：订单的支付明细表、退款明细表、用户的访问日志明细表。

• DWS层

订阅明细层的数据后，会在实时任务中计算各个维度的汇总指标。如果维度是各个垂直业务线通用的，则会放在实时通用汇总层，作为通用的数据模型使用。比如电商网站的卖家粒度，只要涉及交易过程，就会跟这个维度相关，所以卖家维度是各个垂直业务的通用维度，其中的汇总指标也是各个业务线共用的。例如：电商数据的几大维度的汇总表（卖家、商品、买家）。

• ADS层

个性化维度汇总层，对于不是特别通用的统计维度数据会放在这一层中，这里计算只有自身业务才会关注的维度和指标，眼其他业务线一般没有交集，常用于一些垂直创新业务中。例如：手机淘宝下面的某个爱逛街、微淘等垂直业务。

• DIM层

实时维表层的数据基本上都是从离线维表层导出来的，抽取到在线系统中供实时应用调用。这一层对实时应用来说是静态的，所有的ETL处理工作会在离线系统中完成。维表在实时应用的使用中跟离线稍有区别，后面章节中会详细说明。例如：商品维表、卖家维表、买家维表、类目维表。

ODS层：订单粒度的变更过程，一笔订单有多条记录。
DWD层：订单粒度的支付记录，一笔订单只有一条记录。
DWS层：卖家的实时成交金额，一个卖家只有一条记录，并且指标在实时刷新。ADS层：外卖地区的实时成交金额，只有外卖业务使用。
DIM层：订单商品类目和行业的对应关系维表。

5.3.2 多流关联

在流式计算中常常需要把两个实时流进行主键关联，以得到对应的实时明细表。在离线系统中两个表关联是非常简单的，因为离线计算在任务启动时已经可以获得两张表的全量数据，只要根据关联键进行分桶关联就可以了。但流式计算不一样，数据的到达是一个增量的过程，并且数据到达的时间是不确定的和无序的，因此在数据处理过程中会涉及中间状态的保存和恢复机制等细节问题。

比如A表和B表使用ID进行实时关联，由于无法知道两个表的到达顺序，因此在两个数据流的每条新数据到来时，都需要到另外一张表中进行查找。如A表的某条数据到达，到B表的全量数据中查找，如果能查找到，说明可以关联上，拼接成一条记录直接输出到下游；但是如果关联不上，则需要放在内存或外部存储中等待，直到B表的记录也到达。多流关联的一个关键点就是需要相互等待，只有双方都到达了，才能关联成功。

图5.6 多流关联示例.png

在上面的例子中，实时采集两张表的数据，每到来一条新数据时都在内存中的对方表截至当前的全量数据中查找，如果能查找到，则说明关联成功，直接输出：如果没查找到，则把数据放在内存中的自己表数据集合中等待。另外，不管是否关联成功，内存中的数据都需要备份到外部存储系统中，在任务重启时，可以从外部存储系统中恢复内存数据，这样才能保证数据不丢失。因为在重启时，任务是续跑的，不会重新跑之前的数据。

另外，订单记录的变更有可能发生多次（比如订单的多个字段多次更新），在这种情况下，需要根据订单ID去重，避免A表和B表多次关联成功；否则输出到下游就会有多条记录，这样得到的数据是有重复的。

以上是整体的双流关联流程，在实际处理时，考虑到查找数据的性能，实时关联这个步骤一般会把数据按照关联主键进行分桶处理，并且在故障恢复时也根据分桶来进行，以降低查找数据量和提高吞吐量。

5.3.3 维表使用

在离线系统中，一般是根据业务分区来关联事实表和维表的，因为在关联之前维表的数据就已经就绪了。而在实时计算中，关联维表一般会使用当前的实时数据（T）去关联T-2的维表数据，相当于在T的数据到达之前需要把维表数据准备好，并且一般是一份静态的数据。

5.4 大促挑战＆保障

• 毫秒级延时
• 洪峰明显
• 高保障性
• 公关特性

第6章 数据服务

数据部门产出的海量数据，如何能方便高效地开放出去，是我们一直想要解决的难题。在没有数据服务的年代，数据开放的方式简单、粗暴，一般是直接将数据导出给对方。这种方式不仅低效，还带来了安全隐患等诸多问题。

6.1 服务架构演进

6.1.4 统一的数据服务层

图6.5 统一的数据服务层（OneService）架构示意图.png

6.2 技术架构

6.3 最佳实践

6.3.1 性能

• 资源分配
  剥离计算资源、查询资源分配、执行计划优化

• 缓存优化
  元数据缓存、模型缓存、结果缓存

• 查询能力
  合并查询、推送服务

6.3.2 稳定性

• 发布系统
  元数据隔离、隔离发布

• 隔离
  机房隔离、分组隔离、

• 安全限制

• 监控
  调用日志采集、调用监控

• 限流、降级

第7章 数据挖掘

7.1 数据挖掘概述

高速增长的业务必然催生大数据挖掘应用的蓬勃发展。当我们从业务系统中能够轻松采集到海量数据时，往往会发现里面的有效数据信息却越来越稀疏，有效数据和无效数据的增长率是不成比例的。因此，如何从海量数据中挖掘出有效信息形成真正的生产力，是所有大数据公司需要面对的共同课题。

数据挖掘技术与数据仓储及计算技术的发展是相辅相成的，没有数据基础设施的发展与分布式并行计算技术，就不会有深度学习，更不会见证AlphaGo的神奇。

近年来，阿里巴巴数据挖掘应用也呈现出井喷式的增长态势。面向海量会员和商品的全局画像、基于自然人的全域ID-Mapping、广告精准投放平台、千人千面的个性化搜索与推荐技术、非人流量与恶意设备的识别、商业竞争情报的自动化挖掘系统....这些或传统或新兴的大数据挖掘应用已深入阿里巴巴业务的各个环节，“无数据不智能，无智能不商业”，大数据与AI/机器学习融合后的新商业革命己然到来。

基于大数据的企业级数据挖掘需要包含两个要素：

• 面向机器学习算法的并行计算框架与算法平台
• 面向企业级数据挖掘的算法资产管理体系

7.2 数据挖掘算法平台

7.3 数据挖掘申台体系

7.4 数据挖掘案例

7.4.1 用户画像

用户画像即是为用户打上各种各样的标签，如年龄、性别、职业、商品品牌偏好、商品类别偏好等。这些标签的数目越丰富，标签越细化，对用户的刻画就越精准。

例如，分析某用户为女性，可能仅仅是将与女性相关的服装、个人护理等商品作为推荐结果反馈给该用户：但若根据用户以往的浏览、交易等行为挖掘出进一步的信息，如用户的地理信息为海南，买过某几类品牌的服装，则可以将薄款的、品牌风格相似的服装作为推荐结果。

一般而言，用户画像可以分为基础属性、购物偏好、社交关系、财富属性等几大类。对于刻画淘宝网购用户，则应侧重于他们在网购上的行为偏好。

下面以用户女装风格偏好为例，讲解该用户标签是如何基于全域数据产出的。

购买过淘宝商品的读者对商品详情页都不会陌生，一件商品的关键特征除了反映在商品图片和详情页中以外，主要可以采集的信息是商品的标题以及参数描述。女装有哪几种风格？

首先需要将女装行业下的商品标题文本提取出来，对其进行分词，得到庞大的女装描绘词库。然而，淘宝商品的标题由卖家个人撰写，并不能保证其中的词语都与商品风格描述相关。因此，对于所得到的女装描绘词库，首先，需要根据词语权重去除无效的停用词，方法如计算TF-IDF值。其次，在女装商品的参数描述中，如果已经包含了一种商品风格，例如“通勤”“韩版”等常见风格，那么通过计算词库中词语与参数描述中风格词的相似度，可以过滤得到女装风格词库，利用无监督机器学习如LDA等方法可以计算出一种风格所包含的词汇及这些词汇的重要性。

那么，买家偏好什么风格昵？在淘宝网上，买家拥有浏览、搜索、点击、收藏、加购物车以及交易等多种行为，针对每种行为赋予不同的行为强度（比如浏览行为强度弱于交易行为），再考虑该商品的风格元素组成，就能够通过合理的方式获知买家对该风格的偏好程度了。

对于这样的商品偏好计算，数据挖掘人员需要仔细分析用户偏好的商品的类型、品牌、风格元素、下单时间，这一系列行为可以构成复杂的行为模块。同理，利用机器学习算法，可以从用户行为中推测其身份，例如男生和女生、老年与青年偏好的商品和行为方式存在区别，根据一定的用户标记，最后能够预测出用户的基础身份信息。

7.4.2 互联网反作弊

• 账户／资金安全与网络欺诈防控
• 非人行为和账户识别
• 虚假订单与信用炒作识别
• 广告推广与APP安装反作弊
• UGC恶意信息检测