现在您现已了解衔接器从第6章供给给Trino的功用以及怎么装备它们。让咱们将这些常识扩展到一些更杂乱的运用场景和衔接器。这些一般是需求足够智能的衔接器，以将底层数据源的存储办法和思维转化为 SQL 和 Trino 的表导向模型。

经过直接转到关于您想要运用Trino衔接和运用SQL进行查询的体系的部分，进一步了解：

• “运用Phoenix衔接到HBase”
• “键-值存储衔接器示例：Accumulo”
• “Apache Cassandra衔接器”
• “流体系衔接器示例：Kafka”
• “文档存储衔接器示例：Elasticsearch”

然后，您能够经过学习“Trino中的查询联邦”中的查询联邦和相关的ETL用法来完善您的了解。

与Phoenix衔接到HBase

散布式、可扩展的大数据存储Apache HBase构建在HDFS之上。可是，用户并不局限于运用低级别的HDFS并运用Hive衔接器拜访它。Apache Phoenix项目供给了一个SQL层来拜访HBase，而多亏了Trino Phoenix衔接器，因而您能够像拜访任何其他数据源相同从Trino拜访HBase数据库。

和往常相同，您只需一个目录文件，比方etc/catalog/bigtables.properties：

connector.name=phoenix5
phoenix.connection-url=jdbc:phoenix:zookeeper1,zookeeper2:2181:/hbase

衔接URL是到数据库的JDBC衔接字符串。它包含用于发现HBase节点的Apache ZooKeeper节点列表。

Phoenix办法和表被映射到Trino办法和表，您能够运用惯例的Trino句子查看它们：

SHOW SCHEMAS FROM bigtable;
SHOW TABLES FROM bigtable.example;
SHOW COLUMNS FROM bigtable.examples.user;

现在，您现已准备好查询任何HBase表并在下流东西中运用它们，就像从衔接到Trino的任何其他数据源获取的数据相同。

运用Trino答应您查询HBase，同时享受水平扩展的Trino的功用优势。您创立的任何查询都能够拜访HBase和任何其他目录，答应您将HBase数据与其他源兼并到联合查询中。

键值存储衔接器示例：Accumulo

Trino包含多个用于衔接键值数据存储的衔接器。键值存储是一种经过运用仅有键来存储和检索记载字典的体系。幻想一下哈希表，经过键检索记载。这个记载能够是单个值、多个值，乃至是一个调集。

存在许多具有不同功用的键值存储体系。一个广泛运用的体系是开源的、宽列存储数据库Apache Cassandra，Trino供给了对其的衔接器。您能够在“Apache Cassandra衔接器”中找到更多信息。

咱们现在将具体评论的另一个示例是Apache Accumulo。它是一个高功用、广泛运用的开源键值存储，能够经过Trino衔接器进行查询。一般的概念能够转化到其他键值存储。咱们运用Accumulo衔接器作为示例，展现衔接器需求完结什么使命，将不同体系的上下文映射到Trino的概念。

受Google的BigTable启发，Apache Accumulo是一个用于可扩展存储和检索的排序散布式键值存储。Accumulo将键值数据存储在按键排序的HDFS上。

图7-1显现了在Accumulo中，键由行ID、列和时刻戳三元组组成。首先按行ID和列按升序字典次序排序，然后按时刻戳按降序次序排序。

经过运用列族和部分组，能够进一步优化Accumulo。关于Trino来说，大部分操作都是通明的，但了解SQL查询的拜访办法可能有助于优化创立Accumulo表。这与为运用Accumulo的任何其他应用程序优化表是相同的。

让咱们看一下表7-1中联系表的逻辑表明。

因为Accumulo是一个键值存储，它将数据的这种表明办法与逻辑视图不同地存储在磁盘上，如表7-2所示。这种非联系存储使得确认Trino怎么从中读取数据变得不那么直观。

Trino Accumulo衔接器负责将Accumulo数据模型映射为Trino能够了解的联系模型。 图7-2显现Accumulo运用HDFS进行存储，并运用ZooKeeper办理有关表的元数据。

从根本上说，Accumulo是一个由主节点和多个分片服务器组成的散布式体系，如图7-3所示。分片服务器包含并揭露分片，这是表的水平分区片段。客户端直接衔接到分片服务器以扫描所需的数据。

就像Accumulo本身相同，Trino Accumulo衔接器也运用ZooKeeper。它从Accumulo运用的ZooKeeper实例中读取全部信息，例如表、视图、表特点和列界说。

