大数据助力精准扶贫-电子发烧友网

南京录信数软是研究针对大数据行业使用的数据库产品，我们是做数据存储的，比较常见的炫酷的查询界面，比如说建立一些用户画像、人物画像，我们是给他们提供快速的统计分析能力的。那么，今天主要讲的是大数据在人车互联时代的作用。

随着汽车的数量越来越多，汽车成为我们生活中越来越不可缺少的一部分，汽车保有量已经达到2亿左右。过去很长一段时间我们只是针对大数据对人的作用，如果2亿左右的汽车个体能够主动发送一些信息，这个数据量是非常可观的，由此所产生的一些统计信息，也能反作用于车辆的生产和提高出行的质量。

随着车联网的迅速发展，基于OBD基础上的车载信息采集终端技术日益成熟，汽车大数据应运而生。通过T-Box采集的数据可以应用于各个行业，通过对数据的统计和分析，可以应用于经销商、主机厂商以及国家监管部门，最近热门的话题是随着国家国六标准的出台，国家要对每台汽车的尾气排放进行监管，这也属于T-Box数据采集的方向。包括车主和驾驶者，车主可以了解车辆的及时状态。

我们主要是对T-Box的数据采集进行存储的。T-Box将数据上传到服务器或者云平台，国家监管机构、车厂商、经销商或者车主去里面获取相关的信息，车主可以通过APP获得数据，监管部门或者是厂商会通过web界面来获取信息。

今天讨论的是数据存储和查询界面使用的即席检索。所谓即席检索，就是想查什么就查什么，数据在入库时不需要做预统计和预计算，预计算的缺点是没有做预计算的维度是不能查询的，而且预统计比较消耗系统资源。我们的产品可以实现对原始一份数据即席查询，在千亿级别上实现秒级响应。我们的产品定位是一款单机即可支撑500亿条数据的秒级检索分析响应型数据库。特点：无限线性扩展、4台可支撑千亿条、百台可支撑万亿条。

随着汽车数量逐年增长，车载终端所产生的数据量是非常巨大的，我们通过一些合作的客户来看，一个主机厂商一年所能达到的数据量在20万亿，数据可以达到PB级别，当前市场上流行的大数据框架，在这个数据级别上进行快速的统计分析是没有完美解决方案的。如果对数据进行长久存储，三年就要达到60万亿的数据量，传统的数据库已经吃不消了。万亿数据怎么存储呢？可能在数据量比较大的时候，我们会想到Hadoop生态系统，它是开源的，它就是通过整合单机资源，堆积单节点的计算能力，达到比较好的整体算力。它的一个缺点就是它要对全量数据做扫描，全量扫描就会有一个问题，需要更多的硬件满足算力的要求，所以它的硬件成本还是比较高的，虽然说每台硬件成本是配置比较低的普通服务器，但是整体的成本还是比较高的。

有没有这么一种可能性，在海量数据的基础上，建立一层索引，可以减少扫描的数据量，从而降低硬件成本的要求。

如上图，这个框架大家比较熟悉，除了红框里面的部分，我们现在把它改成我们自研的索引引擎，数据筛查的时候经过这个索引引擎，首先过滤掉一大部分数据量，是在很小的数据量中进行检索，所需要的硬件资源已经少了很多。我们为了增加它在复杂统计场景下的性能，我们将spark框架集成在内，这是基于内存的一个计算框架。我们与开源的spark框架还不同，开源的spark框架对文本文件没有过滤，优化过的spark框架最终是和索引引擎进行数据交换的。无论是通过索引引擎直接查，还是通过spark计算框架查，都比原生地要快很多，在某些场景上，已经快了几百倍。它的底层还是建立在Hadoop基础上。对外部的数据接入，可以传统的关系型数据库MySQL、Or acle，也可以通过Kafka实时消费。数据从产生到可查只需2-3分钟。

我们对外提供的场景接口也很丰富，有HiveSQL，或者通过JDBC，或者通过Webservice的方式。

索引+大数据，由于在运算的时候可以减少扫描的数据量，进而可以减少机器台数的要求，原生的架构大量的机器堆积不仅仅为了存储，而是它的计算能力不够，可能每台机器存储只用了一部分，但是每台机器的计算能力已经用满了。我们从减少数据加载量的角度优化，可以减少机器台数。

还有一个就是数据热点的问题，很多场景下都会对最近几天的数据比较关注，比如说最近几天的消费数据、新闻、网页浏览，都属于热点数据，查询频率比较高，针对这样的数据特点，我们采用了冷热数据分离。冷热数据分离可以做到什么好处呢？查询频率比较高的数据，我把它放到SSD固态硬盘上，可以提升数据加载的速度，过一段时间之后，这个数据查询没那么高了，可以把它放到机械硬盘上。这样可以既兼顾了查询的速度，也兼顾了成本。

