百度|一样的钱,6倍的性能,就问你心不心动

“百度BigSQL可为用户提供高性能的即席查询服务 , 它需要大内存在计算节点本地缓存热数据 , 以减少DFS I/O对查询性能的影响 。我们使用来自英特尔的傲腾持久内存 , 在缓存质量得到保证的同时 , 极大地提升了集群的处理能力 , 获得了明显的TCO收益 。”
——百度资深系统工程师黎世勇
在近年来全球数据规模指数级增长的大背景下 , 如何满足用户对服务响应时间的要求成为了摆在众多企业 , 特别是科技企业面前的严峻挑战 。别看只是响应晚一秒钟 , 但企业很有可能流失数以万计的客户 , 因此没有哪家企业敢对客户体验掉以轻心 。
这也是顶级互联网企业百度面临的苦恼 。用黎世勇的话说 , 客户体验是我们的第一KPI , 响应时间是客户体验好不好最直接的体现之一 。为此 , 百度这些年一直在寻找、尝试、开发更好的技术来改善用户体验 。
本文要讲的百度联合英特尔进行的一系列技术创新 , 便是其为用户获得更好体验不断努力的一个缩影 。
软硬一起抓
Apache Spark是大规模数据处理的快速通用计算引擎 , 当前应用极其广泛 。Spark SQL模块是Apache Spark专门为大型数据中心结构化数据处理开发的功能模块 。百度BigSQL数据处理平台基于Spark SQL开发 , 在性能上做了很多优化 , 开发了不少新功能 。
交互式查询能力就是BigSQL在性能优化方面体现非常明显的一个例证 。关于交互式查询的重要性 , 相信不用多解释了 , 服务响应快不快 , 跟它紧密相关 。为实现次秒级的交互式查询响应 , 百度和英特尔在软硬两个层面都下了不少功夫 。
软件层面 , 百度联合英特尔开展了Spark平台优化分析包(OAP)项目合作 。其中 , OAP 能很好地利用列式数据以及选定列上的用户定义索引 , 提高数据检索效率 。与此同时 , OAP还采用了细粒度的内存数据缓存策略 , 以此来消除磁盘和网络中的 I/O 瓶颈 , 将性能最大化 。
硬件层面 , 百度与英特尔合作 , 利用英特尔傲腾持久内存替代部分DRAM , 部署更具成本效益的解决方案 。
百度内部测试显示 , 与使用传统纯内存的解决方案相比 , 使用傲腾持久内存可有效提高OAP的缓存性能及成本效益 , 大幅提升业务成效 , 例如帮助百度即席查询服务图灵减少工作负载、降低平均查询延时等 。
具体如何实现的呢?两步走 。
把常用的数据放在更快的存储里
OAP的核心是使用索引和缓存技术来加快交互式查询响应的速度 。
百度|一样的钱,6倍的性能,就问你心不心动
文章图片

文章图片

当查询具有非常特定的筛选条件时 , OAP可以在符合条件的列上创建索引 。通过与列数据文件并排创建与存储完整的B+Tree索引 , OAP可快速搜索B+Tree 索引来识别目标行 , 同时跳过后端存储(例如HDFS)上不必要的数据扫描 。由于索引文件与原始数据文件保持分离 , 在创建或删除索引时均无需重写原始数据文件 。
在此基础之上 , OAP还借助缓存来优化索引和数据访问进程 。通过将索引和数据缓存在内存中 , 来提升索引加载和数据扫描速度 , 缩短从分布式文件系统读取时磁盘和网络的I/O时间 。此外 , 通过将索引和数据单独缓存 , 其缓存清除和内存空间管理实现了彼此独立 。
百度|一样的钱,6倍的性能,就问你心不心动
文章图片

文章图片

由于采用列式缓存 , OAP 只需缓存查询所需的列 。基于最近最少使用(LRU)策略 , 当缓存达到最大容量时 , 那些最近最少使用的数据项将被淘汰 , 为缓存最新数据释放空间 。依照该策略 , BigSQL启用了一个高级缓存管理器 , 可以主动填充热点列 , 并清除缓存中不再需要的列 。


推荐阅读