让咱们看看怎么从Trino中的Accumulo中扫描数据。在Accumulo中，能够运用Scanner方针从表中读取键值对。扫描器从表的特定键开端读取，并在另一个键或表的结尾结束。扫描器能够装备为仅读取所需的切当列。回想一下联系型数据库衔接器，只要需求的列会添加到生成的SQL查询中以推送到数据库中。

Accumulo还有一个BatchScanner方针的概念。在跨多个规模从Accumulo读取时运用它。这更有用，因为它能够运用多个作业节点与Accumulo通信，如图7-4所示。 用户首先将查询提交给和谐器，和谐器与Accumulo通信以确认来自元数据的拆分。它经过查找Accumulo中的可用索引中的规模来确认拆分。Accumulo回来索引中的行ID，Trino将这些规模存储在拆分中。假如无法运用索引，一个拆分将用于单个分片中的全部规模。最终，作业节点运用这些信息衔接到特定的分片服务器，并从Accumulo中并行提取数据。这经过运用Accumulo的BatchScanner东西从数据库中提取数据。

一旦数据从作业节点中拉回，数据就会被放入Trino能了解的联系格局中，而且Trino会完结余下的处理。在这种状况下，Accumulo用于数据存储，Trino供给了对Accumulo中的数据的高档SQL接口。

假如您自己编写应用程序来从Accumulo检索数据，您可能会编写相似以下Java片段。您设置要扫描的规模，并界说要获取的列：

ArrayList<Range> ranges = new ArrayList<Range>();
ranges.add(new Range("1234"));
ranges.add(new Range("5678"));
BatchScanner scanner = client.createBatchScanner("flights", auths, 10);
scanner.setRanges(ranges);
scanner.fetchColumn("flightdate");
scanner.fetchColumn("flightnum");
scanner.fetchColumn("origin");
for (Entry<Key,Value> entry : scanner) {
  // populate into Trino format
}

不需求读取的列的修剪概念与联系型数据库衔接器相似。Accumulo衔接器不运用SQL下推，而是运用Accumulo API设置要获取哪些列。

运用Trino Accumulo衔接器

要运用Accumulo，请创立一个目录特点文件（例如，etc/catalog/accumulo.properties），该文件引证Accumulo衔接器并装备Accumulo拜访，包含与ZooKeeper的衔接：

connector.name=accumulo
accumulo.instance=accumulo
accumulo.zookeepers=zookeeper.example.com:2181
accumulo.username=user
accumulo.password=password

运用之前的航班示例，让咱们运用Trino在Accumulo中创立一个表，能够运用Trino CLI或经过JDBC衔接到Trino的RDBMS办理东西：

CREATE TABLE accumulo.ontime.flights (
    rowid VARCHAR,
    flightdate VARCHAR,
    flightnum INTEGER,
    origin VARCHAR,
    dest VARCHAR
);

在Trino中创立此表时，衔接器实际上会在Accumulo中创立一个表，并在ZooKeeper中创立关于表的元数据。

还能够创立列族。在Accumulo中，列族是一种用于拜访一同拜访的列的应用程序的优化器。经过界说列族，Accumulo组织怎么存储在磁盘上的列，以便作为列族的一部分频繁拜访的列被一同存储。假如要运用列族创立表，能够将其指定为WITH句子中的表特点：

CREATE TABLE accumulo.ontime.flights (
    rowid VARCHAR,
    flightdate VARCHAR,
    flightnum INTEGER,
    origin VARCHAR,
    dest VARCHAR
)
WITH
   column_mapping = 'origin:location:origin,dest:location:dest';

经过运用column_mapping，您能够界说一个包含列修饰符origin和dest的列族方位，这与Trino列称号相同。

Trino Accumulo衔接器支撑INSERT句子：

INSERT INTO accumulo.ontime.flights VALUES
    (2232, '2019-10-19', 118, 'JFK', 'SFO');

这是刺进数据的一种便利办法。可是，当从Trino向Accumulo写入数据时，当时的吞吐量较低。为了取得更好的功用，您需求运用本机的Accumulo API。Accumulo衔接器在Trino之外供给了用于刺进数据的高功用辅助东西。您能够在Trino文档的独立东西中找到有关加载数据的更多信息。

咱们在前面的示例中创立的表是内部表。Trino Accumulo衔接器支撑内部表和外部表。这两种类型之间仅有的区别是删去外部表仅删去元数据而不删去数据本身。外部表答应您在Accumulo中创立现已存在的Trino表。此外，假如需求更改办法，比方添加列，您能够简略地在Trino中删去表并重新创立它，而不会丢失数据。值得留意的是，当每行不需求具有相同的列集时，Accumulo能够支撑此办法演变。

