随着人们对出行的需求日益增加，出行的安全问题，出行的便捷问题等问题日益突出，特别是安全出行是我们每个人都迫切需要的，为了增加出行的便捷，提高出行的安全，对我们乘车的细节以及发生点我们迫切的需要及时知道，为此特地通过大数据的手段来处理我们海量的出行数据，做到订单的实时监控，乘车轨迹的的细节回放，虚拟车站的科学制定，出行迁途的细节过程，订单报表的大屏展示，以及用户乘车行为统计，用户画像等功能，实现用户的出行统计，制定用户的的“杀熟”策略等。
数据主要分为两部分：第一部分为日志数据，主要是司机端APP每隔一定时间上报经纬度坐标信息，以日志数据的形式进行打印到日志服务器。第二部分数据为业务库数据，主要是存储在mysql，通过分库的形式将各个不同城市的数据存储在不同的业务库里面
数据采集框架很多，包括sqoop,datax,flume,logstash,maxwell,canal等各种数据采集框架适用场景不同，功能描述如以下表格
| 采集框架名称 | 主要功能 |
|---|---|
| Sqoop | 大数据平台和关系型数据库的导入导出 |
| datax | 大数据平台和关系型数据库的导入导出 |
| flume | 擅长日志数据的采集和解析 |
| logstash | 擅长日志数据的采集和解析 |
| maxwell | 常用作实时解析mysql的binlog数据 |
| canal | 常用作实时解析mysql的binlog数据 |
| waterDrop | 数据导入导出工具 |
市面上成熟的消息中间件技术框架也有很多，主要有以下各种消息中间件
| 开源****MQ | 概述 |
|---|---|
| 1.RabbitMQ | LShift 用Erlang实现，支持多协议，broker架构，重量级 |
| 2.ZeroMQ | AMQP最初设计者iMatix公司实现，轻量消息内核，无broker设计。C++实现 |
| 3.Jafka/Kafka | LinkedIn用Scala语言实现，支持hadoop数据并行加载 |
| 4.ActiveMQ | Apach的一种JMS具体实现，支持代理和p2p部署。支持多协议。Java实现 |
| 5.Redis | Key-value NoSQL数据库，有MQ的功能 |
| 6.MemcacheQ | 国人利用memcache缓冲队列协议开发的消息队列,C/C++实现 |
流式处理技术已经非常成熟，且各大框架都有提供很多种选择，以下是各种流式处理技术选型技术对比
| 框架名称 | 框架介绍 |
|---|---|
| Storm | Twitter公司开源提供，早期的流失计算框架，基本已经退出大数据的舞台 |
| SparkStreaming | 当下最火热的流失处理技术之一 |
| Flink 流式计算 | 当下最火热的流失处理技术之一 |
| Blink流式计算 | 阿里二次开发的Flink框架 |
数据永久存储框架也有很多，比较常见的例如Hbase，kudu，HDFS等
| 框架名称 | 主要用途 |
|---|---|
| HDFS | 分布式文件存储系统 |
| Hbase | Key，value对的nosql数据库 |
| Kudu | Cloudera公司开源提供的类似于Hbase的数据存储 |
离线统计的框架也非常多，主要就是基于各种OLAP场景的应用计算
| 框架名称 | 基本介绍 |
|---|---|
| MapReduce | 最早期的分布式文件计算系统 |
| hive | 基于MR的数据仓库工具 |
| impala | 号称当前大数据领域最快的sql on hadoop框架，内存消耗特别大 |
| SparkSQL | 基于spark，一站式解决批流处理问题 |
| FlinkSQL | 基于flink，一站式解决批流处理问题 |
| druid | 针对时间序列数据提供低延迟的数据写入以及快速交互式查询的分布式OLAP数据库 |
| kylin | 基于Hbase实现的预计算 |
| presto | 分布式SQL查询引擎，用于查询分布在一个或多个不同数据源中的大数据集 |
| clickHouse | 俄罗斯开源提供的一个OLAP分析框架 |
现在主要用到成都数据以及海口数据，针对成都以及海口数据字段说明如下
一共五个字段，字段详情参见下表，字段之间使用逗号隔开
| 字段 | 名称 | 类型 | 示例 | 备注 |
|---|---|---|---|---|
| DRIVERID | 司机ID | String | glox.jrrlltBMvCh8nxqktdr2dtopmlH | 已经脱敏处理 |
| ORDERID | 订单ID | String | jkkt8kxniovIFuns9qrrlvst@iqnpkwz | 已经脱敏处理 |
| TIME | 时间戳 | String | 1501584540 | unix时间戳，单位为秒 |
| LNG | 经度 | String | 104.04392 | GCJ-02坐标系 |
| LAT | 纬度 | String | 30.67518 | GCJ-02坐标系 |
注意：上区域的中所体现的OD数据是相比全城是很小的量，不能反映全城的供需情况
目前得到的轨迹数据中可以看到时间不是按照递增的方式进行排列，在进行数据处理时需要先对数据按照时间进行升序排列(轨迹点的产生的时间是递增的，从时间的角度才能看出轨迹的运行规律),排序后便于在地图上进行轨迹的呈现.
海口订单数据一共24个字段，字段之间使用\t制表符分开，字段详情参见下表
| 字段ID | 字段名称 | 字段样本描述 |
|---|---|---|
| order_id | 订单ID | string类型且已脱敏 |
| product_id | 产品线ID | 1滴滴专车， 2滴滴企业专车， 3滴滴快车， 4滴滴企业快车 |
| city_id | 城市ID | 选取海口当地 |
| district | 城市区号 | 海口区号 |
| county | 二级区县 | 记录区县id |
| type | 订单时效 | 0实时，1预约 |
| combo_type | 订单类型 | 1包车，4拼车 |
| traffic_type | 交通类型 | 1企业时租，2企业接机套餐，3企业送机套餐，4拼车，5接机，6送机，302跨城拼车 |
| passenger_count | 乘车人数 | 拼车场景，乘客选择的乘车人数 |
| driver_product_id | 司机子产品线 | 司机所属产品线 |
| start_dest_distance | 乘客发单时出发地与终点的预估路面距离 | 乘客发单时，出发地与终点的预估路面距离 |
| arrive_time | 司机点击‘到达’的时间 | 司机点击‘到达目的地’的时间 |
| departure_time | 出发时间 | 如果是实时单，出发时间(departure_time) 与司机点击‘开始计费’的时间(begin_charge_time)含义相同；如果是预约单，是指乘客填写的出发时间 |
| pre_total_fee | 预估价格 | 根据用户输入的起始点和目的地预估价格 |
| normal_time | 时长 | 分钟 |
| bubble_trace_id | ||
| product_level | 一级业务线 | 1专车，3快车，9豪华车 |
| dest_lng | 终点经度 | 对应乘客填写的目的地对应的经度 |
| dest_lat | 终点纬度 | 对应乘客填写的目的地对应的纬度 |
| starting_lng | 起点经度 | 对应乘客填写的起始点对应的经度 |
| year | 年份 | 对应出行的年份 |
| month | 月份 | 对应出行的月份 |
| day | 日期 | 对应出行的日期 |
开放城市：海口
开放范围：2017年5月1日 - 2017年10月31日
数据内容：上述时间范围内的海口市每天订单数据，包含订单的起终点经纬度以及订单类型、出行品类、乘车人数的订单属性数据。其中所有涉及个人信息的数据都经过了匿名化处理。
\1. 保留起终点经纬度小数点后四位，可能导致与真实环境坐标存在偏差，误差范围大概在十几米到几十米左右。 \2. 针对独门独户上下车点进行技术脱敏处理，将上下车点漂移到小区门口或街道上。
将config.properties当中的IP地址全部更改替换成为自己的对应的IP地址
继续构建我们的travel-web模块用于展示我们的web界面
构建travel_spark子模块，用于实现首页概览，订单监控，轨迹监控，虚拟车站，用户数据，热力图等功能模块的开发
通过回放我们的成都以及海口数据，使用flume采集我们的日志数据，然后将数据放入到kafka当中去，通过sparkStreaming消费我们的kafka当中的数据，然后将数据保存到hbase，并且将海口数据保存到redis当中去，实现实时轨迹监控以及历史轨迹回放的功能