1.Trino的定义

Trino是一个SQL查询引擎。

可以让用户方便地使用SQL来访问任何数据源，也可以利用Trino的横向扩展能力来查询海量数据集。

2.Trino需解决的问题

目前大数据在使用过程中，通常会伴随着以下问题。

2.1.数据洞见依赖更大的数据体量

数据体量增大，每个人都在采集越来越多的数据，这些数据包括设备指标、用户行为跟踪、商业交易、地理位置、软件及系统测试程序和工作流等。从这些数据所得的洞见，能够确定一个商业项目乃至一家公司的成败。

2.2.数据存储方式多样化

目前包括关系型数据库、nosql数据库、文档数据库、键值数据库和对象存储等。对于当前的存储系统，因其适用场景的不同，无法仅仅使用一种。

此外，这些系统不允许我们使用标准工具来查询和检视数据，每个系统的工具各不相同。但是我们的商业分析师已经习惯了业界标准——SQL，无数强大的工具依赖SQL来分析数据，创建仪表盘，制作丰富的报告以及完成其他商业智能工作。

2.3.数据分散在各个孤岛上

数据分散在孤岛，对有些数据查询无法满足分析所需的必要性能。其他系统则将数据存储在单一庞大的系统上，因而不能像现代的云应用程序一样横向扩展。没有这些能力，我们就只能缩小潜在的使用场景和减少用户数量，因此降低数据的实用价值。

2.4.联邦分析的重要性

对全世界的组织来说，创建和维护大型专用数据仓库的传统方法成本高昂。通常，对很多用户和使用模式来说，这种方法也显得缓慢且笨拙。通常被考虑作为解决方案的数据湖，要么成了无人问津的数据倾倒场，要么需要带着巨大痛苦艰难地尝试才能对它做数据分析，作为新方法的数据糊仓，尽管它可以融合数据仓库和数据湖两者的优点，但也不是唯一的解决方案。数据将持续分布，存储在各个地方，并将出现越来越多的系统。

一个系统如果可以释放这些价值，将会带来巨大的机会。

3.Trino特性

Trino具备以下特性。

3.1.为性能和规模而生

Trino是一个使用分布式来执行快速查询海量数据的工具。如果有TB级乃至PB级的数据需要查询，我们可能需要Hive等工具，这些工具依赖Hadoop。与这些工具相比，Trino可以更高效地查询数据。

分析师使用Trino，因为他们期望SQL查询可以在几毫秒、几秒或几分钟内返回结果。Trino支持SQL，通常在数据仓库、数据分析、海量数据聚合和生成报告等任务上，这些通常被归为联机分析处理（OLAP）。

Trion能理解并高效地执行SQL，但它不是一个数据库，因为它不包含自己的数据存储系统。Trino也不适合联机事务处理（OLTP）。许多为数据仓库和数据分析任务设计、优化的数据库也是如此，比如Teradata、Netezza、Vertica等。

3.2.SQL-on-Anything

Trino的设计初衷是用来查询HDFS上的数据。

Trino是一个查询引擎，可以从对象存储、关系型数据库、NoSQL数据库中查询数据。可以取代传统、昂贵、笨重的ETL过程，或者至少为某些现代化高效ETL工具提供一个高效的且能在必要时支持跨所有数据源查询的查询引擎，并减少甚至避免对实际数据源大量的ETL处理。显然，Trino并非只是一个SQL-on-Hadoop解决方案。

Trino在原地查询数据，无需事先将数据迁移集中到某个位置。

Trino几乎可以查询任何东西，是一个真正意义上的SQL-on-Anything。

对于用户来说，这意味着他们与特定系统内数据进行交互时，无须再依赖特定的查询语言和工具。他们可以简单利用Trino和已有的SQL技能。

3.3.数据存储与查询计算资源分离

Trino没有自己的存储，只是在数据所在之处进行查询处理。

使用Trino时，存储和计算是分离的，他们可以各自独立地扩展，Trino代表计算层，底层的数据源代表存储曾。

Trino可以基于对数据的分析需求来扩展和缩减计算资源，无须移动数据或根据当前查询的需求预设计算资源和存储资源，也无需随着查询需求的变化来定期变更资源的分配。

