Presto/Trinoのサブクエリ重複実行問題について

Trino Presto

Presto/Trinoは分散クエリを高速に実行するためにストリーミング型のアーキテクチャを採用しているのですが、このためクエリ内に重複箇所があっても複数回並列に実行されてしまうという問題があります。わかりやすい例だと、CTEで定義したクエリを複数回参照した場合、参照した回数分そのクエリの処理が実行されてしまいます。複数回実行されるクエリが重く、参照回数が多い場合、このコストはかなり厳しいものになります。

調べてみたところ、Presto由来のクエリエンジンでいくつかの対策が行われていたのでまとめてみました。

openLookeng

openLookengというのはHUAWEIがオープンソースで開発しているビッグデータプラットフォームのようなのですが、クエリエンジンはPrestoをベースとしているようです。こちらではCTEに専用のオペレータを導入し、複数のコンシューマのキューにデータをプッシュできるようになっています。

gitee.com

CTE専用オペレータが導入されていることからCTE以外の共通部分には適用できないのではないかと思いますが、直感的なわかりやすさはあると思います。

PrestoDB

PrestoDBではRaptorXというキャッシュ活用プロジェクトの一環としてクエリフラグメントの出力をワーカーのディスク上にキャッシュするという機能が実装されていました。同一のスプリットが同一のワーカーにアサインされた場合にキャッシュが利用されるというもののようです。

github.com

クエリをまたいでキャッシュを共有できるというのはメリットだと思いますが、実際のワークロードでのキャッシュヒット率がどのくらいか気になるところです。ディスクの消費も激しくなると思うのでユースケースによっては使いづらいのではないかと思いますが、インハウスのデータウェアハウスなど、テーブル数やデータ量がある程度限定されており、ワークロードが予測可能な環境であれば有効かもしれません。

Amazon Athena

AmazonのAthenaではクエリの共通部分をリライトすることでマージしてしまうクエリフュージョンという最適化が実装されているようです。

www.amazon.science

www.amazon.science

この方法は対応可能なケースに制限はあるものの、他の方法と違ってクエリのリライトのみで実現できるためアーキテクチャ非依存であるという利点があります。実際AthenaだけでなくRedshiftなどでも同様の最適化が実装されているようです。Trinoにプルリクエストが出されているのですが、まだマージされていません。実際に動かしてみたのですが、ペーパーで書かれている機能がすべて実装されているというわけではなさそうです。

github.com

ベンチマークだと逆に遅くなってしまうケースもあるようですが、オプションで有効・無効を切り替えられるようになっているので入ってくれると嬉しいですね。

まとめ

問題意識としては同じだと思うのですが、Pretso一族の中でも対策は様々でした。このあたりは各プロダクトが想定するユースケースにもよるところもありそうです。その中でもAthenaのクエリフュージョンはクエリのリライトのみで対応できるので副作用も小さそうですし、比較的気軽に試すことができそうです。

また、Athenaのペーパーにはクエリフュージョンだけでなくスプーリングもロードマップにあると書かれています。それなりに大きな変更になりそうですが、実現の暁にはコミュニティにもなんらかの形でフィードバックされるといいですね。

今年のTrinoへのコントリビューションをまとめてみた

Trino

前半は仕事が忙しすぎてOSS活動どころではなかったのですが、後半から少し余裕ができたのでTrinoにも細かい改善やバグ修正などいくつかPRを送って取り込んでもらうことができたので記録のためにまとめてみました。

年末までにまだ増えるかもしれないので増えたら追記します。

GitBucket 4.40.0をリリースしました

GitBucket

Scalaで実装されたオープンソースのGitサーバ、GitBucket 4.40.0をリリースしました。

https://github.com/takezoe/gitbucket/releases/tag/4.40.0

このバージョンでの大きな変更および新機能は以下の通りです。

デフォルトブランチが変更可能に

これまでmaster固定だったデフォルトブランチ名ですが、設定で変更可能になりました。デフォルトは引き続きmasterのままですが、将来のバージョンでmainへの変更を検討したいと思います。

イシュー/プルリクエスト検索でカスタムフィールドをサポート

イシューやプルリクエストをカスタムフィールドで検索できるようになりました。

検索ボックスでfield_name=valueやfield_name<valueといった検索条件を指定できます。

フォークしたリポジトリのデフォルトブランチからプルリクエストを作成可能に

これまでフォークしたリポジトリのデフォルトブランチからはプルリクエストを作成できなかったのですが、これが可能になりました。

