2019年超万亿规模的大数据搜索与统计-浅谈对lucene源码的改造.pdf

《2019年超万亿规模的大数据搜索与统计-浅谈对lucene源码的改造.pdf》由会员分享，可在线阅读，更多相关《2019年超万亿规模的大数据搜索与统计-浅谈对lucene源码的改造.pdf（36页珍藏版）》请在三个皮匠报告上搜索。

1、浅谈对lucene源码的改造超万亿规模的大数据搜索与统计作者简介母延年作者简介所属公司：录信数软职业信息：CTO领域：互联网、大数据十年行业经验，曾任职新浪、酷六、阿里与腾讯。11年：支付宝黄金策的海狗 12年：阿里开源项目：MDRILL（多维分析）14年：腾讯的Hermes（每天千亿总量万亿）15年：技术创业，潜心研究技术。作为lucene的粉丝，现就职于南京录信软件技术有限公司，录信即lucene的发音。有数十个万亿级、几百个千亿级别的项目设计与实施经验。我们对lucene的改进PART 1PART 1万亿秒查万亿秒查应用场景用户根据需求自定义查询条件，想查什么就查什么！万亿秒查适用场景：

2、网络综合搜索综合查询云搜索快速检索等数据规模超大、响应速度极快的查询场景1000台机器还是100台机器？512G内存还是128G内存？2T*12的SSD还是2T*12的SATA？大文本，图片，附件，视频怎么存？万亿数据怎么存？万亿秒查技术挑战面临挑战万亿秒查常规每天百亿数据，总量万亿。需满足上百个维度想查什么就查什么，结果秒级响应。1：按列簇混合使用不同磁盘。2：按列簇设置不同存储生命周期。3：按列簇设置不同的索引格式：行存、列存、混合存储、联合索引。4：大文本，附件，图片，视频单独存储。列簇存储（原生lucene不支持列簇）想怎么存就怎么存！存储根据场景分类万亿秒查-数据管理列簇存储示意图列

3、簇存储示意图数数据据列列一一数数据据列列二二数数据据列列三三数数据据列列四四数数据据列列五五数数据据列列六六列簇一列簇一列簇二列簇二数数据据列列一一数数据据列列四四数数据据列列六六数数据据列列二二数数据据列列三三数据只存储数据只存储在在SAS上上数据存储在数据存储在SSD与与SAS上上数数据据列列五五万亿秒查-数据存储SSD固态硬盘-机械硬盘冷热数据分离索引存SSD，数据存SATAPART 2PART 2多列联合索引多列联合索引场景应用类类型型3000条家寻亲人2300300感恩寻人寻找老赖400关系3000条父母9001600子女朋友500性别5000条男1800女1200姓名500条姓王1

4、8090姓张姓李230多列联合索引场景应用多列联合索引技术挑战只能对单列建立倒排索引，采用docvalues进行统计分析。多列统计多列统计 数据散落在磁盘的不同位置，随机IO太多，硬盘负载太高。每条数据都要进行一次计算，暴力计算CPU与IO消耗很高。数据导出需要瞬间导出百万条。面临挑战1：每列之间采用列存储。2：预先干预数据的排序分布让列存储的压缩更有效。3：依据查询构造顺序读取。4：多个列之间有层次关系。5：结合分块存储。多列统计想统计什么就统计什么！千亿数据即席多维统计多列联合索引lucene改造02PART 3PART 3地理位置检索地理位置检索应用场景区域查车/轨迹匹配-同行同住，同飞

5、地理位置检索技术挑战原生lucene地理位置检索与轨迹匹配慢，性能差地理位置检索采用docvalues的二次验证面临挑战黄色部分需要剪切验证 大幅度的减少随机读取的次数，降低磁盘负载。通过地理位置临近数据临近存储的方式构造硬盘上的连续读取，因常规磁盘的连续读取的性能会远远高于随机读写的性能，从而大幅度的提升查询响应的速度。改造优势地理位置检索lucene改造03随机读变顺序读1：我们抛弃docvalues方式的二次验证与剪切。2：我们按照地理位置临近数据临近存储的方式存储数据，在此基础上进行二次验证PART 4PART 4HDFSHDFS上的索引HDFSHDFS上的索引技术挑战 磁盘写入不均衡

6、，有的机器很满，有的机器很空。本地硬盘无快照功能，误删数据无法恢复。数据迁移，扩容麻烦 个别磁盘变慢，所有查询都卡在该盘的IO上。硬盘均衡硬盘难以均衡、不支持数据快照、数据迁移难度大数据存本地磁盘面临挑战HDFSHDFS上的索引lucene改造04磁盘容错与慢读识别Hdfs：具有容错能力，如果某些磁盘突然坏掉，或者速度变慢，能够自动发现，并自动切换到速度较快的副本上继续读取IO管控通过对IO与查询Session的关联，实现IO管控，判断某个查询的IO消耗，以及执行时间，在IO层可以随时中断，从而实现查询任务的取消，