关于大数据:连载阿里巴巴大数据实践实时技术

2次阅读

共计 5291 个字符，预计需要花费 14 分钟才能阅读完成。

简介： 绝对于离线批处理技术，流式实时处理技术作为一个十分重要的技术补充，在阿里巴巴团体内被宽泛应用。

前言：
- 更多对于数智化转型、数据中台内容请退出 阿里云数据中台交换群—数智俱乐部 和关注官网微信公总号（文末扫描二维码或点此退出）

起源：数智化转型俱乐部

数据价值是具备时效性的，在一条数据产生的时候，如果不能及时处理并在业务零碎中应用，就不能让数据放弃最高的“新鲜度”和价值最大化。

绝对于离线批处理技术，流式实时处理技术作为一个十分重要的技术补充，在阿里巴巴团体内被宽泛应用。

在大数据业界中，流计算技术的钻研是近年来十分热门的课题。

业务诉求是心愿能在第一工夫拿到通过加工后的数据，以便实时监控以后业务状态并做出经营决策，疏导业务往好的方向倒退。比方网站上一个访问量很高的广告位，须要实时监控广告位的引流成果，如果转化率非常低的话，经营人员就须要及时更换为其余广告，以防止流量资源的节约。在这个例子中，就须要实时统计广告位的曝光和点击等指标作为经营决策的参考。

依照数据的提早状况，数据时效性个别分为三种（离线、准实时、实时）：

离线：在明天（T）解决 N 天前（T-N，N≥1）的数据，延迟时间粒度为天。
准实时：在以后小时（H）解决 N 小时前（H-N，N>0，如 0.5 小时、1 小时等）的数据，延迟时间粒度为小时。
实时：在以后时刻解决以后的数据，延迟时间粒度为秒；

离线和准实时都能够在批处理零碎中实现（比方 Hadoop、MaxCompute、Spark 等零碎），只是调度周期不一样而已，而实时数据则须要在流式解决零碎中实现。简略来说，流式数据处理技术是指业务零碎每产生一条数据，就会立即被采集并实时发送到流式工作中进行解决，不须要定时调度工作来解决数据。

整体来看，流式数据处理个别具备以下特色。

1．时效性高

数据实时采集、实时处理，延时粒度在秒级甚至毫秒级，业务方可能在第一工夫拿到通过加工解决后的数据。

2．常驻工作

区别于离线工作的周期调度，流式工作属于常驻过程工作，一旦启动后就会始终运行，直到人为地终止，因而计算成本会绝对比拟高。这一特点也预示着流式工作的数据源是无界的，而离线工作的数据源是有界的。这也是实时处理和离线解决最次要的差异，这个个性会导致实时工作在数据处理上有肯定的局限性。

3．性能要求高

实时计算对数据处理的性能要求十分严格，如果解决吞吐量跟不上采集吞吐量，计算出来的数据就失去了实时的个性。比方实时工作 1 分钟只能解决 30 秒采集的数据，那么产出的数据的延时会越来越长，不能代表以后时刻的业务状态，有可能导致业务方做出谬误的经营决策。在互联网行业中，须要解决的数据是海量的，如何在数据量疾速收缩的状况下也能放弃高吞吐量和低延时，是以后面临的重要挑战。因而，实时处理的性能优化占了工作开发的很大一部分工作。

4．利用局限性

实时数据处理不能代替离线解决，除了计算成本较大这个因素外，对于业务逻辑简单的场景（比方双流关联或者须要数据回滚的状况），其局限性导致反对有余。另外，因为数据源是流式的，在数据具备上下文关系的状况下，数据达到工夫的不确定性导致实时处理跟离线解决得进去的后果会有肯定的差别。

在流式计算技术中，须要各个子系统之间相互依赖造成一条数据处理链路，能力产出后果最终对外提供实时数据服务。在理论技术选型时，可选的开源技术计划十分多，然而各个计划的整体架构是相似的，只是各个子系统的实现原理不太一样。另外，流式技术架构中的零碎跟离线解决是有穿插的，两套技术计划并不是齐全独立的，并且在业界中有合并的趋势。

各个子系统按性能划分的话，次要分为以下几局部：

1．数据采集

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

2．数据处理

