交通信息路况分享资料

交通信息路况分享资料2021.11世纪高通处理系统-实时路况覆盖数量：交通信息覆盖全国340+城市，包括主要高速、国省道，主要通勤道路覆盖率达70%-90%。准确率：封闭道路的准确率高达90%，实现100米高精度表达。更新频次：1分钟快速更新。输出规格：基于link的CNTF发布规格：支持TPEG、TMC、RTIC等全球及中国多种技术标准。处理系统整体架构

路况处理主要是通过不同数据源实时回传的原始车辆轨迹数据，经过路网匹配、路径推测、单车多车融合计算、发布出基于link级别的路况；数据源滴滴两客一危浮动车中寰戴姆勒交通流处理引擎数据总线-Kafka数据存储-Hadoop、湖、数据同步、转发接口标准路况分车道路况亚Link路况数据接入处理系统清洗轨迹积攒推测匹配融合系统单车融合发布系统多车融合多源融合城市分组填补平滑特殊模型处理服务端客户端实时处理离线分析数据轮转数据分析挖掘回溯系统模型训练数据分析数据挖掘数据评价自评价竞品评价处理系统-匹配模块一、匹配系统技术架构（storm）采用Master/Slave体系结构，分布式计算由Nimbus和Supervisor两类服务进程实现，Nimbus进程运行在集群的主节点，负责任务的指派和分发，Supervisor运行在集群的从节点，负责执行任务的具体部分。Storm的核心组件：Nimbus：负责资源分配和任务调度。Supervisor：负责接受nimbus分配的任务，启动和停止属于自己管理的worker进程。Worker：运行具体处理组件逻辑的进程。Task：worker中每一个spout/bolt的线程称为一个task｡同一个spout/bolt的task可能会共享一个物理线程，该线程称为executor。处理系统-匹配模块Topology：计算拓扑，Storm的拓扑是对实时计算应用逻辑的封装，可以理解成由一系列通过数据流（StreamGrouping）相互关联的Spout和Bolt组成的的拓扑结构。Stream：数据流（Streams）是Storm中最核心的抽象概念。一个数据流指的是在分布式环境中并行创建、处理的一组元组（tuple）的无界序列。Streamgrouping：为拓扑中的每个Bolt的确定输入数据流是定义一个拓扑的重要环节。数据流分组定义了在Bolt的不同任务（tasks）中划分数据流的方式。在Storm中有八种内置的数据流分组方式。Reliability：可靠性。Storm可以通过拓扑来确保每个发送的元组都能得到正确处理。通过跟踪由Spout发出的每个元组构成的元组树可以确定元组是否已经完成处理。每个拓扑都有一个“消息延时”参数，如果Storm在延时时间内没有检测到元组是否处理完成，就会将该元组标记为处理失败，并会在稍后重新发送该元组。处理系统-匹配模块Spout：数据源（Spout）是拓扑中数据流的来源。一个Spout可以发送多个数据流。Bolt：拓扑中所有的数据处理均是由Bolt完成的。通过数据过滤（filtering）、函数处理（functions）、聚合（aggregations）、联结（joins）、数据库交互等功能，Bolt几乎能够完成任何一种数据处理需求。一个Bolt可以实现简单的数据流转换，而更复杂的数据流变换通常需要使用多个Bolt并通过多个步骤完成。处理系统-匹配模块二、匹配系统业务模块（一）TrafficProcessSpoutHandle（数据拉取）作为程序的spout，对数据进行拉取，并按照不同topic进行分类，为后续bolt做准备。数据类型：1101=stl（标准接入数据）F101=org（未处理的原始数据）4101=daliy（日更新数据）过滤条件：1、当前时间-数据存入kafka时间<300s发射条件：1、积攒的数据批数>设定量(低频1、高频10)2、与上次发射时差>1s且积攒数据量>0处理系统-匹配模块（二）TrafficProcessBoltParser（数据解析）1、以供应商编号_车辆标识的哈希值分组（3000组）的原因：防止每次都发送，数据太碎，但数据量也不能太大，防止线程处理不均匀，3000为经验值。2、滴滴车状态过滤：（1）已收车（2）到达乘客上车点3、速度、方向过滤：不可信设置为-1speed<0||speed>180head<0||head>3604、数据延迟过滤

