第19回では「データエンジニアのキャリアを考える」と題して、SeattleDataGuyのデータエンジニアであるBen Rogojan氏、クラシルでデータエンジニアを務めているharry氏、NTTデータでデータ活用を推進している渋谷亮太氏の3名に、これまでのデータエンジニアのキャリアや、将来の展望などを話していただきました。
今回の勉強会では、将来生き残っていけるデータ分析アーキテクチャとはどのようなものなのかについて扱っていきます。普段SQL中心のアーキテクチャを専門としている方の中にも、10年、20年先もこの仕事が続けられるか、不安を抱いている方もいると思います。
今回の講演は、そういった疑問を解消し、今後のデータアーキテクトとしてのキャリアにも役立てられる内容となっております。
第20回は「10年戦えるデータ分析入門」と題して、10年先も戦えるデータ分析アーキテクチャとはどのようなアーキテクチャなのか、トークセッションなどを交えながら、詳しくお話しいただきます。
前半の基調講演では、『10年戦えるデータ分析入門』の著者である青木峰郎氏に、SQL中心のアーキテクチャはさらに10年先も戦えるのかについてお話していただきます。本書出版後の業界動向を踏まえつつ、この先のデータ分析アーキテクチャを検討します。
後半のトークセッションでは、青木氏、古橋貞之氏にもデータ分析アーキテクチャについてお話していただきます。Treasure Dataのアーキテクチャについて紹介していただき、それを踏まえ、これからの分析システムについて焦点を当てていきます。
基調講演「さらに10年戦えるかもしれないデータ分析入門 〜AIとDXの時代をこの先生きのこるには〜」
青木峰郎 氏
Treasure Data 株式会社 / Principal Software Engineer元Rubyコ三ッタ―で、前々職では並列RDBMSベンダーを務め、並列データベースと出会う。その後、クックパッドに転職し、分析サービス「たべみる」の開発やDWHの構築に尽力。そして現職のTreasure Data社に務め、CDPの開発を担当。『10年戦えるデータ分析入門』他、著書多数。
Twitterのアカウントはこちら
はじめに、『10年戦えるデータ分析入門』がどのような本であるかについて、お話をいただきました。
『10年戦えるデータ分析入門』を執筆した経緯
青木氏：「（本書は）クックパッドにいた時に、あまり分析SQLになじみのない人たちに分析SQLの書き方を教えたくて書きました。
やはりエンジニアだとSQLを知ってはいますが、基本Ruby on Railsを通して触っています。そのため、『アクティブレコードをとりあえず使い始める』ような方が多く、分析スキルになかなか馴染んでもらえないことが多いです。一方、プランナーやデザイナー、ディレクターなどのエンジニアではない人たちは、そもそもSQLを知りません。
（SQLを知っているが馴染めていない人と、全くSQLを知らない人の）両方に対応できるような本が必要だと思い、本書の執筆に至りました。」
2012年～2015年ごろのIT業界の状況
青木氏：「あくまでも私の認識ですが、上図のような状況だったと思います。
2015年は、エンタープライズに近い会社は、『並列データベース/データウェアハウスにはなじみがあるが、ビッグデータはよくわからない』、『Hadoopもよくわからない』、『最近ビッグデータでDWHはオワコンなのか』といった状況でした。
一方、クックパッドのようなWeb系の新しい企業では、逆にそういった知識が何もなく、『データウェアハウスがわからない』、『データベースがわからない』、『DWHはオンプレで高い？』、『Hadoopを使えばいいのでは？』といった状況でした。
そのため、（エンタープライズ企業とウェブ系の新しい企業では）大きな断絶があったのです。さらに、ウェブ系の企業の中でも、エンジニアとエンジニア以外の人で断絶があり、分析系SQLを取り巻く状況は、非常に良くありませんでした。
こういった混乱した状況をどうにかしたい思いもあって、本書を書いた経緯がございます。」
『10年戦えるデータ分析入門』の内容
青木氏：「本書の内容は、大きく二部構成に分かれており、第1部がSQLの話です。正しい分析のためにSQLを使うと何ができるのかについて書かれています。『インデックスを貼る』、『IDカラムをつける』といった話ではなく、『SELECT文を使おう』、『ジョインを使おう』、『ウィンドウ関数を使おう』といった、あまり見ないSQLの話でした。
第2部は、分析システムの構築についての内容です。並列データベースや、それを使ったビッグデータの処理システムの作り方などを話しました。
大まかに分けると、第1章が前説、第2章〜第10章がSQLの話、第11章〜第13章が「SQL中心アーキテクチャ」という私が名付けた分析システムの作り方の話です。本日もこの内容に沿ってお話しします。
私がこの本で提案したSQL中心アーキテクチャは3つのことをおすすめしています。
1つ目が『SQLで分析しましょう』、2つ目が『データは一ヶ所に集めましょう』、3つ目が『データは3層構造（データソース層、データウェアハウス層、アプリケーション層）に編成しましょう』です。
これが私の言う10年戦えるデータ分析システムです。私の認識としては、今までの8年は戦えたと思ってるため、きっと後2年も戦えると思っています。そのため、『（SQL中心アーキテクチャを）さらに10年戦えるようにするためにはどうしたらいいか』が本日のテーマです。そして先ほど述べた3つのテーマを1つずつ検証し、必要な場合は更新していくことをお伝えします。」
普及したSQL水準
青木氏：「最近のSQLのアップデートについてです。
本を書いた時にすでにあったSQL標準は、最初にSQL標準、それからSQL2、SQL3が普及しました。SQL3では、たとえば正規表現マッチや配列、構造体など、まだ完全に普及しきってはいないが、さまざまなデータベースで実装されてきたものがあります。
SQL:2003ではウィンドウ関数があります。このあたりは本書に記載しました。」
新しめのSQL標準
青木氏：「問題はここからで、新しいSQL標準は数多くあります。
まずSQL:2006のXMLクエリとSQL:2008のTruncate statementはそれほど重要ではありません。SQL:2011のTemporalは面白いですが、今回はあまり説明しません。問題は、SQL:2016とSQL:2023です。これから、SQL:2016とSQL:2023について詳しく説明していきます。」
match_recognizeとは？
青木氏：「SQL:2016のmatch_recognizeは、行の並びに対して正規表現マッチができる機能です。たとえば、ユーザーのアクションが1アクションで記録されており、それに対して『トップページに行き、何ページか商品ページを見て、カートに入れ、すぐ買った』といったパターンが表現できます。
そしてマッチした行に対して集約などができ、素晴らしい機能です。
match_recognizeは意外と実装されており、PrestoやSnowflake、Oracleなどで既に実装されています。」
Aster DataのnPath
青木氏：「私は、match_recognizeに少し思い入れがあります。
上図はAster Dataと呼ばれる並列データで、これがおそらくmatch_recognizeの元ネタです。Aster Dataもmatch_recognizeと同じ機能で、行に対して正規表現マッチして集約ができます。Webのアクセスログの分析をする際に、さまざまなことに使えるため、Prestoなどを使っている方は非常に便利だと思います。
なぜmatch_recognizeに思い入れがあるかと言いますと、このAster Dataという会社は後にTeradataに買収され、私が製品担当していたからです。非常に便利だと思い、当時よく使っていた記憶があります。
ただ、実装は異なる点があり、Aster Dataの方はクラスター内にHadoopが動いており、SQL MapReduceと呼ばれる機能で処理を実行していました。」
JSON typeとJSON operation
青木氏：「次の機能はSQL:2016とSQL :2023で定義された、JSON 関連の機能です。JSON operationは比較的単純で、文字列としてデータベースに入ってきたJSON文字列を、パースしてさまざまな処理ができる機能です。
一方JSON typeが本命で、JSON値をパースしてデータベースに格納し、それに対してさまざまな演算が行える機能です。
なぜ2つに分かれているかというと、単純に時間切れになってしまったらしいからです。本当は最初からJSON typeを実装したかったが、企画がまとまりきらずにとりあえず決まった部分だけ、2016に切り出して実装したようです。」
Polymorphic Table Function
青木氏：「次の機能は、SQL:2016で定義された、Polymorphic Table Functionです。
これは比較的簡単で、テーブル関数から動的に変わるリレーションを返せます。テーブル関数とは、リレーションを引数にとり、リレーションを返す機能です。
これにより、たとえば文字列を引数にとり、他のデータベースにクエリを投げ、その結果のテーブルをそのまま返す機能が実装できます。」
整数リテラル
青木氏：「そのほかにも、整数リテラルにアンダースコアを入れられる機能もあります。SQL:2023では、たとえば3_000_000で300万を表現できます。これも実装していないと思っていたら、PostgreSQL 16や最新のTrinoなどが既にサポートしていました。」
Property Graph Queries
青木氏：「SQL:2023では、Property Graph Queriesと呼ばれる、グラフに対するクエリが書ける機能があります。
たとえば、上図のようなクエリを書けるようです。」
SQL標準ではないが、便利な構文
青木氏：「SQL標準ではないものも紹介します。
1つ目は、私のイチ押しのQUALIFY句です。これはウィンドウ関数が実行された後に評価されるWHERE句です。一般的にWindow関数は先にWHERE句が評価され、Window関数が評価されるため、Window関数の結果で絞り込みをする際は、サブクエリを使う必要があります。
具体的には、まずサブクエリ内でWindow関数を呼び、結果のフィルターを外側のクエリに書くため、非常に面倒くさいです。しかし、QUALIFY句では、セレクトでWindows関数を書けるため、非常に便利です。元はTeradataの独自拡張ですが、今ではBigQueryやSnowflakeもサポートしています。
2つ目は、ラテラル参照です。これはasで付けた別名をWHERE句やGROUP BY句で参照できる機能で、非常に便利です。
この機能も例によって私はTeradataで覚えたのですが、その後RedshiftやHiveにもいつのまにか実装されていました。ラテラル参照は非常に便利であるため、全てのDBで使えるようになると嬉しいです。
3つ目は、ラムダ式です。無名な関数ですが、Trinoが実装してます。」
新しいSQL標準のまとめ
青木氏：「SQLは既に完成しており、追加する余地がないと感じる方もいると思いますが、今でも新しい機能が活発に追加されています。今年も新しい標準が出ているため、まだまだSQLは進化する見込みです。
最近のSQL標準の拡張の特徴としては、Graph QueriesやJSON、XMLなど、伝統的なリレーショナルデータの範疇を超えるものが追加されやすい傾向にあります。『SQLはリレーショナルデータ』と絞らず、何でもSQLだとみなすとても都合のいい展開になっています。私としては、この動きをさらに突き詰めてほしいと思います。」
SQLの嫌いなところ
青木氏：「我々はSQLにまだ頼っていて大丈夫なのかを検証したいと思います。SQL中心アーキテクチャの1つ目である『SQLで分析しよう』を検証しようと思います。
突然ですが、私はSQL嫌いです。
まず、固有の拡張が多いところです。標準SQLを先ほど紹介しましたが、標準SQLと言いながら全く標準ではありません。『標準に入ってる機能が一体どのデータベースで使えるのか』や、『本当に標準のままの機能で動いてくれるのか』が全くわかりません。
拡張性の全くない1950年代の文法も嫌いな点です。大文字、小文字を無視するため、皆の記法が一致しないし、英語に似てるから読みやすいという理論に従って、次々と文法が追加されます。
また、予約語が1000語以上あり、とても覚えられないです。これでは、カラム名に何をつけてもいつか予約語と必ず被ってしまいます。そのため、私のおすすめはアンダースコア区切りにすることです。実は恐ろしいことに、アンダースコアが入っている予約語も2、3つあるのですが、非常にマイナーであるため、多分被らないと思います。
さらに、SQLの初学者を混乱させる、ふわっと変換される文字列や、整数が変換される暗黙の変換機能があります。またNULLも、LEFT OUTER JOINが絡んだ時の挙動が非常に複雑で嫌です。」
どうすればSQLは消えるのか？
青木氏：「以上より、私はSQLに長生きしてほしくありません。そのため、逆にどうしたらSQLが死ぬのかを考えてみたいと思います。
今SQLの力はやはり、ほとんど全てのデータベースがサポートしているところにあると思います。そのため、全ての主要なRDBMSがSQL以外の言語をサポートしたら死ぬはずだと考えます。たとえば、Oracle、SQL Server、MySQL、PostgreSQL、BigQuery、Snowflake、Teradata、DB2などが、全てSQL以外の言語になったらSQLは死ぬはずです。しかしその可能性はゼロでしょう。
では、RDBMSが死んだらSQLも死ぬかもしれないと考えます。RDBMSがなくなり、KVSやNoSQLが勝てばSQLも死にますが、これも起こりそうにないです。一時期KVSブームに乗っかって、さまざまなKVSが出てきたりHadoopが流行ったりして、RDBMSはもうダメだと言われていました。
ところが結果を見ると、逆にNoSQLの人気は落ちて、逆にSQLの人気は高まり続け、むしろ「巨大なデータにもRDBMSで対応できるのではないか」という風潮になっています。
では、人間とBIツールがそろって別の言語を使い始めたら、SQLは使われなくなるのではないかと考えます。確かに人間がSQLを書く未来は、意外とChatGPTなどによってなくなるかもしれません。しかし、BIツールがSQLサポートをやめて別の言語にする動機は何もないです。」
SQLは不滅
青木氏：「したがって、やはりSQLは死なないのです。
それこそNoSQLなどのSQLを真っ向から否定するものが出てきても、何年もSQLは死ななかったため、もう死なないことを証明しているのです。
それどころか、SQLを滅ぼそうとした対抗馬が数多く存在しました。たとえば、Googleが出したMapReduceやSawzallは誰も覚えていませんし、Pigも見なくなりました。また、それぞれが〜QLを定義してSQLを滅ぼそうとしましたが、逆に全部死んでしまいました。
後述しますが、ETLやバッチも、もしかするとSQLでできるような未来が来るかもしれません。
ストリーム処理はまだSpark Streamingなどが流行っているため、SQLではない可能性がありますが、もしかするとSQLが勝ってしまうかもしれません。」
過去30年の分析DBの年表
青木氏：「次のセクションでは、これからの分析データベースはどうなるかを考えてみたいと思います。
私が未来を予測する時の定番として、その歴史を見ます。（分析DBの歴史を）上図のようにまとめてみました。過去30年を見ると、3つぐらいの流れに整理できるかなと思います。
1つ目が、データウェアハウス（DWH）専用機の流れです。1980年ぐらいからTeradataなどが代表されるような、作ってきたDWHや伝統的なDWHの流れです。2つ目が、HadoopとNoSQLの流れです。3つ目が新しい並列RDBMSの流れです。」
過去30年の分析DBの流れ
青木氏：「1つ目のDWH専用機の流れは、アーキテクチャ的にはオンプレshared nothingです。いわゆる伝統的なRDBMSのような構造になっており、トランザクションをサポートします。
一方でそれに対してアンチテーゼとして出てきたのが、HadoopとNoSQLです。『SQL doesn’t scale』は、Googleの中で言われていた標語なのですが、『SQLはスケールしない』という意味で、NoSQLだといい、別のアーキテクチャを模索してみました。
オンプレまたはクラウドのshared nothingであるのは同じですが、ローカルHDDにデータを保存し、レプリケーションするGFSのような構造にするのが目的です。
それをさらに克服すべく登場したのが、新しい並列RDBMSです。これらを特徴付けるのは、computeとstorageの分離です。今までCPUとストレージがくっついていたのを、完全に分離して別のノードにするアーキテクチャが出ました。そして再度SQLを導入して、トランザクションをサポートする構造になっています。」
computeとstorageが分離される前
青木氏：「この3つのトピックについて話してみたいと思います。1つ目がcomputeとstorageの分離、2つ目がトランザクションのサポート、3つ目は後で話します。
computeとstorageの分離については、Redshiftを例にするのがわかりやすいと思います。Redshiftが登場した直後のアーキテクチャは上図のようになっていました。
クラスターを統括するリーダーノードが1台あり、その下に実際の処理をするコンピュートノードが数多くあります。リーダーノードがクエリを受け付けてプランを立て、それをコンピュートノードに指示を出して処理させます。コンピュートノードは、ローカルディスクに置いてあるデータを自分で処理して結果を返すというようなアーキテクチャです。
このアーキテクチャは比較的うまく動きますが、やはり弱点があります。一番の弱点は、ノードの追加に膨大な時間がかかることです。ローカルディスクにデータが置いてあるため、ノードを追加すると、新しいサーバーにも移さないといけないのです。つまり、全てのデータを再度分散し直す必要があります。私も1度やったことがあるのですが、2日ほどかかりました。」
computeとstorageが分離された後
青木氏：「Redshiftが比較的最近に、computeとstorageの分離をサポートしました。
RA3 node typeと呼ばれるものを使うと分離した構造になります。今までコンピュートノードのローカルディスクにあったディスクが全てS3に集約され、コンピュートノードはクエリのたびにSQLからデータをロードして処理する構造です。
このような構造になるとコンピュートノードがデータを持ってないため、自由に増減ができます。クエリごとの増減も可能であるため、クエリのコンピュートパワーが必要な夜間バッチの時だけ増やすことが簡単にできるようになったのです。」
データが離れた分、速度は落ちるのか？
青木氏：「しかし、私が疑問に思っていたのは、『ストレージが全部S3に行ってしまうと遅くなるのではないか』ということです。ところが実際に試してみると、最大でも5%ほどの速度低下で済みますし、速度が落ちないこともあります。
さらに、RedshiftにはSpectrumと呼ばれる、外部のS3のデータにアクセスする機能が元々あり、それらを対応していれば全く速度差は出ないです。クックパッドの場合は特にこのスペクトラムをよく使っていたため、ほとんど速度差は出ませんでした。
その後、Redshift AQUAが導入されました。キャッシュクラスターがS3とコンピュートノードの間に入っているのですが、こういったものを使うとむしろ速くなる場合もあります。AQUAのクラスターはコンピュートノードの近くにあるため、速いSSDにデータをキャッシュしてしまえば、むしろ早くなる場合すらあるのです。
なぜ遅くならないかというと、ネットワークが速くなったからです。昔はネットワークが遅くてもストレージは早かったため、できるだけストレージとCPUを近くに置き、ネットワーク通信をしないのがもっとも重要でした。
しかし、コンピューターの進化とともにネットワークが速くなり、ストレージとネットワークの速度差が埋まってきました。そうすると、ストレージから読んでもネットワークから読んでも、せいぜい10%〜20%の差で済むようになり、コンピュートとストレージの分離が可能になったのです。」
シャッフルクラスターとは？
青木氏：「さらに最近はこの流れを進めて、より層を増やしてコンピュートの利用率を上げる動きが出てきています。その中でも典型的なものは、シャッフルクラスターと呼ばれるクラスターです。シャッフルは再分散を意味し、全てのノードにテーブルを再度分散し直してジョイントに使う処理です。
再分散をするための専用のクラスターを立て、コンピュートノードに1度データを読み込ませるのですが、シャッフルが必要になるとシャッフルクラスターに結果をもらう仕組みです。
ネットワーク転送を2回もするため、いかにも遅そうなのですが、実際入ると早い時もあります。具体的には、大規模になると早いです。PrestoやFacebookの内部システム、BigQueryで実装されています。BigQueryではメモリセパレーションという名前だったはずです。
シャッフルクラスターを使うと早くなるのは、未だに頭ではわかっていますが、なかなか納得がいかないです。転送するほど早いというのは不思議です。」
Treasure Dataのアーキテクチャ
青木氏：「Treasure Dataの構成は上図のようになっています。PrestoとHiveと両方あるのですが、こちらはPrestoの場合です。
まず、Prestoのコーディネーターがいて、その下に実際のデータの処理をするワーカーが並んでいます。コーディネーターがクエリを受け付けてプランをワーカーに投げ、ワーカーがデータを処理します。
データは全部S3に入っており、S3からデータロードして処理します。ただし、Plazmaの特徴的なアーキテクチャとして、Plazmaのメタデータがどこにあるかを全て保存しているPostgreSQLが1台あります。これを使うことで、高速にメタデータの処理ができるのが、Treasure DataのPlazmaの仕組みです。
このアーキテクチャの良いところは、メタデータがPostgreSQLに入っているため、メタデータにトランザクションが効くところです。これにより、テーブルを書き換える時のトランザクションとかがサクッと実装できます。」
トランザクションのサポート
青木氏：「昔は、『ビッグデータだからトランザクションは必要ない』、『SQLをする方が重要』という風潮だったのですが、最近では『やはりトランザクションが必要』という流れに変わり、サポートされるようになっています。
なぜかと言うと、やはり更新が増えてきたからでしょう。これまでは『とりあえずロードをして、あとは分析できればよい』という考えだったのが、そうではなくなっています。
たとえば、OLTP（オンライン・トランザクション処理）のデータベースからテーブルをできるだけ短い間隔でリプレイしたいとなると、どうしても更新が必要になります。あるいは、できるだけリアルタイムに近いレイテンシーでデータを外に出すとなると、どうしても差分更新が必要になり、そのためにはやはり更新が必要になります。そして差分更新が必要になると、同時にトランザクションが必要となるのです。
最近はトランザクションをサポートするシステムが多々あります。たとえばRedshiftはトランザクションがサポートされています。そのほかにも、Apache Icebergなどは公開S3のバケット上でトランザクションが実装できるようなフォーマットを提供しています。
私の見るところによると、ストレージが公開されているかどうかによって、実装の難易度が随分変わる気がしています。『ストレージが公開されている』とは、データベース以外のソフトウェアに触れるかどうかということです。
たとえばS3にデータレイクを作るとして、データレイクに誰もが何でも書き込める状況でトランザクションをサポートするのはかなり難しいです。なぜかと言うと、トランザクションのセマンティックを理解しない方々が、いきなり触れてしまう可能性があるからです。
しかし、ストレージが公開されていなければ、何も心配はいりません。実質、内部ストレージであるため、自分の好きなように前提を置いて実装すればよいです。実装するのも楽ですし、当然パフォーマンスも高くなる予測がたちます。
そう考えると、データレイクだけで全てをまかなう方向にはいかないでしょう。何らかの内部ストレージ（内部ストレージがディスクではなくてS3の場合も当然ありますが）を持ちつつ、データレイクへのアクセスも併用する形が未来の姿なのではないかなと思います。」
BIG DATA IS DEAD？
青木氏：「この記事をご存知の方も多いのではないでしょうか。MotherDuckのCEOが『BIG DATA IS DEAD』という記事を書きました。本記事の主張をざっくり要約します。
まず、大半の企業はもともとビッグデータを持っていません。さらに、コンピューターがますます強力になっているため、より処理できるデータ量が増えます。それにより、今までビッグデータだったものがビッグデータではなくなる、つまりデノミネーションが起こるのです。
さらに著者の主張としては、ストレージは時間に比例して増えていくが、必要なコンピューターも比例して増えていくわけではないです。基本どれだけデータがあっても、大半の参照は直近のせいぜい1日や1週間、1ヶ月で済みますし、データ量がいきなり増えることはないため、処理する量は大して増えないのです。
『これからはビッグデータの時代で、ますます（データ量が）増えます。そのためには、分散データベースで並列処理が必要です』と言われていましたが、そこまで頑張らなくてもいいのではないかと思われます。具体的には、AWSの一番強いインスタンスであれば1台で済むという主張です。u-24tb1.112xlargeだと、24テラのメモリと100以上のコアがあるため、大体の企業のデータは1台で処理できるのです。」
DuckDBによる分析DBの構成
青木氏：「つまり、このような構成になります。大きいインスタンスを1台買って、そこにDuckDBを動かしてその中で並列処理をすれば、それで済みます。
クックパッドはかなりデータ量が多いため、この構成では厳しいと思いますが、世の中のほとんどの企業はクックパッドよりデータ量が少ないため、この構成で処理できてしまう可能性があります。そうなると、分散データベースのアーキテクチャやシャッフルクラスターを頑張らなくても、コンピューター1台ですべてがまかなえる気楽な世界がまた来るかもしれません。」
変わること変わらないこと
青木氏：「もしこのような世界になったら、変わることと変わらないことがありそうなため、それぞれ考えてみました。
まず変わらないことの1つ目は、分析システムの中心にコアとなる並列データベースが必要だと思います。DuckDBも並列には動くため、並列データベースではあります。そうなると、分析用の並列データベースが必要なことは、おそらく変わらないでしょう。
それから、クエリー最適化の手段も変わらないと思います。なぜかというと、データが変わらないからです。具体的には、分散キーとパーティションのことです。
利用側のメンテナンスコストも変わらないでしょう。現在、DuckDBはサービスとして提供されていないため、自前でインスタンスさせて入れる事になると思います。確かに大変ですが、たとえば自分でインスタンスを立ててPostgreSQLを動かすのと大して変わりません。あるいは、RedshiftをAWSから買って起動するのと、誰かが提供してくれるDuckDBサービスを起動して運用するのと大して変わりません。
一方変わることの1つ目は、再分散です。先ほど話した『シャッフルはボトルネックではなくなる』より、性能やチューニングは少し変わる気がします。
それから、マルチテナントの分散DBを作っているベンダーには影響があるかもしれません。なぜかというと、DuckDBでマルチテナントができないからです。そのため、DuckDBを使ってサービスを提供しようと思ったら、シングルテナントである必要があると思います。一つの企業で1台にしないとやっていけないということは、必然的にシングルテナントになります。」
本セクションのまとめ
青木氏：「computeとstorageの分離が新しい時代の趨勢で、おそらく当分は続くでしょう。したがって、computeとstorageは分離した方が良さそうです。それから、クラスターを重ねていくネットワークを信頼し、処理を内容ごとに分けるアーキテクチャが増えてきます。この傾向もおそらく続くでしょう。
トランザクションサポートは当然必要になります。SQLを使うからにはトランザクションが必須になるため、トランザクションを実装しやすいアーキテクチャが勝つと思います。これからは、あえて分散しない選択肢も入ってくる可能性があるため、目配りしておく必要がありそうです。」
分析サービスベンダーの道とユーザー企業の道
青木氏：「以上のまとめを言い換えると、上図のようになる気がします。
1つ目は、分析サービスベンダーの道です。たとえばAWSやGoogleのように大きいマルチテナントのクラスターを建て、マルチテナントで処理します。この道は、クラスターを処理ごとに分割してオートスケールができるようにし、コンピュート効率を高めて処理していくことになると思います。
対局的な道は、ユーザー企業の道です。シングルテナント1企業だけのシングルインスタンスを建て、その中で企業のデータを全て処理する道があり得ると思います。」
つづいて、SQL中心アーキテクチャの2つ目のドグマである、「データを一ヶ所に集めよう」について説明していただきました。
データは一ヶ所に集めるべきか
青木氏：「データを一ヶ所に集めることが正しいのかを考えます。本書籍を書いた時点ではすでにFederated Queryなどが出てきていましたが、まだまだ一つのデータベースに物理的に集めた方が安牌だと思っていました。
しかし、その後にさまざまな機能が普及し、修正した方がよいと思ってきています。さまざまな機能とは、Object Storage AccessとFederated Query、Data Sharingです。」
Object Storage Accessとは
青木氏：「Object Storage Accessは、S3などのようなオブジェクトストアに分析データベースからクエリが直接かけられる機能です。RedshiftであればRedshift Spectrumのようなものです。」
Federated Queryとは
青木氏：「Federated Queryは、他のデータベースを直接クエリする機能です。たとえばRedshiftからはMySQLのテーブルがクエリできます。Object Storage Accessとほとんど図は同じですが、ただのデータか、データベースかというところが違います。」
Data Sharingとは
青木氏：「Data Sharingは、他のデータベースクラスターのテーブルを透過的に参照できる機能です。たとえば、1つ目のRedshiftと2つ目のRedshiftのクラスターがあります。それぞれに専用のS3のバケットがあり、そこにデータは全て収められています。しかし、1つ目のRedshiftから2つ目のRedshiftのデータが直接参照できるのがData Sharingです。」
データ連携機能3つの使いどころ
青木氏：「これら3つのデータ連携機能の使いどころをそれぞれ考えます。
Federated Queryは、サイズで使い分けるのが今のところ現実的だと思います。小さいテーブルや頻繁に参照しないテーブルはFederated Queryで直接参照すればよいです。
ただ、たとえば10億行ある巨大なテーブルをFederated Queryでアクセスすると、それは並列アクセスではなくなってしまうため、さすがに無理でしょう。そのため、（巨大なテーブルは）やはり引き続きETLするのがよいと思います。前提としてFederated Queryはデータベースに直接繋ぐのではなく、レプリカに繋ぐのがベストプラクティスのようです。
Object Storage Accessはトランザクションの有無によると思います。ログなどの巨大なテーブルをS3においてObject Storage Accessでアクセスすることはあると思いますが、この場合は基本ログの更新をしないため、トランザクションを貼る必要性はあまりないでしょう。そのため、トランザクションが無視でき、Object Storage Accessでよいです。
一方でマスターテーブルやサマリーテーブルは、やはり明らかに差分更新をしたい場合が非常に多いため、内部テーブルに落としておき、トランザクションを貼って処理するのがよいと思います。
Data Sharingは、クラスターを2つに分割する目的で使うとよいと思います。私が聞いた中で一番納得したのは、子会社ごとにデータをクラスターに分けておくが、統合するときはData Sharingで参照して親会社クラスターに統合するケースです。」
SQLで透過的にアクセス可能にしておくべき
青木氏：「今後は、物理的に一つのDBへデータを集める必要は必ずしもないでしょう。ただし、SQLで透過的にアクセス可能な状態にはしておくべきだと思います。つまり、Federated QueryやObject Storage Accessで参照できていればよいです。
Zero-ETLとUnistoreは、OLTPデータベースの統合方法として新しい手法が登場しました。たとえば、最近プレビューになったRedshiftのAurora Zero-ETLは、AuroraのテーブルをそのままストリームでRedshift側に流し、Redshift側からテーブルとして参照できます。つまり、Redshiftが勝手にストリーム処理と更新の処理をして、マテリアライズしてくれる夢のような機能です。（Aurora Zero-ETLも）当然、これからはとてもよい選択肢になると思います。
またSnowflakeのUnistoreは、Snowflakeのデータベースの中にOLTP用のHybrid Tableと呼ばれるテーブルを作れる機能です。これを使うと、OLTPに向いて1行だけ取ったり、1行だけ更新する処理が高速に実行できたりします。この機能にも目配りしておく必要があると思います。」
分析システム全体の設計が重要
青木氏：「今までご紹介したことを考慮すると、これからは『データベースが1台あればいい』という話ではなくなります。データベースがあるのは前提で、OLTPのデータベースをどのように連携して、ストリームで流して、マテリアライズするかが重要になるのです。
そのため、データベースが1個あればよいわけではなく、データベースとOLTPのDB、あるいは分析データベースで作ったサマリーを載せるDBまで考えなければ、全体のシステムをうまく作れなくなると思います。
何が言いたいかというと、クラウドは楽だということです。Auroraからストリームで流してマテリアライズして、エラーが起きた場合を考えると運用したくないです。これはできるだけマネージドでやってほしいと思う次第です。」
さいごに、SQL中心アーキテクチャの3つ目のドグマである、「データを3層構造に編成しよう」について説明していただきました。
3層構成の背景
青木氏：「私が本書で提案した3層構造とは、1つ目がソースデータ層です。OLTPなどのインプットのデータを、そのまま置く層です。第2層に、DWH層を作ります。ソースデータ層をきれいに統合して、分析しやすい形にした論理データウェアハウスです。3つ目が、アプリケーション層です。活用目的のために適したサマリーテーブルなどを作ります。
データをまず1層に入れて、必要だったら2層でDWHを作り、3層でサマリーをして、さまざまな活用をするのが私が提案した3層構造です。3層にした理由はいくつかあります。
1つ目がETLよりELTが推奨であることを暗黙的に示したかったからです。第1層にそのまま元のテーブルを入れるのは、加工をしないため当然ETLではなくELTです。ELT方が分析の自由度が高くなります。
それから、物理データマートより仮想データマートが良いでしょう。たとえば外にPostgreSQLを置き、中にサマリーを置いておくのが物理データマートです。物理データマートは、速いし動くのですが、メンテナンスが難しいです。一旦、分析データベースの中でサマリーをしておいて、そのままPostgreSQLに転写した方がメンテナンスがしやすいため、第3層を作りました。
さらに、3層に分けたことで暗黙的に流れが発生します。第1層→第2層→第3層の流れで必ず動かし、逆流してはダメだということを暗示しました。
また、組織の切れ目に対応している場合もあります。」
3層構成を変える余地はあるか
青木氏：「以上の背景から3層の設計をしました。今後10年も、この設計は基本的には変える必要はないと考えています。データは技術にあまり影響されず、データの構造が変わるわけではないからです。」
3つのドグマを伝えるより強調すべきだったこと
青木氏：「ただ、3つ目のドグマを『データを3層構造に編成しよう』ではなく、別の言い方で強調すべきだったと思う点がいくつかあります。
まず、分析データベースにはデータの流れがある点です。ELTで入り口からインジャストで入ってきて加工して出ていくという一方通行の流れがあることをより強調すべきでした。
分析データベースは、データを活用するためにあります。そして、データを活用するということは、ビジネス価値を作らなければいけないのです。加工してデータをさまざまな用途で使うことをactivationと呼びますが、このactivationをしたいのです。
そう考えると、まず一番最初に考えるべきは施策です。施策を考え、どのようなactivation処理が必要か考えます。そのために、データを作り、サマリーしようと考えていくのです。つまり、分析システム全体を施策から始めて作っていくことが、もっとも重要だと思っています。」
まとめ
青木氏：「はじめに、SQLの新機能をいくつか紹介しました。SQLは進化しており、衰退する気配もありません。むしろ適用領域をさらに広げており、重要度は高まる一方です。
最近は、データを物理的に一ヶ所に集める必要はなくなってきています。しかし、SQLによって透過的にアクセスできる場所にあるべきだという点は変わりません。
分散データベースかどうかはわからないが、分析システムの中心に、コアとしてデータベースが必要です。おそらく並列データベースではあると思いますが、何かしらの分散DBが必要になります。そして、それを中心としてFederated QueryやObject Storage Accessなども使いつつ、処理していくのがよいでしょう。
今後は中心にどのデータベースを選ぶかよりも、分析システム全体をどのように作りたいかが重要になると思います。つまり、周りとの連携がより重要になってくるでしょう。
分析システムはデータを活用するために存在し、最終的にはデータ活用してお金を作りたいのです。そのため、活用施策から考えていくのがもっとも重要です。」
トークセッション
古橋貞行 氏
Treasure Data / Chief Architect2011年筑波大学在学中にシリコンバレーに渡り米Treasure Dataを創立。MessagePack、Fluentd、Embulk、DigdagなどのOSSプロジェクトを立ち上げる。現在は主に、システム設計や初期実装を担う。未踏ユーススーパークリエータ、日本OSS貢献者賞、MIT Technology Review Innovators U35 Japan受賞。
Twitterのアカウントはこちら
本トークセッションは、株式会社primeNumberのCPOである小林寛和がモデレーターを務め、以下の流れで青木氏と古橋氏にお話ししていただきました。
- アイスブレイク
- Treasure Dataのアーキテクチャについて
- これからの分析システムについて
はじめに、アイスブレイクとしてSQLの好きなところと嫌いなところ、そして好きな分散DBと嫌いな分散DBについて、お話していただきました。
アイスブレイク
古橋氏：「先ほど、Twitterで見つけたのですが、「SQLが好きな人はほとんどいないのに、みんな使っているのは信用できる」という意見が、確かにそうだなと思いました。
好きなところとは異なりますが、結局実用的という意味ではSQLに変わるものがあまりないです。実際データの近くで計算したいとなると、どうしてもSQLが基本になってしまいます。」
青木氏：「実用面以外だと、SQLはRubyなどに比べると、できることが限られています。（その限られた中で）頑張って、目覚ましい機能を実装することを考えるとなかなか楽しいです。」
古橋氏：「並列分散処理をこれだけ宣言的に、気軽に書いて、しっかりと動くのはあまりないです。並列処理を生で書くのは人類には早すぎると思いますが、SQLなら何とかできています。当然、行ロックでデッドロックすることや、mvccの問題はありますが、世の中的になんとかなっているため、SQLの利点の一つかなと思っています。」
青木氏：「確かにそれは大きいですね。スレッドなどは使いたくないです。」
古橋氏：「今時のシステムでスレッドを使うとなると、まず他の方法がないか考えます。」
青木氏：「SQLの性能で好きなところは、インデックスなどが独立して直行していて、同じSQLでもインデックス貼って速くなる点は好きです。論理的な構造と性能の部分が別々になっている点はいいなと思いました。」
古橋氏：「インデックスも、実装ごとインデックスの特性が違ったりするため大変です。」
古橋氏：「逆に嫌いなところは、実装がそれぞれ違うところが嫌です。結局、プログラムを書き直したくなってしまいます。しかしPostgreSQやPythonなどでも、拡張を書こうとすると、メンテナンス不能になっていくため、柔軟さを担保しようとするとスキルが追いつかなくなりがちです。」
青木氏：「もう少し柔軟なコードを、簡単に差し込む方法があればいいなと思います。」
古橋氏：「確かにそうです。ただ、書けないところが逆にいいこともあります。たとえば、REST APIをSQLとアプリのどちらで設計するかの論争が、今以上に過熱すると大変だと思います。
SQL処理系を実装したいと思ったことが何回かあるのですが、文法の観点では、複雑すぎます。SQL Parserと呼ばれるライブラリはあるのですが、ライブラリだけがあってもどうしようもないわけです。Apache Calciteなど、処理系に書けるようなライブラリもあるのですが、結局、全部実装すると非常に大変で挫折しがちです。」
青木氏：「性能を考えなければ、実装を簡単にできるかもしれません。しかし、基本的にデータベースには性能が必要になってしまいます。
コンパイラだと、LLVMが実装の基盤として使えるのですが、そういったものがあるとよいです。」
古橋氏：「現在だと、Trinoのプラグに変えるのが近いと思います。結局SQLの処理系ではなく、データスキャンの処理系だけ書きますが、アプリケーションのブッシュダウンまで書けば性能が上がる構造をしているため、よいと思います。
たとえばApache Pinotと呼ばれるOLAPのデータベースエンジンがあります。フルのSQLの実行を試みると、Trinoの下に置く必要のあるドキュメントがあり、うまくできていると感じます。」
青木氏：「では、自分のデータベースを実装したければ、Prestoを使えばよいのですね？」
古橋氏：「そうです。一旦Prestoを全体に置いて全機能を使えるようにしてから、その下に再度スケールエンジンを置く、Apache Pinotのパターンはアリだと思います。」
つづいて、2つ目のアイスブレイクトピックである、好きな分散DBと嫌いな分散DBについてお話していただきました。
青木氏：「好きな分散DBはやはり、Teradataです。アーキテクチャが美しく、インターコネクトがいいです。現在もあるのかわかりませんが、バイネットと呼ばれる独自のインターコネクトがありました。
古橋氏：「L1から別なのですか？L2あたりからですか？」
青木氏：「確か、独自のものでした。」
古橋氏：「今では、インフィニウンドなどがありがちですが、違うものなのですか？」
青木氏：「おそらく、上の方がインフィニバンドで、下の方はイーサネットになっています。少し前まではワイネットでした。
ノードの台数に応じてリニアにネットワークの帯域が伸びるスイッチがあり、分散DBにもってこいのアーキテクチャでした。テラデータのためにベル研（ベル研究所）に作ってもらったようです。」
古橋氏：「すごいですね。Teradataの分散OLTPエンジンとしてのアーキテクチャは、基本的にRedshiftなどと似てるのですか？たとえば、「コンピュートとストレージとメモリがつながっていて、横に並んで増える」ようなことはありますか？」
青木氏：「それが非常にややこしいです。理念的にはshared nothingのシンプルなアーキテクチャなのですが、ローカルディスクではなくディスクアレイにつながっています。
ディスクアレイを何台かのノードで共用していて、ノードが一台使えなくなっても、別のノードから同じデータ領域にアクセスでき、片代わりできるようになりました。そのため、shared nothingでストレージの分離はある意味されていないが、（分離が）されているような形です。」
古橋氏：「なるほど、面白いですね。研究したくなります。」
青木氏：「古橋さんの好きな分散DBは何ですか？」
古橋氏：「永続化レイヤーを別のレイヤーにしてるものがいくつかあります。たとえばTiDBやTiKVのような、データのパーシステンシーを担保するものとデータベース機能を実装するものを、論理的にも物理的にも分離してあると、運用面で非常に便利です。データを守る際は、データの方だけを守ってればよいため、非常にやりやすいです。
また、Apache BookKeeperと呼ばれる、非常に特殊なストレージエンジンがあるのですが、ストリーム処理系を作るのに特化したKey-Valueストアのようなものです。この上にApache Pulsarと呼ばれるものが載っているのですが、このアーキテクチャは面白くないですか？「ストリーム処理系も分離するんだ」と思いました。
Kafkaは基本的に1つになっているが、これらは分離されているため、アーキテクチャ的にKinesisと近いと思います。」
青木氏：「Auroraもおそらく、クエリを処理する部分とストレージクラスターが分離していた気がします。」
古橋氏：「そうですね。ただ、中身が見えないため、間違いなくそうだとはなかなか言い切りづらいです。」
古橋氏：「話は変わりますが、クイックウィットと呼ばれる検索エンジンがまた面白いです。
クイックウィットは分散検索エンジンで、その下にタンテビーと呼ばれる集中型の検索エンジンライブラリがあります。クイックウィットのウィットの方が、タンテビーファイルフォーマットで作られたファイルをS3にポンと置き、そのメタデータを別途ポスグレで管理するアーキテクチャになっています。
このあたりは要チェックだと思っています。集中型のタンテビーのようなファイルフォーマットをメーターデータレイヤーで分散し、さまざまなところにポンと置くのは、非常に汎用性が高いと思います。
これは検索エンジンですが、先ほどのDuckDBなどとやっていることは似ています。ファイルを頑張って作り、ノードで手を加えていくという意味では、検索エンジンとOLTPエンジンはそれなりに近さがありそうです。この辺を掘るのは面白そうだと思っています。」
青木氏：「なるほど。メタ質問になるのですが、古橋さんはそういった情報をどのように調べているのですか？」
古橋氏：「新しいものを作ろうと思っていると、検索してちょっと痒いところに手が届かないような状態になります。作りたくないとなると、誰かが作ってくれないかなと思い、調べるとさまざまな情報が出てくる流れです。」
青木氏：「欲しいものがあって、それに合うものをひたすら調べていくのですね。勉強になります。」
古橋氏：「今の会社のポジションで言うと、調べる時間が一番長いかもしれません。」
青木氏：「古橋さんのプロダクトは、どれもよく最初からしっかりと考えてあるなと思っています。私はとりあえず作ってしまうため、それがよくないかもしれないです。」
青木氏：「私の嫌いな分散DBは、MapReduceです。Teradataが好きで、非常に美しいと思ったところに、MapReduceができて、ここまで低レベルなものを書くのかと逆の衝撃を受けました。」
古橋氏：「そういった意味では、運用が難しいデータベースエンジンは大変です。たとえばディグダグを作る時も、データベースに分散コーディネーションをさせています。そのため、データベースさえ守っておけば、ほかの普通のノードは横に並べればよい設計になっています。
この設計には運用上の目的があり、Airflowとは全く違う設計の思想です。単一のメタデータ管理インスタンスがあり、そのメモリがあふれると使えなくなってしまうなど、そういった運用が難しいです。
つまり、コーディネーションだけやってくれるならよいのですが、リーダーに全てをさせるものが嫌いです。あまりないですが、HDFSのメタデータなどは大変だった記憶が蘇ってきます。」
つづいて、2つ目のトピックである「Treasure Dataのアーキテクチャについて」についてお話していただきました。このトピックでは、3つお題に分けてお二方に深掘りしていただきます。
- PlazmaDBのメタデータをPostgreSQLに置いたのはなぜ？
- シングルテナントとマルチテナントどちらが生き残る？
- PlazmaDBのアーキテクチャで今後変えたいところは？
Treasure Dataのアーキテクチャについて
青木氏：「これ（PlazmaDBのメタデータをPostgreSQLに置いたのはなぜ？）は、先ほどの話がそのまま答えになっているような気がします。メタデータをポスグレに置いたのは、データベースを守っていれば運用がしやすいからです。」
古橋氏：「そうですね、それがやはり一番大きいです。現在では、ポスグレは基本的にAWSなどで運用するところまで付随しているため、運用上親切なデータベースになりつつあります。昔は、レプリケーションをセットアップして、オートフェイルオーバーなどを考えると非常に面倒だったのが、今ではシンプルになっています。
クラウドになってから常識が変わってきている気がします。ロックやMVCCなどがしっかりとしている、非常に高機能なポスグレを1箇所に置いておけば動くと言われたら、かなりやりやすいと思います。エトセティやズーキーパーなどを置くより、案外運用が簡単なときもあります。
また、エトセティやズーキーパーにリーダー選出だけさせて、そこからリーダーインスタンスにメタデータ管理をさせるアーキテクチャがメジャーでした。このアーキテクチャでは、メタデータノードを作る必要があり、大変です。結局、ポスグレでMVCCなどができるため、作る上で一番簡単だったと思います。」
青木氏：「なるほど。RDBはAWSがマネージしており運用が簡単なため、一番大変なところを全てRDBで行い、そこだけ守っておけば死ぬことないのですね。」
古橋氏：「さらに、ファイルはS3にあるため、多層化しています。階層化は全てを解決する感覚で、性能上の問題も階層化することで、1段階スケールするようになっているため、大丈夫なのではないかと思います。
青木氏：「なるほど。その代わり、ポスグレが死ぬと死んでしまうのではないですか？」
古橋氏：「そうです。そこが問題で、ポスグレを非常に頑張って運用しなければいけない問題があります。作った当初は、「売れればお金が手に入るため、なんとかなる」発想が大きかったですが、今は頑張って運用する必要があるため、トレードオフでした。
ただ、なんとかなっているのはやはり運用がしっかりとしているからでしょう。しかし、10年ほど現役ですが、まだ改良の余地はありそうです。たとえばタイムトラベルやマルチステートメントトランザクションなども入れようと思えば入れられます。」
青木氏：「では、しばらくポスグレではなくなる予定はないということですか？」
古橋氏：「そうですね。メタデータもファイルにして置いてしまう、アイスバーグのようなアーキテクチャに移行する手もなくはないと思いますが、実装が非常に大変です。結局、ポスグレでトランザクションを実行したほうが早い気がするため、まだ持つのではないかと思っています。」
青木氏：「私も個人的にアイスバーグはあまり好きではありません。面倒な気がしてしまいますし、「結局それってボスグレと同じことを、S3上で実装してるだけじゃないの？」と思ってしまいます。
古橋氏：「Plazmaはまたポスグレ上にMVCCを実装しているため、二重実装ではあるのですが、手間は少ないかなと思います。」
青木氏：「もしポスグレ以外にするとしたら、たとえば違うデータベースを使うなど、何かありますか？」
古橋氏：「やはりスキャンが速くなると嬉しいため、コックローチDBなどはよいと思います。
今一番困ってるのは、コレクションとスキャンが遅いことであるため、それらが分散してうまくいくデータベースエンジンがあったら嬉しいです。」
青木氏：「スパナがAWSにあればよいですね。」
古橋氏：「そこですね。ポスグレを選んだ大きな理由は運用してくれる点です。」
青木氏：「Auroraがやってくれるかもしれません。」
「シングルテナントとマルチテナントどちらが生き残るか？」について、議論していただきました。
青木氏：「先ほどのセッションでも話したように、結局1台でいいのではないかという問題になります。
シングルテナントのほうが楽な面はあります。1台が死んでも、一つのお客さんが死ぬだけで済みますし、大きなお客さんには規模の大きいインスタンスを使えます。その代わり、多くのデータベースを作る手間が発生します。
夢があるのはマルチテナントです。」
古橋氏：「組織や部門によって使いたいものが異なると、シングルテナントでは、どうしてもアクセスコントロールなどもあるため、結局それごとにインスタンスを立てる必要があると思います。運用面とかコスト面だと、結局マルチテナントの方が有利だと思います。
マルチテナントは、その人に依存しすぎる構造が出てしまい非常にリスキーですが、1人担当がいれば何とかなるという意味では、マルチテナントの生き残る確率が高いです。
結局、アプリケーションから見た時にマルチテナントで動かしているものが、どのくらいの性能が保証されるのかや、セキュリティの観点でも分離がどのくらい担保されているのかを考え始めると、シングルテナントの方が嬉しい場合があります。
Treasure Dataでも、お客さんごとにリージョンを分けるようなレベルで、シングルテントが欲しいケースがあります。」
青木氏：「特に最近はセキュリティの要求が強いですね。」
古橋氏：「そうです。さまざまな法律の制約もあるため、シングルテントの圧力はセキュリティ側にあり、せめぎ合いが起こるのではないかと考えています。」
青木氏：「Treasure Dataを作った頃は、マルチテナントに慢性していた時代でした。ところが、最近はシングルテナントが復建してきていると思います。たとえば、SnowflakeやAuroraなどもシングルテナントであるため、意外とわからなくなってきました。」
古橋氏：「BigQueryはおそらくマルチテナントですね。」
青木氏：「そうですね。おっしゃってたように、サービスとしてまとめて提供するなら、マルチテナントの方が楽ではあります。」
古橋氏：「現在、適材適所のような状態です。僕が最近面白いなと思っているのは、「シングルテナントシステムを管理するマルチタントシステム」のようなものです。これは今後それなりに流行ると思っています。たとえば、多くのDuckDBを管理するようなものは需要があるため、実現したら嬉しいです。」
「PlazmaDBのアーキテクチャで今後変えたいところは？」について、お話していただきました。
古橋氏：「今後変えたいところの一つとして、Redshift AQUAのようなレイヤーが欲しいです。レイヤーをDuckDBで作るのは面白いと思います。つまりApache Pinotのような話で、性能が高くて最適化して頑張っているが、SQLがフル機能ではないものを間におき、それにFederated Queryを投げるPrestoやTrinoがいる状態です。
インターフェイスは今のPrestoのフル機能のSQLが使えるが、その下の足回りで別のテクノロジーを入れます。」
青木氏：「DuckDBが十分に速くて、プッシュダウンでいければというイメージですね。」
古橋氏：「プッシュダウンはTrino側の機能に依存すると思いますが、アグリエーションとしてはちょっと難しいですが、一定はできるでしょう。
ただ、DuckDBにデータをどのようにロードするかの問題があると思います。AQUAで言うならキャッシュレイヤーですが、そこにデータがあれば直でスキャンして速いし、無ければ取り寄せてきて次は速いような作りです。
そのような作りに先ほどのDuckDBクラスターのようなものを作ると、その先としてTrinoの下に入れられます。
そうすると、ファイルフォーマットも改善を入れられます。現在、とりあえずORCでファイルを置いておくと変えられなくなってしまいますが、キャッシュレイヤーがあると、キャッシュで一度ファイルフォーマットをコンバージョンします。
アグリエーションインデックスを導入したOLTPのスタートアップがあり、要は集計した状態をインデックスに入れてしまうのです。そのようなことを、キャッシュを作る段階で一緒に行うと、性能が上がります。そういったカッティングエッジな最適化を入れるのにも、このレイヤーは適しているし、MySQLのフル機能を実装しなくてもその上で行ってくれるため、面白いです。」
青木氏：「なるほど。それはよいかもしれないです。
Treasure Dataにおける私の当面の願いとしては、PrestoとHiveが統一されることです。」
古橋氏：「確かにそうですね。運用上ですか？」
青木氏：「SQLの書き味の問題です。文法や性能特性、使える機能が違うのが面倒なため、一つになるといいなと思います。」
古橋氏：「今Treasure Dataは、性能特性がPrestoとHiveで違うため、同じデータに対して複数のエンジンでクエリをかけられるようになっていますが、他にも見られるのですか？」
青木氏：「あまり見られないと思います。SQLとSQLではないものといったように、全く違うワークロードをやるようなものはあるかもしれません。」
古橋氏：「そうですね。Treasure Dataもそういった意味では、ユースケースが違ってエンジンが違うイメージです。そうすると結局、IOレイヤーを2つ作る必要があり大変で、さらに書き味も変わるため、統一したいです。」
青木氏：「なるほど、面白いです。作れるところが色々とあります。シャッフルクラスターはどうですか？」
古橋氏：「シャッフルクラスターは面白いですが、ディスクスキルをまず試してみるとよいのではないかと思います。ディスクIOが共有リソースになり競合するリソースになってしまうため、マルチテナントだと運用が難しいです。
翻って、シャッフルクラスターになると簡単になる訳ではなく、その問題を解く必要があります。シャッフルクラスターは実装が大変であるため、一旦ディスクスキルを試し、問題の状態を把握するステップが必要だと思います。」
青木氏：「（シャッフルクラスターの実装は）大変だと思います。」
古橋氏：「（シャッフルクラスターは）HASH JOINのさらに大きいものというイメージであっているのでしょうか？」
青木氏：「合っていると思います。」
古橋氏：「直感的には非常に遅いですが、最適化できるでしょう。」
モデレーター（小林）：「先ほど青木さんが発表された内容で、最近出てきたなんとなく知っている概念が数多く出てきました。たとえば、シャッフルクラスターなどはなんとなく知ってる程度で思っているかもしれませんが、実際にTreasure Dataの開発を行っている方々から、そういった言葉が出てくるということはしっかりとウォッチしなければいけないなと思ってる方が多いのではないかなと思います。」
3つ目のトピック「これからの分散システムについて」をお話していただきました。本トピックは、以下の流れです。
- SQLに追加したい機能
- ETLは消えるのか？
- HTAPについて
- Declarative data pipeline
古橋氏：「SQLに追加したい機能はラムダです。配列をカラムにして入れるのをデータレイクでやりたくなります。そもそも来ているデータが、JSON のネステッドなオブジェクトで、セミストラクチャードであるため、どうしても入れざるを得ないと思います。
それを処理する際に、SQLはネストしたアレイに対するオペレーションをうまくできるようになっておらず、困ってしまいます。テーブルにする話が出てきますが、テーブルにしたとしても、さらにその中にアレイがある状態なため、GROUP BYしながらGROUP BYするようなことをやりたくなりますが、SQLパズルを解くのは非常に大変です。
そのため、（SQLに）ラムダが欲しいです。」
青木氏：「なるほど。Prestoにはありますよね？」
古橋氏：「Prestoにあるものは独自拡張ですか？」
青木氏：「独自だと思います。」
古橋氏：「MapやReduce、filterなどのいわゆる普通のプログラミング言語にあるような処理が、アレイに対して適用できる状態になっています。」
青木氏：「つまり、スカラーの処理を拡充してほしいのですね。」
古橋氏：「SUBSTRINGやEDXPのようなものをアレイの各要素に対して適用して変換するMap関数や、適用してTRUEが帰ってきたやつだけにするfilterなどが欲しいです。」
青木氏：「私もリレーションではない値の処理は、もう少し充実してもよいと思っています。
たとえば、共通部分式が欲しいです。スプリットする処理が難しいと、共通部分を書きたいため、文字列をスプリットして3つのカラムに分けたいです。今だと、1回サブクエリの中で処理を書き、たとえば3つの配列にして上のクエリで3つのカラムに分ける処理が必要になります。一段のセレクト文の中で、サブクエリを使わずに書きたいです。」
古橋氏：「なるほど、確かに書けないです。
struct型があるクエリエンジンだと、スプリットした結果をstruct側にすることができるため、疑似的に同じようなことができます。」
青木氏：「それを分けて、別の処理をしたいです。」
古橋氏：「（分けて別の処理をするためには）文法的にはどのようにやるのですか？」
青木氏：「拡張だと思います。」
古橋氏：「with文のように、セレクトの前にまず宣言を書くのですね。」
青木氏：「ブレースでもよいですが、宣言できるようにしておいて、宣言したのを参照できるといいなと思います。実際には、共通部分式があると最適化して一つにしてくれるのですが、書きたくないです。」
古橋氏：「逆も欲しいです。Javascriptなどで見られる、ストリングテンプレート式と呼ばれる文字列に変数を埋め込むものが、今時のモダンな言語だと基本的に存在します。これがSQLにも欲しいです。今はパイプで毎回繋ぐ必要があり、間にnullがあると全てnullになってしまうため、非常に大変です。」
青木氏：「それがよいのであれば、マルチラインテキストリテラルが欲しいです。文字列処理や配列処理がもう少し自由にできるとうれしいです。」
古橋氏：「スイッチケースのようなものは、今はケース文で書けますが、大したことはできません。パターンマッチのようなもので、セレクト文を実行したりナビゲーションを変えたりできたら便利だと思います。
たとえばbotアクセスだけ違う処理をする時などに欲しいです。アグリゲートのカウント句の後ろにfilterとつけて、そのカウントに適用する行をWHEREではなく、アグリエーションの関数ごとに絞れるため、非常に楽になりました。ただ、もう一声ほしいですね。」
青木氏：「2030ぐらいになりそうですね。」
古橋氏：「先ほど聞こうと思ったのですが、SQLは今後も覚えた方がよいですか？」
青木氏：「もちろんです。これから機能追加されるし、基本的に覚えておかないと生き残れないんですよ。SQLにならずんば人にあらずです。
あとセレクト句でアスターから除外できるものが最近入ってきたのですが、さらにもっと強化したいです。BigQueryにあるものが入ってきてほしいです。」
古橋氏：「入ってほしいですね。Prestoにも入っていました。
ケーブル関数も確かにできそうです。文法で実装してくれれば優しいです。」
青木氏：「これらは誰に言ったら実装してくれるのでしょうか？」
古橋氏：「SQL空港の近くの誰かではないでしょうか。」
青木氏：「確かにoracleなどでは、買うメンバーがいそうです。」
古橋氏：「マッチなどは普通入りそうにないですが、あれが入ってしまうのはやはり、あの辺のパワーが大きいのかなと思います。」
青木氏：「2016でマッチが入るのだとびっくりしました。Nパスが出たのが、その5年ぐらい前のはずでした。」
古橋氏：「（Nパスは）特許を取られていませんでしたか？」
青木氏：「Nパスが特許なのではなく、SQL MapReduceが特許です。実装が特許で、できることに関してはOKなはずです。」
古橋氏：「Nパスのような事は、覚えると普通のSQLで書けないことが書けるため、使いどころは少ないですが、非常に便利です。」
青木氏：「少ないですが、割とやりたい時はあります。たとえば、weblogのセッション分析です。」
古橋氏：「1セッションの中で、順番も考慮しつつ、人を抽出したい時に使うのですか？」
青木氏：「そうです。基本的にユーザーIDで分けて並べます。」
古橋氏：「なるほど。たしかに使い手がありそうです。」
青木氏：「アスターを買ってくれるほとんどのお客さんは、Nパス側で、Weblogのアクセスログの分析がしたかった方です。」
「ETLは消えるのか？」のテーマで議論していただきました。
青木氏：「それこそ、AuroraのZERO-ETLやCDC（Change Data Capture）を流して再構築する技術が発展してきましたが、果たしてそれでETLは消えるのでしょうか？」
古橋氏：「そもそも、ETLはやりたくないです。遅いし、途中でエラーが起きたら困るし、スキーマを変更したら追従する必要があります。さらに、アクセス制御やセキュリティ管理もする必要があるため、基本的に絶対やりたくないのです。
そのため、どのようにして（ETLを）消すかということでもあると思います。転送は、組織間接続がいる時に結局出てこざるを得ない気がします。データベースエンジンは日々進化しているため、組織の導入のタイミングによってデータベースエンジンが異なります。
したがって、その間をどのようにつなぐかという問題があります。」
青木氏：「なるほど。JTCに勤めている友人の話では、逆にETLの方が交渉が難しいと言っていました。
ディノードと呼ばれるクエリを投げ、仮想的に統合するソリューションを使っていたのですが、その方がまだ許されると伺いました。ETLをしようと言うと、ETLサーバーを立てて、ETLサーバーからデータベースへのアクセスをもらう必要があるが、それは許してもらえなかったようです。
ところが、一時的にFederated Queryでつなぐのは、許していただけたようです。そのため、むしろ仲の悪い組織をつなぐ場合は、Federated Queryの方がよい可能性があるらしいです。」
古橋氏：「なるほど。Federated Queryができ、宛先が柔軟に使えるのは、今後のデータベース選定でも重要ですね。」
青木氏：「ほとんど同じとも思います。」
古橋氏：「コピーが永続化されると監査しないといけませんが、メモリ上であれば許されるのかもしれないです。漏洩リスクやセキュリティに関する法律が関わっているかもしれません、」
青木氏：「たしかに、そうです。GDPRなどもそうですし、何らかの形で永続化してしまうと面倒になります。」
古橋氏：「永続化してしまうと、すぐに消えることが保証されていれば時間次第で許されるかもしれませんが、基本的にしっかりと扱ってるかチェックが必要になります。
では、今後はFederated QueryでETLを無くせるかもしれないですね。」
青木氏：「その場合、大規模なデータはどうするのでしょうか？CDCでできるのでしょうか？」
古橋氏：「CDCでは、コピーしてしまうと思います。」
青木氏：「そうすると、取ってくる元の方も並列にであることを考慮すると、やはりスパナーになるのではないでしょうか？」
古橋氏：「それか、「CDCともFederated Queryとも言っていないが、クエリがかけられてしかも早いと言っていて、中がよくわからない」ものなら許されるかもしれません。」
青木氏：「速くするためには、やはり並列処理ではないでしょうか？」
古橋氏：「結局、並列処理だし中でコピーはするが、実際Aurora ZERO-ETTLなども中で何をやってるかわからないです。中で何をやっているかアクセスする口がないため、コピーに対して永続されてないのと実質同じになると思います。」
青木氏：「やはり、CDCです。」
古橋氏：「CDCとFederated Queryの隠蔽したものでETLを無くせそうです。スタートアップ案のようですね。」
青木氏：「これはスタートアップでできますか？」
古橋氏：「複数データベースエンジンが乱立する宿命にある前提に置けば、可能かもしれないです。AWSのデータマイグレーションサービスのようなイメージで、データベースを繋げられそうです。
EmbulkをPrestoのfrom文に書けるようにするプラグインを書いたことがあります。遅いですが、面白いなと思ったことがあります。」
青木氏：「類似の例があったような気がします。たしかにエクスターナルアクセスとさほど変わらないです。」
古橋氏：「データソースに非常に負荷をかけるため、キャッシュレイヤーが必須ですが、そのキャッシュが暗号化され、自動的にエクスパイアするようになったら、可能性はあるかもしれません。」
青木氏：「そうすると、物理的にファイルとかで置くより、マテビューもようなイメージになります。マテビューに任意のテーブルを入れられる仕組みがあれば便利そうです。」
古橋氏：「マテビューの概念を拡張して、ETLのようなところに落とし込むとよいと思います。」
青木氏：「しかし、エクスターナルテーブルとあまり変わらないような気もします。」
古橋氏：「そこはやはり、先ほどのSCBCやマテリアライズしてキャッシュすることで、上手いことやってくれるものです。隠れているものがセキュリティ監査上嬉しいです。」
HTAP（Hybrid Transaction Analytical Processing）について、ご紹介していただきました。
青木氏：「今時では、OLTPのデータベースでテーブルが非同期でカラムナのデータテーブルも作られるようになっており、分析はそれを使って行うものです。
一言で言うと、ついにOLTPとOLAPの統合の波が来た気がします。」
古橋氏：「一定需要はやはりあると思います。ないと困るエリアもあると思いますが、リアルのアプリケーションの更新したデータをすぐに解析でも見たいことは、あまりないと思います。
そもそも、解析とアプリケーションで読み書きしてるデータを、同じところに混ぜるのはやりたくないです。そのため、分けたいインセンティブが別に発生していると思います。
そうなると、レプリカからETLをしてアナリティからエンジンを入れればよいため、それを乗り越えてなお欲しいケースが、どれだけあるかを考える必要があると思います。」
青木氏：「1インスタンスでつながっている必要はなく、分析データベースとOLTPのデータベースがあり、中で繋がっていて自動的に処理ができればよいと思います。」
古橋氏：「SQL文法やアクセスコントロールのやり方の意味では同じプラットフォームだが、テーブルごとに分けられるのですね。それは良いと思います。」
青木氏：「サービスで提供されていれば、一つのデータベースとして見えるため、よいと思います。」
古橋氏：「それに先ほどのETLを無くすシステムが入れば、素晴らしい世界になります。」
青木氏：「これまで死屍累々だった2つの世界の統合が、ついに実現するかもしれません。」
古橋氏：「そういった意味では、データベースエンジンとして両方できる単一アーキテクチャである必要はなく、うまく使い分けられるような機能が載っていればいいのですね。
Federated Query専用のクエリエンジンは夢があります。たとえば、Trinoは最初からFederated Query用のエンジンでしたし、ClickHouseもMySQL以上にストレージをプラグインします。ネイティブストレージエンジンがあまりない世界には、非常に合いそうです。」
青木氏：「OLTPしてテーブルを分析するところまでは行けそうですが、分析DB側で何かを作って戻したいことがあります。たとえば、何かリコメンドを作ったり、Treasure Dataでで言うアクティベーションのようなことをしたりして、データを作り再度Web側で再利用することがきっとあるはずです。」
古橋氏：「それが、違うデータベーステクノロジーだと、やはり扱いが面倒です。一度インサートするのにもワークフローを組まなければいけません。」
青木氏：「整合性側の問題もあります。」
古橋氏：「密結合して、1個のエンジンの中に入ってた方が簡単ですね。」
青木氏：「密結合はできるのでしょうか？」
古橋氏：「OLTPのようなデータ構造を作ればよいため、たとえばTrinoのプラグインを書いて、インサートをするのは可能だと思います。」
青木氏：「ただ、それを混ぜるのは厳しいと思います。OLTPでミリ秒単位で更新されてる中で、新しいデータを作って書こうとしても、すでに古くなっている可能性があります。そのため、うまく混ぜないといけませんが、結局論理的にはどうにもならない気がします。」
古橋氏：「HTAPという用語の上に、論理的にどのようなテーブル構造を作り、データフローを作るかを議論しないと、実用上困るケースが出てくると思います。」
古橋氏：「我々もまだ参画する余地があるでしょう。TIDBを入れれば終わりではないのです。
書き換えてるテーブルから解析用にデータを呼び出すのと、それをもう1回戻すのは同じようなアクセス傾向だが、やっていることが全く違うし、どのようにMVCCのようなことをするかはかなり難しいです。」
Declarative data pipelineについてご説明していただきました。
青木氏：「Declarative data pipelineは定義もさまざまですが、私の意図としては、ジョブとしてSQLを流していくのではなく、ジョブ1個がマテビューになり、マテビューを参照するマテビューを書くように、多重参照することで自動的に差分更新がされていくマテビューの連なりが作れるのではないかと思っています。」
古橋氏：「現在では、データを変換するSQLを数多く書くことになるが、マテビューみたいな形で書き、つなげていくと差分更新までうまくできるのですね。素晴らしいです。」
青木氏：「自分でデリートやインサートなどをせず、全てデータベースがしてくれます。」
古橋氏：「まず発明としてあるのは、何をエンティティとするかの時に、データとデータの変換を書くのではなく、宛先のエンティティを宣言することです。エンティティを管理するのは、アクセス制御やデータの種類・場所の管理も、そのエンティティを管理すればよいため、管理上も非常によいと思います。
逆に今では、間のSQLを管理するとき、「どちらに寄せよう」や「どちらの人が作るのか」となるため、分離のしやすさの観点からするとよいです。宛先に「このデータは、このように作られるものです」といった宣言を置きます。
そうなると、エンティティがまず分かれており、そこに機能拡張していくことになると思います。そこには、当然メタデータや「このデータはこのように作られており、このデータとこのデータを接合させたものです。」といった分は自動生成できるようになっています。
また、実行エンジンとしては普通のPrestoなどですが、その上のレイヤーでうまくやってくれる世界観は素晴らしいです。」
青木氏：「素晴らしいですね。ただ、運用が難しそうです。原因がわからないが、詰まるようなことがあると、我々は何もできなくなってしまいます。」
古橋氏：「Declarativeは、プロシージャルに制御できる部分が減ることを意味するため、うまく動かないと困ってしまったり、理由のわからない問題が勝手に起きてしまったりします。
SQLもDeclarativeです。昔は1個1個プログラムを書いていましたが、DeclarativeなSQLで最適化レイヤーを各データベースエンジンが持っており、最適化レイヤーが非常に成熟したため、「宣言的の方がよい」となりました。
Declarativeなものをプロシージャルなものに変換するシステムがしっかりと動けば、よいと思います。
現在、これをやってるものはあるのでしょうか？」
青木氏：「今やっているものはないと思います。」
古橋氏：「ポスグレにインクリメンタルマテリアライズドビューのようなものが入ったのでしょうか？ただこれは1段であり、2段になるとどの順番で更新するかの問題が出てきます。２段になると、問題がさらに難しくなる気がします。」
青木氏：「概念はどこかで読んだ気がしますが、実施しているといった話ではありませんでした。」
古橋氏：「私も概念は社内ブログなどで書きましたが、実装の話になるとなかなか見ないです。
AWSのglue crawlerは、作られたテーブルのメタデータを収集してきて、このテーブルありますよって見せてくれます。glue crawlerは似たような結果が得られる部分があると思います。リードオンリーであるため、完成したものがどうなっているかを見るだけであるため、作るところと結合していないのです。
SQLの書き換え手順はそれぞれ書き、書いた結果を管理するとこだけそういったものがありますが、要改善です。」
青木氏：「誰かがやってほしいです。Declarativeは流行るはずですが、Haskellのような例もあるためわからないです。」
過去のData Engineering Studyのアーカイブ動画
Data Engineering Studyはデータエンジニア・データアナリストを中心としたデータに関わるすべての人に向けた勉強会を実施しております。
当日ライブ配信では、リアルタイムでいただいた質疑応答をしながらワイワイ楽しんでデータについて学んでおります。
過去のアーカイブもYoutube上にございます。興味をお持ちの方はぜひご覧ください。
https://www.youtube.com/@dataengineeringstudy6866/featured
