大数据之路：阿里巴巴大数据实践

第1章：总述

如果说在IT时代是以自我控制、自我管理为主，那么到了DT（Data Technology）时代，则是以服务大众、激发生产力为主。阿里巴巴大数据系统体系架构主要分为数据采集、数据计算、数据服务和数据应用四大层次。

第2章：日志采集

阿里巴巴的日志采集体系方案包括两大体系：Aplus.JS是Web端（基于浏览器）日志采集技术方案：UserTrack是APP端（无线客户端）日志采集技术方案。

2.1 浏览器的页面日志采集

浏览器的页面型产品／服务的日志采集可分为如下两大类。

1. 页面浏览（展现）日志采集。
2. 页面交互日志采集。

2.1.1 页面浏览日志采集流程

在HTML文档内增加一个日志采集节点，当浏览器解析时将自动触发一个特定的HTTP请求到日志采集服务器。主要过程如下：

1. 客户端日志采集。在HTML文档内植入日志采集脚本的动作可以由业务服务器在响应业务请求时动态执行，也可以在开发页面时由开发人员手动植入。
2. 客户端日志发送。采集脚本执行时，会发起一个日志请求，以将采集到的数据发送到日志服务器。
3. 服务器端日志收集。日志服务器接收到请求后，立即向浏览器发回一个请求成功的响应，以免对页面的正常加载造成影响。
4. 服务器端日志解析存档。服务器接收到的浏览日志进人缓冲区后，会被一段专门的日志处理程序顺序读出并按照约定的日志处理逻辑解析。

阿里巴巴的页面浏览日志采集框架，不仅指定了上述的采集技术方案，同时也规定了PV日志的采集标准规范，其中规定了PV日志应采集和可采集的数据项，并对数据格式做了规定。

2.1.2 页面交互日志采集

在阿里巴巴，通过一套名为“黄金令箭”的采集方案来解决交互日志的采集问题。“黄金令箭”是一个开放的基于HTTP协议的日志服务，采集步骤如下。

1. 业务方在“黄金令箭”的元数据管理界面依次注册需要采集交互日志的业务、具体的业务场景以及场景下的具体交互采集点，在注册完成之后，系统将生成与之对应的交互日志采集代码模板。
2. 业务方将交互日志采集代码植入目标页面，并将采集代码与需要监测的交互行为做绑定。
3. 当用户在页面上产生指定行为时，采集代码和正常的业务互动响应代码一起被触发和执行。
4. 采集代码在采集动作完成后将对应的日志通过HTTP协议发送到日志服务器，日志服务器接收到日志后，对于保存在HTTP请求参数部分的自定义数据，即用户上传的数据，原则上不做解析处理，只做简单的转储。

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

在大部分场合下，经过上述解析处理之后的日志并不直接提供给下游使用，一般还需要进行相应的离线预处理。

1. 识别流量攻击、网络爬虫和流量作弊（虚假流量）。
2. 数据缺项补正。
3. 无效数据剔除。
4. 日志隔离分发。

2.2 无线客户端的日志采集

