先来讲讲使用业务场景?
为了商家的安全保障，也是服务保障中的基础之一。
用户下完订单，商家可以在详页把当前订单分享给其它朋友，类似于滴滴打车，将自己的行程路径分享给亲朋好友，可以时时查询当前路线，位置，保证商家行程安全.
app（android/ios）上报商家gps打点数据，实时上报经纬度，持续跟踪商家位置
同时让商家可分享自己的行程给朋友，分享渠道可分享微信 QQ等
在微信中可分享其它朋友及朋友圈，保障商家行程的安全
场景示例图解：
2
目标-打造成基础服务化
建设基础数据服务平台
采点后期数据分析，人物画像
支持高并发、扩展性强
3
LBS轨迹服务-预估容量
假设数据量场景如下：
4
LBS轨迹服务-面临问题？
5LBS轨迹服务-如何技术选型呢?
6
LBS轨迹服务-高并发
5秒采集一个点，每天采集点数总量达 2800W+
预估：并发2000-4000
7
大数据量时如何高效存储呢？
app 批量上报,5s采集 20s 压缩，批量上报
16进制压缩：压缩前：400B， 压缩后：156B 压缩率:39%
缓冲队列:加消息队列 异步处理，削峰填谷，灵活，解耦，缓冲
采用批量存储落hbase
8
数据倾斜(面临问题)
难点：hbase中的数据是按照字典序排序的，当大量连续的rowkey集中写在个别的region，各个region之间数据分布不均衡
9
LBS轨迹服务-数据倾斜（思考）?
10
LBS轨迹服务-数据倾斜(方案)
rowKey原理：固定长度的 rever(ordered) | 时间
reverse(orderid)_(Long.max-datetime)
优点：
反转:保证key的离散化;负载均衡
时间段扩展 ;数据量分流，分页读取
如图所示：
11
LBS轨迹服务-整体方案设计
12
LBS商家轨迹服务-详细设计
上报打点数据格式如下：
{ "oid":"业务单号", "sid":"商家单号", "location":[ { "lat":"纬度", "lng":"经度", "r":"定位精度", "s":"速度", "d":"方向", "t":"与第一个点差值", "n":"卫星数" } ]}采集频率：已经由原来的5s采集一次，改为1s采集一次。视业务场景而定
上传频率：由原来的20s上传一次，改为现在10s上传一次。
编号相同的情况下，用时间戳来进行区分
13
LBS轨迹服务-性能收益
数据量可支持TB级别
压测效果：
上报接口 平均耗时：11.5ms 压测QPS：150并发/1600qps
查询接口：平均耗时 8.77ms
14
LBS轨迹服务-问题思考?
如何进行轨迹纠偏,过滤跳点数据?
思路一
可采用高德地图和百度地图提供的轨迹纠偏的服务,用于将行程产生的轨迹坐标点匹配到道路上,(重点：花钱到位就行)
思路二
自定义规则：
相同点舍弃：同一批量相同数据点舍弃
精度舍弃:点的定位精度不足一定规则范围视为无效点
角度舍弃规则：行驶过程中，角度来回折回视为无效点
距离舍弃:距离不满足一定规则舍弃
速度舍弃：行驶速度超过一定范围的舍弃
使用开源的算法：
道格拉斯轨迹抽稀算法,对踩点数据稀释
采用卡尔曼滤波算法，过滤受干扰的gps点对打点轨迹整形
等等一些开源轨迹纠偏算法~
