ハクソク

世界を動かす技術を、日本語で。

F3: 未来のためのオープンソースデータファイルフォーマット [pdf]

236日前原文(db.cs.cmu.edu)

概要

  • 本記事では、 AI（人工知能） の基礎概念と主要な活用分野を解説
  • AIの 歴史的背景 と近年の発展要因を整理
  • 代表的なAI技術（機械学習・ディープラーニング等）の概要を紹介
  • AI導入による メリット と課題について考察
  • 今後のAIの展望と社会的インパクトを展望

AI（人工知能）とは

  • AI（Artificial Intelligence） は、人間の知的活動を模倣・拡張する技術
  • 1950年代に誕生した概念、現在は 機械学習 や ディープラーニング で大きく進化
  • データ解析・パターン認識・意思決定支援など幅広い用途
  • 人工知能は主に 弱いAI（特化型） と 強いAI（汎用型） に分類
  • 産業・医療・金融・エンターテインメントなど多様な分野で活用

AIの主要技術

  • 機械学習（Machine Learning） ：大量データから自動でルールや特徴を抽出する技術
    • 教師あり学習、教師なし学習、強化学習など多様な手法
  • ディープラーニング（Deep Learning） ：多層ニューラルネットワークを用いた高度なパターン認識
    • 画像認識・音声認識・自然言語処理で高精度を実現
  • 自然言語処理（NLP） ：人間の言語を理解・生成するAI領域
    • ChatGPTなど対話型AI、翻訳、要約、感情分析に応用
  • ロボティクス ：物理的な動作・制御をAIで自律化
    • 製造業、物流、介護ロボットなどで実用化

AI活用のメリット

  • 業務効率化 ：自動化による人手削減とコスト最適化
  • 意思決定支援 ：膨大なデータからインサイト抽出
  • 新たな価値創出 ：パーソナライズサービスや新規ビジネスモデルの構築
  • 精度向上 ：ヒューマンエラーの低減と高精度予測
  • 24時間稼働 ：人間では難しい連続稼働が可能

AI導入の課題

  • データ品質と量 ：学習に必要な大量かつ高品質なデータの確保
  • 説明性・透明性 ：AIの判断根拠がブラックボックス化しやすい
  • 倫理・法規制 ：プライバシーや差別、責任所在など社会的課題
  • 人材不足 ：AI開発・運用を担う専門人材の確保
  • コストとROI ：初期投資や運用コスト、効果測定の難しさ

今後の展望と社会的影響

  • 汎用AI（AGI） への進化と社会構造の変化
  • 雇用構造 の変化と新たな職種の創出
  • 倫理的ガイドライン や法整備の必要性
  • 教育分野 でのAIリテラシー向上
  • 持続可能な社会 実現への貢献とリスク管理

まとめ

  • AI は現代社会の基盤技術となりつつあり、今後も重要性が拡大
  • 技術進化とともに、 倫理・法規制・人材育成 など多面的な対応が求められる
  • 持続可能な発展 のために、社会全体でAIとの共生を模索する必要

Hackerたちの意見

これの提案は、Vortexの提案とすごく似てるね。データ処理やコンピューティングの変化があるたびに新しいフォーマットを作る必要がなくなるっていう、データの整理構造と汎用APIを提供することで、開発者が新しいエンコーディング方式を簡単に追加できるってやつ。ただ、F3とVortexの関係がいまいち分からないんだ。プロトタイプはVortexのエンコーディング実装を使ってるって書いてあるけど、Vortexの型システムは使ってないってこと？

└