运用外部表需求更多的作业，因为数据现已以特定的办法存储。例如，在运用外部表时，有必要运用column_mapping表特点。在创立表时，有必要将external特点设置为true：

CREATE TABLE accumulo.ontime.flights (
    rowid VARCHAR,
    flightdate VARCHAR,
    flightnum INTEGER,
    origin VARCHAR,
    dest VARCHAR
)
WITH
    external = true,
    column_mapping = 'origin:location:origin,dest:location:dest';

在Accumulo中的谓词下推

在Accumulo衔接器中，Trino能够运用Accumulo中内建的二级索引。为完成这一点，Accumulo衔接器需求在每个Accumulo tablet服务器上安装一个自界说的服务端迭代器。该迭代器以JAR文件的办法分发，您需求将其仿制到每个tablet服务器上的$ACCUMULO_HOME/lib/ext目录中。您能够在Trino文档中找到关于怎么履行此操作的具体信息。

在Accumulo中，索引证于查找行ID，然后能够运用这些ID从实际表中读取值。让咱们看一个比如：

SELECT flightnum, origin
FROM flights
WHERE flightdate BETWEEN DATE '2019-10-01' AND '2019-11-05'
AND origin = 'BOS';

假如没有索引，Trino将从Accumulo中读取整个数据集，然后在Trino内部进行过滤。作业节点获取包含要读取的Accumulo规模的切片。这个规模是整个tablet的规模。有了索引，比方表7-3中的示例索引，能够显著削减需求处理的规模数量。

和谐器运用WHERE子句和过滤器flightdate BETWEEN DATE ‘2019-10-01’ AND ‘2019-11-05’ AND origin = ‘BOS’扫描索引，以获取表的行ID。然后，这些行ID被打包到作业节点稍后用于拜访Accumulo中的数据的切片中。在咱们的比如中，咱们在flightdate和origin上有二级索引，咱们收集了行ID {2232, 1234, 5478} 和 {3498, 1234, 5678}。咱们对每个索引取交集，知道咱们只需扫描行ID {1234, 5678}。然后，这个规模被放入切片中，由作业节点进行处理，它能够直接拜访单个的值，就像在表7-4的数据具体视图中所示。

为了充分运用谓词推送，咱们需求在要推送谓词的列上树立索引。经过Trino衔接器，能够经过index_columns表特点轻松启用对列的索引：

CREATE TABLE accumulo.ontime.flights (
    rowid VARCHAR,
    flightdate VARCHAR,
    flightnum INTEGER,
    origin VARCHAR,
    dest VARCHAR
)
WITH
    index_columns = 'flightdate,origin';

在这个关于Apache Accumulo的部分，您了解了键值存储以及Trino怎么运用规范SQL查询它。让咱们看看另一个更为广泛的体系，也能够从Trino中获益：Apache Cassandra。

Apache Cassandra衔接器

Apache Cassandra是一种散布式的、支撑大规模数据的宽列存储体系。其容错架构和线性可扩展性导致了Cassandra的广泛应用。

在Cassandra中处理数据的典型办法是运用专为Cassandra创立的自界说查询语言：Cassandra查询语言（CQL）。尽管CQL在表面上看起来很像SQL，但实际上它短少SQL许多有用的功用，比方联接。总体而言，它与SQL有足够的不同，使得运用依赖于SQL的规范东西变得不可能。

可是，经过运用Cassandra衔接器，您能够答应对Cassandra中的数据进行SQL查询。最小的装备是一个简略的目录文件，例如关于盯梢网站上全部用户交互的Cassandra集群，装备文件能够是etc/catalog/sitedata.properties，内容如下：

connector.name=cassandra
cassandra.contact-points=sitedata.example.com

有了这个简略的装备，用户就能够查询Cassandra中的数据了。Cassandra中的任何keyspace（例如，cart）在Trino中都被揭露为一个办法，现在能够运用正常的SQL查询诸如users之类的表：

SELECT * FROM sitedata.cart.users;

该衔接器支撑许多装备特点，答应您根据Cassandra集群自界说目录，为衔接启用身份验证和TLS，等等。

流处理体系衔接器示例：Kafka

流处理体系和发布-订阅（pub/sub）体系旨在处理实时数据流。例如，Apache Kafka被规划为LinkedIn的高吞吐量和低延迟渠道。发布者将音讯写入Kafka，供订阅者消费。这样的体系一般用于体系之间的数据流水线。一般状况下，Trino Kafka衔接器用于从Kafka读取数据，但您也能够运用衔接器发布数据。

