转载

百度张鑫：基于LBS云的海量位置数据存储和检索实现

在3月26号由百度开发者中心、百度地图开放平台和百度车联网联合举办的第62期《基于地图开放技术的车联网实践》百度沙龙上，来自百度开放平台LBS云方向的技术负责人张鑫，分享了题为《基于LBS云的海量位置数据存储和检索实现》的演讲，介绍了 LBS云平台的整体架构，以及在整个发展过程中的优化历程。

演讲者简介：

张鑫是百度高级研发工程师，目前是百度开放平台LBS云方向的技术负责人，主要负责LBS云存储和云检索的架构优化和RGC（逆地理编码）的系统架构优化产品布局，主导了百度RGC效果性能优化项目，项目获得百度创新奖。重新设计优化了云存储基础检索集，摘要检索的架构。

主要分享内容为七部分：

目前LBS云系统所支撑的业务场景
LBS云架构的优化演进
LBS云系统的特点
LBS云系统架构
LBS云索引结构演进
存储演进
存储控制优化

LBS云所支撑的业务场景

百度地图开放平台主要是为地图开发者提供一系列的系统解决方案。目前这些解决方案主要是涵盖六个方面：定位、地图、数据、出行、轨迹和分析。每一个解决方案都有一系列的服务SDK和API，并打包成一个完整的产品来对外提供。开发者也可以根据自己的需求使用集中的服务或者SDK进行开发。在数据处理方面的服务主要还是POI检索，Place检索是对百度地图使用的POI检索服务做了一层封装。

LBS云主要是让开发者上传个性化数据，并支持对这些数据的存储及检索。GC是地理编码引擎，接收一个文本的地址串后解析成百度地址库中对应的地址。还有经纬度信息，RGC和GC恰恰相反，当RGC接收到一个XYZ经纬度坐标之后就会把这个经纬度坐标转换成一个语义上可以解读地址，也就是一个文本串，或者是一个结构化的地址。

目前LBS云所支撑的业务场景可以通过三个相对典型的案例来详述：

首先是物流行业。包裹分发到一个网点，不再需要相应的作业人员看包裹上的地址来进行分发，而是把业务员负责的片区数据存储到云平台上，这个包裹的地址用LBS云的GC转换到一个XY坐标，通过检索系统确定这个坐标所对应的服务片区。
其次是酒店。通过百度地图酒店数据来定位选择合适的酒店，这些数据目前就存储在LBS云平台上，对酒店周边服务进行检索都是通过LBS云平台实现的。
最后是交友。找附近的人估计是很多社交类开发者比较共性的诉求，LBS云平台系统支撑开发者把这样的数据信息上传到云存储，实现查找附近人的功能。

LBS云系统的特点

这里可以介绍一下百度LBS云系统比较突出的6个特点：

高可用性－ LBS云系统存储的可用性可以达到4个9，检索可用性在5个9以下，可用性的标准是根据系统从收到一个请求到给出应答这一过程的耗时不超过两秒，这是可用性的保准。
容量大－ LBS云系统存储现在为每个开发者都提供了大概是千万级别的存储，空间可以达到数百G，而且容量还可以根据需求来申请扩大。
灵活性强－系统可以存储各种各样的POI数据，可以根据用户想要上传的字段来灵活安排，这些字段是否参与检索、是否参与排序都可以自定义的。关键是这些字段的属性也是可以修改的，所以灵活性非常强。
实时－开发者将数据上传到LBS云平台，其存储发布到检索是在秒级之间，能够达到及时更新。
高效的空间索引－从前面分享的场景里可以看出，LBS云系统所支撑的开发者大部分在做周边检索，空间索引算法采取的是GeoHash算法，耗时不到7个毫秒，非常高效。
数据安全－最后一点大家都比较关注，放到LBS云平台上的数据安全吗？从两个纬度来讲：第一，用户之间的数据是互相隔离的，每个用户都有自己的AK，你在注册成为我们开发者的时候有自己的AK，一个用户的数据只能被该用户使用。第二：开发者上传的数据有多个副本存储在平台上，不会出现数据丢失的问题。

LBS云系统架构

既然这个系统有如此多的特点，那么它的架构又是怎么样的，如何支撑这些特点？

百度张鑫：基于LBS云的海量位置数据存储和检索实现

