--- title: "Trinoとは？分散SQLクエリエンジンの仕組みとPresto・Sparkとの違い【Trino 484対応】" url: "https://www.issoh.co.jp/tech/details/5545/" published: 2025-02-26 updated: 2026-10-18 categories: ["データ分析・BI"] publisher: "株式会社一創" --- # Trinoとは？分散SQLクエリエンジンの仕組みとPresto・Sparkとの違い【Trino 484対応】 Trino（トリノ）は、データを1か所に集めずに、S3上のデータレイクやPostgreSQL・MySQLなどの複数のデータソースへSQLを投げて横断集計する分散クエリエンジンです。Facebookで生まれたPrestoから2019年に分岐し、2020年12月に現在の名前へ改称しました。ライセンスはApache License 2.0で、最新版は2026年10月15日公開のTrino 484です。 この記事では、Prestoとの違い、coordinatorとworkerの構成、Java 25が必要になった導入手順を整理したうえで、Trino 484とPostgreSQL 18を実際につないで取った実行計画から、どの条件がデータソース側へ押し下げられるのかを示します。CLIとPythonからの接続、ユーザーごとのアクセス制御、483から484へ上げるときに結果が変わるSQLも、実行結果つきで載せています。 ## まとめ：Trinoの要点 - Trinoはデータベースではなく、SQLを受けて各データソースから読み出して集計するクエリエンジンです。公式ドキュメントはOLTP（トランザクション処理）向けではないと明記しています。 - PrestoSQLが2020年12月27日にTrinoへ改称しました。Facebook側のPrestoDBはLinux Foundation傘下で別に開発が続いており、版番号の体系も別です（Trino 484とPrestoDB 0.299）。 - 構成は1台のcoordinatorと複数のworkerです。データソースへの接続はコネクタが担い、カタログ.スキーマ.テーブルの3階層でテーブルを指定します。 - サーバーの動作要件は64bit LinuxとJava 25（25.0.1以上）です。Java 21以前では起動しません。手元で試すならDockerの `trinodb/trino` イメージが最短です。 - PostgreSQLコネクタでは、整数列のGROUP BYは集計ごとPostgreSQLへ押し下げられましたが、text列のGROUP BYはWHERE句だけが押し下げられました。PostgreSQLのテーブルは1スプリットで読まれたので、大きなRDBのテーブルを結合すると読み出しがボトルネックになります。 - 長時間のバッチを落としたくない場合は、fault-tolerant execution（`retry-policy=TASK` など）を有効にします。既定は無効です。 - Trino 484ではJSON型とinterval型の挙動が変わりました。483と484で同じSQLを実行すると、`hour(INTERVAL '36' HOUR)` は12から36に、`json_parse` のキー順は並べ替えから入力順の保持に変わります。版を上げる前に、JSONやintervalを使うクエリの結果を比べてください。 ## Trinoの位置づけ：データを事前に集めずにSQLで横断する分析エンジン Trinoはデータを自前で保存しません。クエリを受けるたびにコネクタ経由で各データソースから読み出し、結合・集計はTrinoのworkerのメモリ上で行います。公式ドキュメントの[Use cases](https://trino.io/docs/current/overview/use-cases.html)の章は、Trinoを汎用のリレーショナルデータベースと取り違えないよう、次のように書いています。 > `Trino is not a general-purpose relational database. It is not a replacement for databases like MySQL, PostgreSQL or Oracle.` つまり、業務アプリの更新処理を載せるデータベースの代わりにはなりません。向いているのは、テラバイト級のデータレイクへの対話的な分析クエリ、データを複製せずにRDBとデータレイクを1本のSQLで結合するフェデレーションクエリ、BIツールの背後で使うクエリ層の3つです。OLTPとOLAPの違いは[OLTPとは？OLAPとの違いとAWSのOLAP基盤Redshift・Athenaの選び方](/tech/details/9237/)で詳しく扱っています。 ## TrinoとPrestoの違い：2019年の分岐と2020年の改称 Prestoは2012年にFacebookのデータ基盤チームで、Martin Traverso、Dain Sundstrom、David Phillips、Eric Hwangの4人がHadoop上の巨大なデータウェアハウスを対話的に分析するために作ったエンジンです。 Trino公式ブログの[改称告知](https://trino.io/blog/2020/12/27/announcing-trino.html)（2020年12月27日）によると、2018年にFacebookがPrestoの経験がない社内開発者へコミット権を与える方針を決めたことをきっかけに、創設者のうち3人がFacebookを離れました。2019年1月に独立団体のPresto Software Foundationを作り、フォークをPrestoSQLとして開発します。その後FacebookはPrestoの商標を出願し、2019年9月にLinux Foundation傘下のPresto Foundationを設立しました。商標の条件で合意できず、PrestoSQLは2020年12月にTrinoへ改称しています。コードベースと財団（Trino Software Foundation）も同時に改名されました。 | 項目 | Trino | Presto（PrestoDB） | | --------------- | ----------------------------- | ----------------------------------- | | 旧称・系譜 | PrestoSQL（2019年1月のフォーク） | Facebook本家のPresto | | 運営団体 | Trino Software Foundation | Presto Foundation（Linux Foundation） | | リポジトリ | trinodb/trino | prestodb/presto | | 最新版（2026年10月時点） | 484（2026年10月15日） | 0.299（2026年8月28日） | | 版番号の体系 | 整数の通し番号 | 0.xxx | | AWSでの採用 | Amazon EMR（7.14.0で479-amzn-2） | Amazon EMRで引き続き選択可（AWSはTrinoを推奨） | 「presto sql」と「trino sql」の情報が混在するのはこの経緯のためです。2019年以降は別々に機能が追加されているので、新しく導入するならTrinoを、PrestoDBで組んだ既存環境との互換を優先するならPrestoDBを選ぶ、という分け方になります。 ## Trinoのアーキテクチャ：coordinator・worker・connector ### coordinatorとworkerの役割分担 Trinoのクラスタは、クライアントからSQLを受けて解析・計画・スケジューリングを行うcoordinator 1台と、実際にデータを読み出して処理するworker複数台で構成されます。ノード間の通信はすべてHTTPです。どのノードも `etc/config.properties` の設定だけでcoordinatorにもworkerにもなります。公式ドキュメントの最小構成は次のとおりです。 ``` # coordinator coordinator=true node-scheduler.include-coordinator=false http-server.http.port=8080 discovery.uri=http://example.net:8080 # worker coordinator=false http-server.http.port=8080 discovery.uri=http://example.net:8080 ``` `node-scheduler.include-coordinator=false` はcoordinatorに処理を割り当てない設定です。大きなクラスタでcoordinatorに処理を載せると、スケジューリングと監視に使うはずのCPUとメモリが奪われるため、公式ドキュメントも専用マシンにすることを推奨しています。1台で試すときだけ `true` にします。性能は、workerを足して並列度を上げることで伸ばします。 ### カタログ・スキーマ・テーブルの3階層 Trinoからデータソースを見るには、`etc/catalog/` にプロパティファイルを1つ置きます。ファイル名がカタログ名になり、`connector.name` で使うコネクタを指定します。以下は、TrinoとPostgreSQLを同じホストで動かした実行例のカタログ `pg` です。Dockerでは接続先をコンテナから到達できるホスト名に変更し、カタログファイルを `/etc/trino/catalog` にマウントします。 ``` # etc/catalog/pg.properties connector.name=postgresql connection-url=jdbc:postgresql://localhost:55432/shop connection-user=postgres connection-password= ``` SQLではテーブルを `pg.public.customer_segment` のように「カタログ.スキーマ.テーブル」で指定します。同じPostgreSQLでもデータベースごとにカタログを分けられるので、本番と分析用レプリカを別カタログとして並べることもできます。 ### クエリがstage・task・splitに分かれる流れ coordinatorはSQLを分散実行計画に変換し、ステージ（EXPLAINでは `Fragment` と表示）に分けます。各ステージはworker上のタスクとして並列に動き、タスクはデータソースを分割した単位であるスプリットを読みます。タスクの中では、スプリットを1つずつ処理するドライバーが並列に動き、ドライバーはテーブルの読み出し・フィルタ・集計などのオペレーターをつないで実行します。ステージ間の受け渡しはエクスチェンジで、既定では中間データをメモリ上でパイプライン的に流すので、中間結果をディスクへ書き出すMapReduce型と比べてディスクI/Oを減らせるため、対話的な分析に向いた設計です。その反面、ノードが1台落ちるとクエリ全体が失敗します。これを補うのが後述のfault-tolerant executionです。 ## Trinoの導入手順：Dockerとtarballの2通り ### Dockerで最短に試す手順 公式のコンテナイメージ `trinodb/trino` にはサーバーとCLIの両方が入っています。タグを省略すると `latest` になるので、再現性が必要なら `trinodb/trino:484` のように版を指定します。 ``` docker run --name trino -d -p 8080:8080 trinodb/trino:484 docker exec -it trino trino trino> SELECT count(*) FROM tpch.sf1.nation; ``` イメージにはサンプルデータを生成するTPC-Hカタログが入っているので、データソースを用意しなくてもクエリを試せます。`docker ps` の表示が `(health: starting)` から `(healthy)` に変われば起動完了です。Kubernetesで動かす場合は公式のHelmチャートが用意されています。 Trino 484からイメージの土台がRed Hat Hardenedのcore runtimeに変わり、`grep` や `dnf`、`useradd` が入っていません。起動スクリプト `run-trino` も削除されました。独自の `node.properties` をマウントしている場合は、[Release 484](https://trino.io/docs/current/release/release-484.html)のとおり `node.id=${ENV:HOSTNAME}` を書かないと、コンテナのホスト名をノードIDに使う動作が引き継がれません。イメージを継承して `RUN dnf install` などを足しているDockerfileも、484では作り直しが要ります。 ### tarballで立てる場合の要件と設定ファイル4種 サーバーを直接インストールする場合の要件は、64bitのLinuxと64bitのJava 25です。Trino 484の[Deploying Trino](https://trino.io/docs/current/installation/deployment.html)は次のように書いています。 > `Trino requires a 64-bit version of Java 25, with a minimum required version of 25.0.1 and a recommendation to use the latest patch version. Earlier versions such as Java 8, Java 11, Java 17, Java 21 or Java 24 do not work.` 古いTrinoをJava 21で動かしている環境は、Trinoの版を上げる前にJDKの入れ替えが必要です。JDKはTrinoのテストに使われているEclipse Temurinが推奨されています。配布物は、全プラグイン入りの `trino-server-484.tar.gz`（約861MB）と、最小構成の `trino-server-core-484.tar.gz`（約292MB）の2種類です。core版を選んだ場合は、使うコネクタのプラグイン（`trino-postgresql-484.zip` など）を `plugin/` 配下に展開して足します。macOSで試す場合、Intel Macでは `bin/launcher` がアーキテクチャ判定で止まることがあるので、`bin/darwin-amd64/launcher start --etc-dir etc` のように同梱のバイナリを直接指定します。 展開後に `etc/` に置く設定ファイルは次の4種です。 | ファイル | 役割 | 主な項目 | | --------------------- | ----------- | ---------------------------------------------- | | node.properties | ノード固有の設定 | node.environment / node.id / node.data-dir | | jvm.config | JVMの起動オプション | \-Xmx など1行に1オプション | | config.properties | サーバー設定 | coordinator / discovery.uri / query.max-memory | | catalog/\*.properties | データソースごとの接続 | connector.name / connection-url | `node.environment` はクラスタ内の全ノードで同じ値、`node.id` はノードごとに一意の値にします。起動は `bin/launcher start`、フォアグラウンドで動かすなら `bin/launcher run` です。ログの `======== SERVER STARTED ========` が起動完了の目印になります。 ## 公式コネクタ37種の分類 Trino 484のドキュメントに載っているコネクタは37種です。用途で分けると次のようになります。 一方で、利用の少ないコネクタは削除が進んでいます。Accumuloは464、Kinesisは470、KuduとPhoenixは473、Verticaは480のリリースで削除されました。484でもCassandraコネクタがCassandra 4.0以上を必須にし、Hiveコネクタは新しく作るテーブルの既定の格納形式（`hive.storage-format`）がORCからPARQUETに変わっています。古い記事の設定例をそのまま使う前に、コネクタが現行版に残っているかを確認してください。 | 分類 | コネクタ | | --------- | -------------------------------------------------------------------- | | データレイク | Hive / Iceberg / Delta Lake / Hudi / Lakehouse | | RDB | PostgreSQL / MySQL / MariaDB / SQL Server / Oracle | | DWH・分析DB | Redshift / Snowflake / SingleStore / ClickHouse | | その他のDB | Exasol / DuckDB / Ignite | | クラウドサービス | BigQuery / Google Sheets | | NoSQL・検索 | MongoDB / Cassandra / Redis / Elasticsearch / OpenSearch | | ストリーム・時系列 | Kafka / Pinot / Druid / Prometheus / Loki | | 検証・運用 | TPC-H / TPC-DS / Faker / Memory / Black Hole / JMX / System / Thrift | データレイク系のコネクタは、S3などのオブジェクトストレージ上のParquetやORCファイルを、HiveメタストアやIcebergのRESTカタログを通してテーブルとして読みます。テーブル形式の違いは[オープンテーブルフォーマットとは？Iceberg・Delta Lake・Hudiの違いと選び方を実装視点で解説【2026年版】](/tech/details/13784/)、IcebergカタログをTrinoから使う設定は[Apache Polarisとは？IcebergカタログのRBACとDocker導入手順【1.7.0対応】](/tech/details/9631/)で扱っています。 kintoneやSalesforceのような業務SaaS向けの公式コネクタはありません。接続方法には、データをS3やRDBへ書き出す方法、外部提供のコネクタを利用する方法、コネクタを自作する方法があります。外部コネクタは対象SaaSとTrinoの版への対応を確認します。Google Sheetsは公式コネクタがあり、`connector.name=gsheets` とサービスアカウントの認証情報、シート名とテーブル名の対応を書いたメタデータシートのIDを指定して使います。 ## 異なるデータソースを1本のSQLで結合する実行例 ここからは、Trino 484（Java 25.0.4.1、1ノード構成）にTPC-HカタログとPostgreSQL 18.6のカタログ `pg` をつないで実行した結果です。PostgreSQL側には、データベース `shop` に顧客区分を持つ1,500行のテーブル `customer_segment` を作りました。 ``` -- PostgreSQL（psqlでshopに接続して実行） CREATE TABLE customer_segment (custkey bigint PRIMARY KEY, segment text NOT NULL); INSERT INTO customer_segment SELECT g, CASE WHEN g % 10 = 0 THEN 'premium' ELSE 'standard' END FROM generate_series(1, 1500) g; ``` ### TPC-HとPostgreSQLのテーブルのJOIN TPC-Hの注文テーブル（15,000行）と、PostgreSQLの顧客区分テーブルを結合して、区分ごとの注文数と売上を集計します。分析用ストレージへの事前移行や全件複製は不要で、カタログ名を変えることで別のデータソースのテーブルを同じSQLに並べられます。ただし、実行時には必要なデータをTrinoへ転送します。 ``` SELECT s.segment, count(*) AS orders, round(sum(o.totalprice)) AS revenue FROM tpch.tiny.orders o JOIN tpch.tiny.customer c ON o.custkey = c.custkey JOIN pg.public.customer_segment s ON c.custkey = s.custkey GROUP BY s.segment ORDER BY revenue DESC; segment | orders | revenue ----------+--------+--------------- standard | 13485 | 1.911316129E9 premium | 1515 | 2.16080701E8 (2 rows) ``` ### プッシュダウンされる条件とされない条件 フェデレーションの性能は、WHEREや集計をどこまでデータソース側で済ませられるか（プッシュダウン）で決まります。PostgreSQLのログに `log_statement=all` を設定して、Trinoが実際に送ったSQLを確認しました。まず、text型の列 `segment` でGROUP BYした場合です。 ``` -- Trinoに投げたSQL SELECT segment, count(*) FROM pg.public.customer_segment WHERE custkey <= 1000 GROUP BY segment; -- PostgreSQLが受け取ったSQL（ログより） SELECT "segment" FROM "shop"."public"."customer_segment" WHERE "custkey" <= $1 ``` WHERE句は押し下げられましたが、集計はされていません。PostgreSQLからは条件に合う1,000行がそのまま返り、count(\*)はTrino側で計算されています。同じテーブルに整数列 `tier` を足し（`ALTER TABLE customer_segment ADD COLUMN tier int;` のあと、premiumを1、standardを2に更新）、それでGROUP BYすると結果が変わりました。 ``` -- PostgreSQLが受け取ったSQL（ログより） SELECT "tier", "_pfgnrtd_0" FROM (SELECT "tier", count(*) AS "_pfgnrtd_0" FROM "shop"."public"."customer_segment" WHERE "custkey" <= $1 GROUP BY "tier") o ``` 今度は集計ごとPostgreSQLへ渡り、返ってくるのは2行だけです。EXPLAINでも、前者は `TableScan` の上に `Aggregate[type = PARTIAL]` と `Aggregate[type = FINAL]` が残り、後者は `TableScan[table = pg:Query[SELECT "tier", count(*) ...]]` の1ノードにまとまっていました。 文字列の比較や並び順はデータソースごとに違うため、Trinoは結果の正しさを優先して、文字列が絡む操作の一部を押し下げません。PostgreSQLコネクタのドキュメントでも、CHARやVARCHARの列に対する `>`・`<`・`BETWEEN` などの範囲条件は押し下げないと明記されています（`=`、`IN`、`!=` は押し下げられます）。大きなRDBのテーブルを集計する場合は、GROUP BYや範囲条件に使う列を整数や日付にできないかを先に確認し、EXPLAINで `TableScan` に `Query[...]` が出ているかを見ます。 ### JDBC系テーブルの1スプリット読み出し 上のJOINの `EXPLAIN ANALYZE` では、TPC-Hの注文テーブルは `Splits: 16` で並列に読まれていたのに対し、PostgreSQLのテーブルは `Splits: 1` でした。JDBC系のPostgreSQLコネクタは、このテーブルを1スプリット、つまり1本の接続で読み出していました。workerを増やしてもこの読み出しは並列にならないので、大きなRDBのテーブルをそのまま結合するとここが律速になります。大きなテーブルは、あらかじめ条件で絞り込むか、Parquetに書き出してデータレイク系のコネクタから読むほうが、Trinoの並列性を活かせます。 ### 書き込めるコネクタと書き込めないコネクタ 書き込みに対応するかどうかはコネクタによって決まります。TPC-Hカタログへ `INSERT` すると次のエラーになりました。 ``` INSERT INTO tpch.tiny.nation VALUES (99, 'X', 0, 'x'); Query 20261017_171709_00013_e9vhj failed: This connector does not support inserts ``` 一方、Memoryコネクタには `CREATE TABLE memory.default.premium AS SELECT custkey FROM pg.public.customer_segment WHERE segment = 'premium'` で150行を書き込めました。PostgreSQLへも書き込めますが、[PostgreSQLコネクタのドキュメント](https://trino.io/docs/current/connector/postgresql.html)によると方式は操作ごとに違います。`INSERT` は既定で一時テーブルに書いてから対象テーブルへ移し、`insert.non-transactional-insert.enabled=true` にすると直接書き込む代わりにロールバックできなくなります。`MERGE` は `merge.non-transactional-merge.enabled=true` のときだけ使え、例外時に一部だけ更新される可能性があります。ETLの本番処理を任せる前に、失敗時にどこまで書き込まれるかを確認しておく必要があります。 ## fault-tolerant execution：障害時のクエリ・タスク再実行設定 既定のTrinoは、実行中にworkerが落ちたりリソースが足りなくなったりするとクエリ全体が失敗し、手動でやり直すことになります。fault-tolerant executionでは中間データをスプールし、QUERYではクエリ全体を、TASKでは失敗したタスクを再実行します。設定は `config.properties` の `retry-policy` で、既定値は `NONE`（無効）です（[Fault-tolerant execution](https://trino.io/docs/current/admin/fault-tolerant-execution.html)）。メモリ不足で落ちる場合は、再実行の前に `query.max-memory`（クラスタ全体）と `query.max-memory-per-node`（ノードごと）の上限を見直します。ただし、この2つは `retry-policy=TASK` のクエリには適用されません。TASKでは、ノードへタスクを割り当てるときの見積もりに使う `fault-tolerant-execution-task-memory`（タスクごとの初期メモリ）を調整します。 | retry-policy | 再実行の単位 | 向く処理 | | ------------ | --------- | ---------------- | | NONE（既定） | 再実行しない | 短い対話的クエリ | | QUERY | クエリ全体 | 小さなクエリが大量に流れる環境 | | TASK | 失敗したタスクのみ | 長時間のバッチ・大規模なCTAS | `TASK` ではS3・GCS・Azure・HDFSなどに中間データを置くexchange managerの設定が必要になります。また、対応していないコネクタに対して有効にすると `This connector does not support query retries` で失敗します。Trino 484の時点で対応しているのは、BigQuery、Delta Lake、Hive、Iceberg、MariaDB、MongoDB、MySQL、Oracle、PostgreSQL、Redshift、SQL Serverの11種です。SQLの構文エラーのようなユーザー側の誤りは再実行の対象になりません。484では、`TASK` でスプールした中間データが失われた場合に、再試行の上限まで繰り返さず1回の再試行で失敗する動作に変わりました。 ## Trinoへの接続とアクセス制御：CLI・Python・ファイルベースの権限 ### CLI・Pythonクライアントの接続設定 Dockerの中から `trino` コマンドを叩く以外に、手元の端末やアプリケーションからHTTPでcoordinatorへ接続できます。以下の例は `http-server.http.port=18080` で起動した検証環境に接続しています。前述のDocker起動例のままなら、CLIとPythonの接続先ポートは8080です。CLIは実行可能なjarとして配布されており、`--server` で接続先を、`--user` でユーザー名を渡します。`--execute` を付けると対話モードに入らず1文だけ実行して終わるので、シェルスクリプトやcronから使えます。 ``` java -jar trino-cli-484 --server http://localhost:18080 --user analyst \ --execute "SHOW CATALOGS" ``` Pythonからは公式の [trino-python-client](https://github.com/trinodb/trino-python-client)（PyPIのパッケージ名は `trino`、2026年10月時点の最新は0.340.0）を使います。DB-APIの形なので、ほかのデータベースドライバと同じく `cursor()` と `execute()` で書けます。クライアントは事前に `python -m pip install trino==0.340.0` で入れておきます。上の実行例のPostgreSQLのテーブルを集計した結果が次のとおりです。 ``` import trino conn = trino.dbapi.connect(host="localhost", port=18080, user="admin", catalog="pg", schema="public") cur = conn.cursor() cur.execute("SELECT segment, count(*) AS n FROM customer_segment GROUP BY segment ORDER BY segment") print(cur.fetchall()) # [['premium', 150], ['standard', 1350]] ``` `catalog` と `schema` を接続時に渡すと、SQLの中ではテーブル名だけで書けます。`json` 型の列は、Pythonには `'[1,2.50]'` のような文字列で返ってくるので、Pythonの値として扱うなら `json.loads()` を通します。この例のJSON配列はリストになり、JSONオブジェクトは辞書になります。BIツールやJavaアプリからはJDBCドライバ（Maven Centralの `io.trino:trino-jdbc`、Trino本体と同じ484）を使い、URLは `jdbc:trino://host:8080/catalog/schema` の形になります。 ### ユーザー別のカタログアクセス制御 Trinoの権限は、誰かを確かめる認証と、何を許すかを決めるアクセス制御に分かれます。認証にはパスワードファイル、LDAP、OAuth 2.0、JWT、Kerberos、クライアント証明書などがあり、[Authentication types](https://trino.io/docs/current/security/authentication-types.html)のとおり、どれもTLS（またはTLSを終端したリバースプロキシからの転送の許可）と、クラスタ内通信用の共有シークレットの設定が前提です。アクセス制御には、JSONファイルで規則を書く方式、Open Policy Agent、Apache Rangerを選べます。 次は、ファイルベースのアクセス制御で、`admin` にはすべてのカタログを、`analyst` にはTPC-Hの読み取りだけを許した設定です。`etc/access-control.properties` に `access-control.name=file` と `security.config-file=etc/rules.json` を書き、規則ファイルを置いてサーバーを再起動しました。 ``` { "catalogs": [ {"user": "admin", "catalog": ".*", "allow": "all"}, {"user": "analyst", "catalog": "(tpch|system)", "allow": "read-only"} ] } ``` Trino 484で `--user` を変えて実行した結果です。 ``` -- analyst で SHOW CATALOGS Catalog --------- system tpch -- analyst で PostgreSQLのテーブルを読む Access Denied: Cannot access catalog pg -- analyst で memory にテーブルを作る Access Denied: Cannot access catalog memory -- Analyst（先頭が大文字）で SHOW CATALOGS Catalog --------- system ``` 許していないカタログは `SHOW CATALOGS` にも出ません。規則の `user` は正規表現で、大文字小文字を区別して照合されるため、`Analyst` ではどの規則にも当たらず、`system` だけが見えました。IdPから大文字混じりのユーザー名が届く環境では、規則側を `(?i)analyst` のように書く（この書き方に変えると `Analyst` でも `tpch` が見えるようになりました）か、user mappingでユーザー名をそろえます。Trino 484からは `GRANT` や `REVOKE` でもユーザー名が小文字に変換されなくなったので、同じ注意がSQLでの権限付与にも当てはまります。 この検証は認証を設定していないので、`--user` は自己申告です。誰でも `admin` を名乗れる状態なので、本番ではTLSと認証を先に設定し、そのうえでアクセス制御の規則を書きます。 ## Trino 484で変わった点：483から上げる前に確かめるSQL Trino 484は、JSON型を作り直し、interval型の精度を広げた版です。[Release 484](https://trino.io/docs/current/release/release-484.html)には破壊的変更（breaking）の印が付いた項目が多く、同じSQLでも結果が変わるものがあります。Trino 483と484を同じJava 25で並べて起動し、同じSQLを実行した結果が次のとおりです。 | SQL | Trino 483 | Trino 484 | | ----------------------------- | ------------- | ------------- | | `hour(INTERVAL '36' HOUR)` | 12 | 36 | | `json_parse('{"b":1,"a":2}')` | {“a”:2,”b”:1} | {“b”:1,”a”:2} | | ウィンドウ枠の `EXCLUDE CURRENT ROW` | 構文エラー | 実行できる | | `json_serialize(...)` | 関数が存在しない | 実行できる | interval型から時を取り出す `hour()` は、483では24で割った余りの12を返し、484では先頭のフィールドを丸ごと返す36に変わりました。`json_parse` は、483ではキーを並べ替えていましたが、484では入力の順序と重複キーをそのまま保ちます。JSON文字列を比較してデータの差分を検出しているETLや、時間の差を `hour()` で集計しているレポートは、上げた直後に結果が変わります。`EXCLUDE` 句は、移動平均から自分の行を除くような集計を1つのウィンドウ関数で書けるようにするものです。 ``` SELECT x, sum(x) OVER (ORDER BY x ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING EXCLUDE CURRENT ROW) AS neighbors FROM (VALUES 1, 2, 3, 4) t(x); x | neighbors ---+----------- 1 | 2 2 | 4 3 | 6 4 | 3 ``` このほか、リリースノートで影響が大きいのは次の3点です（Dockerイメージの変更は導入手順の章に書きました）。 - **Hiveコネクタの既定の格納形式**：`hive.storage-format` の既定値がPARQUETになりました。ORCのテーブルを作り続けたい場合はカタログに `hive.storage-format=ORC` を書きます。 - **ファイルシステムキャッシュの設定場所**：Hive・Iceberg・Delta Lakeの `fs.cache.directories` などは、カタログのファイルではなくクラスタ共通のキャッシュマネージャーに書く形に変わりました。カタログ側に残すのは `fs.cache.enabled` だけです。 - **ユーザー名の大文字小文字**：`GRANT`・`REVOKE`・`SET AUTHORIZATION`・`CREATE SCHEMA` でユーザー名を小文字に変換しなくなりました。ロール名は従来どおり小文字になります。 JSON型の変更では、`JSON_SERIALIZE` が予約語になったので、この名前の列やテーブルは二重引用符で囲む必要があります。483以前のクラスタを484へ上げるときは、本番のクエリログからJSON関数・interval・Hiveへの `CREATE TABLE` を含むSQLを抜き出し、2つの版で結果を比べてから切り替えます。 ## TrinoとSpark・BigQuery・Athenaの使い分け | 比較軸 | Trino | Apache Spark | BigQuery | Amazon Athena | | -------- | ------------------ | ------------------- | ---------------- | -------------- | | 主な用途 | 対話的SQL・横断クエリ | ETL・機械学習・ストリーム | マネージドDWH | S3へのSQL | | 書く言語 | SQL | Python・Scala・SQL | SQL | SQL | | データの置き場所 | 各データソース | 各データソース | 専用ストレージ・外部データソース | S3・外部データソース | | 運用 | 自前またはEMR・Starburst | 自前またはEMR・Databricks | サーバーレス | サーバーレス | | 主な費用 | 実行基盤・運用費（提供形態による） | 実行基盤・運用費（提供形態による） | 処理量または計算容量＋保存料 | スキャン量または予約計算容量 | Sparkとの違いは、ユーザーが書く処理の幅です。Sparkは分散処理の汎用フレームワークで、DataFrame APIによる変換、MLlibによる機械学習、ストリーム処理まで1つの基盤で扱います。TrinoはSQLだけに絞り、中間データをメモリ上でパイプライン的に流して対話的な応答を狙う設計です。データエンジニアが夜間のETLをSparkで書き、アナリストが同じデータレイクをTrinoで対話的に引く、という併用は珍しくありません。 Amazon Athenaは、Trinoを自分で運用せずにS3へSQLを投げるためのサービスです。AWSのドキュメントによると、Athena engine version 3はTrinoとPrestoの改良を継続的に取り込む方式に変わり、関数もTrinoを基盤にしています。ただし、Athenaで使える関数や構文はAWSが取り込んだ範囲に限られ、Trinoの最新版の機能がすぐ使えるとは限りません。Athenaの料金の考え方は[Amazon Athenaの料金：スキャン量課金の実額とパーティション設計での削減](/tech/details/17347/)、SDKからのクエリ実行とフェデレーテッドクエリは[AWS Athenaの実装：SDKでのクエリ実行とフェデレーテッドクエリ・Iceberg更新](/tech/details/17734/)にまとめています。AWS上でTrino本体を使いたい場合はAmazon EMRを使い、EMR 7.14.0に含まれるTrinoは479-amzn-2です。 データが1台に収まる規模なら、クラスタを組まずに済むDuckDBのほうが手軽です。単体で動く分析エンジンとの違いは[DuckDBとは？特徴・用途とSQLite・PostgreSQLとの違いを実測で解説【1.5.6対応】](/tech/details/5741/)、Rustで組み込むクエリエンジンは[Apache DataFusionとは？Rust製SQLクエリエンジンの実行計画と導入手順【2026年9月版】](/tech/details/9349/)を参照してください。 ## Trinoを採用すべきでない場面 次の条件に当てはまる場合は、Trinoを入れても運用の手間に見合う効果が出にくいと判断します。 - **分析対象が1つのRDBに収まっている**：まずPostgreSQLのリードレプリカへの直接接続を検討します。Trinoのクラスタを追加せずに済み、構成を単純に保てます。前述のとおりTrinoを挟んでも読み出しは1スプリットのままです。 - **更新系の処理を載せたい**：TrinoはOLTP向けではありません。PostgreSQLへの書き込みも、INSERTの既定動作と非トランザクション設定、MERGEの制約を確認する必要があります。 - **PostgreSQLの文字列列での範囲検索や集計が中心**：既定設定や掲載した集計例では押し下げに制約があります。他の条件で十分に絞れない場合は転送行数が増えるため、実行計画で確認します。 - **Java 25を入れられない環境**：ホストの標準JDKを変更できなくても、Javaを同梱したTrinoのコンテナを利用できる場合があります。コンテナや別環境も使えないなら、Athenaなどのマネージドサービスを検討します。 逆に、データレイクと複数のRDBをまたいで分析したい、BIツールのクエリ層を1つにまとめたい、という要件ならTrinoが第一候補になります。BIツールからは、Trino公式のエコシステムページにGrafana（コミュニティ開発のデータソースプラグイン）、Power BI、Tableau、Looker、Metabaseの接続方法が載っています。Metabaseの構成は[Metabaseとは？構成・エディション差と本番構成への移行を実装視点で解説【2026年版】](/tech/details/16142/)で扱っています。Trinoを含むデータレイクの構成から決めたい場合は、一創の[データ分析基盤構築・MLOps構築支援](/service/ai/data-platform/)で設計から相談を受けています。 ## Trinoに関するよくある質問 ### Trinoはデータベースですか？ いいえ。Trinoはデータを保存せず、各データソースから読み出して集計するクエリエンジンです。公式ドキュメントも、MySQLやPostgreSQLの代わりになる汎用のリレーショナルデータベースではなく、OLTP向けでもないと明記しています。 ### Trinoは無料で使えますか？ はい。Apache License 2.0のオープンソースで、商用利用も無料です。費用が発生するのはサーバーやクラウドの利用料と、Starburstなどの商用版、Amazon Athena・Amazon EMRなどのマネージドサービスを使う場合です。 ### Trinoの最新バージョンはいくつですか？ 2026年10月時点の最新はTrino 484（2026年10月15日公開）です（[Release 484](https://trino.io/docs/current/release/release-484.html)）。`JSON_SERIALIZE` 関数やウィンドウ枠の `EXCLUDE` 句が追加された一方、JSON型やinterval型の結果が変わる破壊的変更も含まれます。480から484までの5版は2026年3月から10月に出ており、間隔は3週間から3か月です。導入時は公式のリリースノートで採用する版の変更点を確認してください。 ### TrinoとPrestoのどちらを選べばよいですか？ 新しく導入するならTrinoが基本です。TrinoはPresto創設者3人が2019年に始めたPrestoSQLが2020年12月に改称したものです。PrestoDB（0.299）はLinux Foundation傘下で別に開発が続いているので、PrestoDBで組んだ既存環境との互換を優先する場合に選びます。 ### MySQLやSQL Server、Googleスプレッドシートにもつなげますか？ はい。MySQL、SQL Server、PostgreSQL、Oracle、BigQuery、Google Sheetsには公式コネクタがあり、`etc/catalog/` にプロパティファイルを置けばカタログとして見えます。kintoneのような業務SaaS向けの公式コネクタはありません。kintoneのデータは、RDBやS3へ書き出してから公式コネクタで読むか、外部のコネクタを使います。 ## 関連記事 - [オープンテーブルフォーマットとは？Iceberg・Delta Lake・Hudiの違いと選び方を実装視点で解説【2026年版】](/tech/details/13784/) - [Apache IcebergとParquetの違い｜テーブル形式とファイル形式の関係を整理](/tech/details/4812/) - [AWS Athenaの実装：SDKでのクエリ実行とフェデレーテッドクエリ・Iceberg更新](/tech/details/17734/) - [Apache DataFusionとは？Rust製SQLクエリエンジンの実行計画と導入手順【2026年9月版】](/tech/details/9349/) - [DuckDBとは？特徴・用途とSQLite・PostgreSQLとの違いを実測で解説【1.5.6対応】](/tech/details/5741/) --- 出典: [Trinoとは？分散SQLクエリエンジンの仕組みとPresto・Sparkとの違い【Trino 484対応】]()（株式会社一創）