标签：str 评分 时序 hbase 项目分析 实时 并行 产生 编码
项目需求：①实时分析；②历史查询
实时分析：要求按趟计算超速情况，夜间驾驶情况，疲劳驾驶情况，驾驶里程情况，分别计算各项得分，然后计算综合得分。
历史查询：要求岸田查看各趟情况，每趟中可选择查看每一次违规驾驶行为的详细情况。
项目分析与实施方案，首选大数据方案，在平台选择方面，必然选择流计算平台，主要可选方案是spark和storm，spark1中的spark stream是使用小批量处理来模拟流计算，并不是完全的实时计算。
spark2.0中提供了基于dataset\datefram接口的流计算，与storm一样是事件驱动的，是实时的的流计算，但是还不够成熟，而且spark的计算模型要求所处理的元素需满足交换律和结合律，
而storm的reduceAggregator不要求满足这两条定律，公司设计的驾驶行为评分模型就是不满足交换律和结合律的，因而只能选择storm平台。
吐槽一下：并不是什么任务都是和大数据技术的，不少公司就是为了用大数据二用大数据，就是为了这个噱头，而且模型设计也没设计好，原因就是没有从根本上弄清楚大数据应用的基本条件，就是要满足上述两个定律。
storm虽然可以在不满足上述定律的情况下使用，但是效率就低了很多，并发度最多只能达到一辆车一个线程，而满足交换律结合律两个定律的计算模型可以达到一辆车对应多个线程，大大提高并发度。
更常见的情况是小公司根本没那么多数据，却非要用大数据技术来装逼。
具体分析：
实时分析：针对每辆车进行聚合分析，该聚合分析有严格时序要求，storm并不能算是内存计算框架，并没有提供对计算的中间结果进行内存缓存的API，数据只能在载入后一条线计算，得到结果，不能有多条支路，从而服用中间计算结果，
而这往往是需要的，本项目就需要这个功能，也就是说超速、夜驾、疲驾、驾驶里程的分析只能春兴分析，要并行分析则要分别中心加载原始数据，必然造成更多计算的浪费。
数据的串行流向必然引起数据在各分析节点上的变化，主要是关于个计算节点要保存那些数据到数据库，那些数据是该计算节点自身独有的，还有哪些数据是要传递的给下一计算节点的，这部分内容需要详细分析，稍后分解。
历史查询：实际上所有结果都已经在实时分析时产生了，问题在于如何使历史查询更加高效方便，该项目数据存储选择的是hbase，对于实时评分模型，项目要求每一个事件发生的时间点又有一个分值（包括各分项值和综合值），
除了实时分值，历史查询主要包含以下几部分内容：①按日期查询的多趟数据，每一天包含在改天结束的趟次和在该天开始的趟次，也就是说一趟驾驶行为可能属于前后两天；②对于违规驾驶行为，每一次违规行为都要有详细情况，
所谓的详细情况包括：
1、超速驾驶：首先要提供任一趟的超速频度，而且，所有超速点都被列出详细情况，包括速度、超速程度、经纬度（用于地图匹配）等
2、夜驾行为：夜驾行为没有频次，因而只序列出趟内所有夜驾点的详细情况
3、疲劳驾驶：疲劳驾驶与超速驾驶类似
4、驾驶里程：驾驶里程分析最为简单，只需驾驶里程和经纬度即可。
备注：以上四种驾驶行为的统计量并没有加上分值，需要的话也可以加上。有一个重要的却没有实现的功能就是直接按键查询一次超速、一次疲劳驾驶的起始时间，截止时间等，而是需要查询者自行分析。
实质上可以把按键查询一次违规驾驶事件是一个小粒度查询，按天查询时一个大粒度查询，他下面有按趟次查询，最小粒度查询就是按事件时间查询了，之所以没有提供按违规事件查询是没有找到得到键的方法。
以上是编码一段时间之后的事后分析，下面是具体编码分析，首先是获取原始驾驶数据（原始驾驶数据由kafka提供），将原始数据解析进一个类中（使用driveEvent类表示一次驾驶事件），driveEvent包含车辆信息，速度，事件、经纬度等。
在进入下一处理节点之前，必须要深刻理解storm的编程模型，书要是聚合模型和存储模型。
标签：str 评分 时序 hbase 项目分析 实时 并行 产生 编码
原文地址：http://www.cnblogs.com/cenglinjinran/p/6935637.html