在阿里巴巴内部，多使用名为UserTrack的SDK来进行无线客户端的日志采集。UserTrack(UT）把事件分成了几类，常用的包括页面事件和控件点击事件等。

2.2.1 页面事件

每条页面事件日志记录三类信息：①设备及用户的基本信息；②被访问页面的信息；③访问基本路径。UT提供了透传参数功能，即把当前页面的某些信息，传递到下一个页面甚至下下一个页面的日志中。

2.2.2 控件点击及其他事件

交互类的行为呈现出高度自定义的业务特征，因此UT提供了一个自定义埋点类，其包括：①事件名称；②事件时长；③事件所携带的属性；④事件对应的页面。UT还提供了一些默认的日志采集方法，比如可以自动捕获应用崩溃，并且产生一条日志记录崩溃相关信息。

2.2.3 特殊场景

随着业务的不断发展，业务的复杂性不断提高，采集需要处理的特殊场景也层出不穷。比如，为了平衡日志大小，减小流量消耗、采集服务器压力、网络传输压力等，采集SDK提供了聚合功能。

2.2.4 H5 & Native日志统一

考虑到后续日志数据处理的便捷性、计算成本、数据的合理性及准确性，我们需要对Native和H5日志进行统一处理。在阿里巴巴集团，我们选择Native部署采集SDK的方式。原因有二： 一是采用采集SDK可以采集到更多的设备相关数据；二是采集SDK处理日志，会先在本地缓存，而后借机上传，在网络状况不佳时延迟上报，保证数据不丢失。具体的流程如下：

1. H5页面浏览和页面交互的数据，在执行时通过加载日志采集的JavaScript脚本，采集当前页面参数，包括浏览行为的上下文信息以及一些运行环境信息。
2. 在浏览器日志采集的JavaScript脚本中实现将所采集的数据打包到一个对象中，然后调用Web View框架的JSBridge接口，调用移动客户端对应的接口方法，将埋点数据对象当作参数传入。
3. 移动客户端日志采集SDK，封装提供接口，实现将传入的内容转换成移动客户端日志格式。

2.2.5 设备标识

互联网产品的基本指标访客数（Unique Visitors, UV），对于登录用户，可以使用用户ID来进行唯一标识，但是很多日志行为并不要求用户登录。PC端一般使用Cookie信息来作为设备的唯一信息。阿里巴巴集团无线设备唯一标识使用UTDID，就是每台设备一个ID作为唯一标识。

2.2.6 日志传输

无线客户端日志的上传，不是产生一条日志上传一条，而是无线客户端产生日志后，先存储在客户端本地，然后再伺机上传。服务器端处理上传请求，对请求进行相关校验，将数据追加到本地文件中进行存储，存储方式使用Nginx的access_log, access_log的切分维度为天，即当天接收的日志存储到当天的日志文件中。阿里巴巴集团主要使用消息队列（TimeTunel, TT）来实现从日志采集服务器到数据计算的MaxCompute。

2.3 日志采集的挑战

各类采集方案提供者所面临的主要挑战是如何实现日志数据的结构化和规范化组织，实现更为高效的下游统计计算，提供符合业务特性的数据展现，以及为算法提供更便捷、灵活的支持等方面。

2.3.1 典型场景

1. 日志分流与定制处理：在日志解析和处理过程中必须考虑业务分流、日志优先级控制，以及根据业务特点实现定制处理。通过尽可能靠前地布置路由差异，就可以尽可能早地进行分流，降低日志处理过程中的分支判断消耗，并作为后续的计算资源调配的前提，提高资源利用效率。
2. 采集与计算一体化设计：要求日志采集方案必须将来集与计算作为一个系统来考量，进行一体化设计。目前阿里已成功实现规范制定一元数据注册一日志采集一自动化计算一可视化展现全流程的贯通。

2.3.2 大促保障

首先，端上实现了服务器端推送配置到客户端，且做到高到达率；其次，对日志做了分流，结合日志的重要程度及各类日志的大小，实现了日志服务器端的拆分；最后，在实时处理方面，也做了不少的优化以提高应用的吞吐量。

第3章：数据同步

不同系统间的数据流转。

3.1 数据同步基础

同步方式可以分为三种：直连同步、数据文件同步和数据库日志解析同步。

3.1.1 直连同步

直连同步是指通过定义好的规范接口API和基于动态链接库的方式直接连接业务库。这种方式配置简单，实现容易，比较适合操作型业务系统的数据同步。但是业务库直连的方式对源系统的性能影响较大，虽然可以从备库抽取数据，但是当数据量较大时，采取此种抽取方式性能较差，不太适合从业务系统到数据仓库系统的同步。

3.1.2 数据文件同步

数据文件同步通过约定好的文件编码、大小、格式等，直接从源系统生成数据的文本文件，由专门的文件服务器，如FTP服务器传输到目标系统后，加载到目标数据库系统中。当数据源包含多个异构的数据库系统（如MySQL、Oracle、SQL Server、DB2 等）时，用这种方式比较简单、实用。

为了确保数据文件同步的完整性，通常除了上传数据文件本身以外，还会上传一个校验文件，以供下游目标系统验证数据同步的准确性。另外，在从源系统生成数据文件的过程中，可以增加压缩和加密功能，传输到目标系统以后，再对数据进行解压缩和解密， 这样可以大大提高文件的传输效率和安全性。

3.1.3 数据库日志解析同步

解析日志文件这种读操作是在操作系统层面完成的，不需要通过数据库，因此不会给源系统带来性能影响。然后可通过网络协议，实现源系统和目标系统之间的数据文件传输。数据文件被传输到目标系统后，可通过数据加载模块完成数据的导入，从而实现数据从源系统到目标系统的同步。

数据库日志解析同步方式实现了实时与准实时同步的能力，延迟可以控制在毫秒级别，并且对业务系统的性能影响也比较小，目前广泛应用于从业务系统到数据仓库系统的增量数据同步应用之中。通过数据库日志解析进行同步的方式性能好、效率高，对业务系统的影响较小。但是它也存在如下一些问题：

• 数据延迟。例如，业务系统做批量补录可能会使数据更新量超出系统处理峰值，导致数据延迟。
• 投入较大。采用数据库日志抽取的方式投入较大，需要在源数据库与目标数据库之间部署一个系统实时抽取数据。
• 数据漂移和遗漏。数据漂移，一般是对增量表而言的，通常是指该表的同一个业务日期数据中包含前一天或后一天凌晨附近的数据或者丢失当天的变更数据。

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

3.2.1 批量数据同步

对于离线类型的数据仓库应用，需要将不同的数据源批量同步到数据仓库，以及将经过数据仓库处理的结果数据定时同步到业务系统。阿里巴巴的DataX就是这样一个能满足多方向高自由度的异构数据交换服务产品。对于不同的数据源，DataX 通过插件的形式提供支持，将数据从数据源读出并转换为中间状态，同时维护好数据的传输、缓存等工作。数据在DataX中以中间状态存在，并在目标数据系统中将中间状态的数据转换为对应的数据格式后写入。

DataX采用Framework + Plugin的开放式框架实现，Framework处理缓冲、流程控制、并发、上下文加载等高速数据交换的大部分技术问题，并提供简单的接口与插件接入。插件仅需实现对数据处理系统的访问，编写方便，开发者可以在极短的时间内开发一个插件以快速支持新的数据库或文件系统。数据传输在单进程（单机模式）／多进程（分布式模式）下完成，传输过程全内存操作，不读写磁盘，也没有进程间通信，实现了在异构数据库或文件系统之间的高速数据交换。

3.2.2 实时数据同步

建立一个日志数据交换中心，通过专门的模块从每台服务器源源不断地读取日志数据，或者解析业务数据库系统的binlog或归档日志，将增量数据以数据流的方式不断同步到日志交换中心，然后通知所有订阅了这些数据的数据仓库系统来获取。

阿里巴巴的TimeTunnel(TT）是一种基于生产者、消费者和Topic消息标识的消息中间件，将消息数据持久化到HBase的高可用、分布式数据交互系统。Time Tunnel支持主动、被动等多种数据订阅机制，订阅端自动负载均衡，消费者自己把握消费策略。对于读写比例很高的Topic，能够做到读写分离，使消费不影响发送。同时支持订阅历史数据，可以随意设置订阅位置，方便用户回补数据。

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

3.3.1 分库分表的处理

阿里巴巴的TDDL (Taobao Distributed Data Layer）就是这样一个分布式数据库的访问引擎，通过建立中间状态的逻辑表来整合统一分库分表的访问。TDDL是在持久层框架之下、JDBC驱动之上的中间件，它与JDBC规范保持一致，有效解决了分库分表的规则引擎问题，实现了SQL解析、规则计算、表名替换、选择执行单元并合并结果集的功能，同时解决了数据库表的读写分离、高性能主备切换的问题，实现了数据库配置信息的统一管理。

3.3.2 高效同步和批量同步

阿里巴巴数据仓库研发了OneClick产品，真正实现了数据的一键化和批量化同步，一键完成DDL和DML的生成、数据的冒烟测试以及在生产环境中测试等。

• 对不同数据源的数据同步配置透明化，可以通过库名和表名唯一定位，通过IDB接口获取元数据信息自动生成配置信息。
• 简化了数据同步的操作步骤，实现了与数据同步相关的建表、配置任务、发布、测试操作一键化处理，并且封装成Web接口进一步达到批量化的效果。
• 降低了数据同步的技能门槛，让数据需求方更加方便地获取和使用数据。

IDB是阿里巴巴集团用于统一管理MySQL、OceanBase、PostgreSQL、Oracle、SQL Server等关系型数据库的平台，它是一种集数据管理、结构管理、诊断优化、实时监控和系统管理于一体的数据管理服务；在对集团数据库表的统一管理服务过程中，IDB产出了数据库、表、字段各个级别元数据信息，并且提供了元数据接口服务。

3.3.3 增量与全量同步的合并

每次只同步新变更的增量数据，然后与上一个同步周期获得的全量数据进行合井，从而获得最新版本的全量数据。我们比较推荐的方式是全外连接（ full outer join) ＋ 数据全量覆盖重新加载（insert overwrite）。如果担心数据更新错误问题，可以采用分区方式，每天保持一个最新的全量版本，保留较短的时间周期。

3.3.4 同步性能的处理

阿里巴巴数据团队实践出了一套基于负载均衡思想的新型数据同步方案。该方案的核心思想是通过目标数据库的元数据估算同步任务的总线程数，以及通过系统预先定义的期望同步速度估算首轮同步的线程数，同时通过数据同步任务的业务优先级决定同步线程的优先级，最终提升同步任务的执行效率和稳定性。具体实现步骤如下：

• 用户创建数据同步任务，并提交该同步任务。
• 根据系统提前获知及设定的数据，估算该同步任务需要同步的数据量、平均同步速度、首轮运行期望的线程数、需要同步的总线程数。
• 根据需要同步的总线程数将待同步的数据拆分成相等数量的数据块，一个线程处理一个数据块，并将该任务对应的所有线程提交至同步控制器。
• 同步控制器判断需要同步的总线程数是否大于首轮运行期望的线程数，若大于，则跳转至2 若不大于，则跳转至下一步。
• 同步控制器采用多机多线程的数据同步模式，准备该任务第一轮线程的调度，优先发送等待时间最长、优先级最高且同一任务的线程。
• 同步控制器准备一定数据量（期望首轮线程数－总线程数）的虚拟线程，采用单机多线程的数据同步模式，准备该任务相应实体线程和虚拟线程的调度，优先发送等待时间最长、优先级最高且单机CPU剩余资源可以支持首轮所有线程数且同一任务的线程，如果没有满足条件的机器，则选择CPU剩余资源最多的机器进行首轮发送。
• 数据任务开始同步，并等待完成。
• 数据任务同步结束。

3.3.5 数据漂移的处理

数据漂移通常是指ODS表的同一个业务日期数据中包含前一天或后一天凌晨附近的数据或者丢失当天的变更数据。处理方法主要有以下两种：

1. 多获取后一天的数据：在ODS每个时间分区中向前、向后多冗余一些数据，保障数据只会多不会少，而具体的数据切分让下游根据自身不同的业务场景用不同的业务时间proc_time来限制。
2. 通过多个时间戳字段限制时间来获取相对准确的数据。

第4章：离线数据开发

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

4.1 数据开发平台

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

4.1.1 统一计算平台

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

4.1.2 统一开发平台

围绕MaxCompute计算平台，从任务开发、调试、测试、发布、监控、报警到运维管理，形成了整套工具和产品，既提高了开发效率，又保证了数据质量，并且在确保数据产出时效的同时，能对数据进行有效管理。

1. 在云端（D2)：D2 是集成任务开发、调试及发布，生产任务调度及大数据运维，数据权限申请及管理等功能的一站式数据开发平台，并能承担数据分析工作台的功能。
2. SQLSCAN：SQLSCAN将在任务开发中遇到的各种问题，如用户编写的SQL质量差、性能低、不遵守规范等，总结后形成规则，并通过系统及研发流程保障，事前解决故障隐患，避免事后处理。
3. DQC(Data Quality Center，数据质量中心）主要关注数据质量，通过配置数据质量校验规则，自动在数据处理任务过程中进行数据质量方面的监控。DQC主要有数据监控和数据清洗两大功能。
4. 在彼岸：数据测试的典型测试方法是功能测试，主要验证目标数据是否符合预期。a. 新增业务需求：其主要对目标数据和源数据进行对比，包括数据量、主键、字段空值、字段枚举值、复杂逻辑（如UDF、多路分支）等的测试。b. 数据迁移、重构和修改：对修改前后的数据进行对比，包括数据量差异、字段值差异对比等，保证逻辑变更正确。在彼岸主要包含如下组件：a. 数据对比： 支持不同集群、异构数据库的表做数据对比；b. 数据分布：提取表和字段的一些特征值，并将这些特征值与预期值进行比对；c. 数据脱敏：将敏感数据模糊化。

4.2 任务调度系统

4.2.1 背景

在大数据环境下，每天需要处理海量的任务，任务的类型也很繁杂，任务之间互相依赖且需要不同的运行环境。为了解决以上问题，阿里巴巴的大数据调度系统应运而生。

4.2.2 介绍

1. 数据开发流程与调度系统的关系：用户通过D2平台提交、发布的任务节点，需要通过调度系统，按照任务的运行顺序调度运行。
2. 调度系统的核心设计模型：调度引擎（Phoenix Engine）和执行引擎（Alisa）。调度引擎的作用是根据任务节点属性以及依赖关系进行实例化，生成各类参数的实值，并生成调度树；执行引擎的作用是根据调度引擎生成的具体任务实例和配置信息，分配CPU、内存、运行节点等资源， 在任务对应的执行环境中运行节点代码。
3. 任务状态机模型：针对数据任务节点在整个运行生命周期的状态定义。
4. 工作流状态机模型：针对数据任务节点在调度树中生成的工作流运行的不同状态定义。
5. 调度引擎工作原理：基于以上两个状态机模型原理，以事件驱动的方式运行，为数据任务节点生成实例，并在调度树中生成具体执行的工作流。
6. 执行引擎工作原理。
7. 执行引擎的用法：Alisa的用户系统包括上文的工作流服务、数据同步服务，以及调度引擎生成的各类数据处理任务的调度服务。

4.2.3 特点及应用

1. 调度配置：采用的是输入输出配置和自动识别相结合的方式。任务提交时，SQL解析引擎自动识别此任务的输入表和输出表，输入表自动关联产出此表的任务，输出表亦然。
2. 定时调度：分钟、小时、日、周、月，具体可精确到秒。
3. 周期调度：可按照小时、日等时间周期运行任务，与定时调度的区别是无须指定具体的开始运行时间。
4. 手动运行：当生产环境需要做一些数据修复或其他一次性的临时数据操作时，可以选择手动运行的任务类型。
5. 补数据：可以设定需要补的时间区间，并圈定需要运行的任务节点，从而生成一个补数据的工作流，同时还能选择并行的运行方式以节约时间。
6. 基线管理：基于充分利用计算资源，保证重点业务数据优先产出，合理安排各类优先级任务的运行，调度系统引入了按优先级分类管理的方法。对于同一类优先级的任务，放到同一条基线中，这样可以实现按优先级不同进行分层的统一管理，并可对基线的运行时间进行预测估计，以监控是否能在规定的时间内完成。
7. 监控报警：调度系统有一套完整的监控报警体系，包括针对出错的节点、运行超时未完成的节点，以及可能超时的基线等，设置电话、短信、邮件等不同的告警方式，实现了日常数据运维的自动化。

第5章：实时技术

5.1 简介

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

1. 时效性高；
2. 常驻任务；
3. 性能要求高；
4. 应用局限性；

5.2 流式技术架构

各个子系统按功能划分的话，主要分为以下几部分。

1. 数据采集：日志服务器数据被实时采集到数据中间件中，供下游实时订阅使用。
2. 数据处理：下游实时订阅数据，并拉取到流式计算系统的任务中进行加工处理。
3. 数据存储：数据被实时加工处理（比如聚合、清洗等）后，会写到某个在线服务的存储系统中，供下游调用方使用。
4. 数据服务：在存储系统上会架设一层统一的数据服务层，用于获取实时计算结果。

5.2.1 数据采集

不管是数据库变更日志还是引擎访问日志，都会在业务服务器上落地成文件，所以只要监控文件的内容发生变化，采集工具就可以把最新的数据采集下来。一般情况下，出于吞吐量以及系统压力上的考虑，并不是新增一条记录就采集一次，而是按批次对数据进行采集。对于采集到的数据需要一个数据交换平台分发给下游，这个平台就是数据中间件。阿里巴巴集团内部用得比较多的是TimeTunnel（原理和Kafka类似），还有MetaQ、Notify等消息系统。

5.2.2 数据处理

在阿里巴巴集团内使用比较多的是阿里云提供的StreamCompute系统，涵盖了从数据采集到数据生产各个环节，力保流计算开发严谨、可靠。实时任务遇到的几个典型问题。

1. 去重指标：精确去重。在这种情况下，明细数据是必须要保存下来的。模糊去重，可以使用相关的去重算法：布隆过滤器、基数估计等。
2. 数据倾斜：对数据进行分桶处理。去重指标分桶：通过对去重值进行分桶Hash，相同的值一定会被放在同一个桶中去重，最后再把每个桶里面的值进行加和就得到总值。
3. 事务处理：几个流计算系统几乎都提供了数据自动ACK、失败重发以及事务信息等机制。超时时间、事务信息、备份机制，这些机制都是为了保证数据的幂等性。

5.2.3 数据存储

数据存储系统必须能够比较好地支持多并发读写，并且延时需要在毫秒级才能满足实时的性能要求。在实践中，一般使用HBase 、Tair、MongoDB等列式存储系统。表名设计和rowkey设计的一些实践经验。

1. 表名设计：设计规则：汇总层标识＋数据域＋主维度＋时间维度。
2. rowkey设计：设计规则：MD5＋主维度＋维度标识＋子维度1＋时间维度＋子维度2。以MD5的前四位作为rowkey的第一部分，可以把数据散列，让服务器整体负载是均衡的，避免热点问题。

5.2.4 数据服务

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

• 不需要直连数据库，数据源等信息在数据服务层维护，这样当存储系统迁移时，对下游是透明的。
• 调用方只需要使用服务层暴露的接口，不需要关心底层取数逻辑的实现。
• 屏蔽存储系统间的差异，统一的调用日志输出，便于分析和监控下游使用情况。

5.3 流式数据模型

实时建模跟离线建模非常类似，数据模型整体上分为五层（ODS、DWD、DWS、ADS、DIM）。由于实时计算的局限性，每一层中并没有像离线做得那么宽，维度和指标也没有那么多，特别是涉及回溯状态的指标，在实时数据模型中几乎没有。

5.3.1 数据分层

1. ODS层：操作数据层，实时和离线在源头上是统一的，这样的好处是用同一份数据加工出来的指标，口径基本是统一的，可以更方便进行实时和离线间数据比对。
2. DWD层：根据业务过程建模出来的实时事实明细层，最大程度地保证实时和离线数据在ODS层和DWD层是一致的。
3. DWS层：如果维度是各个垂直业务线通用的，则会放在实时通用汇总层，作为通用的数据模型使用。
4. ADS层：个性化维度汇总层，对于不是特别通用的统计维度数据会放在这一层中，这里计算只有自身业务才会关注的维度和指标，跟其他业务线一般没有交集，常用于一些垂直创新业务中。
5. DIM层：实时维表层的数据基本上都是从离线维表层导出来的，抽取到在线系统中供实时应用调用。

5.3.2 多流关联

在流式计算中常常需要把两个实时流进行主键关联，以得到对应的实时明细表。多流关联的一个关键点就是需要相互等待，只有双方都到达了，才能关联成功。实时采集两张表的数据，每到来一条新数据时都在内存中的对方表截至当前的全量数据中查找，如果能查找到，则说明关联成功，直接输出；如果没查找到，则把数据放在内存中的自己表数据集合中等待。另外，不管是否关联成功，内存中的数据都需要备份到外部存储系统中，在任务重启时，可以从外部存储系统中恢复内存数