この記事は気にはなってるけど触ってないビッグデータ系のツール・サービスを触る Advent Calendar 2022 にリンクしてます。

はじめに

アドベントカレンダー用にいくつか調べてみたい候補として DataSketch や Iceberg などがありましたが、Trino というツールが気になったのでこちらをさわってみようかと思います。

Trino とは?

もともとは Presto を開発したメンバー 2018 年頃に Facebook から離れて別プロジェクトして開発を始め、 2020 年にリブランドしたプロジェクトのようです。リブランドの背景はこちらのブログをください (参考)。会社によってコミュニティへの関わり方や考え方が違うということは私も経験してきましたが、このブログからも Trino 開発メンバーから見た会社とコミュニティへの考え方の現状は把握できるかと思います。もちろん Trino 開発メンバーからの視点だけなので実際の現情はわかりませんので知っている方いたら教えてください。

詳細な概要はこちらの記事のほうがまとまっているのでそちらをご覧ください高性能分散SQLエンジン「Trino」最速ガイド。 Hiveより速いは触ったことがないのでわからないですがそこは気になりますね。

この記事では、 docker で Trino を触ってみた話を書いてみたいと思います。

2022/12/24時点

watch	folk	star
162	2.1 k	6.9 k

Docker ではじめる Trino

まずは Docker の起動と SQL cli の実行です。

docker run --name trino -d -p 8080:8080 trinodb/trino

#2回目の実行は下記
docker run -d -p 8080:8080 trinodb/trino

docker exec -it trino trino

このまま docker exec で実行していくとデータをいれるのが手間がかかりそうなので docker-compoase を使いたいと思います。その前にデータストアについて考えます。

みたところデータをストアする機能は Trino 自身にはなさそうです。本家のドキュメントを確認するといわゆる他の MySQL などの RDBMS の一般的な用途とは異なると記載があるのでストレージの件も含めてたしかにそうかと思います。 Trino 403 Documentation

Trino には Connector が用意されており、ローカルファイル含めて外部のストレージを対象に SQL を実行できるクエリエンジンと捉えると理解しやすいかと思います。 Trino 392 Documentation

12/26 更新 : twitter でご指摘いただき docker-compose の volumes の指定範囲を変えて、起動に必要ファイルはそのまま、properties だけ変更するように変えました。 catalog だけ変更するならこちらのほうが使いやすいです。

docker-compose.yml

version: '3.7'
services:
  trino-eng:
    image: 'trinodb/trino:latest'
    hostname: trino-eng
    ports:
      - '8080:8080'
    volumes:
      - ./catalog:/etc/trino/catalog
    networks:
      - trino-network

  mysql:
    image: mysql:latest
    hostname: mysql
    environment:
      MYSQL_ROOT_PASSWORD: admin
      MYSQL_USER: admin
      MYSQL_PASSWORD: admin
      MYSQL_DATABASE: tiny
    ports:
      - '3306:3306'
    volumes:
      - ./data:/tmp/data
    networks:
      - trino-network
networks:
  trino-network:
    driver: bridge

データの読み込み方ですが、接続先のデータを読む場合は catalog の中につなぎこむ Database のファイルと接続情報を記載します。今回は MySQL を使ったので mysql.properties を使いました。

mysql.properties

connector.name=mysql
connection-url=jdbc:mysql://mysql:3306
connection-user=root
connection-password=admin

今回は MySQL 側でデータをロードしておき、NOAA の gsod2021 公開データをダウンロードして、count(*) をしました。

MySQL の docker でのデータロードでrootで入らず、adminで入ってしまったため、権限がなく local ファイルをインポートする権限が足りず手間取りました… admin が root ユーザーと勘違いしていました。

trino> SELECT count(*) FROM mysql.tiny.gsod2021;
  _col0
---------
 4014939
(1 row)

Query 20221225_112631_00007_2mpa8, FINISHED, 1 node
Splits: 1 total, 1 done (100.00%)
1.79 [1 rows, 0B] [0 rows/s, 0B/s]

mysql> select count(*) from gsod2021;
+----------+
| count(*) |
+----------+
|  4014939 |
+----------+
1 row in set (1.50 sec)

3回実施して真ん中のレスポンスタイムを取得しました。誤差の範囲で変わらないかなと思います。

今度は 2021 年の全観測地点の平均気温（華氏）を計算します。

Trino

trino> SELECT avg(temp) FROM mysql.tiny.gsod2021;
   _col0
-----------
 54.984913
(1 row)

Query 20221225_112649_00008_2mpa8, FINISHED, 1 node
Splits: 1 total, 1 done (100.00%)
27.16 [1 rows, 0B] [0 rows/s, 0B/s]

MySQL

mysql> select avg(temp) from gsod2021;
+--------------+
| avg(temp)    |
+--------------+
| 54.984911127 |
+--------------+
1 row in set (28.19 sec)

これら2つの処理だけだとそこまでは速度変わらないかなと思います。そもそも今回 Trino を動かしているワーカーが 1 なので MySQL と処理は大きく変わらないかなと思いますのでこれで比較するのは Trino のうまみをいかせていないと思っていますのでご注意ください。

まとめ

Presto は Hadoop を本業で扱っているときに把握していたくらいで、同僚が検証した結果をみるくらいしか把握しておりませんでした。その後 Hadoop からクラウドをメインで扱うようになってから 6 年ぶりくらいにその名前を聞きました。まさかそれが紆余曲折あり別名になっているとは最初に Trino を見つけたときには露ともしれなかったです。ただ、昔知っていたツールがいまでも進化していることを知れるとそれだけでわくわくして楽しかったです。

公式ドキュメントに書いてあるとおり、 RDB の代わりになるものというよりは、クラウドやオンプレなどを含めた複数のデータソースを分析できる SQL エンジンと言えると思います。ハイブリッド環境では検討してもよいでしょうし、ハイブリッドではない単体の状況でもノードの設定などパフォーマンスがでるかもしれないので検証してもよいかもしれません。この記事ではノード数とパフォーマンスの関係値までは見れていないので今後試すか、あるいは他の方が検証した結果をみてみたいと思いました。