数据被采集到中间件中后，须要上游实时订阅数据，并拉取到流式计算零碎的工作中进行加工解决。这里须要提供流计算引擎以反对流式工作的执行。

**3．数据存储
**
数据被实时加工解决（比方聚合、荡涤等）后，会写到某个在线服务的存储系统中，供上游调用方应用。这里的写操作是增量操作，并且是源源不断的。

4．数据服务

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

整体技术架构如图所示：

从图能够看出，在数据采集和数据服务局部实时和离线是专用的，因为在这两层中都不须要关怀数据的时效性。这样能力做到数据源的对立，防止流式解决和离线解决的不统一。

在流式计算技术中，须要各个子系统之间相互依赖造成一条数据处理链路，能力产出后果最终对外提供实时数据服务。在理论技术选型时，可选的开源技术计划十分多，然而各个计划的整体架构是相似的，只是各个子系统的实现原理不太一样。另外，流式技术架构中的零碎跟离线解决是有穿插的，两套技术计划并不是齐全独立的，并且在业界中有合并的趋势。

各个子系统按性能划分的话，次要分为以下几局部：

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

因为实时计算的局限性，每一层中并没有像离线做得那么宽，维度和指标也没有那么多，特地是波及回溯状态的指标，在实时数据模型中简直没有。

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

1．数据分层

在流式数据模型中，数据模型整体上分为五层。

ODS 层：跟离线零碎的定义一样，ODS 层属于操作数据层，是间接从业务零碎采集过去的最原始数据，蕴含了所有业务的变更过程，数据粒度也是最细的。在这一层，实时和离线在源头上是对立的，这样的益处是用同一份数据加工进去的指标，口径根本是对立的，能够更不便进行实时和离线间数据比对。例如：原始的订单变更记录数据、服务器引擎的拜访日志。

DWD 层：DWD 层是在 ODS 层根底上，依据业务过程建模进去的实时事实明细层，对于拜访日志这种数据（没有上下文关系，并且不须要期待过程的记录），会回流到离线零碎供上游应用，最大水平地保障实时和离线数据在 ODS 层和 DWD 层是统一的。例如：订单的领取明细表、退款明细表、用户的拜访日志明细表。

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

ADS 层：个性化维度汇总层，对于不是特地通用的统计维度数据会放在这一层中，这里计算只有本身业务才会关注的维度和指标，跟其余业务线个别没有交加，罕用于一些垂直翻新业务中。例如：手机淘宝上面的某个爱逛街、微淘等垂直业务。

DIM 层：实时维表层的数据基本上都是从离线维表层导出来的，抽取到在线零碎中供实时利用调用。这一层对实时利用来说是动态的，所有的 ETL 解决工作会在离线零碎中实现。维表在实时利用的应用中跟离线稍有区别，前面章节中会具体阐明。例如：商品维表、卖家维表、买家维表、类目维表。

2．多流关联

在流式计算中经常须要把两个实时流进行主键关联，以失去对应的实时明细表。在离线零碎中两个表关联是非常简单的，因为离线计算在工作启动时曾经能够取得两张表的全量数据，只有依据关联键进行分桶关联就能够了。但流式计算不一样，数据的达到是一个增量的过程，并且数据达到的工夫是不确定的和无序的，因而在数据处理过程中会波及中间状态的保留和复原机制等细节问题。

比方 A 表和 B 表应用 ID 进行实时关联，因为无奈晓得两个表的达到程序，因而在两个数据流的每条新数据到来时，都须要到另外一张表中进行查找。如 A 表的某条数据达到，到 B 表的全量数据中查找，如果能查找到，阐明能够关联上，拼接成一条记录间接输入到上游；然而如果关联不上，则须要放在内存或内部存储中期待，直到 B 表的记录也达到。多流关联的一个关键点就是须要互相期待，只有单方都达到了，能力关联胜利。

上面通过例子（订单信息表和领取信息表关联）来阐明，如图示。

在下面的例子中，实时采集两张表的数据，每到来一条新数据时都在内存中的对方表截至以后的全量数据中查找，如果能查找到，则阐明关联胜利，间接输入；如果没查找到，则把数据放在内存中的本人表数据汇合中期待。另外，不论是否关联胜利，内存中的数据都须要备份到内部存储系统中，在工作重启时，能够从内部存储系统中复原内存数据，这样能力保证数据不失落。因为在重启时，工作是续跑的，不会从新跑之前的数据。

