2024年にTrinoにコントリビュートした記録をまとめてみました。バグの修正などは除外して、ユーザーに関わる機能にしぼっています。 Delta Lakeコネクタはdelta-kernelを利用せずにトランザクションログやチェックポイントのパースを始め、読み書きを自前で実装していることもあり、ここ2年は作業量が多かったのですが、Delta側が Table Features を導入してからはreaderとwriterのバージョンがあがらなくなり、落ち着いてきました。 プロトコル や RFC も以前ほど頻繁には変更されていない印象を受けます。 そういった背景もあり、Delta Lakeの Variant型 の対応がまだ進行中ですが、先月からは基本的にIcebergのみに完全に注力していくことになりました。現在はIcebergコネクタをWAP（Write-Audit- Publish）パターンを実現できるようにシンタックスの追加を進めています。あとは V3スペック についても対応中です。 Iceberg add_files および add_files_from_table プロシージャの追加 #22751 Sparkのプロシージャと基本的には同じように動作しますが、1つ違いを挙げるとスキーマのバリデーションを追加しています。Sparkでは NOT NULL カラムに対しても NULL が入ったファイルを追加できるのですが、Trino側ではエラーを投げるようにしています。 $all_manifests  メタデータテーブルの追加 #24330 $all_entries メタデータテーブルの追加 #24543 $entries メタデータテーブルの追加 #24172 ALTER COLUMN ... DROP NOT NULL  ステートメントのサポート #20448 Delta Lake Deletion Vectorの書き込みサポート #22102 タイムトラベルクエリのサポート  #21052 メタデータをメタストアにバックグラウンドで保存 #21463 Delta LakeやIcebergでよく問題になるのが information_schema...

6月14, 15日に開催された Trino Fest のキーノートTrino for lakehouses, data oceans, and beyondを見たので日本語訳サマリーです。動画は以下のリンクで見ることができます。 By the numbers 2022年11月から16回リリースされました 2023年に入ってからのコミット数は約2,250 合計のコントリビュータ数は660人以上 Slackメンバーは現在9,900人以上 1,800社を超える2万人以上のコミュニティメンバー db-enginesランキング は96位から69位へ New maintainers 新しいメンテナが2人追加されました。AWSのJames Pettyと、StarburstのManfred Moserです🎉全体のメンテナのリストは https://trino.io/development/roles.html#maintainers に載っています。 Table function improvements 新たに以下のテーブル関数が追加されています。 exclude_columns SELECT文で特定のカラムだけ除いて結果を返却 sequence 指定された範囲の値を生成して返却。従来のスカラー関数は最大で10,000のエントリまでという制限がありましたがテーブル関数ではその制限は撤廃されています。 query/ raw_query リモートで実行するクエリを文字列として受け取って実行結果を返却します。queryテーブル関数はJDBC系のコネクタやBigQuery、Cassandra、MongoDB、raw_queryテーブル関数はElasticsearchコネクタでサポートされています。 procedure   SQL Server内のストアドプロシージャを実行 Fault-tolerant execution 性能の改善やストレージとしてHDFSも対象となりました。MongoDB, BigQuery, Redshift and Oracleコネクタへの対応が追加されました。 Schema evolution, (meta)data, and tools ALTER COLUMN … SET DATA TYPEが新しいシンタックスとして追加 ALTER TABLE …...

Trino version 411 introduced 'migrate' procedure in Iceberg connector. This procedure coverts the existing Hive tables with ORC, Parquet & Avro format to Iceberg table. This article explains the details of the procedure. If you execute CREATE TABLE AS SELECT statement to convert Hive to Iceberg, I would recommend trying this procedure. The procedure will be much faster because it doesn't rewrite files.  The procedure accepts 3 arguments (schema_name, table_name and optional recursive_directory). The possible values for recursive_directory argument are true, false and fail. The default value is fail that throws an exception if the nested directory exists under the table or partition location.   CALL iceberg.system.migrate(schema_name => 'testdb', table_name => 'customer_orders', recursive_directory => 'true');  Let me explain the details of the implementation next.  Generate Iceberg schema object based on Hive table definition Iterate ove...

