阿里云实时计算Flink在多行业的应用和实践

本文涉及的产品
实时计算 Flink 版,5000CU*H 3个月
简介: 本文整理自 Flink Forward Asia 2023 中闭门会的分享。主要分享实时计算在各行业的应用实践,对回归实时计算的重点场景进行介绍以及企业如何使用实时计算技术,并且提供一些在技术架构上的参考建议。

摘要:本文整理自 Flink Forward Asia 2023 中闭门会的分享。主要分享实时计算在各行业的应用实践,对回归实时计算的重点场景进行介绍以及企业如何使用实时计算技术,并且提供一些在技术架构上的参考建议。内容分为以下四个部分:

  1. 业务需求变化推动架构演进

  2. 实时计算在各行业的应用与实践

  3. 从数据看实时计算在各行业的趋势

  4. 总结

一、业务需求变化推动架构演进

任何技术的发展都是随着业务需求而推动。那么随着业务技术的需求推动,是如何发展到当前的技术形态呢?

在早期,企业依靠数据分析和数据仓库查看到最近的数据,如昨天、一个月前乃至三个月前的数据。许多企业的数据仓库是基于像 MySQL、Oracle、DB2 这样的传统单机数据库系统搭建的。随着时间推移,企业对历史数据的分析需求增加,需要分析的数据也越来越多,时间跨度也扩大到了三年、五年,甚至十年,导致单机架构在这种海量数据分析需求面前也显得力不从心。因此,分布式数据库如 Teradata、Greenplum (GP) 应运而生,帮助解决在海量数据情况下企业快速数据分析的需求,并且解决了第二个问题:“大”和“快”的问题。 从2006 年 Hadoop 成为开源社区的顶级项目开始,企业大规模使用 Hadoop 来做离线分析,标志着数据处理能力的一个重要进步。
随着互联网技术的发展,传统的数据仓库已经不仅限于关系数据,可能来自于互联网的行为日志数据,也可能来自不同设备的终端时序数据,这些数据在传统数据仓库中没有办法基于 SQL、存储过程来分析,而是需要基于 MapReduce、 Spark 以及 Python 方式对数据进行预处理和分析。在这种情况下就需要一种新的系统 Hadoop,目前大多数企业已经在这个阶段过渡。后来业务需求对实质性的要求越来越高,需要的不再是 T+1 的数据,而是需要根据前一个小时、前一分钟、前一秒的业务动态来判断下一个角色。所以对时效性要求越来越高,这促使着现在的流计算技术发展,使Flink 成为企业的一个在实时计算的事实标准。

二、实时计算在各行业的应用与实践

接下来分享四个实时计算使用比较多的行业,分别是金融、汽车,交通物流以及零售行业。分享一下在这些行业场景中是如何使用大数据实时计算相关的技术,以及近几年实时计算使用的比例变化。

1. 金融行业

金融业在实时计算的应用里基本上处于百花齐放的状态。不仅可以收到实时推荐的消息、股票交易的动态变化等,而且除了这些情况外,金融机构还会做 To B 端企业服务和私募基金的相关服务。对大客营销需要针对性的监管报送,实时将企业、金融机构的风险提供给监管部门,这些都需要大量的实时计算技术。

接下来举两个行业场景的例子,金融行业是如何使用相关大数据实时计算技术的?下图是一个案例证券交易行为。

在当前股市中,对交易监控的实时性要求极高,主要是因为市场价格波动迅速,股民的交易行为需要得到即时的监管。例如,在实施注册制之前,如果股票的交易价格为 100 元,投资者可以挂出 110 元的买单。在极短的时间内,可能价格就会涨到 110 元,从而使投资者获得 10% 的收益。但注册制实行后,挂单价格的上限受到限制,不得超过当前卖出价格溢价的 2%,也就是说最高只能挂 102 元。这样的变化意味着对交易行为实施实时监控和告警,以及在必要时进行阻断变得更加重要。如果阻断措施延迟,可能会引发数据合规性问题。因此,为了确保合规并保护投资者的利益,对于交易行为的监控系统必须做到快速反应。

