11 月 1 日，在以“数据驱动，共赢未来”为主题的 2024 智协慧同闭门用户沙龙暨智能汽车数据场景与应用研讨会上，智协慧同 CTO 谢宁分享了智协慧同 EXD 车云一体和存算一体的计算框架，详细介绍了智协慧同车云产品的发展历程与未来方向。以下为谢宁的演讲实录：打造车云一体的新一代"车计算"平台
感谢大家参加今天的用户大会，我想快速回顾一下 EXD 产品的历史，介绍我们整个产品的理念，以及为什么我们会认为未来的汽车是“车云一体”的计算平台。在这个过程中，我也想和大家一起探讨几个“灵魂发问”，这不仅是我们对自己的深刻思考，也是我们对行业未来趋势的思考。然后我会分享我们如何实现真正的存算一体、算力下沉，使数据架构成为未来汽车的重要组成部分。2017 年，我们推出了第一代 EXD 产品。可能在座有少数客户还记得这个最早的页面。最初的 EXD 是一个专门为汽车打造的数据分析产品，与今天的产品蓝图已经完全不同。当时为什么要做这个产品？我们注意到机器数据，特别是汽车数据的快速增长趋势，同时看到汽车行业在特斯拉的引领下，在芯片领域发生了巨大的变革。我们的初衷是帮助客户更好地利用这些数据。然而，随着在行业中的深入，我们很快意识到现实远比想象中复杂。与客户沟通时发现，大多数客户仅仅拥有一些基础数据，与我们设想的能够为业务带来实际价值的数据应用还有很大差距。因此，我们迅速开始帮助客户采集高精度数据，协助他们构建一套真正能够驱动架构和业务发展的数据体系。我们深入汽车行业，承担起“脏活累活”，帮助客户将数据采集频率从原来的 30 秒、15 秒、10 秒甚至 1 秒，提升到毫秒级。毫秒级的高精度数据可以支持任何业务需求，赋能客户的运营和决策。我们率先在汽车行业提出，数据应在车与云之间无缝流转，实现真正意义上的“车云一体”。尽管现在许多厂商也在谈论车云一体，但我们认为他们的理解还停留在“车是车、云是云”的阶段，依然将两者视作相互独立的个体。通常情况下，他们会在车上和云上分别部署代码，通过 MQTT 或 HTTPS 等机制来实现数据的传递，但这只是将车视为一个功能载体，而未能实现车与云之间无缝衔接的计算节点。我们认为，这样的方向无法满足未来发展的需求。未来的汽车一定是同样具备强大算力的节点抽象，是车云一体的。关于车和云的未来，我想和大家一起探讨几个“灵魂发问”：首先，今天的汽车已经开始比拼算力，进入了 TOPS（每秒万亿次计算）的竞争时代。在这样的背景下，车和服务器之间真的还有本质区别吗？如果车用的芯片是四核、八核，拥有 100TOPS、200TOPS 的算力，那么它与服务器的差异又在哪里？第二个问题是，当百万台车的芯片连接到网络时，这种车载计算与 2000 年亚马逊推出的早期云计算还有本质的不同吗？尽管今天的汽车网络速度可能不及云，但随着技术发展，这一短板也会逐渐被弥补。我们很快会看到，与当年云计算被质疑相比，今天的汽车算力架构会因硬件、芯片、存储、网络速度的进步而发生天翻地覆的变化。第三个问题，当大模型技术上车后，车企如何利用这些算力资源？目前，车上的芯片利用率实际上很低，车辆 90%的算力时间是闲置的。我们能否将这些闲时算力释放出来，为更有价值的应用服务？谁能实现这一点，谁就能在未来占据主导地位，把车变成一个算力“金矿”，为自己和整个行业创造价值。最后，当车和云都具备相似的算力，并在网络上实现了算力抽象时，是否可以联合计算？事实上，今天已有客户向我们提出类似的问题：当我有百万辆车的数据时，任何一个在百万辆级别的计算操作都将消耗巨大的算力，如何降低这部分成本，释放更多算力？对此，我们将与客户共同打造未来的车云双平台。进入 2024 年，我制作 PPT 时的第一印象就是框框变多了。和最初简单的两个、三个框相比，如今我们的 PPT 上出现了大量的框框。我们技术人做 PPT，框框越多越能体现出产品的丰富性与复杂性，意味着功能越多、产品越多，能为客户带来的价值也越多。从最初在车端为客户提供边缘计算和数据处理存储，到如今我们开始涉足控制功能，甚至扩展到云端，提供历史数据分析和存储，还能引入客户的第三方业务合作。我们从灵活的数据采集起步，现在也在与客户合作开发诊断应用，并共同探索智能大模型的应用。在车端，我们推动算力下沉，与合作伙伴一起探索如何实现存算一体，不仅限于诊断和标定，而是将我们的价值渗透到更多领域。这一路的发展是基于我们一贯的理念，随着行业的发展而逐步前行，未来，我们还会做得更多。接下来，我想跟大家分享一下我们未来的蓝图和愿景。我们的目标是构建一个全栈的数据驱动体系，这是从 2018 年开始我们就与客户探讨并推进的。最初，我们帮助客户实现数据的采集，这是我们与客户共同打造的第一层能力。接下来，我们支持客户的数据加工、数据闭环，实现数据的深度价值，最终目标是建立一个完整的生态开发体系。这一路上，我们始终坚持最早的四层理念，通过一个又一个客户的实际应用不断打磨和完善。到今天为止，我们只是完成了“长征”的第一步。展望未来 20 年，我们希望能够伴随行业发展，将这一套完整的理念真正意义上在我们的产品架构和与客户的合作中完整体现出来。为什么在今天的行业中，大家都在谈“车云一体”，却还没有实现真正意义上的车云一体呢？过去我们一直将车和云视为独立的个体，没有深入回答这个本质问题。举个例子，假设我们要在百万辆车上监控一个简单信号，比如某个信号从 0 跳变到 1。这样的需求在行业中非常普遍，通常做法是将几千个信号的数据从车端传到云端，进行存储和计算分析。对客户来说，这就带来了高昂的成本，每年几百万的存储和算力成本逐年累积。因此，客户面临一个普遍的问题：如何更好地控制这些成本？能否让算力更经济实用？能否实现车云真正意义上的联合计算？比如，能否将一部分计算直接放在车端完成，再将结果传回云端进行汇总？目前，尽管可以通过编写代码实现某些计算在车端执行，但这种方式费时费力，对每个分析需求都要定制，成本很高。为了解决这个问题，我们计划在明年推出 EXD 的全新产品，构建真正意义上的车云一体联合计算框架。这个框架可以自动将百万辆车的复杂计算任务分摊到每辆车上，完成计算后再在云端汇总，打破车云的分离，真正意义上实现Serverless。这样，车和云的算力都变成一个抽象的无状态节点，可以在批量计算和实时计算中灵活应用。我们过去的产品已支持在云端进行批量计算、在车端进行实时计算，而明年开始，全新的车云一体、批流一体框架将打破这些壁垒。车端将能够利用历史数据进行闲时和历史计算，也可以根据实时数据进行实时计算，客户可以根据业务需求自由选择。对于实时性要求高的计算，采用实时计算；对于计算量大但对实时性要求不高的，可以放到历史计算中，充分发挥车端算力。许多客户的车辆在运行时只能分配 5%-7% 的算力给 EXD，但在停车时，车端的全部算力其实可以被利用。这也是我们前文提出的“灵魂发问”的意义所在：如果汽车90%的闲置时间都能释放算力，它不就是一台“矿机”吗？明年，EXD 的全新车云一体架构将实现流批一体、联合计算，彻底打破车和云的边界。这正是我们始终坚持的理念：未来的汽车将成为服务器的抽象节点，不再只是一个数据收集节点，而是一个具备强大算力的车计算平台和网联计算节点。大部分车主每天开车时间在两到四个小时，也就是说，车有 90% 的时间是闲置的。利用这段闲置时间，我们可以在车端进行一些数据处理，减少对云端的依赖。一个简单的应用场景是 T+1 报告（即第二天的汇总报告）。目前，车联网平台为了生成这些报告，通常会将大量数据上传到云端进行处理，消耗大量的云端算力。如果能将这些计算下推到车端，在本地完成数据处理，不仅能减轻云端的负担，还能降低云端成本。另一个重要的应用场景是单车问题或多车问题的排查。现在大多数客户会在车端保存一到两周的历史数据，但这些数据的潜在价值尚未得到充分利用。当需要进行问题排查时，车端已经拥有最高精度的历史数据，我们可以将相应的算法下推到车端执行。车端完成计算后，将结果返回，不占用云端的任何算力。并且这部分电力消耗也不由主机厂承担，而是由车主承担。在单车智能的持续进化中，几乎所有客户都在探索大模型上车的可能性。然而，这些大模型的应用往往涉及到车主的敏感隐私数据，比如语音数据或车内的图像数据。将这些数据上传到云端处理，实际上并不符合未来国家隐私政策的趋势。因此，未来的大方向是大模型在车端的本地化应用。利用车端的历史数据存储，实现从数据接入处理到推理消费、微调和模型进化的全流程在车端完成。这不仅符合隐私保护的政策要求，也更适合在车端进行计算。新算法、新模型，甚至影子模式的验证都可以在车端进行，有效利用车端的算力。通过这种方式，车内的应用场景将会更加丰富，汽车将成为一个强大的计算节点。在兼容云端方面，EXD 在早期的车云计算探索中，推出了一系列能够在车端和云端共同计算的算子，但在实际应用中，这些算子有一定的学习成本。为了降低这种门槛，帮助更多用户便捷地使用，我们明年的产品将全面支持复杂的 SQL 功能，包括子查询、基本的 SELECT、WHERE、GROUP BY 等条件查询。此外，针对汽车行业常见的感知和窗口计算场景，我们还将推出扩展算法，更好地支持相关业务。这些算子既能在系统中使用，也能灵活应用于车云一体的计算模式，将传统需要在云端进行的计算任务下沉到车端。通过我们云端的界面，用户可以使用联合计算的 SQL 来自动将计算任务分配到车端和云端。车端部分负责单机计算，无论是在实时模式还是历史计算模式下，都能在车端进行数据处理和汇总。数据汇总后上传至云端，进行最终的存储和全局汇总，实现车和云的资源共享。我们还将推出一种新的数据格式，称为合并的 VSW 格式。稍后会详细介绍这一格式如何在云端实现更高效的降本增效。同时，对于与我们合作共创的客户，我们将向他们开放该格式和相关代码，所有对云端降本增效有需求的客户都可以使用这套机制。我们举一个简单的例子：在云端写一个非常简单的 SQL 语句，使用标准语法，没有特殊的部分。当我们的产品读到这个语句时，会自动识别出其中包含的车端计算部分，并将其下推到车端处理。统计部分涉及多车汇总行为，则会自动推送到云端。通过这种方式，车端和云端的计算任务可以被自动拆解，车端部分在车端完成，云端部分在云端完成。如果某些时间段没有数据，系统会自动过滤掉，不需要上传无效数据至云端。明年，车端数据库将迎来一次重大升级。之前我们根据客户的需求，存储的都是总线数据。从今年起，我们已陆续开发一些新功能，为明年向 AI 数据融合方向演进打下基础。我们推出了 vector 功能和变长数据结构的 blog 功能，都是为了逐步实现AI数据融合这一目标。具体来说，我们开始支持报文、信号流、vector 存储，能够处理不定长数据。不论是自动驾驶数据、网络包，还是文本结合 VSW 索引，我们都可以支持。这些功能满足了向量分析的需求，也能支持传统的网络分析需求，并对这些特定数据进行针对性的压缩。我们从客户反馈中了解到，他们有大量的非总线数据，这些数据各自有不同的格式和定义，并希望我们基于自身经验，在数据格式上优化存储和流量成本。作为自主研发的产品，我们在这方面具有很大优势。相较于基于其他产品进行改造的方式，自主研发让我们可以超越产品边界，根据客户需求对架构进行最佳优化。同时，我们也将逐步开放这些能力和设计，与客户共同创造未来行业的新能力，支持隐私计算、推理消费、微调等功能。在支持多种数据结构和不同类型数据的业务过程中，我们下一步将推出多层存储机制，并将其与当前系统打通整合。也就是说，我们可以根据数据的类型、业务类型及其属性，进行更加精细的数据管理。例如，重要数据可以存储更长时间，优先级较低的数据则可以缩短存储时间，以进一步优化车端的存储空间利用率。目前所有数据都集中在同一个数据分区内，将来我们会根据数据的重要性或特性进行分区管理，实现更高效的自主空间管理。车端数据库第三个升级点灵活的多频采集功能，目前已经有客户在使用了。基于同一套高精数据底座，客户可以灵活配置不同精度的数据流。例如，高精度数据用于诊断，秒级数据用于 TSP 平台，百毫秒数据用于业务应用。系统可以自动配置这些数据，将不同类型的数据根据需求灵活流转。就像当年我们与博世沟通时，他们认为高精数据很好，但只需要百毫秒精度的数据，不想再从高精数据中再去计算百毫秒数据。如今，我们已为客户打造了整套灵活的数据采集能力，这套能力可以扩展到所有的数据采集和分析环节，让客户能够灵活控制成本和数据频率，以匹配不同业务需求。此外，关于灵活的预制采集，我们支持各种策略，无论是云端下发、车端预制，还是车端预制并通过云端更新的策略，都可以灵活支持。在云端存储方面，我们明年也会有进阶的解决方案。我们客户反馈最多的一个问题是。虽然 EXD 当前的 VSW 格式虽然已经是行业最优，但随着大量车辆产生的数据不断累积，存储成本仍然巨大，能不能再进一步压缩和优化成本。对此，我们的回答是：可以。经过大量调研，我们将推出一种新的合并 VSW 格式，称为 VMW 格式，用于合并车端上传的小时间段数据。由于车端数据不可能上传一个小时的数据包，因为这样的包太大且容易出现问题，因此通常采用分钟级别的数据包上传，这在云端形成了大量的小文件。然而，云端的大数据分析更适合处理大文件，通常以百兆级别为基础的存储单元，而车端上传的包往往在百 KB 到几 MB 之间，这就导致了格式不匹配。为了消除这种不匹配，我们可以在云端合并小文件，通过去除格式冗余信息和使用更高效的压缩策略，进一步优化存储效率，使存储成本降低 25%，在某些场景下甚至可以达到更高的节省比例。通过我们的合并策略，客户可以实实在在地降低存储成本，并支持单车与多车的混合合并。传统云端合并需要对车端数据进行解析、重新编码、压缩和存储，而对于毫秒级的高精度数据，这样的操作会消耗大量算力成本。目前，任何云平台或部门都无法承担如此巨大的算力需求。基于 EXD 的全新合并方案，我们可以在二进制级别快速合并数据。如果熟悉我们的格式就会知道，它是按照时间切片精确切割的，比如 30 秒一段。基于这些切片，我们可以快速合并数据，并应用压缩策略和对冗余信息的去重来进一步降低存储成本，同时避免消耗大量云端算力资源，实现双赢——既节省成本，又无需耗费大量算力。此外，我们新增了一个索引块（index），支持接近存算一体的十到百倍计算性能提升。这种提升适用于所有通用大数据产品，可以实现快速查询，使得基于 EXD 格式的复杂查询能更高效地完成。客户普遍关心这项能力能否开放，我们的回答是：只要客户愿意与我们共同开发这些方案，无论是协议格式还是代码，我们都可以向客户全面开放。查询方案优化对比，这里我不展开细讲。通过多层过滤的方式，我们可以在车联网大量批量计算中，首先根据车型和较大的时间维度（如天、月）进行过滤。传统方案也能做到月、天级别的过滤，但无法精确到车级别。我们则在支持月、天级别的同时，进一步精确到车级别。例如，如果某些车的数据文件不符合查询条件，在读取数据时仅需读取索引块的前几十个字节，就能判断出是否在查询范围内，自动丢弃不符合条件的数据。这种方案不仅可以支持基于车、采集批次、矩阵版本等非数据维度的查询过滤，还可以根据时间切片和自定义索引条件，甚至为特定客户的业务需求定制化条件，灵活满足多样化的查询需求。未来的方向是什么？今天我们也邀请了一些嘉宾与我们探讨未来的方案，因为我们认为，当车端算力进阶到一定程度时，最优的优化模式必然是存算一体和算力下沉。如今，从特斯拉到其他领先厂商，都在朝这个方向前进。当算力和软件逐渐成熟，硬件会逐步融入软件功能，形成差异化；同时，软件也会向下集成硬件，达成纯软件无法实现的能力。比如，在存储空间管理方面，当通过操作系统向存储空间写入数据时，随着时间推移，存储空间可能会变得杂乱。而如果下沉到操作系统底层，与存储硬件共同设计，我们可以更好地将随机写入优化为顺序写入。顺序写入的好处是无需频繁擦除和寻找可用空间。这种优化带来的实际价值是：存储空间的寿命可以提升 2-4 倍，相应地，同样的存储空间成本也会降低 2-4倍。这样的价值在数据量不断增长的情况下会愈加明显。当数据架构下沉到操作系统层面，某种程度上，它已经成为操作系统的一部分。也就是说，数据架构变成了未来车计算平台的一部分，这个平台不仅仅是芯片上的存储系统，而是一个融合了数据处理、大量算力、网联计算、联合计算的操作系统，具备存储、压缩、加密解密等多种能力。因此，我们对未来的展望是，整个汽车架构将发生深刻变革，这种变革不仅仅体现在某个中央计算平台或几个虚拟化键上，而是类似于云端发展的过程。云端从最初在单个节点上运行两个虚拟机，演变成百万级算力节点的抽象化。如今的云计算是面向应用和算力需求的资源调配，而不再局限于物理节点。我们认为，未来的汽车将经历类似的转变，成为具备强大计算能力的抽象节点，为应用和算力需求提供服务。未来的操作系统也将成为车联网和车计算的核心。我们EXD非常有幸能参与到这场深刻的变革中，与大家一起见证和推动这一巨大的变化。
