搜狐智能媒体基于腾讯云大数据 EMR 的降本增效之路

2022 年，搜狐智能媒体完成了迁移腾讯云的弹性计算项目，其中大数据业务整体都迁移了腾讯云，上云之后的整体服务性能、成本控制、运维效率等方面都取得了不错的效果，达到了预期的降本增效目标。

本文主要介绍搜狐智能媒体的大数据业务，在迁移腾讯云大数据 EMR 的过程中，基础系统、历史数据、业务系统等迁移的相关工作和经验，以及在此过程中的关键技术改造。 

本文作者：

翟东波 搜狐智能媒体研发中心资深开发工程师

齐来军 搜狐智能媒体研发中心高级开发工程师

大数据业务概况

1.1 大数据业务分类 

图 1-大数据业务分类图

基于智能媒体大数据业务分类，主要从两个正交的维度来开展，一个是数据操作的维度；一个是数据时效性维度。

1、按照数据操作维度，主要划分为数据生产和分析应用。

数据生产，可以理解为泛化的 ETL 生产，主要包括数据清洗、格式转化、数据关联等一系列数据操作。其主要特点首先是基于大批量计算，存在大数据量输入与输出，且运行时间较长，其次数据处理应具有高容错性，比如 MapReduce、Spark 等计算引擎，能够对单个 Task 失败进行容错、Retry 等操作，不影响整个 Job 或 Application 的执行。

分析应用，基于数据生产的数据进行上层操作，主要是多维分析，比如上卷、下钻、切片等等，主要特点就是查询结果集小，即存在大数据量输入，小数据量输出，但对查询响应的及时性要求很高，一般都要求秒级甚至亚秒级别。

2、按照数据时效性维度，主要划分为离线数据和实时数据。

离线数据，时效性要求在天级或小时级别，离线数据会采用分层建模方式进行管理和操作。

实时数据，时效性一般要求在分钟/秒级别，对于一些物联网场景，甚至会要求数据时效性延迟控制在亚秒级别。由于实时数据分析占总体数据分析的比例还不太高，因此一般会采用烟囱式开发方式进行管理和操作，针对不同的数据生产和分析需求，建立不同的实时数据任务；目前在实践中，也有进行类似离线数据的分层模型架构，对实时数据进行分层建模，底层模型的数据实时写入 Kafka，提供给高层模型使用；随着 StarRocks 等支持大吞吐量数据实时写入的开源数据库的出现，在实时数据应用实践中，开始使用“计算后置”的模式，即将原始的数据通过 ETL 后实时写入数据库作为 ODS 表，并基于这些 ODS 表数据，编写 Join、聚合等复杂的类 Ad Hoc 的 SQL 查询语句，来满足不同的分析查询需求。

根据上面两个维度的划分，可以将数据业务分为四个场景：

1)离线分析，主要是传统数仓业务类型，一般为 T+1 的分析场景，在工程实践中主要使用的技术包括 Impala、Presto、StarRocks 等；

2)实时分析，针对的是实时数仓场景，主要使用的技术是 StarRocks 等；

3)离线 ETL，针对的是 Batch Processing 场景，主要使用的技术包括 HIVE/Spark/MapReduce 等

4)实时 ETL，针对的是 Stream Processing 场景，主要使用的技术包括 StarRocks、Flink、 Spark Streaming 等，由于 StarRocks 的 Routine Load 支持数据清洗，格式转化等效果，因此在智能媒体部分实时业务场景中，直接使用 Routine Load 进行实时数据 ETL 操作。

1.2 大数据业务架构

图 2-大数据业务架构图

根据上面的大数据业务分类，上图是智能媒体的大数据业务总体架构，主要划分为数据源层、数据计算与存储和数据应用三个层次。

1、数据源层，主要包含两大类：业务数据，即业务系统直接操作的数据，这些数据主要是放在 MySQL、Oracle、MongoDB 等数据库中；日志数据，即表征业务系统事件类的数据，通过埋点方式从客户端采集上来的数据，或者是服务器端打印的日志。

2、数据计算与存储，是整个大数据业务架构中最核心的层次。上图左侧为离线数据业务部分，采用分层模型方式，一般分为 STG/ODS/DWD/DWS/ADS 等离线数仓构建；右侧为实时数据业务部分，采用了三种数据开发方式，从左到右依次为烟囱开发方式、分层建模和计算后置。

