Rust版Snowflakeクライアントをオープンソースで公開　データウェアハウスと接続する内部の実装を紹介

kenkoooo氏の自己紹介

kenkoooo氏：じゃあ発表を始めていきたいと思います。「SnowflakeをRustで使おう！」ということで発表します。

先ほど自己紹介があったんですが、自己紹介スライドを作ってしまったのでちょっと見せます。株式会社estieという会社でスタッフエンジニアとして働いています。スタッフエンジニアをもしかしたら聞き慣れない方もいるかと思いますが、「estie スタッフエンジニア」でググるとそれらしい情報がいっぱい出てきます。経歴としては、estieは今はWebアプリの会社なんですが、ずっとWebアプリを作っていたわけではなくて。大学は情報系じゃなかったんですが、自宅で警備をしたり、研究所の技術職員をやったり。

あとは、Web広告もWebアプリではなくドライな広告を入札するシステムみたいなものだったりとか。あとAIスピーカーとか。求人検索はけっこうWeb寄りですが……。

そういう感じで、ソフトウェアエンジニアとして働きつつ、分野としてはいろいろやってきたよという感じで、今はestieで働いています。

estie自体は商業用不動産向けのWebアプリを作っている会社ですが、estieで僕がやっていることとしては、Webアプリを開発するという会社のメインの仕事もやりつつ、興味があって最近はデータ基盤のほうも触っています。

各Webアプリにどうやって正確で大量のデータを届けるかということに取り組んでいたり、あとそれを支えるWebアプリとか、いろいろなプロダクトを支えるプラットフォームを作ったりを最近やっているという感じで、今回話すのはデータ基盤に近いところかなというところです。

データウェアハウス「Snowflake」

会社では「Snowflake」というデータウェアハウスを使っています。気持ちとしては、クソデカデータベースだと思ってもらえれば（良い）と思います。

普通のSQLインスタンスにデータベースをいっぱい作ってるようなことはまあまあやることがあります。あるいは、1インスタンス1データベースで運用していることもあると思います。

ただ、やはり1インスタンス1データベースだと、ぜんぜん違うチーム同士のデータをJOINしたい時とかにけっこう大変で。じゃあ今度は1個のSQLクラスターにいろいろなデータベースを入れると（すると）、こっちのチームのクエリのせいで別のチームのパフォーマンスが下がっちゃったりというところで、データはやはりSQLインスタンスとは別の場所にガッと貯めたいということで、いろいろなデータウェアハウスが世の中にいっぱいあって、それの1つでSnowflakeを我々は使っています。

estieで「Snowflake」がどのように使われているか

estieでどんなふうに使われているかというと、本当にいろいろなチームがどんどんデータを入れていって。「このデータはこのチームの人しか見ちゃだめ」みたいな、そういうセンシティブな情報もいっぱいあるので、そのあたりの権限管理をSnowflakeでうまくやりつつ、いろいろなチームのデータをJOINして、また新しい価値を生み出すようなことは最近できるようになってきました。

ここ1年ぐらいで本当にSnowflakeがフルに使われるようになってきたので、もう「ここからっす」という感じです。

（デモ開始）

Snowflakeを動かす様子を実際にみなさんに見てもらおうと。（画面を示して）こんな感じです。

SQL文で書いてクエリを叩くと、こんな感じでデータが出てきます。これは市区町村の情報が入っていますが、こんな感じで、見た目は完全にSQLという感じです。

（デモ終了）

Rust版Snowflakeクライアント

これでやっていて、このRust版Snowflakeクライアントを今回作りました。オープンソースで公開しているので、ぜひみなさん使ってもらって。

Snowflakeってエンタープライズ向けで、無料プランとかがあまりなくて。AWSみたいに「個人でも気軽に使えます」みたいな感じじゃないので、Snowflakeを会社で使っている人にしか刺さらないライブラリなんですが、けっこう使えると思うので、もしよければ使ってみてください。

今、PythonとかGoとかは公式のSDKがあるんですが、Rust版ではこれが今一番作り込まれていると思うので、使ってみて感想などもらえればと思います。

snowflake-connector-rsのデモ

snowflake-connector-rsが実際に動く様子。

