一汽集团数据专家分享：实时数据技术在汽车行业的应用与实践经验

作者：tapdata

2024-08-19
广东
本文字数：7823 字
阅读完需：约 26 分钟

【导读】在当今快速变化的商业环境中，数据的实时性和准确性是企业制胜的关键。然而，数据孤岛、数据分散、处理时效差等难题却成为制约企业发展的瓶颈。本文将围绕实时数据技术在汽车行业的应用与实践经验分享展开。

本次分享主要涵盖三个方面展开。

第一，关于数据技术的起源以及其与传统 IT 技术在应用系统构建方面的差异。

第二，应用数据过程中所产生的痛点，以及如何应对这些问题。

第三，总结实际操作中的经验，包括一些客观规律，以及在规律下如何提升数据使用效果。

01 汽车行业数据技术实践

汽车行业具有很长的 IT 实践历史，传统的 IT 技术主要用于构建 ERP 系统、营销、供应链等业务领域，以一汽集团为例，其 IT 实践经历多个经济周期。

从 1953 年中国最早的汽车工厂建立至今，一汽集团经历了 70 多年的发展。在这段历史中，穿越了多个经济周期，因此对于技术的应用可能需要更长的时间跨度来总结。在经济周期的四个阶段，即过热、滞涨、衰退和复苏中，我们可以清晰地看到传统业务系统和我们今天要讨论的数据类、建设类项目之间的关系。首先是扩张阶段，当经济状况良好时，企业资金充裕，可以开展 ERP 和财务等项目，以提高整体运营效率。然而，当效率提升进度过半时，大概率会伴随出现数据类项目，最典型的例子就是财务或营销方向的 BI。即，ERP 建设的成效，体现为建设 BI 平台，以满足领导层的数据分析和报表需求。当经济开始下滑，销售额增长放缓，逐渐进入滞胀和衰退期时，企业需要节约成本，此时供应链项目应运而生，数仓类项目也会随之出现。然而，这个阶段的驱动力往往是模仿性的，即依靠其他厂商或自身过去的经验，进一步扩大数仓类、数据分析类、智能数据类项目的规模。当进入衰退期后半段，就会出现一种避险型的驱动力，即企业意识到经验无效，且行业存在生死风险，需要通过 IT、数据类项目来提高风险识别能力，此时，舆情或驾驶舱类项目成为企业的关注点。

因此，我们可以总结出，在四阶段经济周期或者长经济周期的视角下，我们的 IT 投入和伴随的数据技术类投入，具有很强的周期性和规律性。这种规律实际上就是我们进行数据类项目，如数仓、数据湖、数据集成、报表等的项目周期律。

02 数据技术实践痛点：建设深入而收益递减

经济盛衰驱动的技术投入周期中，我们被动地跟随市场的步伐，追随社会经济的节奏前进时，将会面临哪些具体的情境呢？

首先，随着我们在 ERP、财务系统、营销系统以及生产制造工艺系统等方面的不断扩展，以及项目深入进行，工作细致程度和岗位专业化加剧，我们会发现 IT 系统的效益呈递减趋势，呈现 IT 投入的业务效果边际递减趋势，因此，通过 IT 投入来进一步提升业务效能变得非常困难，从而进入了一个 IT 投入回报的瓶颈期。

然而，在这个瓶颈期中，我们又该如何进一步提升我们的效能呢？此时，数据类项目的重要性便凸显出来，ERP 和营销等业务系统的目的，是提高业务动作的可控性，在其上增加数据分析系统，会提高业务动作和链条的可观测性，进而发现更多的可控性环节。这种业务系统与数据系统的相伴相生的周期投资模式，能够对业务和组织带来持续的收益，映射到技术领域的 DT 和 IT 连续投入规律，正是由这个原理所导致的。

抽象成一般的规律，业务标准化、流程化、制度化的过程，目的是提高其可控性，而当可控性到达临界时，通过提高可观测性来进一步提升业务和组织的效能。从学术角度来看，这就是控制论中的可控性与可观测性的对偶关系问题。

03 实践思路与规律总结