stl延迟在300s以内处理系统-匹配模块（三）TrafficProcessBoltFilter（积攒抽稀/过滤）1、fieldsGrouping（分组）：按照carGroupId分组，只代表相同carGroupId使用相同的元组来直行，不是一个元组只处理一种carGroupId数据。2、过滤：（1）公司附近的点过滤（北京，上海，沈阳，广州，陕西），防止公司有测试设备造成异常数据（2）时间乱序的点：新的点比之前的点时间还早（3）未来的点：gps时间在当前时间之后（4）重复时间的点（5）超过300s的点3、gps置信度：速度>20&&（gps方向、gps前点连线方向差<15orgps方向、gps后点连线方向差<15）4、缓存：（1）缓存内有上次剩余的2个点，为了方便计算gps点之间的夹角（2）每次发射数据会发射缓存的第二个点与新进入的非最后一点数据（3）缓存更新，保留新进入的最后两点数据5、发射数据：carId：车辆标识cellgpsPointList：根据车辆id，cellId，分组的点列表处理系统-匹配模块（四）TrafficProcessBoltMatching（匹配：获取备选link）1、LineString介绍：link为一个lineString模型，即多个点连接成的线，故判断gps点与link的最短距离，会经过多次判断。2、备选link筛选：（1）初步筛选（去掉一个cell内的非备选link）1）gps点方向角与link首尾连线角度>902）垂足在起点外：gps点与起点距离>553）垂足在终点外：gps点与终点距离>554）垂足在线上：gps点到线的最短距离>555）link首尾点夹角与gps夹角、gps前点夹角、gps后点夹角>45（3个均满足）6）gps可信&&GPS方向与link方向的夹角>90（2）深度筛选

1）按照gps与link距离排序 2）按照距离由大到小遍历，记录第一个垂足点在link上的数据，删除之前遍历到的数据 3）若备选link数>10，只保留垂足距离最短的10个3、权重计算并重新排序：

点到link的距离，gps夹角、gps前点夹角、gps后点夹角最小值，通过比例计算设定权重处理系统-匹配模块（五）TrafficProcessBoltCache（积攒：主要判断扎堆点）处理系统-推测模块核心算法

/pages/viewpage.action?pageId=7145710推测的作用：根据单车带有备选link的点对路径，结合预先编译好的路网信息，选择一条最合理的路径。处理系统-推测模块特殊模型-红绿灯模型

/pages/viewpage.action?pageId=7146051红绿灯与普通道路不同，它定义拥缓和计算速度的方式也不同；

红绿灯路链打断原则：1）路链长度限制350米：当路链长度不满足350米，但追加下一Link，路链长度不足600米，保留下一Link到路链中，长度超过600米，不保留下一Link。（即：存在250米的buffer）2）当路链长度不满足打断条件，但遇到其他红绿灯，则进行打断3）当路链长度不满足打断条件，但遇到收费站点，则进行打断。处理系统-推测模块特殊模型-不确认模型由于要计算分车道路况需要，需要对车辆轨迹进行积攒判断车辆行驶方向，但是当在发生拥堵时，会造成拥缓路况的延迟发布。处理系统-推测模块特殊模型-加油站模型

一般城市内加油站大部分都位于到边，很容易造成因加油异常停车点匹配错误，造成主路误发拥缓路况。处理系统-推测模块特殊模型--隧道模型

由于隧道中信号弱，容易造成点堆积或点异常导致路况计算错误。处理系统-推测模块--处理流程

处理系统-推测模块-与匹配通讯机制、负载与分区管理

处理系统-融合模块，整体结构

融合模块整体处理流程以及数据流转类型处理系统-融合模块之MINISpoutHandle模块简介：融合模块是基于Jstorm框架的处理服务、上游对接“推测处理模块”，MINISpoutHandle就是用于获取推测处理结果的服务接口。涉及的数据类型：Trajectory类型(Byte数组):记录了设备信息，CancelSDR信息，ConformSDR信息、UnConformSDR信息类型简介：Trajectory:两个点中间的所有路径信息，它由有一组或者多组SDR链路组成。Trajectory处理系统-融合模块之MINIDecoderBolt模块简介：负责将MINISpoutHandle模块获取的数据进行规格转换（Trajectory->JLINK）。涉及的数据类型：SDR：Trajectory数据中的存储数据规格JLINK(BatchJlink):基于SDR信息，按照LINK和点位置打断结果数据，同样也包含Cancel、Conform、UnConform信息类型简介：SDR：从起始点到结束点的一条LINK链路JLINK：基于LINK和点的数据打断处理结果SDRJLINK类型值说明Cancel2解除用纠正之前发错的UNConform0参考这用待转的，不能确定的Conform1放心用明确分方向状态处理系统-融合模块之JlinkAccumulateBolt模块简介：负责将MINIDecoderBolt模块获取的BatchJlink转换融合成RTCNTF数据getSubLinkStrategy处理系统-融合模块之JlinkAccumulateBolt模块单车融合算法：处理系统-融合模块之JlinkAccumulateBolt模块多车分段融合简介：异常车过滤（完走率、异常车速、不确认车辆选取、速度离群等）多车分段融合跳变检测⻋少处理