Starburst 2021年の8月23日にStarburstに入社して1年以上経ったのでその記録もかねて2022年の振り返りです。以前はTrinoに既にコントリビュートしている人が入社してきている印象がありましたが最近は入社してから初めてPRを送る人もよく見かけるので会社としてのフェーズの変化を感じます。 開発する機能によってOSSか社内版かが決まるのですが、僕はほぼフルタイムでTrinoにコミットしています。数年前はOSSのフルタイムコミッターに対する憧れが自分にはあったのですが、実際になってみるとチームにはメンテナーは自分の他にもう1人しかいないので、その人が休暇をとると自分のコードがコミットできず時々困る場面があります。そういった際はPRのレビューにあてる時間を長くしたりして都度調整しています。 Connectors team 入社当時はStarburst EnterpriseのConnectorsチームというSaaS、JDBC、NoSQL系のコネクターを開発するチームに所属していました。チームの名前からはコネクターの開発のみを行う印象を受けますが、必要に応じてエンジンにも手を入れます。例えばALTER TABLE ... SET PROPERTIESやTRUNCATE TALEなどの新しいシンタックスは僕が追加しました。コネクターによって気をつけるポイントは異なるのでそれらについて満遍なく学べたことは良かったです。例えばSaaS系のコネクターは自分達のコードが変わっていなくてもSaaSサービス側の変更で期待とは異なる動作に繋がることがあるので、パッと見では冗長とも見えるほど多くのテストコードを書く必要があります。JDBC系のコネクターではJDBCドライバーの標準になっている部分の開発は比較的楽なのですが、タイプマッピングなど実装依存の部分や、ドライバーのコードがオープンになっていないコネクターを直すのはなかなかの手間でした。JDBC系の多くのコネクターがJulianからGregorianのカレンダースイッチ(1582月10-05日~1582月10日14)以前の日付を正常に扱えないバグを途中見つけたのですが個別に直していくのは時間がかかりました。 Lakehouse team 2022年3月23日からはLakehouseチームというHadoopエコシステム系...

Trinoで2022年に追加された新機能を紹介します。他にも多くの機能が追加されていますがメジャーなものに絞りました。 Polymorphic table functions Polymorphic table functionsは聞き慣れないかもしれませんが、スカラー関数とは違って複数の行や列を返却できる関数のことです。例:  SELECT * FROM TABLE(my_function(1, 100)); テーブルを引数に取れないなど内部的にはまだ未実装の部分もありますが、クエリをパススルーする関数がJDBC系コネクター、Elasticsearch, BigQueryおよびMongoDBが実装しています。関数の性質上、クエリをリモートに実際に実行する前に結果のカラム名とタイプを取得する必要があります。JDBCはPrepared StatementでResultSetMetaDataから取得、Elasticserachは取得が難しいので現状は1カラム1レコードにJSONを詰め込む形の実装、BigQueryはクエリをdry runして取得、MongoDBは内部的に管理している_schemaコレクションから取得といった流れになっています。 JDBCコネクターを使用する人が多そうなのでもう少し内部的な実装を説明すると、ResultSetMetaDataを取得する必要があるのでDDLなどは基本的にはサポートされていません。"基本的には"と書いたのはJDBCドライバの実装依存だからです。DDLに関してはTable functionではなくProcedureで実装される予定です  #12322 。次に内部的には完全にパススルーしている訳ではなくSELECT * FROM (...) oのようにラップしています。そのため対象のデータベースが生成されたクエリを実行できない場合もあります。例えばSELECT * FROM (SHOW DATABASES) oなどはエラーになるDBが多いでしょう。これらはあくまでデフォルトの実装 (DefaultQueryBuilder)なのでコネクターを自身で開発されている方は適宜変更することも可能です。 関連リンク Diving into polymorphic table functions with Trino Tabl...