运用衔接器，您能够运用SQL查询Kafka主题上的数据，乃至与其他数据进行衔接。在Trino中，典型用例是对实时Kafka主题流进行暂时查询，以查看和更好地了解当时体系中流动的状况和数据。运用Trino使这关于数据剖析师和其他一般不具有任何特定Kafka常识但了解怎么编写SQL查询的用户变得更加简略和可拜访。

Trino与Kafka的另一个不太常见的用例是从Kafka搬迁数据。运用CREATE TABLE AS或INSERT SELECT句子，您能够从Kafka主题读取数据，运用SQL转化数据，然后将其写入HDFS、S3或其他存储。

因为Kafka是一个流处理体系，露出的主题会跟着新数据的到来而不断变化。在运用Trino查询Kafka主题时有必要考虑这一点。运用Trino将数据搬迁到HDFS或具有永久存储的另一个数据库体系答应保留经过Kafka主题传递的信息。

一旦数据在方针数据库或存储中永久可用，Trino能够用于将其露出给诸如Apache Superset之类的剖析东西；拜见“运用Apache Superset进行查询、可视化等”。

运用Kafka衔接器的办法与任何其他衔接器相同。创立一个目录（例如，etc/catalog/trafficstream.properties），运用Kafka衔接器，装备任何其他必需的细节，并指向您的Kafka集群：

connector.name=kafka
kafka.table-names=web.pages,web.users
kafka.nodes=trafficstream.example.com:9092

现在，来自Kafka web.pages和web.users的每个主题都作为Trino中的表可用。随时，该表会露出包含主题中全部当时音讯的整个Kafka主题。在Trino上，运用目录、办法和表称号，现在能够轻松经过SQL查询数据：

SELECT * FROM trafficstream.web.pages;
SELECT * FROM trafficstream.web.users;

基本上，您能够运用简略的SQL查询实时查看Kafka主题。

假如要搬迁数据到另一个体系，比方HDFS目录，您能够从一个简略的CREATE TABLE AS（CTAS）查询开端：

CREATE TABLE hdfs.web.pages
WITH (
   format = 'ORC',
   partitioned_by = ARRAY['view_date']
)
AS
SELECT *
FROM trafficstream.web.pages;

一旦表存在，您能够经过定时运转刺进查询来将更多数据刺进其间：

INSERT INTO hdfs.web.pages
SELECT *
FROM trafficstream.web.pages;

为了防止重复仿制，您能够盯梢衔接器露出的Kafka的一些内部列。具体来说，您能够运用_partition_id、_partition_offset、_segment_start、_segment_end和_segment_count。您定时运转查询的具体设置取决于用于删去音讯的Kafka装备以及用于运转查询的东西，例如在“运用Apache Airflow进行作业流处理”中描绘的Apache Airflow。

将Kafka主题（作为表露出）及其包含的音讯的映射能够在etc/kafka/schema.tablename.json中的每个主题的JSON文件中界说。关于前面的比如，您能够在etc/kafka/web.pages.json中界说映射。

Kafka音讯能够运用不同的格局，Kafka衔接器包含最常见格局的解码器，包含Raw、JSON、CSV和Avro。

有关装备特点、映射和其他内部列的具体信息，请参阅Trino文档中的“文档”。

运用Trino与Kafka打开了对经过Kafka传递的数据进行新的剖析和洞察，并界说了Trino的另一个有价值的用途。Trino还支撑用于相似用途的另一个流处理体系，即Amazon Kinesis。

文档存储衔接器示例：Elasticsearch

Trino包含衔接器，用于一些闻名的文档存储体系，例如Elasticsearch或MongoDB。这些体系支撑以相似JSON的文档办法存储和检索信息。Elasticsearch更适用于索引和查找文档，而MongoDB是一个通用的文档存储体系。

概述

Trino衔接器答应用户运用SQL拜访这些体系并查询其间的数据，尽管这些体系没有原生的SQL拜访办法。

Elasticsearch集群一般用于存储日志数据或其他事件流，以供长时间乃至永久存储。这些数据集一般十分庞大，它们能够是更好地了解宣布操作日志数据的体系以及在各种场景中运用的有用资源。

Elasticsearch和Trino是强壮而高效的组合，因为两个体系都能够水平扩展。Trino经过将查询拆分并在集群中的许多作业节点上运转其部分来进行扩展。

Elasticsearch一般在自己的集群上运转，而且也能够水平扩展。它能够在许多节点上分片索引并以散布办法运转任何查找操作。调整Elasticsearch集群以进步功用是一个独立的主题，需求了解查找索引中文档的数量、集群中节点的数量、副本集、分片装备以及其他细节。

可是，从客户端的角度来看，因而也从Trino的角度来看，这全部都是通明的，Elasticsearch只需运用Elasticsearch服务器的URL揭露集群。

