DuckDBを使ったシンプルで安価 なデータマネジメント
 2024/12/10 S-Mat Tech Night
 株式会社ナイルワークス 山田 直行


山田直行(やまだ なおゆき)
 - ナイルワークス ドローン開発部
 自動航行ドローンのサーバー・ネットワーク・データベースなどバックエンド全般の 開発・運用
 - サイバーエージェント AI Lab 経済学社会実装チーム リサーチエンジニア
 研究成果のアプリケーション開発
 X: @satully
 HP: https://www.kirishikistudios.com/
 発表者


IoTデータの課題
 - リアルタイムにみたい
 - 複雑な分析もしたい
 
 を膨大な時系列データに対して安価に両立


IoTのデータの保存方法とクエリ方法が課題だった
 ドローンは電源オン〜飛行〜電源オフまで絶えずリアルタイムでログを送ってくるが、そ れをどこかのデータベース・ストレージに保存して、リアルタイムで監視するという要件が あった(例えば墜落・軟着陸などしたらすぐに検知)
 一番最初はRedisに入れていて2週間で削除(Expire)していたが、Redisだと分析クエリを 投げるのは難しい。時系列の前後のレコードをみて監視・検知するみたいな要件も加 わってきた。さらに2週間より前の過去分もクエリできるようにしたくなり、試行錯誤
 ひとまずKinesis Stream経由でPostgreSQL(Aurora)にもいれるようにしてみた


要件
 - 時系列のIoTデータ
 - スキーマは単一でなく、たくさんある(Heartbeat, 位置情報, 姿勢, GNSS(衛星)情報, バッテリー, etc…)
 - ニアリアルタイムで保存し、数秒以内にはフロントエンドのウェブアプリからクエリで きる状態にする
 - 前後のレコードを比較して監視・検知してSlackにアラートを飛ばす
 - 過去データもフロントエンドのウェブアプリからクエリできる状態を保つ
 - アドホックな分析クエリも投げることがある(頻繁ではない)
 - ファイルベースのログとかRDBとも接続してJOINして分析したい
 - エンジニアは一人(サーバーサイド全般＋データ系をまるっと担当)


分析用クエリのアーキテクチャをいろいろ検討した
 - 単にAurora(PostgreSQL)に突っ込み続けるだけだとテーブルが肥大化して運用が 厳しい。レコードが数千万を超えると分析クエリがレスポンス返ってこなくなってきた
 - AWSを使っていたのでとりあえずAthenaは使った
 - DynamoDBはスキーマ設計が決めきれず挫折
 - BIgQuery・Snowflake・Redshift(Serverless)・Timestreamなどを試用
 
 - あまり複雑な技術・プロダクトは導入したくない(学習コスト、運用コスト)
 - リアルタイムのクエリは頻繁にするが、過去分は毎日みるわけじゃないので常駐 サービスとするほどではない。SaaSにすると金銭コストがかさみそう



 
 
 1年半前のAWS Summit Tokyoミニステージ登壇時の資料
 ナイルワークスの自動飛行ドローンを支えるバックエンドシステム https://www.nileworks.co.jp/news/20230425
 当時は過去データの分析はS3 + Athenaでやっていたが、いろいろ面倒だった
 
 フォロー記事: 時系列+もう一つの何らかの属性で検索することがほとんどのデータは、 S3に置いてs3 selectが有用 - road288の日記 https://road288.hatenablog.com/entry/2024/02/06/151320
 


DuckDBの導入


DuckDBの簡単な紹介
 - https://duckdb.org/
 - データ分析に便利なインプロセスのデータベース
 - SQLiteのOLAP版 + 便利機能をいろいろ追加したもの
 - 各種データソースへの接続が簡単、速い
 - スキーマを事前に定義しなくてもクエリできる 
 - CSV, JSON, Parquet, Excelなどのファイル 
 - PostgreSQL/MySQLなどのリレーショナルDBと接続できる(federationぽいもの) 
 - S3に置いたファイル群を直接クエリできる 
 - パターンに一致した複数ファイルをマルチスレッドで読み込める 
 - DeltaLake/Icebergにも対応(個人的には現時点だと不十分) 
 - Python, Rustなどの言語のSDK, WASMでの利用に対応


いろんなクエリのデモ


サンプルデータのCSV
 適当なiotっぽいログがあるとする


csv/json/parquetなどに共通の機能として、
 スキーマを定義しなくても自動で読んでくれていきなりクエリできる
 


アスタリスクで一括して読み込むこともできる(並列処理してくれる)
 特定のパス以下の特定のパターンのファイルを一括で読める


Parquetファイルへの書き出し・読み込み


S3にあるファイルをクエリできる


S3上のファイルをクエリするわかりやすい活用例
 
 S3にあるALBログの調査はAthenaよりDuckDBのほうが簡単 - road288の日記 https://road288.hatenablog.com/entry/2024/11/06/113954
 


S3上にあるDuckDBファイルに直接クエリもできる


他のデータソースとの接続例
 SQLiteを例に説明します。下記のようなSQLiteのテーブルがあるとして、
 さきほどのiotログと結合させて分析したいとする


DuckDBから簡単に接続できる


DuckDB上でJOIN


Python + Jupyter Notebookから扱う


No content