多车融合：基于多车分段融合的结果，按照Section信息计算整体CNTF的路况信息，并将结果同步给下游服务。处理系统-分组模块

处理流程：接收数据：从kafka实时读取，RTCNTF、CNTI和TXCNTF数据解析：解析kafka的CNTF和CNTI数据分城市：根据link2City对数据分城市，TXCNTF重新按照我们的位置参考分城市缓存：分好城市的数据缓存发布：写Couchbase，通知Zookeeper功能：交通流、事件数据分城市依赖组件：Kafka、Jstrom、Couchbase、Zookeeper、Caffeine处理系统-分组模块

数据：目前分组接的数据有RTCNTF、腾讯CNTF、全量事件和jamtail事件，jamtail事件会在分组中与全量事件融合，供车厂使用分城市：CN的数据与腾讯的数据接入的方式不同，CN的数据是流式分散的，而腾讯是每个城市一个包接入的，所以还修改过分城市的方法缓存：热度缓存，之前分城市缓存的结构按照link为key查找城市，但腾讯数据一批过来的，如果再按照link取城市会有性能问题，所以现在缓存的结构式按照mesh查找积攒：为了提高性能，解析后的CNTF会积攒500条或5分钟以上的数据，然后做分城市处理系统-分组模块

发布：时机：CN每30s将缓存的数据写入Couchbase，并通知Zookeeper；腾讯的CNTF每分钟50S入库并通知，50s的原因是腾讯数据每分钟50s之前会全部接完，并且发布模块需要在整分钟之前接受到数据，参与到下一分钟和CN数据融合。分包：大城市会分包写入，每个包250000条数据，然后通知的时候会写入分包信息分组Zookeeper通知页面处理系统-分组模块

部署：目前部署两份分组在不同的Strom集群，分别处理CN的CNTF/CNTI数据和腾讯的CNTF数据，如下图CNRTCNTF分组TCTXCNTF分组处理系统-发布模块

处理流程：注册/负载：服务节点注册到zk，实现负载均衡监听：监听负载到的城市前段数据的变化初始化：从cb中获取节点负载到的城市的匹配表缓存：监听到数据变化后从cb中获取数据，放入内存编码：将rtcntf、txcntf数据融合编码，生成pubcntf发布：编码结果写回cb和kafka，并通知zk功能：RTCNTF编码转换PubCNTF发布依赖组件：Kafka、Couchbase、Zookeeper处理系统-发布模块

注册/负载：目前CN的发布有10个节点，腾讯融合环境15个节点；每个节点一个进程，程序启动时将节点注册到zk集群，通过城市列表配置文件所有注册的节点会负载配置的城市，并且城市列表有每个城市数据大小，所以所有节点会按照大小均分城市，从而实现负载平均，不会出现资源使用不均的情况；同时掉节点也会触发重新负载处理系统-发布模块

监听：前段分组处理完成后，会想zk写通知信息，发布模块会分城市监听通知的节点，如右图，当监听到节点变化时拿到节点上的信息，然后触发后续的操作；目前腾讯融合环境比较特殊，会同时监听CN环境的通知和腾讯环境的通知初始化：节点会根据分到的城市监听数据，同时编码需要的配置文件也是只加载当前节点分到的城市，所以在分完城市后会初始化内存中的配置文件数据，重启和节点与zk断连等使节点注册变化的情况都会重新初始化缓存：监听到数据变化后，会从cb取数据然后放入内存，再后续编码操作；腾讯融合环境，监听到腾讯数据变化，取数据然后只放入内存，等到监听到CN数据变化时，才与腾讯的数据，融合然后编码处理系统-发布模块

编码：以腾讯融合环境为例时间及分段填补：主要功能是从多个RTCNTF选出基础CNTF，link分段填补和一些过滤外挂原则腾讯融合模型：CN与腾讯的数据根据规则融合深夜模型单辆车计算拥堵不发布6等级一辆车拥堵不发布特殊道路处理：收费站、隧道模型空间填补分段合并：合并逻辑短小linkSeq平滑逻辑将分段路况中路况状态一致的分段进行合并处理系统-发布模块

