大数据:Trino简介及ETL场景的解决方案

这篇具有很好参考价值的文章主要介绍了大数据:Trino简介及ETL场景的解决方案。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。


简介

Presto 在 Facebook 的诞生最开始是为了填补当时 Facebook 内部实时查询和 ETL 处理之间的空白。Presto 的核心目标就是提供交互式查询,也就是我们常说的 Ad-Hoc Query,很多公司都使用它作为 OLAP 计算引擎。但是随着近年来业务场景越来越复杂,除了交互式查询场景,很多公司也需要批处理;但是 Presto 作为一个 MPP 计算引擎,将一个 MPP 体系结构的数据库来处理海量数据集的批处理是一个非常困难的问题,所以一种比较常见的做法是前端写一个适配器,对 SQL 进行预先处理,如果是一个即时查询就走 Presto,否则走 Spark。这么处理可以在一定程度解决我们的问题,但是两个计算引擎以及加上前面的一些 SQL 预处理大大加大我们系统的复杂度。

为了解决这个问题,PrestoDB 启动了 Presto Unlimited 以及 Presto on Spark 等项目用于解决这种问题,这些我们可以到 Presto on Spark:支持即时查询和批处理 和 Presto on Spark:通过 Spark 来扩展 Presto 文章中了解详情。今天我们要讲的是 Presto 的另外一个分支 Trino(PrestoSQL)ETL 之路。在过去的六个月时间里,Trino 社区一直在开发支持 ETL 的功能,其代号为 Tardigrade,也是通过修改 Trino 的代码来支持 ETL 的功能。

什么是 Tardigrade 项目

大家喜欢使用 Trino 的地方在于它的查询速度很快,可以通过直观的错误消息、交互体验和联邦查询来解决业务问题。长期存在的一个大问题是,为长时间运行的 ETL 工作负载配置、调优和管理 Trino 是非常困难的。以下是你必须处理的一些问题:

  • 可靠的完成时间:运行数小时的查询可能会失败,从头开始重新启动它们会浪费资源,并使我们难以满足完成时间的要求。
  • 具有成本效益的集群:我们需要 TB 级分布式内存的 Trino 集群来执行查询;
  • 并发性:多个独立客户端可以并发提交查询。由于在某一时刻缺乏可用资源,其中一些查询可能需要终止并在一段时间后重新开始,这使得作业完成时间更加难以预测。

为了解决上面问题我们可能需要由专家团队来完成,但这对大多数用户来说是不可能的。Tardigrade 项目的目标是为上述问题提供一个“开箱即用”的解决方案。社区设计了一种新的容错执行架构(fault-tolerant execution architecture),它允许我们实现具有细粒度重试的高级资源感知调度(advanced resource-aware scheduling)。以下是 Tardigrade 项目带来的效果:

  • 当长时间运行的查询遇到故障时,我们不必从头开始再运行它们。
  • 当查询需要的内存超过集群中当前可用的内存时,它们仍然能够运行成功;
  • 当多个查询同时提交时,它们能够以公平的方式共享资源,并稳步运行。

Trino 在幕后完成所有分配、配置和维护查询处理的繁重工作。我们可以将时间花在分析和交付业务价值上,而不是花时间调优 Trino 集群以满足我们的工作负载需求,或者重新组织工作负载以满足我们 Trino 集群能力。

Tardigrade 项目原理简介

Trino 是一种无状态的计算引擎,所以为了实现 ETL,是需要对 Trino 进行很多修改的。在实现上,Trino 和 PrestoDB 有一些不一样,PrestoDB 为了同时支持 ETL 和即时查询,在初期是开发了代号为 Presto Unlimited 的项目,其主要是将表进行分桶,每个桶的数据是独立的,所以可以独立计算;如果单个桶的数据计算失败了,直接重试这个桶数据所涉及到的计算即可,关于这部分原理可以参见Presto on Spark:支持即时查询和批处理 和 Presto on Spark:通过 Spark 来扩展 Presto等文章。虽然 Presto Unlimited 解决了部分问题,但它并没有完全解决容错问题,也没有改善隔离和资源管理。要实现这些功能无疑需要对 Presto 进行很大的改造,而且这些工作在其他引擎(比如 Spark、Flink 等计算引擎都有)其实都有类似的实现,再在 Presto 上实现有点重复造轮子;所以 PrestoDB 社区引入了 Presto on Spark,Presto on Spark 是 Presto 和 Spark 之间的集成,它利用 Presto 的 compiler/evaluation 作为类库,并使用 Spark 的 RDD API 来管理 Presto embedded evaluation 的执行;这类似于 Google 选择将 F1 Query 嵌入其 MapReduce 框架的方式。