装备和运用

装备Trino以拜访Elasticsearch是经过创立一个目录文件，例如etc/catalog/search.properties 来完结的：

connector.name=elasticsearch
elasticsearch.host=searchcluster.example.com

此装备依赖于端口、办法和其他具体信息的默许值，但关于查询集群现已足够。衔接器支撑Elasticsearch的多种数据类型。它会主动剖析每个索引，将每个索引装备为表，将表揭露在默许办法中，创立必要的嵌套结构和行类型，并在Trino中揭露全部这些。索引中的任何文档都会主动解压缩为Trino中的表结构。例如，名为 server 的索引会主动在目录的默许办法中作为表可用，您能够查询Trino以获取有关该结构的更多信息：

DESCRIBE search.default.server;

用户能够当即开端查询该索引。信息办法或 DESCRIBE 命令可用于了解为每个索引/办法创立的表和字段。

Elasticsearch办法中的字段一般包含作为数组的多个值。假如主动检测不如预期，能够在索引映射的字段特点界说中添加字段特点。此外，_source 隐藏字段包含来自Elasticsearch的源文档，假如需求，能够运用 JSON 文档解析函数（拜见“JSON 函数”）以及调集数据类型（拜见“调集数据类型”）。这些一般在处理Elasticsearch集群中的文档（主要是JSON文档）时十分有用。

在Elasticsearch中，能够将一个或多个索引的数据揭露为别号。这也能够是经过过滤的数据。Trino衔接器支撑别号的运用，并将它们像任何其他索引相同揭露为表。

查询处理

一旦你从Trino向Elasticsearch宣布查询，Trino运用其集群基础设施，除了现已存在的Elasticsearch集群，以进一步进步功用。

Trino查询Elasticsearch以了解全部的Elasticsearch分片。然后在创立查询方案时运用这些信息。它将查询拆分红针对特定分片的独自切片，然后并行向全部分片宣布独自的查询。一旦成果回来，它们在Trino中兼并并回来给用户。这意味着Trino与Elasticsearch结合运用，能够运用SQL进行查询，而且比独自运用Elasticsearch更高效。

还要留意，在典型的Elasticsearch集群中，这种对特定分片的单个衔接也会发生，其间集群在负载均衡器后运转，并经过DNS主机名进行揭露。

全文检索

Elasticsearch衔接器强壮的功用之一是对全文查找的支撑。它答应您在从Trino宣布的SQL查询中运用Elasticsearch查询字符串。

例如，幻想一下一个包含网站上的博客文章的索引。这些文档存储在blogs索引中。或许这些帖子包含许多字段，如标题、简介、文章、摘要和作者。经过全文查找，您能够编写一个简略的查询，查找全部字段中的整个内容，以查找特定术语，如trino：

SELECT * FROM "blogs:  trino";

Elasticsearch中的查询字符串语法支撑加权不同的查找术语和其他适用于全文查找的功用。

总结

该衔接器还支撑Amazon的Elasticsearch开源版别OpenSearch。运用Amazon OpenSearch服务的用户能够运用对AWS Identity and Access Management的支撑。有关此装备以及怎么运用TLS保护与Elasticsearch集群的衔接等更多具体信息，请参阅Trino文档。

运用Trino与Elasticsearch，您能够运用围绕SQL支撑的强壮东西剖析索引中的丰厚数据。您能够手动编写查询或衔接丰厚的剖析东西。这使您能够比以前更好地了解集群中的数据。

衔接MongoDB到Trino时，也能够运用Trino MongoDB衔接器取得相似的优势。

Trino的联邦查询

在阅读了有关Trino在“Trino用例”中的全部用例，并了解了Trino中全部数据源和可用衔接器的状况之后，您现在现已准备好深化了解Trino中的查询联邦。联邦查询是一种拜访多个数据源中的数据的查询。这种查询能够用于将来自多个联系型数据库（例如在PostgreSQL上运转的企业后端应用程序数据库与在MySQL上运转的Web应用程序数据库）的内容和信息进行相关。它还能够是在PostgreSQL上运转的数据库房，经过来自源头也在PostgreSQL或其他地方运转的数据进行查询。

可是，当您将联系型数据库的查询与针对其他非联系型体系的查询结合运用时，更强壮的示例就会呈现。将数据库房的数据与方针存储中的信息相结合，其间包含来自您的Web应用程序的大规模数据。或许将数据相关到键值存储或NoSQL数据库中的内容。您的方针存储数据湖，乃至您的现代数据湖屋，能够突然经过SQL揭露，而且这些信息能够成为更好地了解整体数据的基础。