在本次技术和经济周期中，从 2004 年大数据技术诞生，2010 年国内引入，2015 年左右集团内部引入，至今为止，我们取得了哪些成果呢？

首先，我们建立了实时的数据湖。因为数据仓库是个自古就存在的效率问题，从 90 年代末开始做数仓，到 2014-15 年大数据技术、Hadoop 技术出现后，我们就需要考虑数仓过渡到数据湖的问题，那么，它应该采用何种架构呢？经过几年的实践和总结，它应该是业务和数据互为驱动力的结构，或者称之为对立统一。同时，为了解决数据分析的时效性，如物联网数据、车联网数据或传感器数据，我们需要面向业务的 Hadoop、流处理技术产品。

最终我们要解决的是，表状态的数据向流态转化的流程，同时，我们在流态中的数据亦需向表内部进行转换，而这两种过程实则构成了一个互逆的状态，体现为企业中的湖仓二元结构，或者宏观上称之为湖仓一体。

它有两个使命，第一，保证数据的准确性，这是不可或缺的条件，不能像互联网那样，有些广告推荐中的流数据可能存在精度、准确性不足的情况，这在企业 ToB 领域中是绝对不能接受的；第二，需要保证速度，因为传统的数仓是 t+1 的，需要隔日处理，这等于放弃了数据驱动业务的机制。那么，在既要保证准确性又要保证速度的前提下，如何基于自身客观条件，在业务数据、数仓、大数据集群以及 Kafka 这样的分布式流总线等资源的基础上，实现及准确又快的数据处理？

经过深入研究，我们发现，实际上有两种引擎可以满足我们的需求，第一种被称为表包流，即我们在表的形式中使用流态引擎进行计算。只有流态引擎才能达到绝对的高速，也就是说，我们将大量的 MySQL、Oracle 数据读取出来后，经过实时处理，然后将其送入总线或数据库集群中，整个过程需要实时完成。这便是从传统的数仓向我们现有的这种无限算力的大数据集群的转变过程，也就是表到流的过程。

TapDataLive Data Platform（TapData 实时数据平台）方案其实是专注于解决该问题的，也就是在形式看起来两侧都是表，但它的处理引擎是流化的，最终其效能、性能、可扩展性均可以得到保证。

第二种则是流包表，即在 Kafka 的结构中，我们是否可以进行某种表类型的操作，如 join、union 或聚合计算等，这些操作的解决方案是类似 Spark、Flink、Paimon 的思路。

综上，表包流和流包表这两种方案，分别承担了架构图中的表向流的转换器和流向表的转换器的角色。总体来看，在当前的技术阶段，大数据技术与数据库技术尚未完全融合，或者说其融合的性价比仍较低的阶段，我们成功地实现了一种结合，即在企业内部既完成了业务库这种计算精准的业务库向大数据的转换，实现实时处理，同时也解决了在流式数据中获取大量的 IoT 数据、车联网数据，在 Kafka 中流式数据向数据库内转换的过程。

这个完整的数据循环模式，是比较适合企业构建实时数据湖的技术逻辑。而 TapData 其实也是提供了一个强有力的工具，在这个过程中既解决了准的问题，也解决了快的问题。以上，是我们在实际操作过程中设计出来的，具有可行性的实时数据湖的架构。

在构建了数据湖之后，我们发现了一些显著的收益，这些收益在我们十多年前构建数仓时是无法感受到的。

首先，数据的速度得到了极大的提升，当我们获得了真正的全域数据，包括集团范围内的十几个整车厂以及超过 100 个子公司，跨越了几十万人的规模的实时数据时，会发现所看到的内容与过去完全不同。从数据分布来看，远期的历史数据，例如一年以上的数据，其中蕴含着大量的规律，例如汽车行业的销量在 1-12 月中，哪几个月销售量较多？哪几个月销售量较少？如果想购买汽车，上市后第几个月的折扣更高？哪个月的折扣更低？从历史数据中是可以找到答案的。

而近期数据，即上个季度到一年的数据，可以观察到最近几个月市场究竟发生了什么？哪些品牌？哪些价格？哪些区间发生了格局性的变化？例如比亚迪发布新车后引发了怎样的市场反应？限购消息前后会发生什么波动？如果能够深入挖掘其中的每一个事件就会发现许多有用的信息，例如竞争对手的关系、产品之间的变动等等，这些信息可以用来支持决策，最典型的应用就是用于销量预测。

