本文发表于： &{ new Date(1688486400000).toLocaleDateString() }

飞凡汽车是一家用户导向的数据驱动型汽车科技公司，作为上汽集团旗下新能源汽车品牌，飞凡汽车致力于打造“高阶智能纯电移动空间”，倡导科技服务于人的理念，持续用科技兑现人类对智能出行的想象。承载数据驱动的战略性部门，飞凡大数据团队肩负使数据更具使用价值，让数据更好赋能业务、驱动业务的使命。

飞凡大数据团队在数据驱动业务上积极尝试敢于创新，保持着行业领先的水平。通常数据会被应用于生产制造、车辆性能优化、销售运营等业务领域，以帮助企业提高生产效率、用户体验等。如经营指标体系，为了让指标数据能对企业的经营发展效率提供有效支撑，飞凡汽车的经营指标看板需要提供准实时级服务，数据延迟不超过10分钟。

以客诉数指标为例，业务人员如果能在第一时间看到指标结果，及时与客户进行沟通，解决客户问题，不仅能提升客户的用车体验，也能提升品牌口碑。这个需求看似是某些指标的时效性提升，但背后却是企业各个经营活动特征及相互联系的多个指标，所构成的具有内在结构的有机整体，计算口径尤为复杂。

此外，车联网大数据智能分析也是飞凡汽车数据驱动的重要抓手之一。在该业务场景下，海量的车辆信号数据会同时接入，高并发写入需求非常常见，对数据库实时数据接入、更新、分析以及高并发承载能力有很高的要求。如车辆异常的实时检测需要秒级反馈结果，相对直观的场景是飞凡汽车的 eCall 系统。在遇到紧急危险时，时间就是最珍贵的资源。

既要保证数据实时分析，还需满足车联网这种数据量大的业务特点，这对大数据技术架构的设计带来了巨大的挑战。如何既能减少公司成本投入，又能灵活支持不同业务应用场景对车联数据的运用，让降本增效落到实处，是飞凡大数据团队面临的难题。

基于上述挑战，2022年6月飞凡大数据团队启动实时数仓建设，镜舟科技凭借出色的产品性能成功入选。8月车联业务场景接入，面对新的挑战，镜舟数据库（Mirrorship）依靠出色的写入性能，被运用于车联业务。同年11月底，飞凡汽车基于镜舟数据库（Mirrorship），搭建了统一的、多级数据链路架构，实现精细化成本管控。

镜舟数据库（Mirrorship）是基于 StarRocks 开发的企业级商用数仓产品，当前广泛应用于汽车、金融、物流等行业头部客户，服务超过260家市值70亿元以上的大型企业。如需要了解该案例详细内容，或对Mirrorship 感兴趣，可点击联系我们，会有专人与您联系。

【实时数仓的 OLAP 引擎选型阶段】

在 OLAP 选型时，飞凡最关注的是实时查询的性能。对比了 Impala + Kudu、ClickHouse 和 Mirrorship 三种解决方案，Mirrorship 在多表关联的复杂加工计算场景、大数据量查询场景、和支持SQL语法三个维度优势显著。

• 多表复杂计算：用7张1.3亿数据量的大表做关联和聚合，Mirrorship 可以在7秒内拿到结果，性能表现超乎预期。
• 大数据量查询：对10亿级的表进行点查和聚合分析，可达到单节点超过1000的 QPS。
• SQL语法：Mirrorship 支持标准 SQL，兼容 MySQL 协议，可以使用 MySQL 客户端工具。

【车联网接入后的数据架构统一阶段】

随着公司车联网业务的发展，大数据量写入成为最常见的 IoT 场景，如车内外各类传感器采集到的数据、车辆运行时零部件产生的数据、人车交互过程中累积到的数据等等。这对当时的实时数仓架构提出了新挑战。镜舟数据库（Mirrorship）起初作为一款 OLAP 实时分析引擎，是否也能支持亿级数据的高频写入？为了最大限度的减少业务影响，在此阶段，飞凡两手准备同步测试时序数据库。选定 TDengine，TimeScaleDB，IoTDB 做部署，采用车联信号读写场景做 POC 测试。

写入结果对比

• TDengine，IoTDB，TimeScaleDB 的写入速率均低于 Mirrorship ，有2-7倍的差距
• TDengine 写入速率4小时下滑了5倍，TimeScaleDB 写入速率平稳，IoTDB 和 TimeScaleDB 的写入速率只有约1000-1300条/s，多信号（500+）写入能力弱

标准SQL查询结果对比

• 简单查询：TDengine 和 IoTDB 的耗时在 1 s以内
• 聚合查询：三款时序数据库支持性都较差
• 关联查询：三款时序数据库均不支持