（デモ開始）

（画面を示して）実際どういうふうに使うかというと、こんな感じです。

おなじみのCargo.tomlにはライブラリを入れてもらって、あとはasyncのRuntimeとかも入れてみたいな。普通のやつと一緒です。

使う時はユーザー名とパスワードでログインするので、それを取ってきて。

Snowflakeのアカウント、テナントみたいなものがありますが、概念としてwarehouseというものがあって。これは「どのコンピューティングリソースを使うか？」みたいなやつですね。

データベースとかスキーマとかがあって、PostgreSQLっぽい感じですが、データベースがあって、その中にまた1つのname spaceがあるみたいな感じですね。その中にテーブルがあるというかたちになります。

あとはrole。roleで権限管理をしているので、このroleを設定することによってこっちのデータが見れるようになって、あるいはこっちが見えなくなったりみたいなことがあります。

クライアントで、create sessionという関数で実際にログインしてセッションを作ります。

横道に逸れちゃうのであまり気にせず聞き流してほしいんですが、セッションがどういうものかというと、Webアプリのセッションと基本的には同じですが、Snowflakeにはtemporary tableという概念があって。そのセッションの有効期間だけ生きてるテーブルみたいなものを作ったりできるんですね。

create sessionすると、このセッションがドロップするまでの間、生きてるテーブルみたいなものを作ることができますと。あとは、おなじみのSQLのクエリを書いてもらって実行すると、先ほどのテーブルでいうとIDとか名前とか、都道府県みたいなものが取れたりします。

先ほどのテーブルを叩いているので、実際にどういうふうに動くかというか……。（画面を示して）これは結果しか表示されないんですが、こんな感じですね。

先ほどのSnowflake上で実際に見たデータが、お手元のRustのコードでも取れるという感じになっています。

（デモ終了）

Snowflakeクライアントの内部の実装

ここから内部の実装がどういうものになっているかを話します。Snowflakeって、SQLでクエリを書いて取ってくるみたいな、結果を取得してくる感じなので、「ほかのSQLとなんとなく一緒なのかな」みたいな。

普通にクライアント使っている分にはほかのSQLと同じように使えるんですが、実態としては、HTTPのAPIを叩いて結果を取得するみたいな仕組みです。

だから、中ではクエリをJSONに詰めてpostしてみたいなことが行われています。なので、SQL文をHTTPリクエストのbodyに入れて、結果はJSONで返ってくるみたいな。クラウド時代のデータウェアハウスでSQLっぽい（ことをしている）感じですね。

HTTPを使っていれば大量の結果を取得することはもちろんできるんですが、結果がJSONで返ってくるのであまりやりたくない。すごく巨大なbodyのJSONを返したくないとかはあって。

一応Webの技術で、大量のデータをずっと継続してレスポンスし続ける仕組みみたいなものはあるんですが、僕がSnowflakeで実装していておもしろいなと思ったのは、これもまたクラウドって感じで……。

最初の数行、数百行だけレスポンスをJSONに載せて返してくるんですが、残りは分割してS3にアップロードして、「S3のここにアップロードしたから、あとはお前がダウンロードして自分で結合してね」みたいな感じで、S3のファイルのリストが来ます。

という感じで、1レスポンスに全部の情報が一応入っていて、ユーザーは最初の数百行はレスポンスに含まれているので、残りの行は全部S3に行ってダウンロードして結合して使うという感じになっています。ライブラリではこのあたりは隠蔽されているんですが、興味があれば中身を読んでみてください。

ほかの公式のSDKとかを見ても、いろいろな工夫があって。我々もまだそのユースケースにたどり着いていないんですが、S3にアップロードするファイルの形式もgzip圧縮されているものだったり、あとは別の形式だったり。なんかいろいろな工夫をしているらしいです。なので、SQLでクエリを書いて、結果がS3に上がってくるということは、いかにも21世紀ですねという感じがしています。

そういう感じでライブラリを作ったので、ぜひ使ってほしいです。Snowflakeを契約している人しか使えないのでちょっと心苦しいんですが、契約している方はぜひ使ってみてください。

という感じで、私の発表は以上になります。ありがとうございました。