（上图）左边部分是系统监控，LBS云系统里的每一个子模块、子服务都有精密严格的系统监控，这个监控包含了对机器资源本身的监控，CPU、磁盘都有监控。另外对QPS、耗时、SLA的监控都是非常完备的，一旦出现任何问题，系统都会灵敏及时的报警。（上图）右边主要包含三部分，一个是针对检索结果和云分析结果的云展示，做数据可视化的展示。另一个是数据管理平台，用户可以通过这个平台对上传的数据进行便捷的编辑、修改。（上图）中间区域是整个架构的核心——控制服务层，主要功能是负责并发控制、配额控制以及集群。通过对服务请求的控制，将存储请求分发到检索层，存储请求会通过存储检索层更新到存储集群当中。如果将这些数据发布到检索，是可以通过系统推送到检索端。而如果是从检索端进来的请求，首先会进行索引查询，查询完之后再去存储集群中查摘要，把索引跟摘要的信息做一个整合反馈给用户，这就是检索接入层。

AS是高级检索单元，主要负责把查询传给DA，做一些语义理解，把理解的结果发到基础的检索集群当中。基础检索集群主要负责真正的倒排检索，基础检索集群里的库分为两部分，一是全量库，全量库静态不可修改。另一个是增量库，实时发布的内容会更新到增量库。通过实时查检索全量库和增量库，并将结果反馈给AS。最后介绍的建库集群有两个功能：一是把增量信息推送到基础检索集群，其次是及时构建全量库，替换基础检索集群库。

LBS云系统架构在经过全面而细致的调研之后，对各个风险点进行了分析，随后做了如下的一些改进：

对基础检索索引进行了一个重构。
对检索性能做了全面的优化。
对ODP存储接入层做了控制优化。
全面升级控制服务层。
对监控的梳理。

LBS云索引结构演进

百度张鑫：基于LBS云的海量位置数据存储和检索实现

通过上图可以看出来，云存储系统可以保证用户数据互相隔离，A用户不能访问B用户的数据，云检索系统中基础检索单元原先的全量库设计是：将所有用户数据的索引混建在一起，取得倒排拉链后，再根据用户的唯一标识user_id做过滤，这种设计会使得某些用户的检索会被其他用户的数据增长影响而导致性能变差，最严重的是会导致很多用户数据会由于拉链过长截断的问题而一直没有机会返回，当用户量小数据量少的时候问题并不明显，而随着接入LBS云的用户越来越多，原先这种索引之间没有彻底隔离的设计对用户体验造成了极大的伤害。

针对这个问题重新设计了LBS全量库的倒排结构，设计目标：

全面隔离用户，用户之间互不干扰，有各自独立的索引区间。
重构后性能至少要比现状好，解决随着用户增长，系统性能不合理地变差。

具体方案：

重新设计了全量库索引结构，提供了支持区间有序，允许全局有重复key的基础索引文件结构，提供了区间二分检索的查询。
采用新的索引结构的同时，设计了Table.meta二级索引结构，用于维护每个用户对应的索引区间，通过记录(起始位置，长度)信息来界定用户自己的索引区间，打破了原来用户索引杂糅无法分离的设计。
上图中table ABC....的索引内容完全分离，互不影响。基础检索集群的平响从12.7毫秒降到了7毫秒，两类PV量最大的空间检索平响超过100ms的长尾比例从原来的2.82%，12%减少到1.58%，5.89%，也彻底解决了用户检索效果上的问题。

存储演进

对存储以及监护层性能优化主要分为三点，第一点是把检索监护层从PHP改成了C++，因为存储集群搭配的PHPdriver本身性能是非常差的。第二点是对driver进行升级。经过测试验证，连接池比短连接性能稳定非常多。第三点改进比较重要，引入cache集群来提升table层的性能。

百度张鑫：基于LBS云的海量位置数据存储和检索实现

关于提升table层的性能有两点需要说明，第一点性能方面我们如何保障的？

首先Cache集群采用了Redis做了存储接入层。其次就是将Cache存储结构里的用户信息缩减。还有就是把存储集群当中的数据加载到Cache集群中，而加载操作不是由检索监护层完成的，检索监护层发一条消息给消息系统，由另外一个模块完成这种存储集群到Cache集群的更新。
第二点是如何有序的更新，以及保证最终一致性。假设现在在更新数据，同一时刻不同的POI数据也在更新，要解决有序性这个问题。方法就是去掉并发，不同的数据可以并发，相同的数据有序更新。