Trino可以通过动态扩展计算集群来扩展查询能力，并可以在数据源中数据所在的位置查询数据。因此，我们可以极大地优化硬件资源需求并降低成本。

4.Trino的适用场景

目前主要有以下场景。

4.1.单一的SQL访问

很多公司运行多个数据库系统，作为消费者或者分析师，我们可能会数不清的问题：

（1）不知道数据在哪里，只能更具经验才能找到正确的数据。

（2）查询多种不同源的数据库，需要使用不同的连接并运行不同的SQL。

（3）若不使用数据仓库，就无法使用查询功能合并来自不同系统的数据。

Trino可以避免这些问题，我们可以从Trino这里访问所有数据库。

4.2.数据仓库和数据源系统访问

一个组织需要更好地理解和分析存放在无数RDBMS中的数据时，数据仓库系统的创建和维护就登上了舞台。从多个系统中提取的数据通过一个复杂的ETL过程，最终进入一个严格受控的、巨大的数据仓库。

尽管数据仓库非常有用，但作为一个数据分析师，会面临很多新问题：

（1）除了原来的数据库，工具和查询现在又多了一个数据接入点

（2）今天使用的数据还没有放入数据仓库，添加数据的过程痛苦、昂贵、又障碍重重

Trino允许添加任何数据仓库作为数据源，就像其他关系性数据仓库一样。

4.3.任何内容的SQL访问

只使用RDBMS的日子早已一去不复返，数据现在存储在许多针对特定使用场景进行优化的不同系统中。基于对象存储、键值存储、文档数据库、图数据库、事件流系统和其他NoSQL系统提供了独有的特性和优势。

Trino允许我们将不同的数据系统作为一个数据源，可以用标准的ANSI SQL来查询相关数据。

4.4.联邦查询

将所有数据孤岛都暴露给Trino是向理解数据迈出的一大步。你可以使用SQL和标准工具来查询所有这些内容，但如果想要回答的问题往往需要我们深入这些数据孤岛，将他们的一些内容提取出来，然后再在同一个地方将其组合起来。

Trino支持联邦查询，联邦查询是在一个语句中引用冰使用不同数据库和模式的SQL查询。可以用同一条SQL语句，在同一时间查询出来自完全不同的系统的数据。

4.5.虚拟数据仓库

数据仓库系统为用户创造了巨大的价值，对组织来说却是一个负担，表现在以下三点：

（1）运行和维护数据仓库是一个巨大而昂贵的项目

（2）需要专门的团队运行与管理数据仓库和相关的ETL过程

（3）将数据导入数据仓库需要用户执行繁琐的操作，并且很耗时

Trino可作为虚拟数据仓库，一旦所有的数据库都配置成Trino的数据源，我们就可以查询这些数据库。使用SQL和Trino支持的函数和运算符，可以直接从数据源获取想要的结果。在使用这些数据前，无须复制、移动、转换它们。

4.6.数据湖查询引擎

数据湖通常指的是一个巨大的HDFS或类似的分布式对象存储系统，在数据被存储到这些存储系统时，并没有特别考虑接下来如何访问它们。Trino可以使它们成为有用的数据仓库。

实际上，Facebook开发Trino的目的就是对一个非常大的Hadoop数据仓库进行更快、更强大的查询，提供Hive和其他工具无法提供的能力。这也是Trino Hive连接器的起源。

4.7.SQL转换和ETL

基于对数据存储系统的支持，Trino也可以用于迁移数据，它所提供的丰富的SQL函数集可以让你查询数据，转换数据，并将数据写入同一个数据源或任何其他数据源。

4.8.更快的响应带来更好的洞见

复杂的问题和海量数据集带来了诸多限制，将数据复制并加载到你的数据仓库并在其中分析它们最终会过于昂贵。要么消耗大量的算力来运行它们，要么耗费许多时间才能得到一个答案。

Trino在设计上避免了数据复制，Trino的并行计算和深度优化通常能为数据分析带来性能提升。

4.9.机器学习和人工智能

Trino将尽可能多的数据开放给SQL相关标准工具，并将查询能力扩展到海量数据集上，这使其成为了大数据处理的主要工具。

随着机器学习和人工智能系统的发展，处理的复杂度也随之上升。基于对R语言和其他工具的支持，Trino也必将在这些使用场景中占据重要位置。