举个例子,在股市交易监控方面,各种订单数据,如股票的买入量、当前报价及股票代码,以实时数据的形式流入系统并进入消息队列。除了这些流式数据,还需要引入与所购股票相关的基本信息,比如客户购买的财报数据、昨日的涨停价和开盘价等。这些基础数据存储于 Hologres 中,以维表的形式存在,用于与流式数据进行关联。数据关联之后,再利用 Flink 对这些信息进行加工和判断分析。如果检测到用户在近几分钟内挂出的订单价格超过了当下价格的 2%,系统会立即采取阻断措施并发出告警。考虑到场景架构图中存在众多的风险和交易规则,我们采用基于复杂事件处理(CEP)的方法来实现风控规则,而上述只描述了其中一条规则。同时,还可能需要引入离线数据来补充用户信息。这些离线数据每天按照T+1模式更新,通过分析这些历史数据并将它们与实时数据结合,可以对交易情况做出更加细致的判断。

下面第二个案例是零售银行面向 c 端的用户推荐。

银行和许多金融机构会定期发布各种促销活动,包括针对股票和基金的活动。作为用户,当通过 APP 或 H5 页面点击参与活动时,就会生成一条实时触发的消息流。接下来,系统需要判断这个用户应该得到多少优惠券,并且通过积分奖励的方式鼓励用户完成购买,形成销售的闭环。为了处理这个流程,整个链路会使用 Flink+Hologres 来协助客户做处理。

2. 汽车行业

近年来,随着新能源汽车产业的快速发展,汽车行业对数据的依赖日益增加,数据量的增长速度非常迅猛。可以看到一个现象,在云上的多数企业 CPU 和内存的使用成本远远高于数据存储成本,在云上的来说存储相对廉价。然而,汽车行业的情况颇为独特,由于数据涌现速度极快,特别是新能源汽车产生的数据已经在云平台上造成存储成本超过计算成本的现象。

汽车行业从初期的研发制造、供应链、销售、再到对外的服务,整个链路都包含了众多的实时场景与应用。包括在研发阶段需要对研发过程的实时监控、研发参数的实时告警。在供应链环节,对零部件进行实时预警同样关键,每一个供应链环节都可能直接影响到一个企业的业务目标和销售业绩。在销售环节,针对C端用户的商品推荐和行为分析也极为重要。

另一个场景是在服务阶段,如何提供良好的汽车服务以促进二次销售也是企业需要关注的场景。下文将介绍一个重要的行业应用:新能源汽车的车联网场景。随着车辆上装配的摄像头、传感器和雷达数量的增多,这背后采集到的数据量也在相应增加。

我们有一个客户,每天要采集大约 42 亿条数据,采集频率是每秒一次。相比之下,在一年前他们可能是每天只采集一次数据。随后这个频率提高到了每10分钟一次,继而因为业务需求,他们需要将采集频率从原先的每 10 秒逐步过渡到每秒采集。此外,我们还有汽车行业的客户,现在已经需要达到每 500 毫秒采集一次数据。以 30 万辆运行中的车为例,如果每秒采集数据一次,就意味着每秒需要采集 30 万条数据。然而,这些数据与其他行业的数据有所不同,一条数据就可能包含多达 3,000 到 4,000 个字段的信号数据

在车联网场景中,前端设备可能是 TBOX 或 TSB 这样的车载平台,它们通常采集的是二进制数据。许多企业首要的工作是利用 Flink 将这些车载二进制信号数据转换成后续可进行分析的结构化数据,这是处理流程的第一步。接下来,他们可能会使用 Hologres 进行实时的在线分析服务。针对汽车行业高昂的存储成本问题,Hologres也推出了价格更低廉的存储产品,包括低频访问的存储解决方案,帮助客户在处理海量数据时实现存储分层,从而帮助降低整体成本。