7/11に開催されたPresto Conference Tokyo 2019について書こう書こうと思いつつ放置していたところ、ちょうど3ヶ月後の10/11にコミッターになったので、ご報告もかねて下書きを開きました。この記事では当日話そうと思ってスライドから削った部分や最近のコミュニティについて書きたいと思います。 現在 Presto Software Foundation (PSF)とPresto Foundationという2つの組織があり、前者はPrestoを最初に作り始めたクリエイター達および Starburst のメンバーを中心に、 Arm Treasure Data 、 Varada 、 Qubole などその他にも多くの企業・開発者から支持されながら運営されています。後者はFacebookを中心にTwitter, Uber, Alibabaが支持していて、Linux Foundationにホストされることが先日発表されました。こう書くとどららを選ぶべきか悩むかもしれませんが、前者の方が開発の速度は早くコミュニティが非常に活発に動いてるので、特別な理由がなければPSF側のPrestoを使用することやコミュニティへの参加をお勧めします。Facebook側のリポジトリやSlackも見るようにしているのですが、対応が遅く残念な気持ちになります。メーリングリストは両者で同じアドレスが使用されているのですが、回答者の多くはPSFのコミュニティメンバーなのでSlackで直接質問するとすぐ回答を得られます。 PSFのSlackにはこちらのページにあるリンクから参加できます。 https://prestosql.io/slack.html チャンネルは結構多くて戸惑いそうですが、個人的にお勧めするチャンネルは以下の通りです。 #troubleshooting #generalで質問しても問題ないのですがトラブル等はこちらで質問すると素早く回答を得ることができます #community-announcement ミートアップなどの情報がポストされます #dev 開発に興味がある方はぜひ！ #general-jp 日本語で気軽に話せるチャンネルです 実際に開発に参加しなくても、もっと日本からコミュニティに参加してくれる方が増えてくれるとと...

This is quick tutorial for presto-ml connector. The connector isn't maintenanced actively and the supported model is only SVM. You can see below sample query in the test directory. As the same as Teradata Aster and BigQuery ML, there're two kinds of functions. learn_classifier: receives training data and generates the model classify: receives the model & test data and returns the prediction SELECT classify (features(1, 2), model) FROM (  SELECT learn_classifier (labels, features) AS model  FROM (   VALUES (1, features(1, 2))) t(labels, features) ) t2 → 1 SELECT classify (features(1, 2), model) FROM (  SELECT learn_classifier (labels, features) AS model  FROM (   VALUES ('cat', features(1, 2))) t(labels, features) ) t2 → 'cat' Let's try using Iris data sets. CREATE TABLE iris (   id int , sepal_length double , sepal_width double , petal_length double , petal_width double , species varchar ) INSERT INT...

If you are hive user and ETL developer, you may see a lot of INSERT OVERWRITE. Though it's not yet documented, Presto also supports OVERWRITE mode for partitioned table. Currently, there are 3 modes, OVERWRITE, APPEND and ERROR. OVERWRITE overwrites existing partition. APPEND appends rows in existing partition. ERROR fails when the partition already exists. You can change the mode by set session command. set session hive.insert_existing_partitions_behavior = 'overwrite'; set session hive.insert_existing_partitions_behavior = 'append'; set session hive.insert_existing_partitions_behavior = 'error'; The enhanced feature for an unpartitioned table is ongoing in this PR ( https://github.com/prestosql/presto/pull/648 ) by James Xu . The enhancement was merged as  https://github.com/prestosql/presto/pull/924

Presto SQL release 304 contains new procedure system.sync_partition_metadata() developed by @luohao .  This is similar to hive's  MSCK REPAIR TABLE . Document about Hive Connector Procedures is  https://prestosql.io/docs/current/connector/hive.html#procedures The syntax is `system.sync_partition_metadata(schema_name, table_name, mode)`. The supported mode are add, drop and full. Example query is call system.sync_partition_metadata('default', 'test_partition', 'add'); call system.sync_partition_metadata('default', 'test_partition', 'drop'); call system.sync_partition_metadata('default', 'test_partition', 'full'); # Mode DROP hive> create table default.test_partition (c1 int) partitioned by (dt string); hive> insert overwrite table default.test_partition partition(dt = '20190101') values (1); hive> dfs -mv hdfs://hadoop-master:9000/user/hive/warehouse/test_partition/dt=20190101 /...