最后，我们讨论的是最近的数据，即当期的数据，也就是我们当天到近几个月内每一条的数据，如果都能获取的话，那么当业务系统中出现了某一条销量或者线索的时候，就能够实时地将其传递给需要的部门，下一个业务动作就可以由数据来推动。

最典型的例子就是当一个客户走进 4S 店，他需要维修车辆，是否可以让移动出行服务商，比如专门从事滴滴服务的人，为他提供一张优惠券？就像我们在互联网上的一些推送一样，这种动作只有在业务数据充分的实时且顺利流动，推数据和拉数据我们都能顺利地完成，而且成本并不高的情况下，才能将这种业务动作结合起来。

最终所提炼的效果就是，有能力供应实时保鲜的数据，搭建一个数据链路只需要 15 分钟，然后就能将六大部门、几十个场景、数百套系统全部连接起来，而且能应对数据链路的变动。

下面介绍我们最新的一些案例，第一个，关于进出口的，我们向国外销售汽车的时候，跨云数据同步非常困难，因为数据来自国外，包括欧洲甚至是中东的，我们实现了跨云的实时数据同步；第二个，数据中心内部的两个数据库，或者说是不同部门之间的数据库，双向同步就是 a 到 b 再回 a，而且要实时不能有延迟的，因为要保证业务动作能够连续进行；第三个，主数据平台的建设，在我们拥有众多数据库，如几百甚至几千套系统时，如果要了解其内部结构，用于数据治理任务，或者建设数据资产，那么，实时捕捉系统结构的变化并传递，就有能力完成主数据、元数据以及参考数据的修正或评估工作等。

总之，数据的不同时效性在业务中的影响完全不同，当我们具备了实时的数据能力，就能够直接推动业务操作。

接下来是第二个重要效果，就是报表的效率问题。在大型组织中，特别是在央国企、大型财团，或者是一线互联网企业，都要面临领导的“管理体验”难题。领导需要查看大量报表，如果拥有十几万员工、分布在好几个城市、几百个分支机构，面对这么复杂的组织，生成报表时将面临极大的困难，甚至出现了本月的报表直到下个月过完了都出不来的情况，即，生成一份月度报表所需的时间可能超过 30 天。

实践出的规律是，企业报表时效性与组织复杂度呈现强相关，也就是“企业大则报表慢”。具体表现是，随着组织规模的扩大，统计的延迟也会相应增加。当我们有了实时仓库和湖的能力后，企业大则报表慢的问题就可以解决，因为我们已经将整个组织内的数据实时地流动起来，也就是说，通过技术手段把上图中这条线向左移动，解决了组织规模大但报表速度未减缓的问题。

实际上，我们已经成功实施了财务、质量、营销、制造、研发以及行政人事这六大典型部门，这些业务部门面临着大量的报表延迟问题，给领导层汇报的时候，总是没有办法提供新鲜的统计结果。在我们掌握了实时仓库和湖的能力之后，业务方又构建了大量的监控系统，能够及时观察到业务组织的动作。

反之，如果没有高效的数据，业务部门仍然需要等待两到三周才能生成报表。假设要统计全集团范围内的某种质量问题，他们需要等待最后一份数据的到达，他们才能完成汇总，这个等待的周期是非常惊人的。因此，组织复杂度与时效性冲突的问题通过我们的实时数据湖方案得以解决，甚至由此催生了一系列监控系统，这无疑是技术驱动业务改善的典型效益。

接下来是实践中总结出来的规律，首先需要探讨的问题是对数据的认知过程是什么样子的？根据我们长达 10 年甚至更久的企业经验总结，如果想要使用数据，实际上必须经历一个逐步深入的过程，而且无法跳过里面的阶段，否则就会失败。具体来说，首先要先打开数据 Excel 或 CSV 看到数据；第二步是搜索数据，使用 Control-F 找到需要的关键词；第三步是拼装数据，用 union 和 join 按照特定条件将两张表合并；第四步是可视化数据，即能够直观地看到数据的形态；最后需要理解数据，即能够在头脑中形成数据的含义，并在应用程序中使用它，输入一个条件，随之提供一个结果，在业务动作中表达含义或起作用。