ニュースフィードで参照可能な全リポジトリのアクティビティを表示

これまでダッシュボードのニュースフィードでは自身が管理者として所有しているリポジトリのアクティビティのみ表示されていましたが、参照権のあるすべてのリポジトリのアクティビティを表示するようになりました。

これによってこれまでは表示されていなかったコラボレーターとして登録されているリポジトリのアクティビティもニュースフィードに表示されるようになりました。

Java 8サポートの廃止

GitBucketの実行環境としてJava 8はサポートされなくなりました。もしGitBucketをJava 8環境でお使いの場合、Java 11以降へのアップグレードをお願いいたします。

git pushのパフォーマンス改善

git pushのパフォーマンスを改善しました。巨大なリポジトリではこの改善では不十分な可能性がありますが、引き続き改善策を模索していきます。

今回のバージョンではこの他にもWeb APIを中心に様々なバグフィックスを行っています。詳細についてはIssueの一覧をご覧ください。

Scalatra 3.0.0をリリースしました

Scala

サーブレットベースのScala用WebフレームワークでScalatra 3.0.0をリリースしました。

github.com

機能面では2.x系と基本的に変更はなく（非推奨になっていたモジュールを削除したりはしています）Scala 3とJakartaへの対応がメインとなっています。Jakarta対応に伴って各モジュールのアーティファクト名に-javaxまたは-jakartaというサフィックスが付くようになっていますのでご注意ください。

// for javax
libraryDependencies += "org.scalatra" %% "scalatra-javax" % "3.0.0"

// for jakarta
libraryDependencies += "org.scalatra" %% "scalatra-jakarta" % "3.0.0"

周辺ライブラリのScala 3対応待ちもあり、最初にマイルストーンビルドを出してから1年以上経ってしまいましたが、先日最後のブロッカーだったTwirl 1.6.0が無事リリースされたのでScalatraも正式にリリースすることができました。サンプルやドキュメントなどがまだ更新できていないのですが、量がかなりあるので少しずつ修正していきたいと思います。

今後についてですが、Scalatraは新規に使い始めるユーザさんより既存のアプリケーションで使用していてアップグレードしたいというケースの方が圧倒的に多いと思うので互換性を維持しつつ最新のScalaやライブラリに対応していくだけで十分かなとは思うものの、SPA以前のWebフレームワークなのでAPI開発には使いにくいと感じる部分もあり、そのあたりは強化してもよいかもしれないなぁと感じています。

GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ

書籍

GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ

GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ

Amazon

私が勤務するトレジャーデータは現在フルリモート環境というわけではないのですが、パンデミック以前からチームはグローバル体制だったのでリモートワークや非同期コミュニケーションは必須で入社直後はそれゆえの難しさを感じることもあり、パンデミックでフルリモートとなって改善した点もあったり、オフィス回帰の流れとなっても結局チームメンバーがオフィスに揃うわけではないので以前の問題が解決するわけではなかったりと、グローバルチームにおいては時差や文化の差異など、単にリモート or オフィスに止まらない難しさがあり、何かヒントが得られればと思いこの本を読んでみました。

内容的には評価制度などあまりリモート固有ではなさそうなトピックもあったり、ドキュメントやオンボーディングなど気になっていたトピックがめっちゃサクっと終わってしまったり、「リモート組織のつくりかた」というだけあってやはり組織の強力な意志がないと実現が難しい部分が多く一社員が読んでどうこうという本ではないような気もしたりしましたが、カルチャーの話やコミュニケーションのルールなど個人でも参考になる部分もありました。GitLabの方が書いているわけではないので難しいのかもしれないですが、もう少し立場に応じた具体的な例や体験談があったりすると嬉しかったような気もします。

著者の方もパンデミックを機に自社をリモート組織に変革したとのことなので、このタイミングでの出版は仕方ない気もしますが、どちらかといえばオフィス回帰の流れな昨今、パンデミック初期に本書が出ていたらもう少し違った受け止め方をされていたような気もします。しかし自分がGitBucketを作り始めた頃はまだGitLabも法人化したかどうかくらいだったの時期だったと記憶しているのですが、いやはやすごい会社になったものだなぁと勝手に感慨に浸っていますw

WEB+DB PRESSと私

技術系情報誌の廃刊ラッシュを乗り越え20年以上の長きに渡り続いていたWEB+DB PRESSがまさかの休刊ということで、WEB+DB PRESSにお世話になったソフトウェアエンジニアの端くれとしてWEB+DB PRESSとの思い出を書いてみたいと思います。