1)烟囱开发针对不同的业务构建实时数据任务，在 ETL 任务内部会进行 Join 等复杂的处理，由于在 Stream Processing 中处理 Join 操作很复杂，而且会存在数据准确性等问题，烟囱式开发也逐渐在减少；

2)分层建模，借鉴离线业务模式对数据进行分层，减少烟囱开发，主要应用在线上业务实时更新数据、实时推荐模型等场景；

3)计算后置，通过实时 ETL 生成贴源层 ODS 表数据，业务分析需求直接基于 ODS 表数据编写 SQL 语句，将数据的 Join、窗口、聚合等计算操作后置到查询的时候进行；

3、数据应用层，主要是对接部门内部 BI 系统，基于 Impala，Presto，StarRocks 满足不同场景下的数据 快速查询需求。

1.3 云下大数据技术架构

图 3-云下大数据技术架构图 

根据大数据的业务架构，云下大数据技术架构如上图所示。

离线数据部分，日志数据同步主要使用 Flume ，业务数据同步使用 Sqoop 及自研的 MongoDB、Elasticsearch、Redis 等 Sqoop 插件；数据存储使用 HDFS，Batch Processing 使用基于 YARN 资源管理的的 HIVE 和 Spark，基于自研离线数据管理平台，采用分层建模方式构建离线数据仓库，同时 ODS/DWD/DWS/ADS 数据处理任务的 DAG 进行管理，并带有补数 、数据质量、元数据管理等功能；离线分析主要基于 Impala/Presto/StarRocks 等 MPP 查询引擎。

实时数据部分，日志数据同步主要使用 Flume，业务数据同步使用 Canal 等 CDC 产品；数据存储使用 Kafka 和 StarRocks，实时 ETL 使用 Flink 和 Spark Streaming，实时分析主要使用 StarRocks。 

以上是对云下大数据技术架构的整体介绍，云下大数据总体概括总结如下：

1)基础系统：云下使用的是搜狐公司提供的 Hadoop 平台，有专门的团队负责运维；StarRocks，是团队自建自运维的。

2)历史数据：目前累积的历史数据量在 10PB 级别。

3)业务系统：包括自建的 Report、OLAP、Ad Hoc 等 BI 系统；以及自研的离线数据管理平台，针对离线数据分层建模任务进行管理。整个的大数据业务迁移上云，就是围绕上面三个部分展开。 

云下的大数据架构在多年的发展中也遇到了一些痛点，比如机房扩容周期长，难以快速根据业务需要来补充计算资源；不管是否有计算任务，资源都需要随时预留；以及多个业务部门共享计算资源的成本分摊问题。这些痛点也都在上云的过程中得到了圆满的解决。

上云降本增效之路

2.1 云上大数据技术架构

图 4-云上大数据技术架构图

为保障大数据业务快速迁移上云，针对大数据组件采用平迁的形式迁移至腾讯云 EMR，EMR 在对开源组件进行了内核级优化的同时，也保证了与开源组件的完美兼容，避免因组件版本导致业务不兼容问题，尽量减少上云迁移的工作量、难度、风险等因素。

大数据迁移至腾讯云 EMR 主要工作分为如下几个方面： 

1、基础系统：

1)云下的 Hadoop 使用的是 CDH 5.XX 的版本，云上 EMR 我们选择的是 2.6，在实际使用中两个版本 Hadoop 的各个组件功能基本是兼容的；

2)EMR 上有独立 StarRocks 集群组件可以选择，可以完全替换云下的 StarRocks；

3)Flink 我们使用的是腾讯的 Oceanus，Oceanus 在提供了快捷的 Flink SQL 开发方式的基础上，提供了更强大的任务管理能力以及更稳定的运行环境。由于 Oceanus 是完全容器化的，所以可以比传统基于 YARN 调度实现更精细化的资源管理，在 ETL 链路的场景下甚至可以使用 0.25CPU 来运行一个算子，极大的节约了计算成本；

2、历史数据：

考虑到成本问题，且 EMR 作为云原生的大数据平台，天然支持了存算分离架构，可以直接使用对象存储作为数据存储的文件系统，Hive、Spark、Impala、Presto 等组件都可以直接操作 COS/OFS 上的数据；于是我们决定将 HDFS 中的历史数据迁移到对象存储的元数据加速桶 OFS 中，在完全无需改变数据操作方式的同时，解决了海量历史数据成本高昂的难题，也让后续保留更多历史数据进行分析或者机器学习训练成为可能。

