百度案例:使用Alluxio提速数据查询30倍

2023-10-09 03:08

本文主要是介绍百度案例:使用Alluxio提速数据查询30倍,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

作为全球最大的中文互联网搜索提供商,百度在其产品数据服务系统方面经验丰富。在本案例研究中,百度的高级架构师刘少山分享了他们在生产环境中使用Alluxio的经验,以及为什么Alluxio能够带来显著的性能提升。使用Alluxio将原先的批处理查询将转换为交互式查询,这使百度能够以交互方式分析数据,从而提升了生产力,并改善了用户体验。


业务挑战

百度作为中国最大的搜索引擎,这意味着我们有很多的数据,如何管理这种规模的数据并快速提取其中的有用信息一直是一个挑战。

举例来说,庞大的数据量常常会导致查询需要花费数十分钟甚至数小时才能完成,因此需要让产品经理等待数小时才能开始下一个查询。更令人沮丧的是,改动查询后将需要重新运行整个过程。大约在一年前,我们意识到需要一个特殊的查询引擎来解决这些问题。首先,我们提出了一个目标规范:该查询引擎需要管理数PB的数据,并能在30秒内完成95%的查询。

我们将查询引擎从Hive切换到了Spark SQL(许多用例已经证明了它在延迟方面相对Hadoop MapReduce具有优势),我们期望Spark SQL能将平均查询时间降到几分钟之内。但是,它没有达到我们所希望的查询响应时间。虽然Spark SQL确实将平均查询速度提升了4倍,但仍需10分钟左右才能完成。

因此,我们再次仔细思考,挖掘分析更多细节。事实证明,这个阶段的查询瓶颈不再是CPU而是数据传输网络。由于PB级别的数据分布在多个数据中心,因此数据查询很可能需要将数据从远程数据中心传输到计算所在数据中心,这就是导致用户运行查询时出现很大延迟的原因。由于数据存储中心节点和数据计算中心节点具有不同的最优硬件规格,因此解决方案并不是将计算过程移动到存储数据中心那么简单。我们需要一个内存级的存储系统来存储常用的数据,并且该系统能够位于计算节点上。


为什么选择Alluxio

我们需要一个内存级的存储系统。该存储系统不仅能够提供高性能和可靠性,还能管理数PB的数据。我们开发了一个使用Spark SQL作为其计算引擎的查询系统,将Alluxio作为本地内存级存储解决方案。我们使用百度内部的标准查询作为压力测试方案,需要从远程数据中心提取6TB数据,然后在数据之上运行其他分析,整个压力测试持续了1个月。

结果表明,Alluxio带来了优异的性能提升。如果系统仅使用Spark SQL,平均查询需要100-150秒才能完成。加上Alluxio后,平均查询耗时10-15秒。此外,如果所有数据都存储在Alluxio本地节点上,则只需要大约5秒钟,比单独使用Spark SQL30倍。基于以上结果和系统可靠性方面考虑,我们围绕AlluxioSpark SQL构建了一个完整的大数据查询系统。

我们的系统包含以下组件:

  • 操作管理器:包装Spark SQL的持久化Spark应用程序。它接受来自查询UI的查询,并提供查询解析和查询优化功能。

  • 视图管理器:管理缓存元数据并处理来自操作管理器的查询请求。

  • Alluxio:用作存储常用数据内存级存储系统,提供计算本地性。

  • 数据仓库:基于HDFS系统的远程数据中心,用于存储数据。

下面,我们将介绍整个系统的执行流程:

  1. 查询已提交。操作管理器分析查询并询问视图管理器数据是否已在Alluxio中。

  2. 如果数据已经在Alluxio中,操作管理器从Alluxio中获取数据并对其执行分析。

  3. 如果数据不在Alluxio中,那么该数据未命中缓存。操作管理器将直接从数据仓库请求数据。同时,视图管理器启动另一个作业以从数据仓库请求相同的数据并将数据存储在Alluxio中。这样下次提交相同的查询时,数据已经在Alluxio中。


收益

系统部署后,我们使用典型的百度查询测量其性能。使用原始的Hive系统,需要超过1,000秒才能执行完成该典型查询。仅使用Spark SQL,耗时能够降低至150秒,而加上Alluxio后,耗时能够进一步降低至约20秒。该查询运行速度提高了50倍,并满足了我们为项目设置的交互式查询要求。因此,通过使用Alluxio,能够将执行耗时为15分钟的批量查询转换为耗时不到30秒的交互式查询。

在过去的一年中,该系统已部署在一个拥有100多个节点的集群中,Alluxio系统存储管理了超过2 PB数据并且使用了Alluxio高级功能——分层存储。此功能允许我们将内存作为一级存储,SSD作为二级存储,HDD作为最后级存储。将这些存储介质组合在一起,我们可以提供超过2 PB的存储空间。