下面是介绍新能源汽车行业,结合刚才的实时数据可以做的哪些场景。

在这一场景中,我们可以采集到多种车辆数据,包括车辆所处的车道、驾驶员是否双手握方向盘、车速以及车辆是左转还是右转等信息。通过分析这些数据,系统能够判断驾驶员是否存在危险驾驶行为。例如,如果一个驾驶员在五分钟内持续双手脱离方向盘,或者在高速公路上连续五分钟的速度超过 150 公里/小时,那么系统就会将其归类为危险驾驶,并可能采取相应措施向客户发出预警。

同时,还可以根据这些数据对用户进行画像。如果数据显示用户偏好激烈的驾驶行为,那么在下一次购车时,系统可能会向该用户推荐性能更强的车型。如今,无论是传统主机厂还是排名前十的新能源汽车制造商,超过 70% 的车联网平台都在运行于阿里云上。结合这些企业的实践经验,阿里云推出了一套面向车联网行业的推荐参考架构。许多领先的汽车厂家都按照这套架构实施其车联网平台。

下图左侧是实时架构,右侧是离线架构。

实时数仓与实时计算的主要区别在于数据的处理和管理方式。在传统的数仓中,数据通常会进行层次化处理,涉及到离线数据的不同层级,比如 DWD、DWS 和 ADS。然而,在实时计算中,进行层次化分隔较为困难,因为它缺乏统一的存储层次。例如,ODS 层的数据可能存放在 Kafka 中,加工后的 DWD 层数据可能放在 RDS 中,这些数据难以统一管理。目前,阿里云通过整合 Flink 和 Hologres 技术,使接入的数据在消息队列中存储,并经过 Flink 的处理转化成宽表格式,之后统一存放在 Hologres 中,实现了数据流的实时处理与分析。

很多业务部门早期将数据存放在消息队列中,但这样做无法执行查询,也无法使用 SQL 语句进行数据操作。现在,可以将宽表格式的数据直接存储在 Hologres 中,并且借助 Flink 按照离线数仓的层次化架构,加工形成指标数据后统一存放入 Hologres 引擎。将 Hologres 定义为面向业务的唯一数据出口,避免了对其他关系数据库和 Key-Value 数据库的依赖。将所有数据集中存储在 Hologres 中后,前端应用、报表和各种数据产品都能基于 Hologres 实现数据的统一访问与输出,这样不仅简化了数据架构还提升了数据处理的效率。

3. 物流行业

预计今年,许多物流企业采用实时计算的比例将超过50%。

物流行业在数据流转方面与零售行业相似,都是围绕着人、货和场所进行。一个显著特点是物流行业对位置信息的要求日益增高。用户在下单之后会时刻关注快递的位置,因此,物流企业开始围绕位置信息展开实时计算的数据加工与处理。数据的生成起始于用户通过手机APP下单或电话联系快递员上门这样的环节,从而形成一套订单信息。这些订单在物流企业内部经过分发处理后,转换为具体的运单信息。运单形成后,进一步贯穿于派送和签收等环节。在整个流程中,对链路时效性的要求越来越高,用户对数据更新的容忍度逐渐降低,希望能够实时、每秒钟都能看到最新的快递信息。

下面举几个简单的场景,第一个场景是大件物流。与小件快递不同,大件物流主要是做快运。

快运服务的一个特点是车辆类型的多样性,包括大、中、小型车辆,此外还有许多特定的标签,比如载重能力。例如,如果一个客户需要运输两吨重的物品,但是分配了一个能承载十吨重的车辆,这显然会有些浪费。背后的匹配逻辑相当复杂,因为有时两吨重的货物实际上可能因体积较大而需要更大的车辆。那么,该如何有效地进行车辆与货物间的匹配呢?这就需要通过数据对车辆和货物进行精确的标记,随后实时计算技术便可以根据用户货物的变化和位置变化进行合适的匹配与推荐。

接下来看第二个场景:

疫情期间所带来的挑战可能让人感受更为明显,比如一个企业负责从杭州到北京的大件物流运输。在这种情况下,可能会遇到运至某城市时发现该城市正处于疫情管控,无法通过。这样原本确定的物流单可能被迫取消,导致货主双方都面临一系列问题。为了解决这类问题,借助实时计算技术,司机可以实时上报自己的位置和其他相关信息,这通常需要硬件的支持;同时,货主端也能实时监控货物的状态变化。通过这种方式,能够有效提高整个物流过程的效率和响应时效。

以下就是围绕刚才讲的两个场景,物流行业场景的整个技术架构图。

总体来看,涉及的数据包括订单数据、货源数据、司机数据以及用户会员数据等。这些数据如何进行有效匹配呢?在这样的数据架构背后,不仅包括了实时的流消息,还涉及到离线的用户标签数据、车辆的静态维度表数据等多种数据类型。利用 Flink 技术,可以综合处理这些不同来源的流数据和静态维表数据进行必要的加工处理。加工后的数据可以应用于多种业务场景,例如智能匹配车辆与货物、实时监控路线以及提供最优路线推荐等,有效地优化物流配送的效率和服务质量。

针对这个场景,我们提出了一个参考架构。前端的埋点数据、用户端数据以及 APP 上报的数据将会统一推送到消息队列 Data Hub 中。数据一旦推送到 Data Hub,就会通过 Flink 进行实时的接入和加工处理。处理完成的数据随后会统一存储到 Hologres 中。前端应用可能直接从 Hologres 中执行 OLAP 分析,或者在这基础上进行实时决策支持。 Hologres 可以提供实时的运力匹配关系、供需动态以及实时轨迹分析等关键业务信息,这些功能在需要快速响应市场变化和用户需求的业务场景应用中特别重要。在架构的右侧,主要针对的是离线场景,同样会将实时处理的数据写入离线的对象存储中,以便用于离线数据的进一步补充和处理。

4. 零售行业

零售行业是最早开始采用实时计算的行业之一。阿里巴巴在最初开展双11大促活动时,就已经能够通过大屏实时展示当前的销售动态数据。企业的决策者们需要了解当前的销售情况,并依据这些实时数据进行相关的决策。接下来,我会举两个具体的例子来说明。

第一个例子是,在特别是像双十一、双十二这样的大型促销中,许多零售企业会准备大量促销活动。假设企业需要准备 1,000 万优惠券,它们需要对这 1,000 万的优惠券的动向进行实时监控。接着,根据优惠券的发放情况,需要进行动态的调整。如果在最开始的五分钟内 1,000 万优惠券就被抢光了,企业需要立刻决策是否再追加 1,000 万以增加用户转化率?这些都是在营销的全过程中,包括营销前、营销中、营销后,业务流程中需要考虑的因素。

在技术实现方面,离线场景涉及到大量的历史数据,包括用户的行为、他们偏好的服装类型、年龄和性别等信息,这些都会被储存在历史数据平台上。当出现购买信息或潜在的点击行为时,基于 Flink 引擎可以帮助实时作出判断。它能预测用户是否可能在接下来的两分钟内下单,并且识别出哪种优惠券对用户来说更有吸引力。整个过程需要 Flink 利用技术手段来进行评估和决策。下图是实施营销的一个决策方案架构:

下面是第二个场景:

很多企业依赖实时数据分析来强化其商业决策,这需要能够迅速向企业决策者和各个业务部门提供关键信息。例如,精确追踪某个用户在特定页面的停留时间及其带来了多少转化率。基于一款提供相关查询和分析的平台,简而言之,用户需要进行查询,尽管这背后可能涉及海量的数据,可能是几亿甚至几十亿条记录。那么如何解决这一挑战呢?解决方案是通过 Hologres。我们可以看到,底层的数据被存储在 Hologres 中,并且可能存在各种检索条件。基于这些检索条件系统需要快速地给业务提供决策支持和响应能力。比如,可能需要查询特定品类、用户当前行为、某个商品占位信息或广告投放的效率等。基于多样的检索条件,Hologres 提供的 OLAP 查询能力可以满足这些需求,从而实现客户对于数据的快速查询。