3、业务系统：

BI 系统的迁移相对简单很多，数据和基础系统迁移完，将数据库链接信息配置到新的 Impala、Presto、StarRocks 等系统即可；离线数据管理平台，迁移上云的工作量较大，积累了数千个离线数据任务，要将任务 DAG 在云上平台跑成功。 

2.2 迁移主要工作

2.2.1 基础系统迁移

基础系统的迁移工作，主要包含如下几个方面：

1、集群规划及搭建：

根据大数据业务场景和数据的处理流程，主要规划了两套 EMR 集群：一套用于离线数据处理，另一套用于实时数据的 Spark Streaming 任务。之所以搭建两套集群，是因为主要是考虑到离线数据处理的资源使用有明显的波峰波谷特点，可以使用 EMR 的资源弹性伸缩功能；而 Spark Streaming 任务，都是 Long Running 的任务，资源消耗会很平稳。由于 EMR 具有分钟级快速构建集群的能力，通过集群级别快速进行资源隔离，效果会比同集群内进行队列划分效果更好，同时也更方便后续成本分担。

针对 StarRocks 集群，由于云下受限于机器以及维护成本问题，只搭建了两套粗粒度集群。云上的 StarRocks 集群搭建，不再受资源限制，而且创建和维护成本都低很多，我们按照业务划分创建了多个细粒度的集群，减少业务之间的使用干扰。

Flink 的任务直接使用了腾讯提供的流计算平台 Oceanus，并在 Flink 上做了 SQL API、常用数据源数据源 Connector 等封装，且基于社区版本内核及 CDC 进行了大量增强，比单独在 Hadoop 集群内使用 Flink 要方便很多。同时 Oceanus 还可以将任务资源使用控制到 0.25CU 级别，相比开源的 Flink 每个 CPU 只能分配单个 Slot，极大增加了流计算任务的资源使用率。

2、EMR 离线集群配置和部署方式的优化。

1)动态弹性扩缩容策略配置：开始我们使用按负载伸缩来进行弹性扩容，但在测试负载伸缩过程中发现，由于用户提交的计算任务往往不会主动指定资源使用量，从而造成资源利用率监控上出现毛刺。如果对负载阈值的监控敏感度配置过高，则容易反复触发扩容，如果对负载阈值的监控敏感度配置过低，则扩容响应容易有滞后。在跟腾讯云架构师讨论后，我们观察到离线任务大部分都在凌晨执行，有明显的时间周期，因此直接使用了按时间伸缩的扩容模式，简单快速的满足了业务上对分时调度资源的需求；

2)YARN 调度：由于云下的 Hadoop 集群是固定的大资源池，且所有使用方平摊成本，所以调度策略使用的是公平调度方式。在迁移上云的时候，我们期望能把资源利用率尽量提高，相对于 IDC 超万核的常驻队列，在 EMR 上我们可以做到平时常驻的队列只有小几千核。这个时候如果还继续沿用公平调度策略，则会导致大量任务都能同时向 RM 进行资源申请，导致每个任务都没能获得足量资源。在腾讯云架构师的建议下，我们更换了容量调度方式，资源可以优先得分配给 Running 中先进队列的任务，保证任务及时完成；

3)HIVE 配置：根据云下 Hive 集群的调优经验以及在 EMR 使用过程中的摸索，调整了很多参数，比如 JVM 堆内存、MR Task 内存、日志等级、Session 链接数等等；

4)Impala/Presto：EMR 支持使用独立的 Task 节点进行既席查询引擎部署，避免跟 Node Manager 混布造成的资源争抢。在遇到一些大查询或高并发查询场景时，也不会对 Master 节点造成压力，甚至可以单独为查询进行查询引擎的快速扩容。

3、集群运维：

腾讯云的 EMR 是一款半托管的 PaaS 产品，与云下 Hadoop 集群相比，更具有灵活性和定制性。客户即使没有丰富的运维经验也可以借助 EMR 提供的白屏化运维工具轻松参与运维工作，根据业务需求进行灵活的配置，获得更好的性能和扩展性。

