大数据平台构建建议书

汽车企业大数据顶层设计论证建议书目录1建设目标12技术路线23数据源分析53.1数据源总体树形结构53.2数据源类别63.2.1车辆数据63.2.2供应链数据183.2.3政府数据203.2.4市场数据253.2.5生产数据263.2.6环境数据283.2.7社交媒体303.2.8第三方数据333.2.9安全审计数据363.3数据分类403.3.1重要性413.3.2实时性433.3.3数据量估计444大数据平台架构464.1平台需求分析464.1.1平台目标464.1.2功能需求464.1.3技术需求474.2总体设计514.2.1概述514.2.2设计原则514.2.3架构设计534.3数据中心架构安全及数据共享安全774.3.1数据中心建设的安全策略774.3.2数据中心安全策略的功能设计784.3.3数据共享的安全875服务资源池895.1应用对象画像895.2画像建模方法906应用场景916.1降低车辆故障率916.1.1获取行车表现，预测失效以规避事故916.2基于场景感知的精准设计与生产，增强产品与应用环境的匹配度926.3提升驾驶员与乘车者体验936.3.1最优行车速度指导（HMI）936.3.2精准保养957总结96II1 建设目标考虑到SGMW数据平台处于起步阶段，随着数据量的增长，需要对基础架构做长远规划，其建设目标可以分为若干阶段展开。首先是在柳州地区建立集中化、大容量、可不断线性扩展、高可用性、高安全可靠性的数据库平台，使用标准化功能组件，支持全网型数据、跨域数据的整合，形成集中化管理的城市级数据中心。满足柳州地区10万辆车的实时数据采集与存储需求，并具备完备的查询与可视化能力，具备较高的防入侵、防信息泄露的信息安全能力，实现高性能实用范例“柳州模式”。在“柳州模式”成熟的前提下，在少数重点城市推广，该数据平台可以一体化管理区域内百万级级别的车辆数据量，具备更加完善的安全防护系统，维护地区车辆信息安全。逐步实现精细化运营，开发多种功能软件，车联网实现片区化、网格化管理，可以采集大量数据实现匹配地区特征的高性能设计，对不同小众消费者具备足够宽的个性化生产能力，订单生产周期大大缩减，零部件层层筛选优化，整车性能不断提升，与第三方全面合作，对政府开展建设起到支撑作用等。最终推向全国，实现多区域运营，考虑到响应速度与传输距离，在全国范围内建立三个大型基站，柳州具有统筹全局作用，可以全网服务，全网销售，统一管理调度。同时车联网数据平台可实时智能运行，主要表现在可实时获取与处理数据，分析事件，主动触发处理机制，还可以让数据平台团队精简高效。2 技术路线分别围绕政府、企业和用户热切关注的“大数据驱动的智能电动汽车智能制造” “基于大数据的智能电动汽车精准营销” “基于大数据的智能电动汽车驾车体验优化” “基于大数据的智能交通平台构建”，“大数据驱动的汽车到电网（V2G）关键技术”，“基于大数据的车联网安全与防御体系建设”共六大问题开展科学的、系统的、全面的分析，以覆盖智能电动汽车设计、生产、销售、使用、安全、维护全生命周期内各场景的需求，进而明确构建智能电动汽车车联网大数据安全平台的意义和所涉及的基础理论和关键应用技术。本文档将以大数据在智能汽车车联网的衍生为技术路线，构建基于大数据的智能电动汽车车联网平台及其安全保障体系，同时考虑了车联网大数据平台自身的安全保障框架。项目首先从系统论的观点出发，统一开展智能电动汽车车联网大数据平台的场景需求、数据源、采集技术、大数据存储、深度分析理论、示范应用等环节的顶层设计，形成需求、数据源、采集技术、存储技术、分析理论与应用的整体考虑，在此基础上，构建能够满足不同场景用户需求的基于大数据分析的智能电动汽车车联网服务体系架构。其次，以现有数据挖掘、深度学习为基础，围绕基于大数据分析的智能电动汽车设计、生产、销售、使用、信息安全、维护七大主线，开展智能电动汽车供应链优化、个性化设计、智能生产、精准营销、驾车体验、安全出行、合理化维修与保险等基础应用的支撑理论和关键技术研究，技术路线如下图所示。在场景需求层面，从实际出发分层次的分析未来车联网大数据平台可能的服务场景，如智能制造、0元购车、智能充电、智能出行、个性化车型设计、零配件定制、高效广告投放等；在数据的采集和存储方面，拟采用多元异构融合、分布式协同计算等相关技术以保证车联网系统异构性、实时性和移动性的特点，特别的，为了适应日益增长的信息与网络安全需求，我们建议部署新型通信网络如软件定义网络（SDN）或信息中心网络（ICN），此外，新型加密技术如访问控制加密、同态加密、基于属性加密，以及以深度流检测、虚拟执行等为代表的新型攻击检测技术，以拟态安全、移动目标防御为代表的下一代攻击防御技术也可以选择性部署；在虚拟画像与服务组合方面，我们建议对各场景进行细粒度、多维度的刻画，如对于用户应包括车型偏好、驾驶偏好、消费习惯、生活水平、教育水平等，对于车辆应从供应商、生产商、用户、定价、销售地域、行驶路线等进行刻画；对于整车厂，应对订单、库存、生产流程、工艺等进行刻画，细粒度的用户画像和服务组合要求高可靠的数据挖掘、深度学习技术，为了管理者能够对各类资源的监督、管理和调配，数据分析与可视化技术不可或缺；最后，对于场景服务的优化，拟融入层次化决策理论、认知学习、动态重构等技术以保障车联网系统应用的灵活性和可扩展性。图3-1 大数据平台整体技术路线3 数据源分析为实现上述提出的目标与思路，需要先全面分析了解各功能场景所需要的数据源。该部分对所需数据源做了全面的汇总，并根据其采集位置、获取渠道分为若干部分，对每一部分细化出来的数据源，做出了注释与区分，方便技术人员在实现的过程中，快速调阅。3.1 数据源总体树形结构图 31 数据源总体树形结构如图 31所示，该结构图涵盖了所有车联网数据平台所需要的数据源项与采集位置、获取途径。对于每一项数据源，下文将分别做出解释与区分。3.2 数据源类别3.2.1 车辆数据车辆本身是采集的主体，是展开车联网大数据分析、实现各种应用场景的基础。在上层设计阶段，在完善该数据时，采取的分层架构以及全面考量的原则，为后续的数据平台的拓展留下长远规划，减少数据死角的出现。为便于区分存储及后续调用分析，车辆数据分为静态数据与动态数据两大类，如图 42所示，每个大类会根据数据采集点的分为若干类，同时采集点并不局限于车辆本身，还包括与车辆捆绑在一起的其他信息。分述如下。图 32 车辆数据3.2.1.1 静态数据静态数据指的是在用户提交订单之后到产品到达用户手上之间与产品相关的信息，该部分信息是相对静态的，如不发生意外不会变化，会始终跟随车辆与用户，如图 43所示。图 33 静态数据3.2.1.1.1 车主信息车主信息主要是包含车主的年龄、性别、职业、工作领域等，用来帮助刻画用户肖像、制定精准营销策略、为4s店精准推荐车型提供建议、售后部门展开调研等，还能在意外情况下，帮助追回被盗车辆等，如Error! Reference source not found.所示。该部分数据是静态数据，所需存储较小，据估计在GB级别。3.2.1.1.2 出厂信息（整车信息）出厂信息主要是车辆在制造过程中所选用的零部件型号，配置情况。该部分主要是服务为售后、维修等提供参考，属于静态信息，估计在TB级别。3.2.1.1.3 关键配件参数车辆在装配中使用的关键零部件型号参数，是为后续展开基于场景感知的精准设计与生产、提升用户体验、售后部门提供检测维修建议、与供应商共同升级完善产品的基础数据。该部分数据是静态数据，主要是由供应商提供，对与重要指标，SGMW可以自行检查并记录。该部分数据是静态数据，估计在TB级别。3.2.1.2 动态数据(实时运行信息)动态信息指的是用户拿到车之后，在签署协议之后，允许车联网大数据平台依靠安装在车辆上移动终端采集的各个重要指标信息。该部分数据主要包括动力源系统、电机系统、轮胎、底盘悬架、整车控制系统、传动系统、辅助设备等主要部件在运行过程中产生的动时数据，如图 44所示。及时的了解车辆在运行中所有关键部位、容易发生失效的部位的运行状态，可以让大数据平台不断分析与提取指标，及时发现疲劳或者趋于失效的零部件以规避危险，提高品牌可靠性，掌握零部件表现，构建智能制造生态链，感知场景优化设计与生产，提升驾驶舒适性，提取用户的驾驶习惯，完善用户画像，精准营销与购车推荐，建设只会城市都有关键作用。车辆的动态数据极大，其数量取决于采集点的数量、采集频率等，初步估计在100 TB级别。图 34 动态数据3.2.1.2.1 动力源系统动力源系统包括储能电源、能源管理系统和充电器，可以获得电池电压、充放电电流、温度等数据，如图 45所示。动力源系统的信息是电动汽车的重要组成部分之一。电池的监控数据是电源管理系统的基础，保障电池的安全和健康运行。动力源系统的状态信息是车辆运行及其他辅助用电设备如空调等智能控制的前提。该数据从车辆端获取，基于车载传感器的采集数据。采集频率不低于1次/s，正常状态下不超过30s在车载终端存储一次，发生3级警报时，不超过1s存储一次。如果此处记录20个条目，按照1s的采集频率，存储3年的数据，5万辆车，数据量在TB级别。图 35 动力电池实时数据3.2.1.2.2 电机系统电机系统主要是指从电池输出到电机输出之间的所有部件，包含电机本体，逆变器，驱动板，MCU等。需要采集的车载电机系统数据主要是包括电机的电压电流、绝缘温度、转矩转速、电力电子设备温度、异常检测电路等的数据，如图 46所示。电机系统的数据不仅是前述动态数据的一部分，参与疲劳失效预警，规避危险，构建智能制造生态链，感知场景优化设计与生产，提升驾驶舒适性等功能的实现，还可以对电机这个核心部位的后续开发提供支撑。该数据量在TB级别。图 36 驱动电机实时数据3.2.1.2.3 轮胎轮胎支承车身，缓冲外界冲击，实现与路面的接触并保证车辆的行驶性能。它在行驶时承受着各种变形、负荷、力以及高低温作用，而且车辆有时候会在复杂和苛刻的条件下使用，因此必须具有较高的承载性能、牵引性能、缓冲性能。同时，轮胎还要求具备高耐磨性和耐屈挠性，以及低的滚动阻力与生热性。轮胎压力数据是检验车辆运行状态的重要指标：从经济性上说，轮胎胎压过低会让轮胎的接地面积增大，从而增大摩擦力导致油耗的提升；从安全上说，轮胎胎压过低可能会碾压轮胎造成轮胎损伤；从舒适性上说，胎压过低和过高对乘坐的舒适性都有很大的影响。除此以外，在大量胎压数据的基础上，可以提取到轮胎的磨损程度，可以帮助用户及时更换问题轮胎。通过反馈回来的，不同型号参数的轮胎的表现，可以不断调整轮胎参数，使得轮胎在下一批次的产品中更加匹配该车型的底盘、更加适合特定区域、路况和驾驶人群。轮胎信息主要是利用安装在轮胎内或气门嘴上的压力传感器来直接测量轮胎气压，在利用无线发射器将数据发送到接收器上，然后在显示屏上对各轮胎的数据进行显示。该数据属于动态数据，大概在TB量级。3.2.1.2.4 底盘悬架底盘悬挂系统传递作用在车轮和车身之间的一切力和力矩，并且缓和由不平路面传给车身的冲击载荷、衰减由此引起的振动、保证乘员的舒适性、减小货物和车辆本身的动载荷。底盘悬架系统是实现大数据平台了解车辆动力性、提取路况信息、侧面反映零部件与装配优劣、分析用户驾驶习惯等的研究主体。该部分数据主要来源于车辆本身的传感器，考虑到成本问题，传感器的数量可以根据用户需求的配置等级自由搭配。该部分数据总量大约在TB等级。3.2.1.2.5 整车控制系统整车控制系统数据包括车辆行驶数据如：速度、加速度、方向盘偏角等，车辆实时状态数据如：电池剩余电量、电机故障信息等各部件的主要信息，如图 47所示。利用整车控制信息可以实现对汽车行驶控制的功能、整车的网路化管理、电源能量管理与优化、车辆状态的监控和显示、故障的在线诊断与处理以及外接充电的管理。该数据车辆端获取，是对车载传感器采集到的数据在各ECU进行简单分析处理后的一些结果信息。针对采集要求，数据量大概也在TB级别。图 37 整车控制系统数据3.2.1.2.6 传动系统传动系统将机械动力传给汽车的驱动车轮，一般由离合器、变速器、万向传动装置、主减速器、差速器和半轴等组成，需要采集的数据如图 48图 410所示。考虑到本数据平台不局限于现有新能源汽车，可以将各种情形下的传动系统其考虑在内。该部分是车辆动力性体现的重要环节，是前述动态数据的重要组成部分，根据车辆架构不同而不同，该数据主要是依靠速度传感器，温度传感器等采集，规模估计在TB级别。图 38 变速箱数据图 39 转向系统数据图 310 ABS系统数据3.2.1.2.7 辅助设备（空调系统、GPS、车灯等）电动汽车的辅助设备主要包括空调系统、GPS、车灯、座椅的自动调节等，数据主要有GPS信息、空调运行功率、车灯状态以及辅助设备的用电消耗信息等，如图 411 图 413所示。辅助设备能够帮助用户提升驾驶的舒适性、方便性，以及提升驾车时的安全性。例如：在电动汽车的导航系统中，根据GPS信息，规划行车路线，结合对空调的需求以及空调的状态信息，在行车过程中对空调的输出功率进行自动调节，在调节温度的同时，降低对车辆动力性能的影响。该部分数据对安全性的影响不是很高，因此实时性可稍微放松。数据量大概在TB级别。图 311 空调数据图 312 车身/仪表显示系统数据图 313 导航系统数据3.2.2 供应链数据3.2.2.1 供应商数据供应商数据主要包含所提供的零部件产品的的类别、型号、性能指标等，如图 414所示。获取清晰精准的车辆零部件数据能够帮助SGMW了解供应商资源，可以不断细化丰富库存的种类，增加车辆配置选型项，在基于场景感知的精准设计与生产过程中，能及时按照车辆在某地区的表现调整所采用的零部件型号，找到匹配性更好的潜在零部件。该部分信息可以直接从供应商手中获得，其数据量在GB等级。图 314 供应链数据3.2.2.2 原材料库存原材料库存指各种原材料的存储数量，存储仓库编号，存储时间长度等信息。原材料库存数据可以帮助生产厂家对原材料采购数量、采购地点、存储地点、使用方式等决策做出优化，减少原材料存储成本，提高原材料使用效率。数据可以从原材料存储仓库数据库、原材料采购商数据库中获得。每有一笔采购就将数据放入数据库中，一年的数据量大概在GB量级。3.2.2.3 仓储信息仓储信息主要是建立在仓储数字化、信息化基础之上的，包括仓库的存储空间，调运能力，调运速度等信息。仓储信息主要是在大数据背景下智能制造的一部分，通过这种安排，仓库接收来自制造工厂指定送往某车间某一特定额的材料，然后把它们整合成单一的一票装运，其好处是有可能实现最低的运输费率，有效减少车辆的生产周期。尤其是在大数据应用中，通过分析得到近期生产所需要的生产材料，数字化仓储可以迅速给出反馈，及时补充欠缺材料与零部件，从而有效减少生产中的出现的库存不足问题，也能尽可能减少库存冗余，充分利用空间。库存数据可以从各厂区的仓库中获得，每天更新地区数据，每周更新全国数据，一年的数据量大概在GB量级。3.2.2.4 产品库存产品库存在产品规模达到一定程度之后，与智能物流一起在全国范围内实现配货、销售数字化，可以尽量避免在产品配置过程中的物流浪费和仓储浪费。该数据大概在GB量级。3.2.2.5 物流信息数据物流信息数据主要包括物体的运输、仓储、包装、搬运装卸等信息。通过获得的信息，可以对物流中造成的成本浪费、仓储量管理、运输设施选择等有一个更好的优化。该数据主要通过各地的仓储电脑数据库收得的信息获得。每当有一批物流运输完成，就将此次物流的完整信息上传数据库，可以每个星期全国汇总一次，全国总数据大概在GB量级。3.2.3 政府数据3.2.3.1 道路信息数据道路信息数据主要包括城市道路布局、道路路段交叉口位置与类型、道路速度管制、道路标志等信息，如图 415所示。道路信息数据是通过数据分析手段解决城市道路交通拥堵、城市道路规划等问题的基础。该数据可以通过向市交通局、有关规划部门申请获得，也可以通过百度地图、高德地图等地图软件提供的api爬取获得，或者直接与第三方地图数据收集公司合作，获得详细数据。道路信息数据属于静态数据，随时间变化不大，主要记录的是道路与交叉路口的经纬度坐标，相对应的限速指标，道路标记类型等，数据规模主要依据城市规模大小，大概在GB量级。图 315 政府数据3.2.3.2 路况信息数据路况信息分为两部分，一部分是道路拥堵数据，一部分是道路路面现状数据，包括是否存在积水、深坑的情况，如图 416所示。路况信息数据是我们做城市交通拥堵治理，道路规划、城市聚集人口疏导的重要参考，也是帮助用户设计合理行驶路线，提升用户体验、保证用户安全的重要依据。道路拥堵数据可以通过在交叉路口布置摄像头，或在路边放置传感器等方法直接测得，也可以利用移动数据，根据用户手机的使用情况，统计出道路拥堵程度，或直接与百度地图等第三方进行合作。道路拥堵数据属于动态数据，道路拥堵情况会根据时间变化，需要10秒更新一次，数据库中也需要存储历史道路交通拥堵数据，一年的数据量大概在几十GB。道路路面现状需要记录道路ID，出现问题的经纬度指标等，只需维护一个静态的关系型数据库，大概在MB量级。图 316 路况信息3.2.3.3 信号灯信息数据信号灯信息主要是指信号灯的位置、信号灯时长等信息，如图 417所示。该数据主要存储于市公安交巡警大队数据中心。信号灯信息是我们做城市智能信号灯控制的重要参考。信号灯信息属于静态数据，可以通过一个关系表进行维护，数据量在MB量级。但是如果进入智能信号灯实施阶段，需要一个能够进行快速I/O的高性能数据库，将计算中心通过结合车流量、车辆行驶轨迹预测、交叉路口分布情况所得到的信号灯时长，及时发给信号灯管理系统。图 317 信号灯信息3.2.3.4 交通事故历史数据道路交通事故数据记录了道路事故基本信息，包括事故编号、类型、地点、时间等，如图 418所示。交通事故历史数据是我们在做事故高发路段道路分析，用户车险合约智能评估的重要依据。该数据主要从市公安交巡警大队处获得。 交通事故数据可以通过一个关系型数据库进行维护，当有新的交通事故数据产生时，可以方便地添加进数据库。历史数据建议一直保留，一年的数据量大概在GB量级。图 318 交通事故历史数据3.2.3.5 公共交通数据公共交通数据主要包括班车调度信息，公交车GPS、离到站运行信息等，如图 419所示。公共交通数据可以帮助我们对城市有一个更深入的理解，为我们解决城市道路拥堵、城市道路规划问题提供参考，并帮助我们设计出合理、高效的新能源车租赁和拼车平台。该数据可以从市公交公司等政府部门获得。班车调度表和公交车路线图都是是一个很小的关系表，只在MB量级。图 319 公共交通数据3.2.3.6 城市规划信息数据与车联网相关的城市规划信息包括城市停车场布局，充电桩布局，工地信息等数据，如图 420所示。我们可以结合城市规划信息，对城市道路规划，新能源汽车租赁点布局，充电桩设备布局等问题制定更合理的解决方案。城市规划信息可以从市建等有关部门获得。相关信息也可以通过关系型数据库进行维护，数据大小在MB量级。图 320 城市规划数据3.2.3.7 车主信息数据车主信息包括车主驾驶证信息，出行轨迹、是否有违法记录、交通事故信息等，如图 421所示。车主信息可以跟其他信息相结合，构建出一个完整的用户画像。一个准确、全面的用户画像是车险智能评估、拼车用户推荐、提升用户驾驶体验等应用的基础。车主信息主要是通过4S店获得车主买车时留下的个人信息，在跟市政府部门、移动通讯公司等单位合作，完善车主信息。车主信息可以通过将各种信息汇集起来，构成一个关系型数据库。同时，在设计时，要与其他数据源的数据库相统一，为下一步构建用户画像打下基础。图 321 车主信息数据3.2.3.8 人流信息数据人流信息主要指城市市民的出行规律，需要采集的数据如图 422所示。城市人口流动信息可以帮助我们更深入的理解一个城市的运行模式，为城市道路规划、拥堵预警与疏导、新能源汽车租赁点布局，拼车用户推荐等应用提供参考。人流信息我们可以通过想市政部门申请一卡通数据或者移动通信公司的移动电话使用数据来分析获得。城市人口流动信息带有一定的规律性，每间隔5分钟，分析一下该时间点的城市人口分布，将各时间点的城市人口分布联合起来，就可以得到整个城市的人口流动模式。一般来说城市的人口流动模式不会发生重大的变化，但是我们可以记录下多年的数据来为下一步的打下基础，存储需要GB量级。图 322 人流信息3.2.4 市场数据3.2.4.1 市场调研数据市场调研数据是指通过问卷调查、用户AB测试、焦点访谈、用户访谈、用户日志、网上有奖调查等方式获得的用户最直接的对产品的某种需求的体现，如图 423所示。通过调研数据可以了解市场需求、确定目标用户、确定产品核心，找准产品机会缺口，然后衡量各种因素，制定产品战略线路，提高产品的销售决策质量、解决存在于产品销售中的问题或寻找机会进而系统，从而更好的制订市场需求文档。该部分数据需要通过调研获得，或者针对特定需求从相关的第三方购买。由于市场调研数据动态性不高，仅与调查的覆盖范围有关，数据量不大，在MB量级。图 323 市场数据3.2.4.2 销售数据销售数据的主要是指销售日期、区域、地点、销售渠道、产品、销售量等在产品销售环节产生的数据。市场营销是企业的命脉，针对销售分析的目的，确定数据分析的主要方向和重点。通过对销售数据的深入分析和统计，挖掘数据背后的规律和隐含的信息，可以提升企业的科学管理和科学决策的水平，制订有针对性和便于实施的营销战略奠定良好的基础。例如：通过对销售额和销售量的增长趋势的把握，可以找出客户增长或下滑的本质，是结构性增长还是容量性增长。该部分数据是从销售部门、4S店获取。数据大小在MB量级。3.2.5 环境数据环境数据如图 424所示。图 324 环境数据3.2.5.1 气象数据气象数据包含温度、方向、风量、雨量等。为车联网中的其他服务诸如汽车在极端环境下的稳定性设计、提升驾驶安全系数提供气象方面的支持。可以向政府气象部门申请或与第三方气象数据收集公司合作获得。气象数据一般需要与其他数据相结合，作为其他分析中的一个重要环节。所以需要注意标示气象信息的时间、地点等标志的格式与其他数据在数据库中的格式相统一。3.2.5.2 空气质量数据监测城市中的空气质量，分析城市空气质量的变化规律。空气质量数据的价值可以从两个方面理解，一方面是空气质量的变化给新能源汽车本身带来了哪些影响，新能源汽车在PM2.5较高的环境中，零配件状态是否会发生改变，还有就是随着空气问题的加重，用户是否更愿意选择购买新能源汽车。另一方面是新能源汽车是否可以减轻环境的压力，为空气质量带来改善，这也是环保部门比较关心的事情。因为新能源汽车对于空气质量的影响需要在新能源汽车大力推广、广泛应用之后，才能得到结论，所以这部分数据应该是一个长期积累的数据，要有几十年的保存计划。需要较为稳定的数据库，并及时做好数据备份工作。3.2.5.3 地理数据地理数据包括一个城市的经纬度信息、海拔信息、地貌数据、水文数据、河流数据、常发灾害等。地理数据可以反映出一个特定城市对于汽车车型是否有比较特殊的需求，厂商可以根据这种需求，设计出满足需求的车辆，并根据这种特殊需求，调整销售部剧 。地理数据一般都可以从国家基础地理数据库中获得。3.3 数据分类对于采集到的车辆数据，可以从三个方面进行分类：数据对应的子系统；数据重要性；数据实时性。图 325 数据的三个分类方法3.3.1 重要性车辆数据对应的子系统包括动力源、驱动装置等，已在前文讨论过。依据数据的不同用途，将其分为核心、重要、一般三个层级。数据的用途包括： 监测外部环境。通过在车上安装额外传感器（如摄像头、空气质量检测仪等），实现对车辆周围环境的监测。所采集到的数据可以反馈给公安、气象局等部门，分别用于治安管理和气象监测。这部分数据会直接交给第三方机构用于进一步分析，大数据平台不会长期保存。 监测关键零部件状态。如监测驱动电机的使能状态以及故障状态。这部分数据仅仅用于确认零部件是否正常工作，不用于建立物理模型。大数据平台会短暂保存这部分数据以备回溯分析。 建立用户模型。通过采集车辆加速踏板开度、制动踏板开度、方向盘转角、方向盘转动角速度等信息，可以建立驾驶员模型，从而对驾驶员群体进行分类，得到关于其驾驶风格的信息。结合其它方面的信息，如用户的性别、年龄、职业、消费习惯、消费水平等，可以得到完整的用户画像，并将其用于保费估计、精准营销等。 建立关键零部件模型。通过采集某个关键零部件（如电机、电池）的运行状态信息，可以建立相应的零部件模型。随着数据的不断积累，模型精度将不断提高。所得到的模型可以用于后续开发过程中的计算机仿真，也可用于预测零部件的剩余寿命以及工作状况，从而实现基于产品反馈的开发以及基于性能预测的精准维修。 建立车辆典型运行工况。考虑到大多数车主将车辆用于通勤，有必要采集车速、加速度、横摆角速度、横摆角加速度、GPS信息、实时SOC、实时电耗等数据，并通过数据压缩、序列预测等技术抽象出其典型运行工况。所建立的典型运行工况可以用于预测车辆在特定时间点的运行情况，从而实现功率管理策略优化、换挡规律优化、智能乘车环境等应用。 建立路况模型。基于每个车载终端实时反馈的车辆位置信息以及速度、加速度信息，结合道路智能终端（如智能路灯）采集的数据，可以获得某个路段的实时路况信息，包括车流量、拥堵情况等。随着数据量的增大，可以建立某个地点的历史路况模型，从而实现对未来路况的预测。 建立道路模型。在车上安装垂向加速度传感器后，可以实时采集车辆的垂向加速度信息，并将其用于推测车辆行驶过的道路的路面情况。这些信息可以提供给路政部门用于道路养护参考等。根据车辆的行驶轨迹，利用SLAM算法，可以建立道路拓扑模型，并与第三方地图供应商提供的地图数据进行对比，不相符的部分意味着车辆所行驶的道路可能未被地图软件收录。这些信息可以帮助地图供应商完善其地图数据。上述应用中，用户模型和车辆模型是整车厂最关心的，因此认为与之相关的数据是核心数据；道路模型和路况模型相关的数据属于重要数据；用于监测车辆内外部环境的数据仅需保留较短时间以备回溯分析，属于一般数据。图 326 数据重要性分层3.3.2 实时性车辆数据可以分为实时数据（动态数据）和非实时数据（静态数据）两类。如前所述，静态数据即车辆从出厂后到交付用户之前所拥有的数据，它反映了整车以及关键零部件的配置信息；动态数据即车辆在运行过程中所产生的数据，它反映了车辆的动态运行情况。其中，实时数据又可分为强实时数据以及弱实时数据。强实时数据包括电压、电流、压力、功率、加速度、转动加速度、故障信息等被积分量，弱实时数据包括位移、速度、角度、角速度、温度、能量、SOC等积分量。区分强实时数据和弱实时数据的目的是对具有不同实时性的数据采用不同的采样周期。对于前者，由于其时间常数较小，建议将采样周期设置为0.1s；对于后者，由于其时间常数较大，建议将采样周期设置为0.5s。具体采样周期需要根据实车CAN网络上相关信号的发送周期确定。根据电动汽车远程服务与管理系统技术规范规定，车辆数据上报的时间周期不得超过30s；出现3级报警时，应上报故障发生时间点前后30s的数据且信息采样周期不得超过1s，其中故障发生前的数据以补发形式传输。同时，对数据量及带宽限制加以考虑，建议将上传周期设置为1s。3.3.3 数据量估计根据电动汽车远程服务与管理系统技术规范规定，各个信息体的大小大致如下图所示，总计约200 Byte。但是国标中只规定了主要子系统的状态信息，数据量较小。实际上，一辆纯电动汽车所有报文的总数据量约为1000 Byte，考虑到未来大数据平台可能拓展至数据量更大的多储能装置、多驱动装置的混合动力汽车，每次上传的数据量最大为2000 Byte。图 327 每次上传数据量假设每辆车上传数据的周期是1s，数据在云端保留3年，前期支持1万辆车的数据采集，则总数据量为220024360036531104 Byte2 PB2000TB另外，由于大数据平台采用Hadoop配置，为了满足为了满足可用性要求，每份数据需要存储3份，因此硬件存储容量需求为6 PB。4 大数据平台架构4.1 平台需求分析4.1.1 平台目标新能源汽车大数据平台希望实现下述目标：u 新能源汽车生产、市场、运行、供应链等数据的采集与存储u 政府、互联网、合作伙伴、第三方等数据的采集与存储u 支持实时和非实时的数据分析u 支持主流的并行化统计算法和机器学习基础算法库u 支持对外提供数据服务u 提供可视化的数据展示4.1.2 功能需求4.1.2.1 非结构以及半结构数据采集和存储目前，非结构及半结构数据主要包括：车辆生产和运行数据、系统日志、图像、视频以及语音等，这些数据分散存放在各个系统中，对这些数据的检索和分析，目前存在诸多不便。大数据平台实现对这些数据的存储，并在存储过程中对部分附加信息加以结构化处理，使得具备对这些数据的检索和统计能力。4.1.2.2 实现和结构化数据平台的互通目前结构化数据主要存在Oracle、Mysql、SQL Server等几种数据库环境中，在大数据平台搭建之后，需要建立结构化数据库系统和大数据平台的数据通道。一方面，需要把传统关系数据库的数据加载到大数据平台中进行存储，以供计算。另一方面，也要把计算的结果能提供给关系型数据库，使前台应用能够使用计算结果数据。形成双向数据交换的ETL模板开发。4.1.2.3 数据的计算、建模和展示提供已经收集到系统中的数据查询、计算并进行展示，并能提供接口和推送服务，为第三方系统和应用提供数据基础和计算能力。4.1.3 技术需求4.1.3.1 数据采集存储数据采集存储的技术需求包括：1) 对多种结构化数据源的采集对多种结构化数据源的支持，主要包括常见的数据库Oracle、MySQL和SQL Server。2) 半结构化数据的加载支持对各类半结构化数据的采集、解析和处理；半结构化数据主要指车辆运行数据、系统日志等数据。 3) 非结构化数据的存储非结构化信息主要包括：文档、图像、视频以及语音等，这些非结构化数据分散存放在各个系统中，对这些数据的检索和分析，目前存在诸多不便。大数据平台实现对这些数据的存储，并在存储过程中对部分附加信息加以结构化处理，使得具备对这些数据的检索和统计能力。4) 增量采集和断点续传该需求主要包括a)定时增量采集；b)全量采集时，在网络或进程故障恢复后，能够支持断点续传。5) 支持压缩传输数据压缩传输可以减少网络流量，提高数据采集速度。6) 传输数据的一致性检查海量数据迁移，必须要有手段和机制来验证源数据与目的数据的一致性和完整性。7) 定时任务采集，保证错峰运行为了保证数据采集过程不影响业务系统的正常运行，需要考虑数据采集可通过定时任务的方式进行错峰运行，特别是关系型数据库的数据采集。8) 提供数据采集接口大数据平台提供定制的API接口，用于支持实时数据采集。4.1.3.2 数据处理数据处理是数据整合的一个重要阶段。本平台中对于数据处理的需求主要来自下面几个方面：1) 车辆生产运行数据、日志数据的解析(Parse)、扩充(Enrich)和序列化存储2) 数据格式转换3) 数据的压缩与解压缩4) 数据加密与解密5) 数据治理4.1.3.3 高性能1) 支持PB级别海量数据的采集、分布式存储和分布式运算。2) 支持分钟级实时数据采集、运算和查询。4.1.3.4 数据完整性1) 大数据平台底层系统支持u 数据高容错；u 数据冗余；u 数据完整性检查；2) 保证数据采集和加载后的数据一致性；3) 数据完整性保障除了能应对系统故障外，还应能处理用户和应用错误导致的数据无意或有意删除，这要求大数据基础平台能支持下列功能：u 回收站功能。用户删除的数据自动进入回收站。通过回收站的数据恢复功能可以恢复用户无意删除的数据。u 数据快照(Snapshot)。数据快照可以根据策略定时执行快速快照功能（如每小时自动快照）。管理员可以根据需要将系统恢复到上一个快照点，来实现数据恢复的目的。u 自动化异地容灾。4.1.3.5 用户交互对数据的处理以及系统的监控，有比较好的交互界面。1) 系统接口需求u 提供API等第三方交互接口及详细的文档说明，供第三方或自主开发的系统调用，接口功能覆盖完备。对输入与转换后输出的数据进行内容与格式上的核对，如出现传输错误则需要生成错误日志并发出警告。u 系统应提供确保数据质量的相关功能、工具和方法。2) 系统监控需求u 提供对处理流程及其状态的监控功能，在异常事件发生时，可方便的通过监控界面定位和解决问题；u 提供对批处理脚本运行状态、结果、起讫时间的监控，可方便的定位运行出错脚本，查看出错日志，并组织重新运行。u 提供系统Service的监控、出错定位及纠错功能；4.1.3.6 系统需求1) 安全性u 系统对全部业务操作日志留痕并永久保留，提供日志查询功能。2) 稳定性u 系统要求7 x 24小时稳定运行。u 系统应具备监控服务，当服务异常时能够及时报警。3) 高可用性u 系统需满足高可用的部署要求，核心组件必须部署冗余应用并支持快速切换或接管。u 系统能提供全面的备份恢复策略和管理系统，包括维护用于日后恢复的备份版本和日志。备份恢复操作应自动化、可调度。4.2 总体设计4.2.1 概述方案整体架构采用基于Hadoop的数据平台架构。Cloudera Distributed Hadoop（CDH）是业界使用最广泛的开源稳定版Hadoop平台，后续的方案设计都基于CDH进行描述。具体架构图如下图5-1所示：图5-1CDH平台架构图4.2.2 设计原则根据新能源汽车大数据平台的要求，在考虑整体方案设计时，将依照下述原则进行设计。l 科学性。大数据平台的设计应遵守科学方法，有步骤、有系统地进行；l 完整性和前瞻性。方案应该是完整的，并具有前瞻性，能够满足新能源汽车5年或更长时间的业务需求；l 可实施性。方案应该结合方案征集方的实际，是可实施的，实施风险是可控的；l 持续改进。大数据平台项目结束后，方案征集方有能力进行自我的完善和改进。同时，根据多年来的大数据平台建设使用经验考虑以下设计原则：1) 系统弹性面临突发性高业务量涌入，大数据平台架构层面应具备足够的弹性，以应对突发的高峰数据涌入。当出现业务波峰时，大数据平台除了能平稳应对上游系统的波峰压力，保障自身的高可用外，还应能缓冲对下游系统的压力。同时，大数据平台在设计系统架构时，应考虑系统在下述情形时也能保障上下游系统安全可靠运行，同时业务数据不丢失。a）大数据平台因突发事件或故障导致完全宕机。b）大数据平台停机维护。c）大数据平台系统升级。2) 产品成熟度大数据生态环境由多个Apache开源项目/产品组成。这些项目/产品很多都来自于互联网公司多年的运营管理经验，其功能可以为企业带来较高的价值；同时由于开源社区的贡献，这些产品版本迭代速度也很快。但这些产品往往也存在一些缺陷：a) 产品成熟度不如传统商业软件；b) 产品设计未考虑企业复杂的IT环境 。在这种情况下，选用的组件部署上去后，很有可能出现水土不服的情况，导致项目出现各种问题，甚至失败。因此在架构设计中，还需要综合考虑产品成熟度。这非常考验供应商在开源产品上积累的经验教训。3) 安全易用平台应在技术和管理上确保系统的各个环节的安全。同时设计要遵循简单原则，即平台设计应方便用户的使用。平台维护和管理也应遵循高效、便捷、易于维护管理的原则。4.2.3 架构设计我们建议的大数据平台系统架构图如下图所示。架构采用了大数据领域常见的Lambda架构作为基础，同时借鉴了LinkedIn的系统架构，在数据上游增加了一层采用Kafka为基础的数据落地层。图5-2大数据中心总体架构流程图4.2.3.1 Lambda架构介绍Lambda架构是一种面向大规模流式处理的解决方案，它结合批处理与实时处理以实现可扩展性和容错。Lambda架构如下图5-3所示：图5-3 Lambda架构示意图Lambda的两条重要原则：a)数据输入是不可变的；b)原始数据输入可以被再处理用以重新输出结果。保留原始输入允许我们处理数据，即使以前所未有的方式也无所谓，还能在因不明原因损坏数据的情况下提供恢复机制。当需要新的输出时，或前一个版本的处理代码有bug导致输出不正确时，都需要再处理数据输入。1) 批处理层(Batch Layer, Apache Hadoop)批处理层主要由Hadoop来实现，负责数据的存储和产生任意的视图数据。计算视图数据是一个连续的操作，因此，当新数据到达时，使用MapReduce迭代地将数据聚集到视图中。将数据集中计算得到的视图，这使得它不会被频繁地更新。根据你的数据集的大小和集群的规模，任何迭代转换计算的时间大约需要几小时。2) 服务层(Serving layer ,Cloudera Impala)服务层是由Impala框架来实现的，整体而言，使用了Impala的主要特性。从批处理输出的是一系列包含预计算视图的原始文件，服务层负责建立索引和呈现视图，以便于它们能够被很好被查询到。由于批处理视图是静态的，服务层仅仅需要提供批量地更新和随机读，而Impala正好符合我们的要求。为了使用Impala呈现视图，所有的服务层就是在Hive元数据中创建一个表，这些元数据都指向HDFS中的文件。随后，用户立刻能够使用Impala查询到视图。3) 加速层 (Speed layer,Spark, Cloudera Search)Hadoop和Impala是批处理层和服务层极好的工具。Hadoop能够存储和处理PB级（petabytes）数据，而Impala能够以秒级快速且交互地查询到这个数据。可是，批处理和服务层单独存在，无法满足实时性需求。原因是MapReduce在设计上存在很高的延迟，它需要花费几小时的时间来将新数据展现给视图，然后通过媒介传递给服务层。这就是为什么我们需要加速层的原因。在本质上，加速层与批处理层是一样的，都是从它收到的数据上计算而得到视图。加速层就是为了弥补批处理层的高延迟性问题，它通过Spark或Cloudera Search或二者结合的框架计算实时视图来解决这个问题。实时视图仅仅包含数据结果来提供批处理视图。同时，批处理的设计就是连续重复从获取的数据中计算批处理视图，而加速层使用的是增量模型，这是鉴于实时视图是增量的。Lambda架构可以兼顾实时处理和非实时处理。针对新能源汽车当前的非实时数据处理需求，系统可以使用下图黄框所示的组件进行数据处理。其中MapReduce或Spark作为可选项，可以根据需要进行增减。图5-4 大数据中心批量处理功能而针对新能源汽车需要的实时数据处理需求，系统将使用下图蓝框所示的组件进行数据处理。其中Spark Streaming作为可选项，可以根据具体需求进行增减。图5-5 大数据中心实时处理功能4.2.3.2 数据落地层介绍数据落地层是大数据平台非常重要的一个组成部分，考虑到系统整体可扩展性、弹性和易维护性设计原则，我们建议将数据落地层作为平台的一个组成部分。数据落地层主要完成是下述几个部分工作：1) 数据汇聚数据汇聚可以将企业内部复杂的数据上下游系统之间的关系（如下图所示）简化成更易于管理的结构。图5-6数据落地层设置前后对比图2) 数据缓冲数据缓冲可以增强大数据平台的整体弹性，应对突发的高峰数据涌入。3) 数据重放数据落地层可以根据业务需要保留足够时间的数据，可以在因不明原因导致数据损坏或数据计算不正确的情况下通过数据重放提供恢复机制。4) 数据格式转换数据落地层可以根据业务需要进行数据格式转换。例如，非结构化数据解析成结构化数据。5) 原始数据隔离检疫 (Quarantine)外部系统采集的原始数据往往夹杂着很多无效数据、异常数据，数据落地区可以根据业务需要过滤、清洗和数据补全。4.2.3.3 数据采集存储企业的信息系统绝大多数都采用成熟的商业软件和硬件，具备标准化的数据访问接口。下游系统都可以通过数据访问接口获取数据。而一些好的工具可以使这个过程变得更加轻松直接。如下图5-7所示：图5-7 针对不同数据源的不同工具CDH平台具有多种数据源访问和数据采集工具，可以支持下列数据源的采集：u 共享日志文件u 关系型数据库u TCPu SNMPu Syslogu NetCatu Windows Event Logu Avrou Thrift根据不同的业务系统和实时要求，我们建议采用下图所示三种数据采集模式：图5-8 数据采集的三种模式模式一：导出文本文件u 定时任务将数据以文本格式导入到NAS存储。数据采集服务器使用flume将日志从NAS实时写入总部的Kafka服务器。u 优点：服务器可主动选择写入NAS的时机；高可用NAS提供更多的数据冗余；上下游系统耦合度低，有更好的弹性机制。下游系统故障，可重新导入NAS数据。u 缺点：服务器可能需安装Agent，