在这个过程中的五个阶段的一种物化或技术化表达方式，是在数据仓库层次中使用的 ODS-DW-ADS 层次逻辑。从数仓层次的使用频度上，存在一个分布不均的现象，最底层的数据，即 ODS 数据，其使用频率实际上占比很高。我曾咨询过多家专门制作报表的企业级机构，以及一些资深架构师，询问他们直接从原始数据制作报表，即简单清理后的报表所占比例。普遍认为，这个比例应在 70%以上。而经过 DW 中逐层推演、思考、分析师处理和建模后的报表，可能仅占 20%。最后一种拖拉拽生成的内容可能仅占不到 5%，且这个比例是相当稳定的经验数值。

那么这 ODS-DW-ADS 层次使用频度的分布情况揭示了什么呢？实际上，在企业中观察到的一种现象称为数据资产积累循环或报表积累循环，即创造内容的人和数据分析师创造的模型和新的经验沉淀为固定报表的过程。意味着只要发现了新的数据认知，经过一段时间，大家发现这个报表经常需要查看，那么它就会变成标准化的内容，用数仓建模并直接生成，这个循环的建立就意味着需要持续进行这五个步骤，即接触、检索、拼装、可视化和理解。这个循环的建立，使得企业内部不断沉淀内容。那么它的认知成果是什么呢？就是 DIKWI 模型，我们加入了一个名为直觉的元素，因为当理解一个非常熟悉的领域时，可以猜测出一些东西，这就是直觉，即数据、信息、知识、智慧、直觉的递进。

此时，会产生一个衍生的问题，这也是这张图中最令人困惑的部分，即我们在研究了多年的数据湖和数仓之后，实际上诞生了一种名为数据中台的概念。很多人会有一个问题，数据中台上了之后，问题是否就能得以解决了呢？或者说，已经部署了诸多数据中台，为何数据问题依旧未能根除？答案通常是否定的。

剖析数据中台概念，最大特征是让业务人员能够操作数据，即数据中台其主要功能在于优化可视化及分析过程，然而，对于大型及具有一定规模的机构而言，其大部分数据消费场景主要集中在占比 70%以上的数据接触和检索阶段，即已固化的那部分内容。换言之，数据中台的主要作用恰恰是在数据消费较少的 20%环节，这意味着数据中台的架构是逆着报表积累循环的，实践中的数据中台项目会出现短期缓解问题，长期恶化问题的现象。这也解释了为何数据中台会演变为新版 BI，以及为何数据中台无法支撑实时业务，无法在业务流程中发挥作用。此外，数据中台也无法垄断并治理企业的数据消费，原因在于数据中台的技术特性将其定位在了数据认知的后半程，如果重金投入数据中台，必然影响数据其他阶段的建设，造成数据问题持续性的搞而不定的现象。

那么，是否存在一些数据技术领域的客观规律，能够指导我们前进呢？实际上，确实存在这样的规律，其中最为基础的原则，我们称之为算量守恒定律。

在当前的技术条件下，假设我们以目前市场上可购买的 CPU、内存、GPU 等设备为参考，无论我们计算何种固定算法，无论是排序、复杂检索，还是某种聚合计算，在不同的计算平台、不同的编程语言之间，其性能差异不会超过两个数量级，也就是在 100 倍以内，即在我们当前的技术条件下，计算一个事物所需的时间是相对稳定的。例如，Python 的计算耗时是 C 语言的 55 倍。

由此引申出的一个重要结论是，如果我们想要大规模地缩短计算时间，或者说如果提高它的实时性和时效性，最有效的方法就是预先计算也就是说，在编写代码时，解决效率问题，最优先考虑的是读取和生成数据的格式。

那么，根据算量守恒定律，我们得出了一个规律，既然我们要提高时效性，缩短计算时间，那么我们就需要进行冗余，也就是增加它的份数，即预计算的效率就来自于预计算引起的冗余，那么，冗余的膨胀逻辑也就是它膨胀的机制是什么，这是我们需要研究的核心问题。