DuckDB導入後のアーキテクチャ
 - リアルタイム(~当日)のデータクエリはPostgreSQL(Aurora)
 - PostgreSQLに書き込むのと並行してKinesis Stream〜Firehose~S3に置き、過去分 データはDuckDBからクエリ
 - Firehoseを使わずとも、直接Kinesis Stream~LambdaでDuckDBに書き込んでそこから Paquet書き出しできないか試行錯誤中 
 - シングルスレッドでしか書き込めないがappenderが十分高速なら可能と思っている 
 - FIrehoseでParquetにするにはGlueでスキーマ定義が必要なのが面倒なのでそれをカットした い
 - 今後はIceberg(S3 Tables)も使っていきたい


DuckDBの良いところ


ローカル環境(クライアント環境)のリソースを使える
 - どれだけクエリしても料金がかからない
 - レイテンシが小さい
 - 認証の操作がだるくない。すぐ分析を始められる
 - 一般に開発者のPCはマルチコアでスペックも良く、自分自身しか使ってないので 一定以下の規模のデータに対してはクラウド上のリソースより高速、快適。DuckDB はマルチコアをフルに使ってくれる


- 必要なデータだけ抽出してローカルに持ってきてしまえば、「なんか適当に操作した らまずいかも」の懸念が無いので、思いっきりいじれる
 - パフォーマンス影響・課金影響の2軸 
 - 「サーバーに負荷かけるような重いクエリ発行しないでくださいね〜」みたいな注意 添えられて権限もらっても、ライトユーザーは困ってしまう
 - SaaSだと、テーブル全体をスキャンするクエリを実行しちゃうとけっこう課金されちゃ うのもありがち
 - DuckDB-Wasm + 生成AI on Next.js で、どなたでも、いますぐ、地理空間情報の分 析ができましてよ
 - 「サンドボックス化されたデータベース」という表現が良い 
 
 サーバーに負荷かけちゃう懸念が無い


データをS3+ファイルベースにすることで、認証・認可の問 題がシンプルになる
 - 任意の関係者にS3の読み取り権限を付与するのはiam user, iam roleなどでシンプ ルに管理できる
 - S3バケット単位・パス単位でシンプルに権限付与できる
 - データ抽出済みのものについてはファイルを受け渡しすればよいだけ
 - 誰でも再現がとれる、追加の分析ができる


- pythonやjupyter notebookでスクリプト書いて扱いたいときに特にメリットが大きい
 - クラウドの認証キーとかをいちいち発行してコードや環境変数に含める必要がな い。ファイルにアクセスするだけ
 - センシティブな情報の厳密な管理には向いていない 
 - 弊社でこうした分析で扱ってるのはIoTのログのみ 


Big Data is Dead - MotherDuck Blog
 タイトルはやや誇張だけど、メインの主張は、99%の企業のデータはシングルノードで処 理できるという点
 ビッグデータを持っていても、すべてを一度にクエリするわけじゃない
 


ローカルに持ってきて処理するには大きすぎるデータ量の ときは、lambdaで前処理する
 - 処理対象のS3のキーのリストを抽出する親スクリプト＋そこからLambda呼び出し (非同期)
 - Lambdaは1000並列までデフォルトでいけるので処理はすぐ終わる
 - S3のファイルリストを入力にして、S3のパスごとにデータ変換して、S3の新しいパス に配置しなおす
 - そうしてサイズを小さく＋ParquetにしてからDuckDBでクエリする
 


クラウドコストが安いのがメリット
 - S3もLambdaも単体で使う分には十分に安い
 - S3のStorage ClassはIntelligent Tiering
 - ストレージコストを使用頻度が低いデータは安くしていけるのが良い(※128KB未満のオブ ジェクトは処理対象外なので注意) 
 - ほとんどのBig Dataソリューションはそうではない。データ保有量に対して線形に料 金がかかる
 


LambdaはPython, Node.jsでも十分速くて安いが、最近は Rustを使ってみている
 - 実行が高速、メモリ使用量が少なくかつ予測しやすい、バイナリサイズが小さい、 Cold Start問題の影響がほぼ無い(ゼロではない)
 - cargo-lambdaがすばらしい。デプロイが簡単
 - ついでにCDKとの連携も簡単で優勝
 - https://github.com/cargo-lambda/cargo-lambda-cdk 
 - Rustはこういうたくさん実行する小さいプログラムを書くのに向いてる


S3 + 標準SQL + αの知識で扱えて学習コストが低い
 - S3のオブジェクトは厳密には「ファイル」ではないが、実質的にファイルのような概 念で扱える。データの実体が見えるので、これが敷居が低い
 - SQLを使える人は多い
 - ＋αの知識についても直感的なものが多い
 
 - AWSは周辺のサービスを使っていくと高い
 - firehose, glue, athena, cloudwatch… 地味にコストがかさむ 
 - S3とLambdaはAWSの特売品


- DuckDBを業務の中でうまく組み込めるポイントがあったという事例紹介 
 - DuckDB単体で全部できるという話ではなく、PostgreSQLと組み合わせてつかっている 
 - BigQueryとかSnowflakeなどと排他的な関係ではなく補完できるツール 
 - DuckDBはコンピューティングとストレージのうち、コンピューティングを一部担うイメージ。スト レージはデータ形式はParquet、フォーマットはIceberg/DeltaLakeとかが今後は有望だと思う 
 - 中小規模のサービスのデータマネジメントを想定 
 - 目安としてDBテーブル数億レコード以下、DBストレージ数百GB、S3ストレージ数TB以内 
 - 顧客単位の分析とか範囲を絞った用途なら大規模でも使える局面はあるはず 
 
 - ファイルベース・クライアントベースの世界はいろいろシンプルになる！ 
 今日の発表の前提・要点・まとめ