CarbonData集成 Presto（Trino）（1）- 介绍 & 环境篇

个人介绍

有幸在开源之夏选上课题基于CarbonData 之 Presto 优化课题，这个课题主要是针对Presto使用CarbonData查询上做更多的一些优化。这个课题对于我来说十分有挑战点，涉及大数据领域的组件十分多，首先CarbonData作为大数据的一种文件存储格式，在OLAP计算引擎上的查询加速实现有助于数据更快的查询和产出；其次大数据涉及的组件和版本比较广泛，在测试、兼容各种方面带来的挑战会很多，例如Hadoop、Spark、Presto（Trino）、Hive等多个开源大数据组件的协同运行和调试，给项目的协同运行带来十分多挑战，如何把这些组件兼容完美的运行在CarbonData上面也是我的其中挑战点之一；最后开发我们是以课题性能优化为目标，提升用户的查询速度为主要目的去实现相关代码。明确了开发目标后，我们开始动手，首先我们先从了解这2个主要组件开始入手。

CarbonData 是什么？能干嘛？

CarbonData是一种新型的Apache Hadoop本地文件格式，使用先进的列式存储、索引、压缩和编码技术，以提高计算效率，有助于加速超过PB数量级的数据查询，可用于更快的交互查询。同时，CarbonData也是一种将数据源与Spark集成的高性能分析引擎。CarbonData作为Spark内部数据源运行，不需要额外启动集群节点中的其他进程，CarbonData Engine在Spark Executor进程之中运行，运行架构如下

CarbonData特性

• SQL功能：CarbonData与Spark SQL完全兼容，支持所有可以直接在Spark SQL上运行的SQL查询操作。
• 简单的Table数据集定义：CarbonData支持易于使用的DDL(数据定义语言)语句来定义和创建数据集。CarbonData DDL十分灵活、易于使用，并且足够强大，可以定义复杂类型的Table。
• 便捷的数据管理：CarbonData为数据加载和维护提供多种数据管理功能。CarbonData支持加载历史数据以及增量加载新数据。加载的数据可以基于加载时间进行删除，也可以撤销特定的数据加载操作。
• CarbonData文件格式是HDFS中的列式存储格式。该格式具有许多新型列存储文件的特性，例如，分割表和数据压缩。CarbonData具有以下独有的特点：
  • 伴随索引的数据存储：由于在查询中设置了过滤器，可以显著加快查询性能，减少I/O扫描次数和CPU资源占用。CarbonData索引由多个级别的索引组成，处理框架可以利用这个索引来减少需要安排和处理的任务，也可以通过在任务扫描中以更精细的单元（称为blocklet）进行skip扫描来代替对整个文件的扫描。
  • 可选择的数据编码：通过支持高效的数据压缩，可基于压缩/编码数据进行查询，在将结果返回给用户之前，才将编码转化为实际数据，这被称为“延迟物化”。
  • 支持一种数据格式应用于多种用例场景：例如，交互式OLAP-style查询，顺序访问（big scan），随机访问（narrow scan）

CarbonData关键技术和优势

• 快速查询响应：高性能查询是CarbonData关键技术的优势之一。CarbonData查询速度大约是Spark SQL查询的10倍。CarbonData使用的专用数据格式围绕高性能查询进行设计，其中包括多种索引技术和多次的Push down优化，从而对TB级数据查询进行最快响应。
• 高效率数据压缩：CarbonData使用轻量级压缩和重量级压缩的组合压缩算法压缩数据，可以减少60%~80%数据存储空间，很大程度上节省硬件存储成本。

从以上上述描述可以发现，CarbonData作为大数据的一种文件格式，通过一些压缩算法和快速查询索引技术提升查询速度和加速Spark查询，在交互式查询上面具有十分大的优势，下面我自己也做了个表格，通过简单对比目前开源社区上面已有的文件格式（ORC和Parquet）进行对比这3者的一些功能异同点

Presto（Trino）是什么？

Presto是什么是Facebook开源的，完全基于内存的并⾏计算，分布式SQL交互式查询引擎.是一种Massively parallel processing (MPP)架构，多个节点管道式执⾏,⽀持任意数据源（通过扩展式Connector组件），数据规模GB~PB级使用的技术，如向量计算，动态编译执⾏计划，优化的ORC和Parquet Reader等 ，它的查询架构如下：

Presto查询引擎是一个Master-Slave的架构，由下面三部分组成:

• 一个Coordinator节点
• 一个Discovery Server节点
• 多个Worker节点

Coordinator: 负责解析SQL语句，生成执行计划，分发执行任务给Worker节点执行
Discovery Server: 通常内嵌于Coordinator节点中
Worker节点: 负责实际执行查询任务,负责与HDFS交互读取数据
Worker节点启动后向Discovery Server服务注册，Coordinator从Discovery Server获得可以正常工作的Worker节点。如果配置了Hive Connector，需要配置一个Hive MetaStore服务为Presto提供Hive元信息

一些数据模型划分的基本概念如下：

与Spark对比的优缺点如下：

通过以上对比可以看出Presto擅长的领域主要在OLAP查询以及多数据的联邦查询上，可以进行跨库跨数据源查询
适合：PB级海量数据复杂分析，交互式SQL查询，⽀持跨数据源查询
不适合：多个大表的join操作，因为presto是基于内存的，多张大表在内存里可能放不下

社区Presto®商标之争

2019年中，由于Presto社区给FaceBook抢占了商标，导致了PrestoSQL社区不得不更换名字为Trino并且基于原有的PrestoSQL继续发展社区。这个仅仅是更改名字，之前的社区和软件都还在那的，这个项目还是由 原创始人和创造者以及主要贡献者支持。Presto 的新 GitHub 地址为 https://github.com/trinodb/trino

关于为什么取名为 Trino，Presto 创始人 Martin 解释到：
It was inspired from neutrinos (subatomic particles), which are light and travel very fast. And then we made the name smaller by shortening it to trino.
也就是 Trino 的灵感来自中微子，中微子是一种光速很快的粒子，然后大佬们把这个名字缩短为 trino

详细可以查看下面链接的相关情况描述：
https://trino.io/blog/2020/12/27/announcing-trino.html

开发所需环境搭建

我们按照官方文档QUICK START说明，我们可以看到 如果想运行Presto + CarbonData ，我们首先要使用Spark 生成CarbonData文件，并且使用Presto依赖Hive的元数据进行查询对应生成的数据。整体流程是比较复杂的。所以我们首先本地需要先有Hadoop、Hive、Spark环境，以上这些软件还依赖Java和S