下面是在线做电商的一个客户,基本上几十 TB 级的数据。自助分析的响应速度控制在 3 秒以内,基本上 99% 的查询都是在 3 秒以内响应,业务方认为这样的速度能够非常快捷地帮助他们提高决策效率。

零售行业也提出了一个参考架构。

在零售行业中,数据仓库通常包含了如商品、会员、销售、售后和运营等多个标准化领域,这些分域和层次结构一般来说都非常规范和通用。基于这样的架构,可以借助阿里云的 MaxCompute 来执行离线数据仓库的分层处理。对于实时计算需求,则可以通过结合 Flink 和 Hologres 来实现实时数据仓库的操作,以及构建统一的架构。至于调度管理层,可以使用 DataWorks 来提供统一的工作流程调度和数据加工服务。这是一个在零售行业常见的推荐架构。上述四个方面是对实时计算依赖性较高且使用效果良好的行业中的典型应用场景。

三、从数据看实时计算在各行业的趋势

根据阿里云发布的公有云数据报告,中国大约有 50% 的大数据用户选择使用阿里云服务,拥有数万名大数据客户。从这些客户数据中做出的简单分析显示,在四年前的 2020 年,实时计算的普及率还相对较低,基本都在 10% 以内。大部分企业当时仍然主要依赖于 T+1 的小时级离线分析。然而,预计下一年,金融行业实时计算的使用比例将超过 25%,物流行业的比例可能会超过 50%。因此,实时计算成为未来发展的一个关键考虑点。整个行业实时计算的用例预计都会超过 30%,这表明实时计算的普及率正处于一个迅速上升的阶段。

四、总结

作为阿里云计算平台的成员之一,除了今天讨论的实时计算技术之外,还基于服务数万+客户的经验,沉淀出了面向未来的一套云上数据仓库参考架构。这一架构的设计旨在为客户提供一套高效、可靠、可扩展的数据处理与分析平台,以支撑大数据、人工智能和数据仓库等多种复杂应用场景。

在未来的交流和分享中,我们将基于这一推荐的参考架构,深入探讨如何有效地利用大数据技术、人工智能能力以及数据仓库功能,来帮助客户解锁数据价值,推动业务成长和创新。通过这些互动,我们希望与客户共同探索和实践最佳的云计算解决方案,以满足客户不断变化的业务需求。


更多内容

img


活动推荐

阿里云基于 Apache Flink 构建的企业级产品-实时计算 Flink 版现开启活动:
新用户复制点击下方链接或者扫描二维码即可0元免费试用 Flink + Paimon
实时计算 Flink 版(3000CU*小时,3 个月内)
了解活动详情:https://free.aliyun.com/?utm_content=g_1000395379&productCode=sc

retouch_2024070417440476.jpg