背景は複雑なんだ。CMU、清華大学、Meta、CWI、VoltronData、Nvidia、SpiralDBの間で、単一のファイルフォーマットに統一するためのコンソーシアムを作る計画があったんだけど、CMUの弁護士がMetaのNDAの件でパニックになって、Velox Nimbleのプレビューにアクセスするのが難しくなって、結局その計画は頓挫したんだ。私は法律の専門家じゃないけど、MetaのNDAは合理的に思えたな。だから、約1年後に計画がダメになって、みんなそれぞれのフォーマットをリリースしたんだ。→ MetaのNimble: https://github.com/facebookincubator/nimble → CWIのFastLanes: https://github.com/cwida/FastLanes → SpiralDBのVortex: https://vortex.dev → CMU + 清華大学のF3: https://github.com/future-file-format/f3 研究の側では、私たち（CMU + 清華大学）は新しいエンコーダーを開発することには興味がなくて、WASMの埋め込み部分に集中したかったんだ。元々のアイデアは、Hannes@DuckDBからWes McKinney（私たちの共著者）への提案から来たんだ。Vortexの実装を使ったのは、Rustで書かれていて、少し手を加えればほとんどがWASMにコンパイルできたから。VortexはF3プロジェクトとは別のもので、サポートするためのエンジニアリングエネルギーがある。F3は今のところ学術的なプロトタイプなんだ。今年、ドイツ人もWASMを使った独自のファイルフォーマットをリリースしたけど、彼らはファイル全体をWASM化していて、個々のカラムグループではないんだ。→ ドイツ人: https://github.com/AnyBlox

物理学者の未来にはないね！/冗談だけど。次の20年間で大型ハドロン衝突型加速器で生成されるエクサバイトのデータは、CERNが自家製で作ったフォーマットに保存されるんだって。https://cds.cern.ch/record/2923186/

列指向ストレージとそれ以外の違いがよく分からなくてごめんだけど、これがそんなにクールなのはどうして？カスタムな小さなベクトル埋め込みデータベースをサンドボックス付きで送れるのが大きな利点なのかな？論文からは「ステップチェンジ/基盤となるビルディングブロック」って雰囲気を感じるし、プロジェクト名自体も少し「je ne sais quoi」を暗示してるけど、残念ながらページごとに数文しか理解できないんだ。写真はきれいだし、色の選び方もセンスがあって大胆だね。簡単に影響される私からは二重のグッド評価！

└

カスタムの小さなベクター埋め込みデータベースをサンドボックス付きで送れるのが大きな勝利なの？ いや、これは将来のエンコーディング変更に向けた互換性レイヤーなんだ。例えば、ORCv2は新機能を新しいフォーマットバージョンにまとめようとしたから、今まで出荷されてないんだ。新しい機能を無効にした状態でライターを出荷して、サポート付きのリーダーを出荷して、最後にライターを新しいフォーマットで書き込むように切り替えるっていう流れだったんだよ。具体的には、浮動小数点エンコーディングの新しい反転ビットバージョンがあって、最大圧縮のために指数、仮数、符号を整数として送信するものだったんだ。もし新しいファイルと一緒にwasmシムを出荷できて、全リーダーがサポートするまでの1年以上の待ち時間をスキップできたら、もっと簡単に出荷できたのに。フォーマットの進展もあっただろうし、古いファイルが独自の情報を持っていれば、互換性を失うことなくコード内のリーダー実装を非推奨にできたんだ。今日、Sparkのバリアントタイプみたいなものはこれから恩恵を受けるだろうね。サブカラム化は、分割されたカラムからのすべての可能な再結合をサポートするインタプリタとしてではなく、バイトコードとして出荷する方がずっと簡単になるだろう。PS: ORCでtpc-hを調整したり、ライターのOOMを修正したりするために多くの夜を費やしたから、ベンチマークでそのビットを保持しているのを見ると心が温まるよ。

└

確かに、カラムストレージの利点は、すべての行を通してカラム全体をすぐにスキャンできることだよね。OSのバッファリングをうまく活用できるから、例えば「b = 'x'のときのaを選択する」みたいなクエリがすごく早いんだ。

└