除了查询性能方面的改进之外,对我们来说更重要的是整个系统的可靠性。在过去的一年中,Alluxio一直在我们的数据基础设施中稳定运行,很少遇到问题,这给了我们很多信心。因此,我们正在准备大规模部署Alluxio。首先,我们通过部署拥有1000Alluxio worker节点的集群来验证Alluxio的可扩展性。在过去的一个月里,这个拥有1000Alluxio worker节点的集群一直运行稳定,该集群提供超过50 TB的内存空间。据我们所知,这是目前世界上最大的Alluxio集群之一。


总结

我们已经验证了Alluxio能够极大地提高性能,并且可靠可扩展。接下来,我们正在逐步将不同的百度工作负载任务迁移到Alluxio集群上。例如,为了提高在线图像服务和在线图像分析的性能,我们正在与Alluxio社区密切合作,试图在Alluxio之上开发一个高性能的Key-Value存储。这样,只需要Alluxio一个存储系统:Key-Value存储可以执行有效的在线服务;对于离线分析,我们可以直接访问Alluxio获取图像数据。这大大降低了我们的开发和运营成本。

作为Alluxio的早期使用者,我们验证了它所描述的以内存为中心的分布式存储系统,以内存速度跨集群框架实现可靠的数据共享。除了可靠且具有内存速度之外, Alluxio还提供了一种基于内存的扩展存储以提供足够存储容量。

640?wx_fmt=png

这篇关于百度案例:使用Alluxio提速数据查询30倍的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/169905

相关文章

大模型研发全揭秘:客服工单数据标注的完整攻略

在人工智能(AI)领域,数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者,掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中,工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注,不仅能够帮助提升客服自动化系统的智能化水平,还能优化客户服务流程,提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

百度/小米/滴滴/京东,中台架构比较

小米中台建设实践 01 小米的三大中台建设:业务+数据+技术 业务中台--从业务说起 在中台建设中,需要规范化的服务接口、一致整合化的数据、容器化的技术组件以及弹性的基础设施。并结合业务情况,判定是否真的需要中台。 小米参考了业界优秀的案例包括移动中台、数据中台、业务中台、技术中台等,再结合其业务发展历程及业务现状,整理了中台架构的核心方法论,一是企业如何共享服务,二是如何为业务提供便利。

关于数据埋点,你需要了解这些基本知识

产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定

中文分词jieba库的使用与实景应用(一)

知识星球:https://articles.zsxq.com/id_fxvgc803qmr2.html 目录 一.定义: 精确模式(默认模式): 全模式: 搜索引擎模式: paddle 模式(基于深度学习的分词模式): 二 自定义词典 三.文本解析   调整词出现的频率 四. 关键词提取 A. 基于TF-IDF算法的关键词提取 B. 基于TextRank算法的关键词提取

Hadoop企业开发案例调优场景

需求 (1)需求:从1G数据中,统计每个单词出现次数。服务器3台,每台配置4G内存,4核CPU,4线程。 (2)需求分析: 1G / 128m = 8个MapTask;1个ReduceTask;1个mrAppMaster 平均每个节点运行10个 / 3台 ≈ 3个任务(4    3    3) HDFS参数调优 (1)修改:hadoop-env.sh export HDFS_NAMENOD

使用SecondaryNameNode恢复NameNode的数据

1)需求: NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2)故障模拟 (1)kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 (2)删除NameNode存储的数据(/opt/module/hadoop-3.1.4/data/tmp/dfs/na

异构存储(冷热数据分离)

异构存储主要解决不同的数据,存储在不同类型的硬盘中,达到最佳性能的问题。 异构存储Shell操作 (1)查看当前有哪些存储策略可以用 [lytfly@hadoop102 hadoop-3.1.4]$ hdfs storagepolicies -listPolicies (2)为指定路径(数据存储目录)设置指定的存储策略 hdfs storagepolicies -setStoragePo

Hadoop集群数据均衡之磁盘间数据均衡

生产环境,由于硬盘空间不足,往往需要增加一块硬盘。刚加载的硬盘没有数据时,可以执行磁盘数据均衡命令。(Hadoop3.x新特性) plan后面带的节点的名字必须是已经存在的,并且是需要均衡的节点。 如果节点不存在,会报如下错误: 如果节点只有一个硬盘的话,不会创建均衡计划: (1)生成均衡计划 hdfs diskbalancer -plan hadoop102 (2)执行均衡计划 hd

Hadoop数据压缩使用介绍

一、压缩原则 (1)运算密集型的Job,少用压缩 (2)IO密集型的Job,多用压缩 二、压缩算法比较 三、压缩位置选择 四、压缩参数配置 1)为了支持多种压缩/解压缩算法,Hadoop引入了编码/解码器 2)要在Hadoop中启用压缩,可以配置如下参数