云下 Hadoop 集群，公司是有团队专门运维的，每月需要将运维人力费用与业务团队进行分摊。迁移上云之后，腾讯云提供了专业的运维团队，为客户提供全面的 7*24 小时的免费技术支持，客户可以获得及时的技术支持和问题解决，运维效率得到了显著提升，确保业务的稳定运行。

在此基础之上，我们期望能进一步将运维工作往自动化、智能化的方向转型。目前搜狐与腾讯共建告警驱动运维的方式，从多个方面进行告警监控配置，主要包括 EMR 硬件/软件监控告警、腾讯云后台巡检告警以及搜狐业务监控告警，三个告警形成并集，尽可能覆盖住 EMR 所有可能的故障场景。通过主动运维将故障减削于未然，显著的提升了问题排查的能力与运维效率。

图 5-完善的监控告警组成图 

2.2.2 历史数据迁移

历史数据的迁移工作，主要包含以下几个方面：

1、数据仓库

为节约存储成本，我们将云下 HDFS 中的数仓数据的历史数据迁移到对象存储中，此过程中解决了一系列难题:

1)云下 Hadoop 集群由于有多个业务部门共用，所以开启 Kerberos 认证，而云上已经进行了网络、安全组以及集群级隔离，且业务方只能通过调度系统提交代码，为了方便管理团队，云上的集群没有开启 Kerberos，数据迁移 Distcp 任务均从云下 Hadoop 拉起；

2)由于 COS-Distcp 需要在 Hadoop 集群中引入对象存储的依赖包，为避免对云下 Hadoop 生产集群造成变更，数据迁移使用云上 EMR 集群进行，先通过 Distcp 将数据迁移到云上的 HDFS，随后再通过 COS-Distcp 将云上 HDFS 数据同步到对象存储中，迁移完成后，使用 SkipTrash 参数直接清除云上 HDFS 中转数据；

3)受限于带宽限制问题，由于云下机房到云上机房是有带宽限制，拷贝数据时要时刻关注对 带宽的影响，同时在执行 Hadoop Distcp 时引入 Bandwidth 和 m 参数，来控制迁移任务的带宽和 Map 并发数；

4)数据校验问题，由于 Hadoop Distcp 命令无法校验 HDFS 和对象存储数据的一致性，需在数据迁移完后使用腾讯云提供的 COS-Distcp 工具进行校验；

5)文件时间问题，通过-pt 参数将云下 HDFS 上文件时间属性一并迁移到对象存储中，后续可以根据文件时间属性进行归档操作。 

2、Hive 元数据迁移

基于离线数据管理平台元数据管理模块，获取云下所有的数据库，数据表并通过 Show Create Table XXX 获取数据表的建表语句，数据表 Location 与云下路径保持一致，并通过云上离线数据管理平台实现数据表的批量创建。

3、Raw Log 迁移

将云下存储在 HDFS 中的 Raw Log 数据迁移到 COS 中，结合业务对数据的使用场景，一月前基本不使用的数据存储到深度归档中，一周前的 Raw Log 数据使用频次低，采用低频存储借助 COS 的深度归档和低频功能进一步降低存储成本。

4、StarRocks 迁移

当前云下 StarRocks 数据迁移到云上 StarRocks 主要有以下三种方式:

1)通过 EXPORT 将云下 StarRocks 的数据导出到 HDFS 上，再通过 Broker Load 将数据导入到 云上 StarRocks 中，此方式适合大批量、无特殊字段类型的数据迁移。

2)在云上 StarRocks 中建云下 StarRocks 的 External Table，再通过 Insert Into XXX Select XXX 方式将数据导入，这种方式适合有 HLL、Bitmap 字段的数据表迁移，但如果是大表的话导入速 度相对较慢

3)遗留的 Apache Doris 系统数据迁移，由于 StarRocks 和 Apache Doris 数据格式不兼容，不 能使用 Exprot 方式，通过 MySQL Client 将数据查询结果重定向到本地，再通过 Stream Load 数 据导入到云上 StarRocks 中。

2.2.3 业务系统迁移

图 6-业务系统分布式部署示意图

业务系统迁移工作

主要是离线数据管理平台的迁移工作，

1、服务进程部署在 Router Node 上，相对于云下，机器节点资源更丰富，可以根据需要来伸缩 Router Node；

2、存在 MySQL 中的数据任务、表元信息等，使用 DTS 等工具可以很方便的同步到云上；