概括回顾一下，我们的冗余膨胀机制已经历了四代发展。

第一代是统计学驱动的，主要涉及平均值、标准差、峰度偏斜等概念。我们会根据数据的技术特征进行计数，在使用之前，会预先计算出这些统计和特征，以便在需要时直接提取。SPSS、Excel、设备预警用的时序数据库等工具都能够快速地完成这项工作。

第二个阶段是管理学驱动的，即我们能否迅速地计算出在业务认知中出现的一些指标，如利润率、周转率、产批零售量以及计划完成率等，这些都是我们可以预先计算的。典型场景是财务分析领域对企业三表的分析。

第三阶段是业务模型驱动，其中最具代表性的是 Cube，也就是数仓的核心部分，通过拉齐各个领域，利用维度来实现整合。此时，我们实现了全组织的业务视野，包括同比、环比、市占率变化等，这些都是我们在业务模型中，在 Cube 中可以预先计算出来的。

第四阶段是概率论驱动的神经网络参数，也就是现在的 AI 技术，它是基于概率论驱动的高维度数据微分计算结果。我们首先将数据中的逻辑概率固定在神经网络中，即训练过程，然后由神经网络推算出我们所需的概率，也就是推理的过程，即推算出最大概率的那个点是什么。

四代的膨胀方式，在技术上并不是完全的继承关系，更多的是应用领域不断扩大的过程，更是对数据更广泛适配的过程。其中蕴含着对香农信息论的反向应用的趋势，值得更深层次的探索。

此外，对数据本体第一性原理，是否有什么新的认知呢？实际上，在《流系统设计》这本书中就提到了流表相对论的问题。

当我们深入剖析这个问题时，我们发现了流的流表二象形问题，并不仅仅是组件的批流相对论问题，而是数据本身存在一个两象性问题。

第一，表的本质上是格式化的一条一条的消息，即数据的表化就是一个对齐的过程；第二，流实际上是这个表的内容变化的集合，也就是表的变化的记录。所以，数据的分析大概率是由表来承担的，而对其进行详细记录或变更痕迹则需要流的参与。

那么，无论任何一条数据或大量数据，无论是单个表单还是一系列子表，都可以将其转化为表格形式，或者构建为数据信息流，则数据天生就具备两象性，只是要考虑的是，不同情况下，什么地方应用数据流的特性，什么地方应用表的特性。在什么情况下对数据的流和表的形态进行转换，并且是在什么样子的时间、空间约束条件下进行的转换，约束条件下需要什么样子的算力模式、并发规模、检查条件等技术方案。

总结以上的分享，根本的出发点是对于数据的流表二象性的探索，在算量守恒定律的技术约束下，面向不同的数据冗余机制，诞生了各种数据结构和计算机理，在企业和组织的数据认知过程中，解决报表效率和数据价值问题，体现为实时数据湖的物理形态，作用在企业和组织行为的可管理和可观测能力上，最终在经济周期的不同阶段交替起作用。

关于 TapData

TapData Inc.「深圳钛铂数据有限公司」，成立于 2019 年 9 月，核心员工来自 MongoDB、Oracle、百度等，研发人员占比超 80%，至今已获五源资本等多家头部风投数千万美元融资。已服务中国移动、中国联通、南方电网、中国一汽、中芯国际、周生生、富邦银行等数十家行业标杆企业。TapData 坚持“开放+开源”战略，推出 TapData Cloud，将无代码数据实时同步的能力以 SaaS 的形式免费开放，目前已积累 1,000+ 云版和企业版客户，覆盖金融、制造、零售、能源、政府等多个行业。此外，TapData 社区版也已发布，正在面向开发者逐步共享其核心功能。TapData Live Data Platform 是一个以低延迟数据移动为核心优势构建的现代数据平台。企业可以用来实现核心数据系统之间的实时同步、实时交换及实时处理。当实时数据需求日益增多时，企业可以结合分布式存储，使用 TapData 将孤岛数据无缝集中到中央数据平台，为众多下游业务提供一站式的实时数据交换和发布服务。

产品优势：