另外，订单记录的变更有可能产生屡次（比方订单的多个字段屡次更新），在这种状况下，须要依据订单 ID 去重，防止 A 表和 B 表屡次关联胜利；否则输入到上游就会有多条记录，这样失去的数据是有反复的。

以上是整体的双流关联流程，在理论解决时，思考到查找数据的性能，实时关联这个步骤个别会把数据依照关联主键进行分桶解决，并且在故障复原时也依据分桶来进行，以升高查找数据量和进步吞吐量。

3．维表应用

在离线零碎中，个别是依据业务分区来关联事实表和维表的，因为在关联之前维表的数据就曾经就绪了。而在实时计算中，关联维表个别会应用以后的实时数据（T）去关联 T - 2 的维表数据，相当于在 T 的数据达到之前须要把维表数据筹备好，并且个别是一份动态的数据。

为什么在实时计算中这么做呢？次要基于以下几点的思考。

数据无奈及时筹备好：当达到零点时，实时流数据必须去关联维表（因为不能期待，如果等就失去了实时的个性），而这个时候 T - 1 的维表数据个别不能在零点马上准备就绪（因为 T - 1 的数据须要在 T 这一天加工生成），因而去关联 T - 2 维表，相当于在 T - 1 的一天工夫里加工好 T - 2 的维表数据。

无奈精确获取全量的最新数据：维表个别是全量的数据，如果须要实时获取到当天的最新维表数据，则须要 T - 1 的数据 + 当天变更能力获取到残缺的维表数据。也就是说，维表也作为一个实时流输出，这就须要应用多流实时关联来实现。然而因为实时数据是无序的并且达到工夫不确定，因而在维表关联上有歧义。

数据的无序性：如果维表作为实时流输出的话，获取维表数据将存在艰难。比方 10:00 点的业务数据胜利关联维表，失去了相干的维表字段信息，这个时候是否就曾经拿到最新的维表数据了呢？其实这只代表拿到截至 10:00 点的最新状态数据（实时利用永远也不晓得什么时候才是最新状态，因为不晓得维表前面是否会产生变更）。

因而在实时计算中维表关联个别都对立应用 T - 2 的数据，这样对于业务来说，起码关联到的维表数据是确定的（尽管维表数据有肯定的延时，然而许多业务的维表在两天之间变动是很少的）。

在有些业务场景下，能够关联 T - 1 的数据，但 T - 1 的数据是不全的。比方在 T - 1 的早晨 22:00 点开始对维表进行加工解决，在零点达到之前，有两个小时能够把数据筹备好，这样就能够在 T 的时候关联 T - 1 的数据了，然而会缺失两个小时的维表变更过程。

另外，因为实时工作是常驻过程的，因而维表的应用分为两种模式。

全量加载：在维表数据较少的状况下，能够一次性加载到内存中，在内存中间接和实时流数据进行关联，效率十分高。但毛病是内存始终占用着，并且须要定时更新。例如：类目维表，每天只有几万条记录，在每天零点时全量加载到内存中。

增量加载：维表数据很多，没方法全副加载到内存中，能够应用增量查找和 LRU 过期的模式，让最热门的数据留在内存中。其长处是能够管制内存的使用量；毛病是须要查找内部存储系统，运行效率会升高。例如：会员维表，有上亿条记录，每次实时数据达到时，去内部数据库中查问，并且把查问后果放在内存中，而后每隔一段时间清理一次最近起码应用的数据，以防止内存溢出。

在理论利用中，这两种模式依据维表数据量和实时性能要求综合思考来抉择应用。注：本书中呈现的局部专有名词、专业术语、产品名称、软件项目名称、工具名称等，是淘宝（中国）软件有限公司外部我的项目的习用词语，如与第三方名称雷同，实属偶合。

连载：阿里巴巴大数据实际—数据开发平台 >>
连载：阿里巴巴大数据实际—实时技术 >>

数据中台是企业数智化的新基建，阿里巴巴认为数据中台是集方法论、工具、组织于一体的，“快”、“准”、“全”、“统”、“通”的智能大数据体系。目前正通过阿里云数据中台解决方案对外输入，包含批发、金融、互联网、政务等畛域，其中外围产品有：