Executive Summary

核心观点（金字塔原理）

结论先行: 车联网数据平台建设的核心是打通”数据采集-解析清洗-共享-挖掘-价值产出”全流程，并通过数据分层和质量管理确保数据可用性

支撑论点:

1. 数据流需经历采集、校验清洗、分析转发、落盘四个阶段的标准化处理
2. 数据质量管理需从准确性、可靠性、完整性、安全性、易用性、及时性、精确性七个维度把控
3. 数据仓库分层设计（ODS-DW-APP）能清晰数据结构、减少重复开发、统一数据口径

SWOT 分析

适用场景

• 车联网/物联网数据平台从0到1建设
• 大数据团队数据治理与质量管理体系搭建
• 数据仓库分层设计与规范制定

• 工作内容这里不展开说, 只简述技术思路

总括

• 打通车联网数据全流程

思考

• 问题是什么?
• 目标是什么？
• 前期调研？
• 计划？
• 如何做？
• 如何更好快速迭代？
• 阶段性重构？
• 系统当前情况？
• TODO

车联网

目标

• 逻辑: 数据采集 -> 数据解析清洗 -> 数据共享 -> 数据挖掘 -> 产生价值

数据流

• 数据采集(基础校验,过滤)
• 数据校验清洗,统一格式化
• 数据分析转发
• 数据落盘

数据接入

• 数据源类型多样：包括GPS定位数据、CAN总线信号（车速、转速、油耗等）、OBD诊断数据、用户行为埋点数据（APP操作、驾驶习惯等），不同数据源的采集频率和数据格式差异较大
• 数据传输协议适配：车端设备主要通过MQTT协议进行轻量级消息推送，服务端API通过HTTP/HTTPS接入，部分嵌入式终端采用TCP长连接保持实时上报
• 接入层数据校验：在数据网关层进行前置校验，包括协议格式合法性检查、必填字段完整性验证（如GPS报文必须包含经纬度和时间戳）、数据大小和频率限流，不合规数据写入异常队列待后续排查

数据处理

• 实时处理链路：基于Flink/Spark Streaming构建实时流处理管道，处理GPS轨迹实时纠偏、电子围栏实时告警、车辆状态实时监测等低延迟场景，端到端延迟控制在秒级
• 离线批处理链路：基于Spark构建离线批处理任务，执行日级别的全量数据清洗、里程重算、行程切割与特征提取，为数据仓库提供高质量的宽表数据
• 数据清洗规则：包括去重（同一报文重复上报）、异常值过滤（GPS漂移点识别、速度异常值如255剔除）、格式归一化（时间戳统一、坐标系统一转换为WGS-84），清洗规则可配置化管理并支持版本追溯

数据落盘

• 存储层分层选型：离线数据采用HDFS存储并以Parquet/ORC列式格式压缩落盘，在线随机查询场景使用HBase提供毫秒级按车辆ID检索能力，实时流数据以Kafka作为中间缓冲层实现生产消费解耦
• 数据分区策略：HDFS上按日期（dt）作为一级分区，车辆ID哈希作为二级分区，兼顾按时间范围扫描和按车辆维度查询两种常见访问模式，避免小文件问题
• 数据压缩与格式：统一采用Parquet列式存储格式配合Snappy压缩算法，在压缩比和读取性能间取得平衡，相比原始JSON格式存储空间节省约70%以上

数据监控

• 管道运行监控：对数据处理链路的关键指标进行实时采集，包括各节点吞吐量（条/秒）、端到端处理延迟、消费堆积量（Kafka Lag）、任务失败率，通过Grafana面板实现可视化
• 数据质量看板：建立日级数据质量报告，监控各数据源的到达量与预期基线对比、字段空值率、异常值占比、数据延迟分布，质量分数低于阈值自动标红告警
• 告警规则与SLA：定义分级告警规则——数据量环比下降超过30%触发P1告警、处理延迟超过5分钟触发P2告警、单批次错误率超过5%触发P3告警；核心链路SLA目标为数据可用性99.9%、端到端延迟不超过T+1小时