查询联邦能够协助您真正了解不同体系中全部数据之间的衔接和依赖联系，从而更好地洞察整体局势。

在接下来的示例中，您将了解在散布式存储中联接数据与联系型数据库中的数据的用例。您能够在“Flight Data Set”中找到有关必要设置的信息。

运用这些数据，您能够经过运用SQL查询提出诸如“每年飞机的平均延误是多少？”这样的问题：

SELECT avg(depdelayminutes) AS delay, year
FROM flights_orc
GROUP BY year
ORDER BY year DESC;

另一个问题是“二月份从波士顿出发的最佳星期几？”：

SELECT dayofweek, avg(depdelayminutes) AS delay
FROM flights_orc
WHERE month=2 AND origincityname LIKE '%Boston%'
GROUP BY dayofmonth
ORDER BY dayofweek;

因为多个数据源和查询联邦的概念是Trino的一个组成部分，咱们鼓励您设置一个环境并探究数据。这些查询能够激发您创立自己的附加查询的灵感。

咱们运用航空数据的两个示例剖析查询来演示Trino中的查询联邦。咱们供给的设置运用存储在S3中并经过装备Hive衔接器拜访的数据。可是，假如您乐意，您能够将数据存储在HDFS、Azure存储或Google Cloud存储中，并运用Hive衔接器查询数据。

在第一个示例查询中，咱们期望Trino回来HDFS中数据中航空公司飞翔最多的前10家航空公司：

SELECT uniquecarrier, count(*) AS ct
FROM flights_orc
GROUP BY uniquecarrier
ORDER BY count(*) DESC
LIMIT 10;

 uniquecarrier |    ct
--------------- ----------
 WN            | 24096231
 DL            | 21598986
 AA            | 18942178
 US            | 16735486
 UA            | 16377453
 NW            | 10585760
 CO            |  8888536
 OO            |  7270911
 MQ            |  6877396
 EV            |  5391487
(10 rows)

尽管前面的查询供给了飞翔最多的前10家航空公司的成果，可是它要求您了解uniquecarrier的值。假如一个更具描绘性的列供给了航空公司称号的全称而不是缩写，那将会更好。可是，咱们从查询的航空数据源中获取的数据不包含这样的信息。或许假如另一个包含此信息的数据源存在，咱们能够将数据源组合起来以回来更易了解的成果。

让咱们看另一个比如。在这里，咱们期望Trino回来飞翔最多的前10个机场：

SELECT origin, count(*) AS ct
FROM flights_orc
GROUP BY origin
ORDER BY count(*) DESC
LIMIT 10;

  origin |  ct
-------- ---------
 ATL    | 8867847
 ORD    | 8756942
 DFW    | 7601863
 LAX    | 5575119
 DEN    | 4936651
 PHX    | 4725124
 IAH    | 4118279
 DTW    | 3862377
 SFO    | 3825008
 LAS    | 3640747
(10 rows)

与前面的查询相同，成果需求一些范畴专业常识。例如，您需求了解origin列包含机场代码。关于对成果进行剖析的专业常识较少的人来说，这个代码是没有意义的。

让咱们经过将成果与联系型数据库中的附加数据结合起来，增强咱们的成果。在咱们的示例中，咱们运用PostgreSQL，但关于任何联系型数据库，相似的进程也是适用的。

与航空数据相同，咱们的GitHub库房包含在联系型数据库中创立和加载表以及装备Trino衔接器以拜访它的设置。咱们挑选装备Trino从包含附加航空公司数据的PostgreSQL数据库查询。PostgreSQL中的carrier表供给了航空公司代码到更具描绘性的航空公司称号的映射。您能够将此附加数据与咱们的第一个示例查询一同运用。

让咱们看一下PostgreSQL中的carrier表：

SELECT * FROM carrier LIMIT 10;

 code |                 description
------ ----------------------------------------------
 02Q  | Titan Airways
 04Q  | Tradewind Aviation
 05Q  | Comlux Aviation, AG
 06Q  | Master Top Linhas Aereas Ltd.
 07Q  | Flair Airlines Ltd.
 09Q  | Swift Air, LLC
 0BQ  | DCA
 0CQ  | ACM AIR CHARTER GmbH
 0GQ  | Inter Island Airways, d/b/a Inter Island Air
 0HQ  | Polar Airlines de Mexico d/b/a Nova Air
(10 rows)

该表包含code列和description列。运用这些信息，咱们能够运用咱们的第一个示例查询来衔接来自PostgreSQL carrier表的数据和flights_orc表的数据：

SELECT f.uniquecarrier, c.description, count(*) AS ct
FROM datalake.ontime.flights_orc f,
    postgresql.airline.carrier c