但是反过来看 Trino ,其实现思路和上面不太一样,Trino 的 Tardigrade 看起来是直接在 Trino 上实现了容错、查询/任务重试、shuffle 等核心功能。Trino 将上游 stage 的 shuffle 数据进行落盘,这个支持把数据写到 AWS A3、Google Cloud Storage、Azure Blob Storage 以及本地文件存储(这个是用于测试的),下游的 stage 从磁盘里面读取需要的数据。
大数据:Trino简介及ETL场景的解决方案文章来源地址https://www.toymoban.com/news/detail-480599.html

到了这里,关于大数据:Trino简介及ETL场景的解决方案的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Hive数据倾斜常见场景及解决方案(超全!!!)

    Hive数据倾斜常见问题和解决方案 目录 前言 一、Explain 二、数据倾斜 1.什么是数据倾斜?它的主要表现? 2.产生数据倾斜的常见原因 一.join时:首先是大表关联小表,容易发生数据倾斜 二.join时:空key过多,或者相同key过多 三.join时:不同数据类型关联产生数据倾斜 四.join时

    2024年02月03日
    浏览(44)
  • 数字金融建设中数据传输场景及解决方案

    金融数据泄露、滥用、篡改等安全威胁影响重大,涉及用户个人隐私和企业商 业机密,关乎国家安全和社会稳定,数字金融安全能力建设重要性凸显。 数字金融建设总体情况. 数字金融是通过互联网及信息技术手段与传统金融服务业态相结合的新一代金融服务,依托于大数据

    2024年02月14日
    浏览(55)
  • 基于MapReduce的Hive数据倾斜场景以及解决方案

    通常认为当所有的map task全部完成,并且99%的reduce task完成,只剩下一个或者少数几个reduce task一直在执行,这种情况下一般都是发生了数据倾斜。 即为在整个计算过程中,大量相同的key被分配到了同一个reduce任务上造成。Hive的数据倾斜本质上是MapReduce计算引擎的数据倾斜,

    2024年02月13日
    浏览(53)
  • Unity切换场景保存上一个场景的数据,Unity切换场景的案例,Unity切换场景再返回数据丢失的解决方案

    Unity在切换场景之后在再次返回上不会保存上一个场景的数据的。 但是大多数时候我们是需要这些数据的,这应该如何解决呢? 文件链接:我将解决方案打包了,点我下载,免费,或者私信我发你 首先将需要存储到一个class中,这里以学生为例子 然后我们再创建一个脚本,

    2024年02月02日
    浏览(49)
  • 音视频解决方案(一):在线KTV场景方案

    在线 KTV 是社交娱乐场景下的新型互动玩法,通过歌曲把人与人连接起来,让沟通破冰变得更简单,有效提升平台用户停留时长。 在线 KTV 玩法有很多种,按照形式主要由以下几种: 排麦独唱:观众上麦后可以进行点歌排麦等待,歌曲开始播放后即可进行独唱。 实时合唱:两

    2024年01月24日
    浏览(56)
  • 音视频解决方案(一):秀场直播场景化方案

    秀场直播场景为社交娱乐模式下的视频互动场景,场景支持多人视频连麦互动,更容易吸引用户参与连麦互动,提升用户的消费意愿及粘性。 产品功能目前是推流到 ZEGO 音视频云服务,观众再从 ZEGO 音视频云服务进行拉流,同时主播与观众之间连麦也是通过 ZEGO 音视频云服务

    2024年02月01日
    浏览(53)
  • 零代码解决方案的使用场景和目标

    使用场景: 核心业务需求较为简单; 时间和资源有限,无法大幅度增加开发人员; 财务预算有限,不希望在软件开发方面花费巨额资金; 开发人员可能缺乏必要的技能。 目标: 提高开发效率,快速生成简单的应用程序; 降低开发成本,减少开发人员的工作量; 减少编码

    2024年02月11日
    浏览(48)
  • 94、Kafka消息丢失的场景及解决方案

    1、ack=0,不重试 producer发送消息完,不管结果了,如果发送失败也就丢失了。 2、ack=1,leader crash producer发送消息完,只等待 leader 写入成功就返回了,leader crash了,这时follower没来及同步,消息丢失, 3、unclean .leader .election .enable 配置true 允许选举ISR以外的副本作为leader,会导

    2024年02月16日
    浏览(44)
  • 揭秘Spring事务失效场景分析与解决方案

    在Spring框架中,事务管理是一个核心功能,然而有时候会遇到事务失效的情况,这可能导致数据一致性问题。本文将深入探讨一些Spring事务失效的常见场景,并提供详细的例子以及解决方案。 场景: 当一个事务方法内部调用另一个方法,而被调用的方法没有声明为 @Transact

    2024年02月02日
    浏览(45)
  • 音视频解决方案(二):直播电商场景最佳实践

    本文介绍使用ZEGO SDK 开发电商场景的小程序,具备音视频直播、IM互动、商品列表推送、美颜等功能,可满足商家多种直播卖货需求,可参考该组件实现自己的需求。 若小程序具备符合live-pusher、live-player的类目,则可以使用live-pusher和live-player,live-room 的isNative属性传入true。

    2024年02月20日
    浏览(52)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包