Flink 实时湖仓,为汽车行业数字化加速!
摘要:本文整理自阿里云计算平台产品专家李鲁兵(云觉)老师在阿里云实时计算 Flink 产品介绍中的分享。本次分享主要面向汽车行业场景的专项介绍,内容分为以下四个部分:
洞察趋势:市场浅谈(以汽车行业为例)
典型大数据架构分析(以汽车行业为例)
产品市场地位及能力解读
典型落地客户案例(以汽车行业为例)
一、洞察趋势:市场浅谈(以汽车行业为例)
中国新能源汽车市场快速增长
新能源汽车行业作为国家新智生产力方向之一,行业呈现飞速发展态势。据统计,预计到 2025 年,将有 1300 万台新能源车在线运行,从 2022 年到 2026 年,新能源车的复合增长率预计将达到 35.1%,这表明该行业正处于一个高速发展的阶段。车辆规模增长对大数据系统提出了更高要求,具备实时、高性价比的大数据系统,能更好支撑汽车行业实现数字化和智能化发展目标。
数据实时化是汽车行业大数据应用的重点方向之一,在线采集是实时处理的最大场景。
在汽车行业中,在线数据采集是数据处理的最大场景。针对整个汽车行业,我们进行了多种场景的分析,主要包括销售/经营、车联网以及自动驾驶。以下仅列举了一些典型场景,其他与车辆相关的应用场景在此不做详细展开。
销售/经营:销售经营方面与其他零售行业比较类似,涉及门店流量监控、指标监测、用户画像圈选、客户满意度评估以及售后维护等方面。此外,还包括供应链管理在内的各种数据应用。
车联网:车联网主要利用车辆传感数据和位置信息进行应用。在预测性维护、远程诊断、基于位置的应用、车辆统计以及 OTA 在线更新等方面,车联网都有广泛的应用。
自动驾驶:此外,还有自动驾驶相关的业务,包括辅助驾驶、高精度地图、安全预警等应用。
数据海量、低密度、峰谷明显是汽车大数据的典型特点,实时化、低成本是高质量发展的业务要求。
上图展示了我们对汽车行业客户场景特点的画像。第一个关键词:海量。随着新能源汽车市场竞争的加剧,新能源汽车变“卷”。如今对实时高效的数据处理需求变得更加迫切,同时也需关注成本控制。每辆车每分钟至少采集 400KB 的数据,即使是 10 万级车辆同时在线,也是一个非常庞大的数据量,如何处理海量数据是一个巨大的挑战。
第二个是数据价值密度低。单辆车采集的数据字段超过 1000 个甚至达到 3000 个以上。在这些字段中,数据的时效性和有效性各不相同,部分数据在部分时间段的利用率相对较低。因此,从海量数据中挖掘有价值的信息变得更加具有挑战性。
第三个是峰谷明显。出行需求跟时间段有密切关系,呈现明显的峰谷特点。
我们可以看到,车辆上的一些数据对于实时化要求非常高。业务上希望在数据上传后,能够进行实时解析。在数据应用方面,也希望能够实现实时或近实时的业务应用。
在自动驾驶的场景中,客户也会更加关注实时化,特别是预警功能。他们期望能够在秒级时间内获取车辆自动驾驶相关的统计数据。在销售或营销场景中,则期望、数据统计和分析、在线营销数据支持等能够尽量实现实时化。
二、典型客户大数据架构分析(以汽车行业为例)
接下来是典型的大数据架构分析。由于汽车业务整体非常复杂且庞大,我在这里整理了一个参考的业务架构图。需要注意的是,不同的客户和厂商可能有各自的业务特点,因此会有不同的架构设计。这张架构图仅作为一个参考。
1. 整体业务架构
这张架构图分为四层:
数据采集层:最大的数据显示来源是车辆本身。车辆的数据主要通过车载终端的埋点数据采集,这部分数据量非常大。此外,车联网相关的厂商或运营商也会有自己的用户端 APP 或应用系统,这些系统中的埋点数据也是一个重要的数据来源。同时,在生产研发和供应链环节中,也存在各种类型的数据。
数据层:基于原始数据采集,对数据进行加工处理,形成分域分主题的数据。这些主题域的数据包括用户数据、车辆数据、三电数据等。通过这种方式,我们能够将大量的原始数据组织成特定主题的数据域,以便后续的分析和应用。
应用层:典型的场景包括移动端、PC 端和大屏端,因此车辆相关的一些应用场景对于各个终端的覆盖非常全面。在销售、财务、研发、质量和供应链等场景下,都有非常丰富的应用。除了这些应用之外,我们还可以看到车辆数据和经营销售等相关的数据。如果我们希望高质量地支撑业务,就必须制定一些标准,因此还存在标准层。
标准层:这一层规定了数据战略、数据架构、数据安全、数据质量、数据标准、数据生命周期、数据指标以及数据治理等方面的标准。
2. 典型技术方案
在技术架构上,我们可以看到有两个典型的技术架构。
(1)Lambda 架构
第一个是业内常用的架构,称为 Lambda 架构。其典型特点是离线和实时处理分为两条独立的链路。在这个架构下,我进行了一些简化,离线计算使用的是 MaxCompute,实时计算则使用的是 Flink + Hologres。这只是一个参考架构,还有其他的数据和技术选型,这里不再赘述。Lambda 架构的典型特征是两条链路独立运行,实时数据和离线数据相互之间不能互通和复用。
(2)实时湖仓一体化架构
另一个架构是最近在数据海量增长和成本压力下,厂商们开始逐步采用的新架构,即实时湖仓架构。其典型特点是以 Flink 实时计算流批一体化引擎为核心,加上 Paimon 统一流批存储,构建流批计算存储一体化方案,在数据口径、开发语义、数据复用、流批计算等可以做到更好的统一,从而提升系统应用的效率。该架构的底层通常使用对象存储 OSS,承载海量数据存储的同时也能兼顾性价比。在数据分析处理方面,可以使用 StarRocks 或 Hologres 进行数据查询分析及相关服务,兼顾高效率查询分析的需求。因此,这套架构方案在汽车行业中逐步被更多的客户所认可和实施。
三、产品市场及能力解读
“阿里云位居 IDC MarketScape 中国实时湖仓评估领导者”,这一评价来自于 IDC 中国实时湖仓市场 2024 年厂商评估报告,该报告中指出,阿里云在实时湖仓产品能力上处于国内非常领先的地位。
同时,我们对这一场景也进行了核心洞察。首先,我们看到,湖仓架构从最初的广泛讨论和试验,发展到现在业内和企业的认可以及规模化落地,这已是非常明确的趋势。其次,湖仓架构开源开放,兼容流计算、批计算和 OLAP 等计算范式,这对于汽车行业的用户来说更加开放和灵活。在数据的新鲜度方面,我们希望湖仓架构能够提供更好的实时性支持。此外,围绕湖仓架构,在元数据管理、数据安全和数据质量治理上,将成为后续企业应用的重点。
1. 实时化过程
再回到大数据的实时化过程。我们可以看到,当前有几个明显的趋势:公共云、实时化、AI 化。汽车行业现在非常拥抱公共云,因为在云上可以获得广泛的大数据和 AI 处理能力,也可以更好的满足行业飞速发展带来的基础设施快速增长的需求。今天我们重点介绍实时计算 Flink 产品,因此将重点关注实时化方向。
整个数据架构的发展经历了三个主要阶段:
(1)第一个阶段:引入数据仓库,同时引入数据湖的概念,基于 HDFS 构建数据湖。
(2)第二个阶段:融入湖仓方案。在这个阶段,我们看到许多开源的湖仓架构方案,包括 Hudi、Iceberg 等。然而,这些开源方案主要面向批量计算场景设计,因此在实时化支持上相对较弱。
(3)第三个阶段:进入 3.0 时代,我们期望原生支持湖仓的实时化和 AI 化。基于 Apache Paimon 和实时计算 Flink 产品,我们构建了实时湖仓的底层架构,推动了这一阶段的快速发展。
2. 整体方案
具体来看,这个方案以实时计算 Flink 产品为核心引擎,构建了一个实时湖仓的整体架构。数据来源方面,车联网会涉及车载数据的采集,同时还包括一些应用上 Database 的数据采集。我们可以通过 Flink 以流批处理的方式,将数据采集到 Apache Paimon Table 中。基于这些 Table,可以使用 Flink 进行流批计算,进一步加工后续下游的分层数据。在计算层面,这就是整个流程。而在数据分析层和查询层,我们可以使用 StarRocks、Hologres 等作为核心的 OLAP(在线分析处理)引擎,对数据进行查询和分析。
这套完整的方案基于低成本存储构建了 Paimon Lakehouse,并深度集成了 Flink,实现了全链路的实时化。其核心优势在于低成本和全链路实时化的特点,同时实现了流批存储和流批计算的统一。其中,流批存储是基于 OSS(对象存储服务)构建的 Paimon Table,而流批计算则由 Flink 支持流和批的计算。同时,这个平台具备数据管理、调度和临时查询等相关能力,并且该方案开放支持多引擎。适用的场景包括离线方案的优化、全链路实时化的加速、全实时链路成本的降低,以及流批存储和计算的统一等。
具体来说就是 Flink 与 Paimon 的结合能够构建一个低成本的实时化方案。在大数据架构的选型中,我们通常会面对一个“不可能三角”,即在性能、新鲜度和成本之间进行权衡。实时湖仓方案,旨在尽量在这三者之间取得一个较好的“Trade-off”。具体来说,我们希望在分钟级别的数据新鲜度条件下,实现数据实时流动,同时保持低成本。此外,对于加工处理后的数据,我们期望能够实现秒级查询响应。
这套实时湖仓方案不仅能够覆盖传统 Warehouse 的 T+1d 时效性及 Lakehouse 的 T+1h 的场景,同时还能提供分钟级数据新鲜度,让系统的时效性提升一个量级。
另一个显著特点是全链路的实时化流动。我们知道,数据的实时化处理旨在实现端到端的实时流动。在我们的方案中,可以实现全链路的实时化流动,支持实时更新,分钟级别的数据新鲜度,以及秒级的查询响应。因此,在整个流程中,我们能够达到全链路实时化流动的效果。
在具体能力方面:
(1)数据摄取:通过 Flink CDC(Change Data Capture),可以实现全量和增量数据的统一处理,并支持 Schema Evolution 等功能。
(2)数据存储:我们基于对象存储构建了 Paimon 的 Table,在此基础上可以实现 Upsert(更新插入)和 Partial-Update(部分更新)等功能。这些功能能够覆盖和支持传统 Lakehouse 架构的需求。
(3)数据计算:以 Flink 计算引擎为核心,支持流式和批量计算。同时,我们也开放支持其他计算引擎,以便让用户基于自己的业务场景进行数据计算和处理。
(4)数据查询:我们开放支持多种 OLAP 引擎,可以通过外表的方式直接查询,实现秒级响应。同时,也支持直接 upload 到对应的 OLAP 引擎,以加速查询进程。这其中既有低成本方案,也有高效快速的方案,用户可以灵活选择。
3. 实时入湖入仓
(1)简化操作
在实时入湖入仓的场景下,我们能够实现非常简便的操作方式。可以通过 CTAS 的方式分库分表合并同步,通过 CDAS 的方式整库同步。过程中我们所有加工的数据,可以通过 SQL Script(临时查询)Select 对应的数据去做查询分析。
(2)兼容表变更
同时,我们的方案也支持表变更(Schema Evolution),这一功能可以有效兼容上游数据表的 Schema 变化。
(3)多种过程操作
实时入湖入仓,还可以支持多种过程操作,包括 Select、Where、Group by、Join、Top-N、Insert 等这样一些方式,可以有效的去处理上下游的数据。
4. 低成本构建流批存储
我们基于 OSS 构建的 Paimon Table 存储方案,具备低成本和高性价比的特点。基于 OSS 或 HDFS 等低成本存储方案进行构建,帮助用户在应对海量数据存储的同时还能保持更好的性价比。此外,采用 LSM Tree 结构,使得读写性能能够得到很好的平衡。基于这些能力,我们的方案具备低延时、低成本、流批存储和易集成等优势。
在支持数据流批计算方面,Paimon 创新的 Changelog 机制支持下游计算引擎订阅,让数据实时流动,这是这套方案区别于其他湖仓方案的另一个非常显著的特点。基于 File Store 和 Log Store 两条存储路径,提供更新(Update)和删除(Delete)操作,更好地支持数据流计算和批计算。同时,我们支持列格式的存储和压缩优化,提升数据存储的效率。
5.阿里云实时计算 Flink 产品丰富的企业级能力
(1)在数据摄取上,它支持 Flink CDC,可以实现全量和增量数据一体化处理,包括整表合并和分库分表同步。同时,我们还计划推出新的开发方案,例如基于 Yaml 的开发方式,以更接近自然语言的方式进行数据摄取的开发。在数据连接方面,平台内置了三十多种主流数据产品的连接器,并且支持自定义 Connector 或 Format 的方式进行数据连接和开发。
(2)在任务开发和调度测试方面支持流批计算、多语言、多版本以及动态 CEP,还提供了统一元数据管理(Catalog)。此外,实现了开发和生产环境的隔离,并提供了测试数据的管理和生成调试功能。我们还支持临时查询功能,帮助数据工程师在开发过程中进行基础的数据查询和分析。同时平台还可以对外提供开发环境,支持客户平台对于阿里云实时计算 Flink 产品的集成。
(3)在运维方面,我们支持批任务的调度,工作流可以帮助简化批流任务的运行和管理。我们还具备数据血缘分析、智能诊断、自动调优、资源队列管理、状态管理和变量管理等功能。
以上就是我对于 Flink 产品以及基于 Flink + Apache Paimon 构建的实时湖仓方案介绍。
四、典型落地客户案例(以汽车行业为例)
接下来我们就看一些具体的落地的场景。当然我们还是以汽车场景为例。
在车联网的应用中,以 Flink 和 Apache Paimon 为核心构建了一套实时湖仓方案,数据存储在 Apache Paimon on OSS 上,计算引擎选择阿里云实时计算 Flink 或 EMR-Spark 进行实时数据或批数据计算,查询分析层采用 StarRocks 作为查询分析引擎。整体架构从 Flink CDC 开始,同步数据到 Paimon 表存储,通过 Flink 进行数据流批计算,通过 EMR-Spark 进行大量批计算。架构整体简洁、全链路可实时化流动、流批统一、查询可加速,帮助用户实现高性价比实时化升级,提升了业务数据实时获取的能力。
最后,我们还有一个附录,列出了一些车辆的数据类型作为参考。这些数据类型包括整车数据、驱动电机数据、燃料电池数据等。这个附录仅供参考。
以上就是我今天分享的全部内容。如果大家希望详细了解,可以扫码参与试用,同时也可以查看实时计算 Flink 版产品的详情页,了解具体的产品功能。感谢大家的参与,期待我们在线下进行更深入的交流。
评论