数据质量

• 准确性: 合法性, 数据项是否合法 比如GPS? Speed?….，是否要做一次清洗？在抽取宽表的时候做？
• 可靠性: 大数据量数据传输是否可靠？数据在传输链路上是否发生丢失？重发，重复？丢失怎么补救？丢失率如何？在哪个阶段处理？离线Spark？不丢数据, 每天定时任务处理校验, 有一定的延迟, 发现丢失进行补漏
• 完整性: 数据项是否完整？是否存在缺少属性情况？比如GPS报文少经纬度？
• 安全性: 内网? 其他业务线如何防止泄露?
• 易用性: 实时方案/离线方案 ? 如何快速对接？离线抽取时，做一个统一的宽表？抽取哪些字段？实时如何抽取为统一服务？
• 及时性: GPS生成时间 > GPS接收到的时间 ? 怎么处理？
• 精确性: GPS误差飘逸范围？GPS上传错误？GPS精度100, 1000？里程误差？校准？异常值255？上传频率？10s/30?

针对业务需求的数据质量入手

理论闭环: 业务需求 -> 定义指标 -> 校验指标 -> 总结分析 如有问题 -> 重新进入定义指标 直到满足业务需求

数仓总结

为什么要设计数据分层? 为什么要做元数据管理？ 为什么要做数据质量管理？

• 现实情况可能是很混乱的，没有一个良好的数据层级，可能会造成取数错误，或者单位未转化..等等诸多问题. 为解决这种痛点, 提高开发效率, 所以要做数据分层. 一般分为 ODS -> DW -> APP

  数仓搭建优势 资料

• 清晰数据结构：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解
• 减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算
• 统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径, 标准统一, 比如里程数据向上层统一为km
• 复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层解决特定的问题
• 最大化复用数据, 统一输出
• 数据维度统一, 比如所有时间统一为UTC毫秒时间戳，里程统一为千米(km)，速度统一为km/h，温度统一为摄氏度(°C)，确保上下游数据消费方无需重复转换
• 数据逻辑统一, 比如里程计算逻辑统一采用GPS两点间距离累加，而非OBD里程表读数；行程切割统一以熄火信号或停留超过10分钟为判断依据，避免不同业务线使用不同逻辑导致数据口径不一致

技术迭代架构图

• V1 离线批处理阶段：初期采用最简架构，车端数据通过网关写入Kafka，由Spark批处理任务每日定时消费并落盘HDFS，满足基础的离线报表和里程统计需求，优点是架构简单易维护，缺点是数据时效性差（T+1）
• V2 增加实时流处理：随着实时告警、在线监控等业务需求出现，在离线链路基础上引入Flink实时流处理层，Kafka数据同时被实时和离线两条链路消费，实时链路处理GPS纠偏和围栏告警，离线链路负责全量数据清洗和数仓建设，形成Lambda架构雏形
• V3 统一架构与数据湖：将Lambda架构演进为Kappa架构思路，以Kafka+Flink为核心统一实时和离线处理逻辑，引入数据湖（如Delta Lake/Iceberg）实现流批一体存储，减少两套代码维护成本，同时支持数据回溯重算和Schema演进

总结

车联网数据平台建设是一个从0到1逐步演进的过程，核心经验总结如下：第一，数据质量是一切上层应用的基石，必须在数据接入层就建立严格的校验机制，越早发现问题修复成本越低；第二，数仓分层设计（ODS-DW-APP）能有效降低数据混乱带来的开发成本，统一数据口径和维度标准是团队协作的前提；第三，架构设计要兼顾当前需求和未来扩展，从简单批处理起步，逐步引入实时处理和流批一体架构，避免过度设计也避免推倒重来；第四，完善的数据监控和告警体系是平台稳定运行的保障，数据问题的发现速度直接决定业务影响范围。车联网场景下数据量大、数据类型复杂、实时性要求高，这些特点要求我们在平台建设中始终以数据质量为核心、以业务价值为导向进行技术选型和架构演进。