WHERE c.code = f.uniquecarrier
GROUP BY f.uniquecarrier, c.description
ORDER BY count(*) DESC
LIMIT 10;

 uniquecarrier |        description         |    ct
--------------- ---------------------------- ----------
 WN            | Southwest Airlines Co.     | 24096231
 DL            | Delta Air Lines Inc.       | 21598986
 AA            | American Airlines Inc.     | 18942178
 US            | US Airways Inc.            | 16735486
 UA            | United Air Lines Inc.      | 16377453
 NW            | Northwest Airlines Inc.    | 10585760
 CO            | Continental Air Lines Inc. |  8888536
 OO            | SkyWest Airlines Inc.      |  7270911
 MQ            | Envoy Air                  |  6877396
 EV            | ExpressJet Airlines Inc.   |  5391487
(10 rows)

现在，咱们现已编写了一条单一的SQL查询，从S3和PostgreSQL中联合数据，咱们能够供给更有价值的成果以提取意义。与其有必要知道或分隔查找航空公司代码不同，成果中包含了描绘性的航空公司称号。

在查询中，当引证表时，有必要运用彻底限制的称号。当运用USE命令设置默许的目录和架构时，非限制的表称号与该目录和架构相链接。可是，每逢需求查询超出目录和架构规模的内容时，表称号有必要合格。否则，Trino测验在默许目录和架构中查找它，并回来错误。假如您引证的是默许目录和架构中的表，则无需彻底合格化表名。可是，每逢引证默许规模之外的数据源时，最好作为最佳实践进行彻底合格化。

接下来，让咱们看看 PostgreSQL 中的 airport 表。这个表是咱们联邦化第二个示例查询的一部分：

SELECT code, name, city
FROM airport
LIMIT 10;

 code |           name           |         city
------ -------------------------- ----------------------
 01A  | Afognak Lake Airport     | Afognak Lake, AK
 03A  | Bear Creek Mining Strip  | Granite Mountain, AK
 04A  | Lik Mining Camp          | Lik, AK
 05A  | Little Squaw Airport     | Little Squaw, AK
 06A  | Kizhuyak Bay             | Kizhuyak, AK
 07A  | Klawock Seaplane Base    | Klawock, AK
 08A  | Elizabeth Island Airport | Elizabeth Island, AK
 09A  | Augustin Island          | Homer, AK
 1B1  | Columbia County          | Hudson, NY
 1G4  | Grand Canyon West        | Peach Springs, AZ
(10 rows)

从 PostgreSQL 的这些数据中，你能够看到 code 列能够与咱们在 flight_orc 表上的第二个查询进行衔接。这答应你在查询中运用 airport 表中的附加信息以供给更多细节：

SELECT f.origin, c.name, c.city, count(*) AS ct
FROM hive.ontime.flights_orc f,
    postgresql.airline.airport c
WHERE c.code = f.origin
GROUP BY origin, c.name, c.city
ORDER BY count(*) DESC
LIMIT 10;

 origin |                   name                   |         city          |   ct
-------- ------------------------------------------ ----------------------- ---------
 ATL    | Hartsfield-Jackson Atlanta International | Atlanta, GA           | 8867847
 ORD    | Chicago OHare International              | Chicago, IL           | 8756942
 DFW    | Dallas/Fort Worth International          | Dallas/Fort Worth, TX | 7601863
 LAX    | Los Angeles International                | Los Angeles, CA       | 5575119
 DEN    | Denver International                     | Denver, CO            | 4936651
 PHX    | Phoenix Sky Harbor International         | Phoenix, AZ           | 4725124
 IAH    | George Bush Intercontinental/Houston     | Houston, TX           | 4118279
 DTW    | Detroit Metro Wayne County               | Detroit, MI           | 3862377
 SFO    | San Francisco International              | San Francisco, CA     | 3825008
 LAS    | McCarran International                   | Las Vegas, NV         | 3640747
(10 rows)

与咱们的第一个示例相同，经过在两个不同的数据源之间进行联邦，咱们能够供给更有意义的信息。在这里，咱们能够添加机场的称号，而不是让用户依赖难以解说的机场代码。

经过这个查询联邦的快速示例，你能够看到不同数据源的组合以及在 Trino 中的中央查询能够极大地改善查询成果。咱们的比如仅增强了成果的外观和可读性。可是，在许多状况下，运用更丰厚、更大的数据集，查询的联邦以及来自不同来源的数据的组合可能会导致对数据彻底新的了解。

现在咱们现已从最终用户的角度经过了一些查询联邦的示例，让咱们评论一下这是怎么作业的架构。咱们在 Trino 架构的第 4 章学到的一些概念的基础上构建。

