摘要：本文整理自阿里云计算平台产品专家李鲁兵（云觉）老师在阿里云实时计算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版产品的详情页，了解具体的产品功能。感谢大家的参与，期待我们在线下进行更深入的交流。