3、数据任务迁移，在腾讯云大数据团队的支持下，通过工具对上千个数据任务进行运行测试，主要校验数据任务中的 HIVE 及 Spark SQL 语句，云上和云下 SQL 基本兼容，上千个数据任务中只遇到个别的 SQL 语句兼容性问题，在测试 的时候发现 EMR 的 HIVE CLI 和 Beeline 执行开始阶段会占用大量 CPU，进行了相关 Jar 替换；

最后通过测试、双跑、切流，逐步将整个数据任务 DAG 迁移到云上。

2.3 关键技术改造

2.3.1 存算分离

存算分离技术改造

相信所有企业从传统云下 IDC 切换到云服务的时候，如何选择数据存储是迁移上云过程中遇到的最大难题，腾讯云提供可选择的方案主要有三种：

1、使用 EMR 原生 HDFS 加本地盘方案，该方案能获得更高的本地吞吐，更低廉的存储费用。

2、使用 EMR 原生 HDFS 加云盘方案，该方案能获得更高的灵活性，可以随时根据需要扩容磁盘。

3、使用对象存储 COS，该方案能允许客户在仅保存单副本的情况下实现数据的高可用，从而节约数据存储成本，但是由于从本地读取变成了网络读取，会牺牲一些读写及吞吐性能。

在选择方案前，我们首先看下这些资源的价格：

表 1-资源价格表

1)全部存在 HDFS 会导致 EMR 成本太高。

按照 1P 的数据量进行统计，使用 HDFS 存储，使用 D3 作为 DataNode，按照 3 副本（磁盘坏盘率在每年千分之三，低于 3 副本的配置可能存在丢失数据的危险）计算，至少需要 70 台节点，成本约 45.76 万/月；而使用 OFS 的标准存储，成本约 12.37 万/月，还可以使用归档功能进一步降低成本，两者成本相差 5 倍以上。另外，大量使用 HDFS 还会导致集群不容易弹性伸缩，DataNode 节点下线，每次只能下线 2 台以内，节点上下线还会引起 Rebalance 等问题，对正常业务造成影响。

2)使用对象存储（OFS），实现完全存算分离 

由于对象存储每个桶是有网络带宽限制的，也就在数十 Gb/s，在大量并发任务执行的过程中，会影响数据任务执行效率，而使用 DataNode，每个机器节点的带宽都在 10Gb/s，几十台的机器累积带宽就在上百 Gb/s。

3)Hadoop 和 OFS 的存算分离

在跟腾讯云充分讨论了搜狐智能媒体当前的数据架构及业务逻辑之后，我们借鉴了目前业界流行的架构，共同设计了 Hadoop 和对象存储混存的存算分离架构。在搜狐智能媒体的数据架构中，离线数据的时间效应非常明显，生命周期越近的数据使用频率越高，夜间大量的离线任务主要计算的都是当天的数据。因此我们以一周为界限将数据进行冷热划分，一周前的冷数据沉降到对象存储（OFS）中，降低存储成本；最近一周的热数据存储到 HDFS 中，保障数据任务的效率。由于 Hadoop 不再大量存储数据，我们可以极限地压缩 HDFS DataNode 机器资源的数量，将计算资源 YARN 部署在 D3 和 SA3 节点上，其中 SA3 根据时间或计算需求进行弹性伸缩，极大地降低计算成本并保障执行效率。HDFS 上的数据除了包含每日离线数据任务定时产生的数据外，还会包含通过补数据等方式产生的历史数据，有可能在短时间内堆积大量数据，因此冷数据迁移到 OFS 必须及时、高可靠，且还不能对集群造成影响。

图 7-存算分离数据迁移高可用技术架构图

存算分离的数据迁移高可用技术架构上图所示，迁移功能被设计在上文提到的离线数据管理平台里，基于 Quartz 分布式任务调度架构实现。在 Quartz 里运行 Distributer Job，通过 Quartz 的高可用架构，保障 Distributer Job 能一直运行，Distributer Job 会实时获取 HIVE 元数据，判断按日期分区的一周前的 Partition 所对应的 Location 是否在 OFS 中，如果不在 OFS 中，则将表信息放到任务调度队列中。为了控制数据迁移任务对系统的负载影响，系统只设置了 10 个 Worker Job 运行数据迁移任务，当有 Worker Job 执行完成后，Distributer 会在 Quartz 创建一 个新的 Worker Job 进行数据迁移，这些 Worker Job 会被 Quartz 均衡地调度到各个节点。在每个 Worker Job 内部会将数据从 HDFS 迁移到 OFS，更新 Hive、Impala 等元数据信息，最后再删除 HDFS 中数据。存算分离实践效果：