时间及分段填补车少拥缓不发布：当前时间三辆车拥缓时，前三分钟没有车，不发布；当前时间没有数据，上一个时间戳三辆车拥缓，前三分钟没有车，不发布BMW周边l定制化策略主干路：早晚高峰时段，正常逻辑处理；非夜间时段，拥缓状态在车辆数多时（大于等于3辆车）可发布；夜间时段（车辆数大于等于7辆），拥缓状态可发布次干路：早晚高峰（交通的早晚高峰而非上下班的早晚高峰）时段，拥缓状态在车辆数较多（大于等于3辆车）时可发布。其他时段，全部发绿支路：全天24小时发布绿色特殊link：当前时间车辆数<=3，前两分钟没有拥缓，当前时间戳不发时间和分段填补处理系统-发布模块

腾讯融合模型（腾讯数据时间3分钟以前的不用）隧道模型：linkSeq基础，优化隧道模型，隧道全用腾讯，如果CN与腾讯全部一致，不使用腾讯收费站模型CN无路况，使用腾讯数据，不全部分使用腾讯存在部分的路况填补绿CN有路况，先走收费站模型，计算出路况，然后与腾讯路况做对比，CN如果拥缓，TX畅通，使用TX路况，其他情况使用CN自己路况检查站：CN未发布或者CN发布畅通且腾讯发布拥缓，使用腾讯的路况非特殊场景融合逻辑：ERTIC分组用腾讯数据补充CN未发布的如果ERTIC内CN所有link状态均一致，则使用CN路况整个ERTIC如果有一个link与腾讯发布一致，整个ERTIC使用腾讯的路况，并不参与合并逻辑处理系统-发布模块

腾讯融合模型（腾讯数据时间3分钟以前的不用）深夜模型（22:00

–

6:00）CN无路况时，因TX填补导致的深夜拥缓误报比例较高，故只保留0等级拥堵时使用TX填补当满足融合逻辑时，且只有0等级，其中拥缓路段路况与腾讯一致时，当CN拥缓路况对应的车辆数>=3辆车时，才与腾讯融合；其余所有情况不与腾讯融合。当CN的路况发布拥缓，TX发布畅通时，使用TX畅通路况拥缓优化如果高通状态为2,3；腾讯状态是4,5，整个ERTIC状态使用腾讯路况状态0等级主路CN缓慢，腾讯畅通，整个ERTIC状态使用腾讯路况状态处理系统-发布模块

单辆车计算拥堵不发布：车辆数小于等于1并且非畅通，判断一下之前该状态RTCNTF的占比如果大于65%，则该状态可以发布6等级一辆车拥堵不发布车辆数等于1，非畅通，6等级速度小于10或者发布时间与数据时间相差大于299满足以上条件拥缓修改为畅通，填补标识修改为11单辆车计算拥堵路况不发布特殊道路处理隧道模型：思想是用隧道前后link的路况填补隧道中的路况处理系统-发布模块

特殊道路处理收费站模型收费站后按照正常link计算，收费站前走收费站模型收费站前影响link，若存在腾讯填补的link，则收费站前整体均不走模型收费站前影响link，若都没有路况，则默认发布畅通将收费站前按照距离分为0-100、100-200、200-300、300+重新进行自由流计算（速度加权）同时对0-100、100-200、200-300、300+进行基础速度设定，用新计算的自由流与其比对，哪个小用哪个0-100，20km/h；100-200，35km/h；200-300，45km/h；300+，60km/h重新计算出车辆畅通的时候通过收费站的时间预估领卡需要耗时10s，缴费耗时15s，收费站前畅通车辆数[0，5]，缓慢车辆数（5，10]，拥堵车辆数（10，15]，极度拥堵车辆数>15。则可以计算出，畅通、缓慢、拥堵对应的等待时间用车辆的实际通过时间-车辆畅通时通过收费站的时间=车辆的等待时间，用等待时间匹配等待的拥缓区间，则算出收费站的整体状态隧道模型处理系统-发布模块

空间填补如果ERTIC包含腾讯的CNTF，反复用小状态的link填补没有路况的link，保证ERTIC所有的link都有路况（高速除外）判断CNTF是否能用于空间填补，只要拥缓才判断，条件如下被填补的link比填补的link长度差距小于三倍填补的link车辆数不小于3填补的link数据时间和数据发布时间不大于3分钟填补->只有一侧有路况，畅通状态直接填补；非畅通如下条件发布时间与数据时间间隔小于2分钟，直接进行填补发布时间与数据时间间隔大于2分钟，车辆数大于6，直接填补；3-6之间，相同状态