カラム型ストレージは素晴らしいよ。複雑なネストされたスキーマをリーフ値に分解して、プリミティブとして保存できるから。リーフ値に直接アクセスできるから、IOやパースの手間が大幅に減るんだ。これらのフォーマットは実際には最上位レベルで行のグループにパーティション分けされていることに注意してね。ここでの大きな利点は、データページからApache Arrowのバッファを直接取得できること。提供されたWASMを使うか、ネイティブデコーダーを持ち込むことで実現できる。Parquetでは、これが現在非常に複雑なんだ。ParquetはDremelエンコーディングを使っていて、プリミティブ値と二つの整数ストリーム（繰り返しと定義レベル）を一緒に保存して、スキーマから構築された状態機械を使ってレコードを再構築するんだ。これらの整数ストリームを取得するのも難しい。Parquetは「RLE」に決まっていて、これはビットパッキングとランレングスエンコーディングの混合で、リファレンス実装ではビットパッキング部分だけで74,000行の生成コードを使ってる。だから、ParquetからArrowバッファを取得するのはかなりの手間がかかる。F3はこれをずっと簡単にして、将来にも対応できるはず。ここでの提案された利点の一つは、メタデータへのランダムアクセスができること。GeoParquetを使うときは、メタデータをSQLiteにインデックスしてる。そうしないと、例えばOverture Mapsで空間クエリを実行するのに約10分かかるところが、数ミリ秒で済むから。約500ファイルのフッターをパースする必要があって、約150MBのThriftをパースしてクエリしなきゃいけない。でも、GoogleのFlatbuffersを選ぶのはちょっと変だね。FlatBuffersのメモリ安全性は知られている問題だし[1]、これらの脅威を軽減するために生成されたコードが実際のパフォーマンス向上を示すとは思えない。実際、SQLiteデータベースを埋め込んじゃえばいいんじゃない？[1] https://rustsec.org/advisories/RUSTSEC-2021-0122.html

これ、めちゃくちゃおかしいよ。> Wasmのデコードパフォーマンスの低下は、ネイティブ実装と比べて最小限（10〜30%）なんだって。つまり…最初から10%-30%のパフォーマンス低下を受け入れて、将来的にデコーダーを改善する機会を永遠に失うってことだよね。それに、「ブロック全体をデコードしてメモリに保存する」以外の高度なデコーディング機能も放棄することになる。なんで誰がこんなことをするのか全く理解できない。スピードが大事なら、wasmは無理だよ。スピードが気にならないなら、特別なエンコーディングアルゴリズムなんて必要ないし、よく知られているものを使えばいいだけ。

└

ちょっと同意するけど、もっと全体像があるよ。君が説明している状況は、すでにいろんな圧縮アプローチで起こっていることなんだ。たとえば、一般的な圧縮機を使う代わりにビットパックを選ぶこともあるし、圧縮機を完全に変えることもある。こういうことはWASMなしでも存在していて、ソフトウェアを新しい技術で更新した後にファイルを「トランスコード」つまり書き直さなきゃいけないってことだ。WASMでも同じで、ファイルを書き直すだけなんだ。確かに、これがイテレーションのコストを効率が悪く上に押し上げているのは同意するよ。全体的に見ると、これってかなり高くつくし、将来を見越す価値があるかは不明だね。エクサバイト規模のシステムで働いたことがあるけど、データの大部分を再エンコードするのは良くないと思う。

└

つまり…最初から10%-30%のパフォーマンス低下を受け入れて、将来的にデコーダーを改善する機会を永遠に失うってことだよね。WASMはバックアップとして使うものなんだ。もしネイティブデコーダーがインストールされているなら（例えば、クレートとして）、システムはそれを優先して使う。そうでなければ、WASMにフォールバックする。10-30%のパフォーマンス低下は、ファイルをまったく読めないよりは価値があるよ。

Wes McKinneyについて知らない人のために。Wes McKinneyは、Pythonの定番タブラー分析ライブラリであるPandasの創始者なんだ。これにより、彼のフォーマットは最初から広く受け入れられるし、問題に対する関心も数十年にわたってあるから、彼の洞察は特に価値があるんだ。

└

データとコードを混ぜるのは、典型的なセキュリティのミスだよね。ちょっと知られた個人が関わっているからって、ミスが少なくなるわけじゃないし。

└

彼のParquetに関する仕事は、権威を示す良い例だと思う。

└

Apache Arrowのクリエイターでもある。現代のデータ分析のコアコンポーネントだね。

└

Wesの仕事が大好きで、Pandasはものすごく影響力があったよ。でも、技術的には彼のベストな作品ではなかったと思う。セールスポイントで言うと、Arrowデータフォーマットは技術的にずっと優れていて、データエコシステム全体にもっと影響を与えていると思う。DataFusionとかね。そう言えば、F3が実際に何なのか見てみたいな（あ、あなたのコメントがリンクをクリックしたくなった理由だよ）。

