php学院网站源码,做网站的格言,京津冀协同发展四区指的是,泰州免费网站建站模板来源#xff1a;数智化转型俱乐部
数据价值是具有时效性的#xff0c;在一条数据产生的时候#xff0c;如果不能及时处理并在业务系统中使用#xff0c;就不能让数据保持最高的“新鲜度”和价值最大化。
相对于离线批处理技术#xff0c;流式实时处理技术作为一个非常重…来源数智化转型俱乐部
数据价值是具有时效性的在一条数据产生的时候如果不能及时处理并在业务系统中使用就不能让数据保持最高的“新鲜度”和价值最大化。
相对于离线批处理技术流式实时处理技术作为一个非常重要的技术补充在阿里巴巴集团内被广泛使用。
在大数据业界中流计算技术的研究是近年来非常热门的课题。
业务诉求是希望能在第一时间拿到经过加工后的数据以便实时监控当前业务状态并做出运营决策引导业务往好的方向发展。比如网站上一个访问量很高的广告位需要实时监控广告位的引流效果如果转化率非常低的话运营人员就需要及时更换为其他广告以避免流量资源的浪费。在这个例子中就需要实时统计广告位的曝光和点击等指标作为运营决策的参考。
按照数据的延迟情况数据时效性一般分为三种离线、准实时、实时
离线在今天T处理N天前T-NN≥1的数据延迟时间粒度为天。准实时在当前小时H处理N小时前H-NN0如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过期的形式让最热门的数据留在内存中。其优点是可以控制内存的使用量缺点是需要查找外部存储系统运行效率会降低。例如会员维表有上亿条记录每次实时数据到达时去外部数据库中查询并且把查询结果放在内存中然后每隔一段时间清理一次最近最少使用的数据以避免内存溢出。
在实际应用中这两种形式根据维表数据量和实时性能要求综合考虑来选择使用。注本书中出现的部分专有名词、专业术语、产品名称、软件项目名称、工具名称等是淘宝中国软件有限公司内部项目的惯用词语如与第三方名称雷同实属巧合。 原文链接 本文为阿里云原创内容未经允许不得转载。