还有我们针对每个数据类型，有专门的压缩格式，可以减少硬盘的存储。

上图是我们在一个真实的项目遇到的情况，它的数据量也是达到万亿级别。这是对开源系统和索引+大数据系统的对比。首先是硬件成本，很明显机器台数已经降到之前的1/5，对硬件配置的要求也有很大的下降。还有就是人力成本，之前有三套系统，有做统计分析的mapreduce集群、有做实时检索的hbase、还有建立二级索引的ES，三套系统保存三份数据，数据膨胀率很高，而且三套集群，4种完全不同的风格的API，对开发的要求很高。索引+大数据的架构，它对外是统一的SQL接口，通过sql语句来进行交互，极大的减少人力成本。

我们的数据存储还是建立在HDFS上，实时检索相比目前主流的检索框架来说，它继承了很多HDFS的特点，比如说磁盘容错，某些情况下磁盘突然坏掉了，或者速度变慢，磁盘容错能够自动发现，自动迁移到速度比较快的副本上面，然后自动读取。还有一个是IO管控，如果某个查询需要的资源非常高，已经影响到服务的性能，可以随时中断这个任务，从而保证整个服务可查。还有比较重要的是数据快照，有时候数据不小心删掉了，我们提供数据快照的功能，在短时间内可以对大量的数据创建快照，1P数据只需要2秒钟创建。

检索分析场景，基于车载T-Box产生的数据，对各个行业的统计是非常复杂的。国家监管机构可能要对尾气排放进行监控，对车辆实时轨迹、位置进行监管，还有通过驾驶员的驾驶习惯，比如说急刹车、急转弯，对驾驶员进行教导。对车厂商来说市场上车辆各组件性能损耗的多维分析，比如说汽车的每个功能组件损耗到什么程度，然后用于改善生产。经销商可以建立用户画像，某一型号车辆在全国各个省的分布情况，可以用于精准营销。对车主来说，需要掌握车辆的整体状态。

对各个行业来说，数据的统计分析是非常复杂的，在大量的数据基础上进行这么复杂的分析，是一个很大的挑战。在索引+大数据的框架下，无论是检索还是统计分析，查询性相比较开源都有很大幅度的提升，但是在某些具体场景，我们也是有一些特定的优化的。比如说一些轨迹类的查询，像轨迹回放，要求是在过去的某一段时间，对某一个车辆进行轨迹的检索，将轨迹信息实时展示在地图上面，用于一些轨迹监控之类的。

这个数据其实就是经纬度字段在界面上展示，至于这个界面做到多炫酷，那是界面的事情，我们是提供数据快速查询的能力。还有就是区域查车，在地图上可以人为圈定一个规则的圆形或者矩形，或者不规则的多边形，可以监控这个图形范围内的车辆信息，出来的也是经纬度的信息。值得一提的是目前开源解决方案对不规则的多边形支持并不友好，有些并不支持，我们通过改善空间地图位置索引的结构，就能很好地支持这种不规则多边形的索引。

其实这两种轨迹类的查询，只是对经纬度字段的查询度比较高，其它的字段不查询。针对一个表中某几个字段查询比较高的情况，是不是有其它的方案呢？列簇和异构是比较好的解决方法。列簇是说，一张表里面有几个列，它的保存周期、存储格式不同，就可以把相同生命周期的数据或者是相同存储格式的数据保存在一个目录里面，后期进行数据淘汰或者增加压缩比。然后是异构，根据数据的重要程度，选择在保存在不同的存储介质上，如果使用频率不高的，可以保存在机械硬盘上。那么轨迹类的查询，就可以把经纬度字段放在比较好的硬盘上，获得好的数据加载性能。等过了一段时间，数据会自动迁移到一些廉价的硬盘上。