相关实践学习
基于Hologres轻松玩转一站式实时仓库
本场景介绍如何利用阿里云MaxCompute、实时计算Flink和交互式分析服务Hologres开发离线、实时数据融合分析的数据大屏应用。
Linux入门到精通
本套课程是从入门开始的Linux学习课程,适合初学者阅读。由浅入深案例丰富,通俗易懂。主要涉及基础的系统操作以及工作中常用的各种服务软件的应用、部署和优化。即使是零基础的学员,只要能够坚持把所有章节都学完,也一定会受益匪浅。
相关文章
|
1月前
|
存储 分布式计算 流计算
实时计算 Flash – 兼容 Flink 的新一代向量化流计算引擎
本文介绍了阿里云开源大数据团队在实时计算领域的最新成果——向量化流计算引擎Flash。文章主要内容包括:Apache Flink 成为业界流计算标准、Flash 核心技术解读、性能测试数据以及在阿里巴巴集团的落地效果。Flash 是一款完全兼容 Apache Flink 的新一代流计算引擎,通过向量化技术和 C++ 实现,大幅提升了性能和成本效益。
1237 73
实时计算 Flash – 兼容 Flink 的新一代向量化流计算引擎
|
1天前
|
消息中间件 JSON 数据库
探索Flink动态CEP:杭州银行的实战案例
本文由杭州银行大数据工程师唐占峰、欧阳武林撰写,介绍Flink动态CEP的定义、应用场景、技术实现及使用方式。Flink动态CEP是基于Flink的复杂事件处理库,支持在不重启服务的情况下动态更新规则,适应快速变化的业务需求。文章详细阐述了其在反洗钱、反欺诈和实时营销等金融领域的应用,并展示了某金融机构的实际应用案例。通过动态CEP,用户可以实时调整规则,提高系统的灵活性和响应速度,降低维护成本。文中还提供了具体的代码示例和技术细节,帮助读者理解和使用Flink动态CEP。
129 2
探索Flink动态CEP:杭州银行的实战案例
zdl
|
1月前
|
消息中间件 运维 大数据
大数据实时计算产品的对比测评:实时计算Flink版 VS 自建Flink集群
本文介绍了实时计算Flink版与自建Flink集群的对比,涵盖部署成本、性能表现、易用性和企业级能力等方面。实时计算Flink版作为全托管服务,显著降低了运维成本,提供了强大的集成能力和弹性扩展,特别适合中小型团队和业务波动大的场景。文中还提出了改进建议,并探讨了与其他产品的联动可能性。总结指出,实时计算Flink版在简化运维、降低成本和提升易用性方面表现出色,是大数据实时计算的优选方案。
zdl
157 56
|
1月前
|
SQL 运维 数据可视化
阿里云实时计算Flink版产品体验测评
阿里云实时计算Flink基于Apache Flink构建,提供一站式实时大数据分析平台,支持端到端亚秒级实时数据分析,适用于实时大屏、实时报表、实时ETL和风控监测等场景,具备高性价比、开发效率、运维管理和企业安全等优势。
|
2月前
|
运维 搜索推荐 数据安全/隐私保护
阿里云实时计算Flink版测评报告
阿里云实时计算Flink版在用户行为分析与标签画像场景中表现出色,通过实时处理电商平台用户行为数据,生成用户兴趣偏好和标签,提升推荐系统效率。该服务具备高稳定性、低延迟、高吞吐量,支持按需计费,显著降低运维成本,提高开发效率。
84 1
|
2月前
|
运维 监控 Serverless
阿里云实时计算Flink版评测报告
阿里云实时计算Flink版是一款全托管的Serverless实时流处理服务,基于Apache Flink构建,提供企业级增值功能。本文从稳定性、性能、开发运维、安全性和成本效益等方面全面评测该产品,展示其在实时数据处理中的卓越表现和高投资回报率。
|
3月前
|
运维 数据处理 数据安全/隐私保护
阿里云实时计算Flink版测评报告
该测评报告详细介绍了阿里云实时计算Flink版在用户行为分析与标签画像中的应用实践,展示了其毫秒级的数据处理能力和高效的开发流程。报告还全面评测了该服务在稳定性、性能、开发运维及安全性方面的卓越表现,并对比自建Flink集群的优势。最后,报告评估了其成本效益,强调了其灵活扩展性和高投资回报率,适合各类实时数据处理需求。
|
4月前
|
SQL 消息中间件 Kafka
实时计算 Flink版产品使用问题之如何在EMR-Flink的Flink SOL中针对source表单独设置并行度
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
2月前
|
运维 数据处理 Apache
数据实时计算产品对比测评报告:阿里云实时计算Flink版
数据实时计算产品对比测评报告:阿里云实时计算Flink版
|
3月前
|
存储 运维 监控
阿里云实时计算Flink版的评测
阿里云实时计算Flink版的评测
87 15

相关产品

  • 实时计算 Flink版