This snippet is bulk-loading csv to Teradata via Python. Recently teradatasql  was released, but this code uses  PyTd . If you haven't setup PyTd, please install the library by `pip install teradata`. import teradata import csv udaExec = teradata.UdaExec() session = udaExec.connect("tdpid") data = list(csv.reader(open("testExecuteManyBach.csv"))) batchsize = 10000 for num in range(0, len(data), batchsize):     session.executemany("insert into testExecuteManyBatch values (?, ?, ?, ?)"),     data[num:num+batchsize], batch= True ) The points are batch=True and specifying batchsize. If you don't set the batchsize or the size is too large, it will be failed (forgot the actual message though). The performance in my environment (1 node) was 10,000 rows/sec. The table has 4 columns. I assume tens of thousands looks fine, but more rows should be imported with FastLoad or MLOAD.

My colleague found that some queries on Teradata are improved by  Short-circuit evaluation . This is common knowledge among software engineers, but DBA may not know it. I knew it short circuit, but I didn't know it is effective to sql. For example, following query seems not bad and you may think everything is ok. (Please forget 'like any' since it is rewritten internally) SELECT  * FROM t1 WHERE  c1 LIKE '%a0001%' OR  c1  LIKE  '%a0002%' OR  c1  LIKE  %a0003%' ... OR c1  LIKE  '%a9999%' ; By using short circuit, this query can be rewritten like this.  SELECT  * FROM t1 WHERE  c1  LIKE  '%a%' and  (  c1  LIKE  '%a0001%'  OR c1  LIKE  '%a0002%'   OR  c1  LIKE  '%a0003%'  ...   OR  c1  LIKE  '%a9999%' ) ; Of course, this rewrite isn't effective for all situations. It depends on the data character...

Trinoのパーサー部分では ANTLR が使われています。 ファイルは以下のパスにあります。パーサー系で追加したり修正する場合はまず SqlBase.g4 を参照することになるかと思います。 以下はCTAS文の抜粋です。例えば、SELECT文でカッコをつけても正常にパースしたい構文を追加する例をまずはあげてみます。  CREATE TABLE (IF NOT EXISTS)? qualifiedName    (COMMENT string)?    (WITH tableProperties)? AS query    (WITH (NO)? DATA)?                                             #createTableAsSelect 修正例はこんな感じになります。右側のカッコはエスケープするためにクォートで囲んでいます。 なんとなくイメージがつくと思いますが、|はORの役割を果たしているのでqueryもしくは(query)をこれは表しています。  CREATE TABLE (IF NOT EXISTS)? qualifiedName    (COMMENT string)?    (WITH tableProperties)? AS (query | '('query')')    (WITH (NO)? DATA)?                                             #createTableAsSelect SqlBase.g4を修正したtrino-par...

6/15に行われたPresto Meetup 第3回に参加してきました。実際に運用されている方々の話はやっぱり勉強になりますね。 Presto Update by @Lewuathe 0.152から0.178へのアップグレード時の変更点などの説明。 EXPLAIN (type VALIDATE)は他のDWH製品から移行を検討する時に使えそう。Lambda式は使い所があまり分かっていなかったけれど、複数カラムに対しては便利ということに納得しました。 Presto at Treasure Data by @taroleo 単に時間がかかるクエリが問題なのではなく、普段より遅いクエリが問題という問題設定方法がおぉーと思いました。PrestoのログをPrestoで分析してるのは再帰的な感じがして面白いですね。 Prestoベースのマネージドクエリサービス Amazon Athena by 志村 誠さん AWSユーザーが多かったのか、質問タイムが大盛況。Athenaについてはあまり調べてなかったのですが、これを機に今後はちょくちょくチェックしていきたいと思います。 Presto - 僕とヤフーと時々Teradata(仮) by @uokada 既存のシステムをPrestoに置き換えて97%高速化したお話。この夏、EmbulkのORCアウトプットが作成されるということで楽しみにしています。 DMMでのprestoおよび周辺エコシステムの運用事例 by @r_megane 主に日中に使われるアドホック用と夜間に使われるバッチ用にクラスタを分けていて、夜間帯はアドホック用のWorkerをバッチ用クラスタに追加するという使い方。ここらへん、わざわざクラスタを分けずに、ユーザーの設定や他DWHのスロットルみたいな感じでできたら便利そうな気がしますね。