/home/by-natures/dev*

データ界隈で働くエンジニアとしての技術的なメモと、たまに普通の日記。

2023/02/16 読んだ記事まとめ(BIG DATA IS DEAD, DuckDB)

同僚に教えてもらった DuckDB について目につく記事が出ていたので読んでみましたが、DuckDB の根本思想とも言うべき記事でした。

BIG DATA IS DEAD

motherduck.com

DuckDB は、PC上で分析してしまおうというスケールアップの考え方で開発されている分析用データベースです。近年のハードウェアは性能向上が目覚ましく、クラウドでも例えばAWSが登場した2006年当時のEC2 インスタンスはシングルコア・2GB RAM のインスタンスしか選択肢がありませんでした。しかし今日では標準的なインスタンスは64コア・265GB RAM を搭載しており、メモリに特化したインスタンスならさらに一桁増やすことも可能です。

データ量が莫大に増え、既存のデータ処理ツールでは対応できなくなると言うのが常套句でしたが、そんなことはごく一部の企業にしか当てはまらないと言います。もしビッグデータと呼べる規模のデータを持っていたとしても、実際に利用するのは24時間以内のデータで、1ヶ月以上前のデータはただそこに存在しているだけで、利用されることはあまりありません。データ量課金のクエリ体系の場合はペタバイト級のデータ処理に数千ドルかかるため、コストの観点からも短い期間でのデータ利用が促されます。Snowflakeのようなウェアハウスの稼働時間単位の課金でも、データ量が少なくなればクエリが早く完了してウェアハウスのサイズも小さくて済むため、同じ力学が働きます。

過去のデータを使おうとしてもデータ品質が低くてバグがあったり、全期間通じて統一して扱えないような仕様(一定期間だけバグでカラムが入れ替わっている、null が入っているなど)があると、そもそも過去のデータを使おうという気すら起きないでしょう。データの意味も分からなくなっている可能性もあります。

面白い観点として、データを捨てる手間と保存する手間を比較して、ビッグデータの場合にはデータを捨てる手間が大きくなって惰性で蓄え続けてしまうという話があります。データレイクはデータスワンプ(沼)となり、何が入っているか分かりません。どうしてこのデータを保存しているのか?将来分析に使うかもしれないと思うなら、それはデータを保存するコストに見合うような分析であるか?むやみに溜めているだけではないか?と質問を繰り返し、データに対する適正なコストを見極めるべきだと述べています。

感想

データマネジメントはデータを資産として管理する活動で、資産と言うからには「負債」にもなりうるとDMBOKで説明があります。上の記事で惰性でデータを溜め続けるという指摘は、まさにデータの大半が「負債」になっていることを表しているように感じました。

DuckDB はスケールアウトに対するスケールアップという思想で作られているので、ノードがいくつか死んでもうまく強調してくれるデータベースとは異なり、サーバ1台への可用性が求められると思います。可用性を高く保つ使い方があるのか、可用性が低くてもよいようなユースケースでのみ利用するべきなのか… 今のところ後者に見えますが、またの機会に調べてみます。