1)整个 HDFS 集群存储空间的使用量可以控制在 65%左右，如下图所示。极大节省因业务数据增长带来的 HDFS 存储开销。 

图 8-腾讯云 EMR 近 7 天 HDFS 存储量趋势图

2)离线 EMR 集群弹性伸缩，按时间伸缩，每天凌晨 12 点会拉起 2/3 的总资源，上午 6 点多会释放这部分资源，在此阶段，Vcore 的使用率基本都在 90%以上，如下图所示；整个白天和晚上，只保留总资源的 1/3，可以看到此部分的资源使用率维持在 60%左右，短暂时间点有一些使用高峰。

图 9-腾讯云 EMR 集群 近 7 天 YARN Vcores 趋势图 

2.3.2 成本管理 

成本方面腾讯云 EMR 目前只提供整个集群的成本，无法看到单个任务的成本。而我们则希望 能够做成本的精细化管理，可以采集某个人运行的任务资源信息，进而统计出个人、团队使用的资源信息。针对此需求，我们对相关数据进行采集，并使用 StarRocks 进行数据统计分析。数据采集分为两个部分: 

一部分是从 YARN 采集，YARN 提供的 Cluster Applications API 里包含 ID、AllocatedMB、 AllocatedVCores 等字段，如下图所示，使用定时任务每 5 秒采集一次将数据写入到 Kafka 中。 

图 10-YARN 提供的 Cluster Applications API 提供相关参数介绍图

另一部分数据，基于离线数据管理平台，由于 YARN 中的 Application 均是从离线数据管理 平台中提交，对应管理平台中的一个 Job。如下图所示，管理平台会收集 HIVE/Spark 等 Client 端打印的日志信息，获取其中的 Application ID，将 Application ID 和关联的 Job ID 写入到 Kafka 中。值得注意的是，如果是 HIVE 任务，一个 Job ID 可能会关联多个 Application ID。

图 11-离线数据平台与 EMR YARN 交互示意图

在 StarRocks 会建立两个 Routie Load 任务消费 Kafka 中的数据，还会建立一个 MySQL 外表，获取数据平台 Job 的 ID 和 Author 等信息，按照“计算后置”的思路，依赖 StarRocks 强大的计算能力，对三个数据源的数据进行关联、聚合等操作，进行各种分析，比如统计某个时间段内，哪个用户使用的 Vcore 资源最多。

2.4 上云效果

1、降本方面：

1)相比于云下 Hadoop 的总成本，云上大数据的成本控制，取得了满意的效果；

2)费用管理更清晰，可以精确到团队、个人及单个任务，控制不必要的计算需求；

3)成本控制手段更丰富，比如 EMR 弹性伸缩、COS/OFS 的归档等功能，对成本控制不断精进。

2、增效方面：

1)云上单个数据任务要比云下执行的快，主要云下 Hadoop 是多部门共享，资源使用率一直维持在高水位，任务之间相互影响很大；

2)每日基线达标率提升明显，数据任务都能在上班之前完成，提高数据使用效率；

3)资源扩容需求敏捷响应，有大的计算需求来时，可以很快的扩充资源，满足计算需求；

4)技术支持更给力，各种难题腾讯云内部会调动各方面资源进行解决。

后续规划

我们会在降本增效的道路上继续践行，跟腾讯云持续共建。

1、降本方面：

1)开启 OFS 归档和深度归档，及开发配套的回热功能，降低持续增长的数据存储成本；

2)尝试 EMR 容器版，计算资源需求按照负载伸缩，实现完全弹性；

3)尝试使用托管的 PAAS/SAAS 产品，降低运维成本。

2、增效方面：

1)使用 StarRocks 替换 Impala/Presto，作为交互式分析统一入口，StarRocks 有向量化、CBO 等功能，性能比 Impala/Presto 有明显的优势；

2)使用多个 OFS 存储桶，提高总体的带宽性能，提升数据使用效率；

3)尝试使用目前业界的新技术尝试使用，比如数据湖等产品，提升整体数据开发效率。