└

Andy Pavloも注目に値するよ。彼はデータベースの権威で、「データ指向のライフスタイル」を送っているんだ。彼の「What goes around comes around ...」という2本の論文は、過去と未来の50年間のデータベースについての素晴らしい概要を提供しているよ（CMUセミナーシリーズもすごい）。彼がこのプロジェクトに関わっているのを見るのが楽しみだ。あまり知らない中国の共著者には申し訳ないけど、しっかり読んでおくね！

ざっと見た感じ、Parquetの多くの欠点に対処しているみたいで、すごくワクワクする。特に順不同で: - ParquetのメタデータはThriftだけど、「このフィールドが存在するなら、この別のフィールドも存在しなければならない」とコメントが付いているだけで、実際にその事実を検証するコードはないから、偽のThriftメタデータを与えたらリーダーがクラッシュすると思う。 - Parquetのメタデータは解析しなきゃいけないから、バッファを割り当てて、メタデータのバイトを読み込んで、メタデータのバイトを解析するたびにダイナミックにたくさんのものを割り当て続けなきゃいけない。具現化されたメタデータのサイズがわからないからね！ヒープの割り当てが多すぎる！このファイルフォーマットのFlatbuffersアプローチは、Flatbufferのバイトを直接解釈できるから、これを解決しているみたい。 - エンコーディングがずっと強力になった。データベースコミュニティでは、ずっとコンポーザブルで再帰的な軽量エンコーディングが必要だと言われてきたと思う。BtrBlocksが私の記憶に残る最初のオープンなフォーマットで、その後FastLanesが続いた。どちらもParquet単体よりずっと良かったから、これらの2つのフォーマットのアイデアが取り入れられているのは嬉しい。 - ParquetはDremelのレコードシュレッディングをやっていて、頭が爆発しそうだったけど、それを取り除いてくれて嬉しい。実際の利益もなく、フォーマットを不必要に複雑にしているように思えた。 - Parquetのデータページは異なる行数を含む可能性があるから、欲しい行を見つけるためにColumnChunk全体をスキャンしなきゃいけなかった。ここでは、欲しいDataPage（IOUnit）に直接ジャンプできるみたい。 - 重い圧縮を取り除いて、Delta/Dictionary/RLEのものだけにした。重い圧縮は結局何の役にも立たなかったし、実装するのも超面倒だったから、20の依存関係を引き込む必要があった。全体的に素晴らしい改善だね。これがデータ分析の分野を席巻するのが楽しみだ。

└

圧縮に関して、今は世界中でzstdが定番になったのかな？

└

この技術がデータ分析の分野を席巻するのが楽しみ。Parquetは意外と難解だからね。効率的に使うためには、たくさんの面倒でドキュメントも不十分な細かいことを理解しておく必要がある。

└

wasmコンパイラは、‘重い’圧縮よりも多くの依存関係を持ち込むと思うんだ。15年前はCPUがもっと豊富だったから、ネットワークやディスクの帯域幅に比べて、もっと高価な圧縮がもっと効果的だったかもしれないね。

└

https://stackoverflow.com/questions/31812780/append-a-new-co...

ソースコードを見つけるのにちょっと時間がかかったけど、ここにあるよ: https://github.com/future-file-format/F3

データを読みたい実装がWebAssemblyを実行できる必要があるってことは、依存関係や肥大化を減らそうとする環境には不向きだね。

└

Wasmは結構シンプルだよ。「ウェブ」の部分と混同しないでね。他の人も指摘してるけど、wasmはバックアップみたいなもんだ。ネイティブバインディングを使えば、wasmを通さずに済むから、パフォーマンスが良くなるよ。

└

ネイティブデコーダーがあれば、WASMを実行する必要はないんだ。これはまさに抽象的な話だよ。

PDFについて文句を言ってる人のために、DOIはこれだよ: https://dl.acm.org/doi/10.1145/3749163

列（これ）や行（sqlite？）のための「最適」なフォーマットってもう確立されてる？俺は一日中切り替えなきゃいけないことが多いんだけど、うちで作ったメモリ上のものは動くけど、標準のものはないんだよね。