Trino 能够和谐查询在触及的数据源之间的混合履行。在之前的示例中，咱们在散布式存储和 PostgreSQL 之间进行查询。关于经过 Hive 衔接器进行的散布式存储，Trino 直接读取数据文件，无论它们来自 HDFS、S3、Azure Blob Storage 等。关于 PostgreSQL 衔接器这样的联系数据库衔接器，Trino 依赖于 PostgreSQL 作为履行的一部分。让咱们运用之前的查询，但为了使其更有趣，咱们添加一个引证 PostgreSQL airport 表中列的新谓词：

SELECT f.origin, c.name, c.city, count(*) AS ct
FROM datalake.ontime.flights_orc f,
  postgresql.airline.airport c
WHERE c.code = f.origin AND c.state = 'AK'
GROUP BY origin, c.name, c.city
ORDER BY count(*) DESC
LIMIT 10;

逻辑查询方案相似于图 7-5。你能够看到方案包含扫描 flights_orc 和 airport 表。两个输入都被馈送到衔接运算符。但在机场数据馈送到衔接之前，应用了一个过滤器，因为咱们只想查看阿拉斯加州的机场的成果。衔接之后，应用了聚合和分组操作。最终，TopN 运算符履行 ORDER BY 和 LIMIT 的组合。

为了从 PostgreSQL 中检索数据，Trino经过 JDBC 发送查询。例如，在朴素的办法中，以下查询被发送到 PostgreSQL：

SELECT * FROM airline.airport;

可是，Trino比这更聪明，Trino 优化器企图削减在体系之间传输的数据量。在这个比如中，Trino仅查询它从PostgreSQL表中需求的列，并将谓词推送到发送到PostgreSQL的SQL中。

因而，现在从Trino发送到PostgreSQL的查询将更多的处理推送到PostgreSQL：

SELECT code, city, name FROM airline.airport WHERE state = 'AK';

作为JDBC衔接器回来数据到Trino，Trino继续处理在Trino查询引擎中履行的部分的数据。一些简略的查询，比方 SELECT * FROM public.airport，彻底被推送究竟层数据源，如图 7-6 所示，使得查询履行在Trino之外，Trino充当一个透传的角色。

关于更杂乱的SQL推送，取决于衔接器。例如，只触及联系数据库办理体系（RDBMS）数据的衔接器能够将触及的衔接推送到PostgreSQL以消除数据传输到Trino。许多聚合函数也能够由PostgreSQL衔接器推送下去，而其他衔接器未必能够履行此操作。

提取、转化、加载和联邦查询

提取、转化、加载（ETL）是用来描绘将数据从数据源仿制并导入另一个数据源的技能术语。一般在将数据着陆到方针之前，还有一个中间进程来对来自源的数据进行转化。这可能包含删去列、进行计算、过滤和清理数据、兼并数据、履行预聚合等操作，以准备数据并使其适用于在方针中查询。在某些用例中，这些操作的次序会改动，这个进程被称为提取、加载和转化（ELT）。尽管存在一些要害的差异，Trino适用于这两种办法。

Trino并不计划成为一个与商业解决方案相媲美的完好的ETL东西。可是，它能够经过防止需求ETL来供给协助。因为Trino能够从数据源查询，可能就不再需求移动数据了。Trino在数据地点的方位查询数据，从而减轻了办理ETL进程的杂乱性。

您仍然可能期望履行某种类型的ETL进程。或许您想在预聚合的数据上进行查询，或许您不想给底层体系添加更多负载。经过运用CREATE TABLE AS或INSERT SELECT结构，您能够将数据从一个数据源移动到另一个数据源。

Trino能够在这些和其他场景中供给协助，并作为由其他东西编列的ETL作业负载的查询处理和履行引擎。

在运用Trino进行ETL作业负载和用例时的一个巨大优势是它支撑超出联系数据库之外的其他数据源。对查询的容错履行的新支撑使Trino在与现代数据湖库房设置结合运用的ETL用例中成为一流的查询引擎。结合Trino相关于许多其他ETL解决方案的功用优势以及现代数据流水线东西（如dbt、Apache Flink和Apache Airflow）的集成，Trino正在超越纯剖析用例，成为现代数据湖库房和数据渠道架构的重要组成部分。

总结

你现在对Trino中的衔接器有了很好的了解。是时候充分运用它们了。装备你的目录，准备好深化了解有关查询数据源的更多信息。

这将咱们带到了下一个主题，即Trino中SQL的方方面面。SQL常识关于成功运用Trino至关重要，咱们将在第8章和第9章中涵盖你需求了解的全部。