在轨迹类查询方面，比如说想查询某个车牌号或者某个手机号今天的轨迹信息，一般的做法就是针对时间字段做排序，然后取最新的几条，在万亿数据基础上做排序，是一件很头疼的事情，我们针对大数据量的TOP N的排序也做了优化，目前业界主要做的是一条一条暴力扫描，将数据加载之后再获取TOPN。我们所做的针对排序的数据结构是叫tired tree，它是针对数值类型的排序，比如整型int是四个字节，那么，先根据第一个字节建立索引，然后再根据第一、二个字节建立索引，之后再根据第一、二、三个字节建立索引，最后对全量数据建立索引，通过对相同前缀建立索引，可以获得较好的性能。比如要查询423这个值，首先去查4，定位到4，之后5、6就不查了。然后定位42，44就不需要查询了，之后再直接找到423，经过几次的查询，和全量扫描最底层所有的记录来说，已经高效了不少，当然这里的数据量比较少，我们看不出来有多么高效。如果我要找TOP N，我可以直接定位到这个数值前面最大的前缀，这里是6，找到6之后，我可以找到64下面的，直接返回了。它可以通过索引直接定位到TOPN个结果，无序额外计算，只需作TOP N排序，避免读取全量数据。通过这种高效排序和异构+索引在轨迹类的查询，可以做到很好的性能提升。

在海量数据上进行多维的数据统计和分析，进而建立用户画像也是一个常用的业务场景，比如说可以根据车辆的报警信息，做出一个报警的分布图，也可以根据用户的急加速、急减速行为做出一个统计结果，根据用户的属性分类，建立一个用户画像。包括某个车辆在全国的销售情况，后期用于精准营销，提供一些判断的依据，对各个维度的信息进行多维的统计分析，本来不是一件特别难的事情，当数据量小的时候，在Oracle、MySQL里面就可以做，如果放到千亿级别、万亿级别就很头疼。目前开源是怎么解决这个问题的呢？

它把过滤之后的数据全部加载到内存，通过拼I/O资源和CPU资源，人为地做一些聚合、分组统计，这个性能还是依赖硬件。我们对这个业务场景做的一个调优是我们在入库的时候，就对我们所要统计的某些字段进行预排序，干预它的排序规则，比如要对一个表里面有三个字段city_id、age、score进行统计分析，数据存储的时候，就是按照这种group by 的顺序来存储，那么遇到这种查询的时候，就可以直接获取到后面的数据，就不需要重新计算。如果某个统计分析后面加上检索条件，也不需要做全列扫描，通过在真实数据基础上创建一个二级的跳跃表结构，每一个节点上会记录当前区域里面的最大值和最小值。通过第一层可以找到第二层，第二层缩小到更小的区间，在千亿甚至万亿的数据里面，最后筛选的数据量就很少，可以极大地过滤掉数据，加载数据的内容很小，释放很多的I/O资源。用户可以根据需求自定义任意维度，快速统计。当然它和预计算、预统计是有区别的，预计算的容量更重，它需要占用的CPU资源更高。

在这种统计分析场景下，如果某一个时刻，入库压力比较大，而且查询的频率又比较高，这个时候一个进程既承担读也承担写就成为整个系统的瓶颈。那么一主多从可以实现读写分离，提高效率。

主节点负责数据写入，多个从节点承担读的压力，它和我们熟知的My SQL主动复制有区别，MySQL主动复制是每个节点各保存一份数据，比如说一主三从，它有4份数据，而且主和从之间有数据同步的过程，也是存在延时的。上面的一主多从架构只保留一份数据，它没有数据冗余，减少磁盘存储。在大量的数据更新、新增时主节点和从节点没有任何的延时。

上表是开源系统和索引+大数据系统的在查询方面一个直观的对比图。开源方案如果要实现多维统计，多个表的表关联，或者一个表的多列的复杂的分组统计，需要使用离线集群跑MR任务，它的一份数据要存在三套系统里面，数据膨胀是很大的。索引+大数据的框架仅需要维护一套系统，这一套系统既可以用于检索，也可以用于统计。体验对比，Hbase只能查预计算维度，时效性差、数据膨胀率高。系统各自独立，无法实现协同查询，如果想要玩转这三套系统，技术要求是比较高的，数据量过亿后，无法实现统计分析。对比下来索引+大数据，数据从产生到可查只需要2到3分钟，而且多种数据可以相互引用，相互组合过滤，并且支持任意维度的快速分析统计。

下面介绍一下录信数软的产品。我们的产品就是想解决当前大数据行业所存在的一些痛点。

第一是成本高。目前想要在纯检索的情况下，实现千亿量级的统计分析，需要100台SSD机器，在这种情况下，索引+大数据的框架可以节省60%-70%的硬件成本，包括机器台数和硬件配置。

第二是时效性的问题，目前的行业现状是进行大数据分析统计，数据量是T+1天可查，它有时间间隔，复杂业务可能要达到一到两个小时甚至更长时间。索引+大数据从产生到可查询只需要几分钟，多维多表的统计分析可以达到秒级。

第三是易用性比较差，目前大数据的框架一般Hadoop+hbase+ES，它需要多份数据、多种业务接口，上手复杂。索引+大数据是多种业务一套数据库一站式解决。