需要额外指出，由于飞凡车联网业务场景的原因，从设备端读取的数据会被写入到多张大宽表内，每张信号列数500+，而这可能是某些时序数据库产品不擅长的地方，所以并未能把产品性能发挥到极致。

同时，时序数据库在语法上，对业务侧来讲也存在差异。相较而言，选择 Mirrorship 来统一数据架构，既能够减少运维成本，避免不同组件的兼容问题，还能满足车联端业务需求，同时节省了额外开支，也保持了语法上的优势，是个多方共赢的结果。

至此我们把实时性要求较高的车联端业务数据，与用户类和经营类非车联数据进行统一管理，将不同类型的数据源（业务系统、行为埋点、车联、外部）数据进行集中、重组、标准化清洗与加工，解决了企业的数据孤岛问题，因此可以把车联数据赋能到任意有需求的业务团队，提升整体业务表现。

同时，也提高了车联相关业务处理的时效性，有助于业务团队提升消费者的用户体验。如在售后阶段，消费者驾车过程中出现故障问题时，飞凡汽车的业务团队会实时收到告警，同时可发起与车主的沟通，提供主动式服务。

当汽车搭上科技的翅膀，从硬件设施变成一种生活方式时，企业需要提供的不仅仅是出行工具，还包括以车联为载体的交互陪伴与全生命周期的运营服务。

【搭建统一的、多级的数据链路架构，

实现精细化成本管控】

确定实时与离线两条分析链路进行统一融合后，在项目执行初期，车联信号数据从Kafka 写入 Mirrorship 集群曾遭遇过 IO 瓶颈，我们的优化方案从以下两方面着手：

1、模型优化：

对信号模型进行优化，从行式设计（vin，信号名，信号值）调整为列式设计（vin，信号1，信号2，信号3，信号4，信号5，......）

2、组件选型：

基于车联数据写入，针对三个典型查询场景（简单明细查询、聚合查询、关联查询），进行了两种测试方案的对比：

相同 CPU /内存/ HDD 存储/节点数硬件配置，对比 HBase 和 Mirrorship

结论：

HBase 写入能力比 Mirrorship 高1.35倍，查询能力比 Mirrorship 低20倍

相同 CPU /内存/节点数硬件配置，对比镜舟数据库（Mirrorship）在 HDD 存储和 Nvme 存储的表现

结论：

镜舟数据库（Mirrorship）在 Nvme 存储上比 HDD 存储的写入能力高5倍

综上，对于不同场景需求，结合控本要求，2022年11月底飞凡大数据团队确定通过设计、搭建多级分流数据链路架构，来匹配高实时、准实时、离线的应用场景，实现了飞凡大数据极速统一的数据分析新局面。

镜舟数据库-Mirrorship （高配）：

时效性：实时30s-5min；

热数据：近14天；

特性：快写、少量计算、快速查询，有少量 Join，对大表查询没有要求。硬件采用 SSD 盘。速率比 Mirrorship 中配高5倍；

成本估算：1辆车，近10元/14d；

通过部署较高 CPU、内存、SSD 存储介质资源，组成高配的 Mirrorship 集群，可以满足实时数据的高速写入需求。车辆运行数据可以通过 Kafka 或 Flink 链路实现秒级的数据直接写入，之后依赖 Mirrorship 强大的实时分析能力，支撑诸如 eCall 等应用场景端到端的快速响应。

镜舟数据库-Mirrorship （中配）：

时效性：3min-25min；

热/温数据：近90天；

特性：积攒批次写、大量计算、大量/快速查询、稳定性差。存储容量是 Mirrorship 高配的12.5倍；

成本估算：1辆车，近10元/90d；针对诸如远程诊断、电池预警等实时性要求相对较低的场景，选择中配 Mirrorship 集群（相对少的 CPU、内存资源以及 HDD 存储介质等），同时对数据进行稍大规模的攒批写入，在降低成本的同时仍可保证一定程度的写入，与较高的查询分析能力。

HDFS：

时效性：T+1（隔天）；

温数据：近1年；

特性：写入慢、计算慢、海量计算、少量结果查询、稳定性高。健壮性系数最高，比 Mirrorship 高5倍；

成本估算：1辆车，10.7元/365 d，对于实时性需求较低的业务场景，可以直接将数据写入 HDFS ，之后的可以综合考虑使用镜舟数据库（Mirrorship）外表或离线导入等方式满足数据分析需求。

OSS：

时效性：T+1（隔天）恢复；

冷数据：归档；

特性：不可直接使用，会恢复；

成本估算：1G数据价格，1元/年（1.5副本）

未来，飞凡汽车仍将基于多级分流的数据链路架构，在业务与成本之间做到更加精细化的设计与考量。通过对内存、宽表读写、物化视图等各方面的优化，实现进一步的成本管控。双方将继续保持紧密合作，帮助飞凡用数据加速业务前进。