gihyo.jp

私がWEB+DB PRESSに出会ったのはちょうど新卒で横浜のとある弱小零細偽装請負SES企業に就職した直後のことでした。自社で立ち上げるサービスを社員教育を兼ねて（今思えば新卒社員をいきなり現場に売るわけにもいかず）Javaで作るということで、Webといえば学生時代PerlでCGIを書いたりはしていましたが、Javaを触るのはほぼ初めてだったので、創刊号のTomcatやJSPの記事を読みながら一生懸命動かしていた記憶があります。

gihyo.jp

その後も都内各所に派遣されたり幽閉されたりしながらSI業界の底辺で働いていた若かりし日の私にとって、WEB+DB PRESSやJAVA PRESS、Java Worldといった技術情報誌は様々な分野の最新技術について学ぶことのできる情報源であるとともに、記事を執筆されているスーパープログラマーの皆さんは憧れの存在でもありました。また、Java専門誌だったJAVA PRESSやJava Worldと違ってWEB+DB PRESSは記事のバラエティも豊富で、当時自分からは遠い存在だと思っていたキラキラWeb界隈の様子を窺い知ることのできる貴重な場でもありました。

その後、OSS活動を行うようになり、その絡みで雑誌やWeb媒体で執筆の機会を頂いたり書籍を出させていただいたりもするようになったもののWEB+DB PRESSだけは縁がなかったのですが、2005年ついにJSF特集の際に当時個人でOSSとして開発していたJSF開発用のEclipseプラグインを紹介する記事を書かせていただいたのは一生の思い出です（多分WEB+DB PRESSで記事を書かせていただいたのはこれが最初で最後だったと思います）。

gihyo.jp

現在では技術情報はインターネットで最新の情報をいくらでも得ることができる時代ですが、自分から情報を取りに行くというスタイルだとどうしても自分が興味のある分野に偏りがちです。WEB+DB PRESSのような雑誌は自分が普段興味のない分野の情報にも触れることができますし、著者の方独自の知識や経験に基づいた記事など、単なる技術情報を超えたコンテンツも大いに魅力のあるもので、最近も気になる特集記事がある場合はちょこちょこ購入させていただいていました。

振り返ると駆け出しの頃にWEB+DB PRESSに出会っていなければ現在の私はなかったといっても過言ではありませんし、同じようにWEB+DB PRESSに育てられたという方も多いのではないかと思います。これで残る紙媒体の主要な技術系情報誌は同じく技術評論社さんのSoftware DesignだけになってしまいましたがWEB+DB PRESSの分まで末長く頑張って欲しいです。

エンジニアのためのマネジメント入門

書籍

エンジニアのためのマネジメント入門

エンジニアのためのマネジメント入門

Amazon

スタッフエンジニア本のインタビューで「過去にマネジメントやってたときの経験が今でも活きている」という話をさせていただいたのですが、よくよく考えるとSI時代はマネジメントと言ってもプロジェクトマネジメントが中心でしたし、前職の時点でもまだ世の中的に形ばかりの1:1などが導入され始めたくらいでエンジニアリングマネジメントに関する知識が一般化されているとは言えない時期でした。

結局その後ICとして現職に転職しマネジメントからは離れることになりましたが、最近では日本国内でもエンジニアリングマネージャーというロールが一般的になってきてはいるものの、一言でエンジニアリングマネージャーと言ってもその果たすべき役割は組織の状況によって様々だなーと感じることが多く、また現職でも様々なタイプのマネージャーと接する機会があり、いろいろ思うところもあったのでこのあたりで一度自分の考えを整理しておきたいと思いこの本を読んでみました。

内容はマネジメント入門というだけあってコミュニケーションの基礎から組織のマネジメント、予算管理、採用・評価、技術戦略など浅く広く触れられています。実務を通じてなんとなく思っていたことがきちんと言語化されており、当時こういった知識があればもう少し違った振る舞いができたかもしれないなーと思うなどしました。これらの知識は自身がマネージャーでなくてもチームで仕事をする際に活かすことができると思いますし、こういった視点を持っておくとマネージャーと意思疎通がしやすくなるというメリットもあるのではないかと思います。

個人的に読んでいて面白いなと感じたのは「チームのフェーズによって必要なリーダーシップのスタイルが異なる」という話で、確かにそうだなと実感するところはあるものの、実際は同一のマネージャーがころころとスタイルを使い分けるのはなかなか難しいのではないかと思いましたw