ビッグデータの終焉 (2023)
(motherduck.com)- BigQueryの初期エンジニアとしての経験から見ると、多くの組織のボトルネックはデータの大きさよりも、データの活用方法とコスト構造に近かった
- BigQueryの顧客や業界からのフィードバックでは、データウェアハウスの大半は1TB未満であり、よく使う顧客の中央値でも100GBよりはるかに小さかった
- クラウドにおけるストレージとコンピュートの分離は保存量を大きく増やしたが、分析コンピュートの需要は最近のデータと集計が中心のため、同じ比率では増えない
- BigQueryで年間1,000ドル以上使う顧客のクエリの90%が100MB未満を処理しており、巨大なデータセットを持つ顧客でも大規模クエリを頻繁には実行していなかった
- 古いデータは、規制、訴訟、意味の風化、特殊な処理ロジックのために負債になり得るため、生データの保管よりも集計・削除・要約の方が良いかを点検すべき
ビッグデータの恐怖と実際のボトルネックの違い
- 10年以上にわたり、データから実行可能な洞察を得るのが難しい理由はデータの大きさにある、というメッセージが繰り返されてきた
- 大規模な拡張を処理する新技術を買えば解決するという処方箋が続いたが、新しいツールの導入やレガシーシステムの移行後も、多くの組織はなおデータを理解することに苦労している
- 2023年の状況は、ビッグデータ警告が始まった時期とは異なる
- 予測されていたデータ大激変は起きなかった
- データ量は多少増えたが、ハードウェアはそれ以上の速度で進化した
- ベンダーは依然としてスケーラビリティを訴求しているが、実務者はそれが現実の問題とどう結びつくのか疑問を持ち始めている
BigQueryの経験から見た顧客データ規模
- Google BigQueryの創業エンジニアだった筆者は、公開プレゼンで1PBクエリを実行し、大規模データ処理能力を実演した
- その後、BigQuery顧客の問題をデバッグし、書籍を2冊共著し、2018年からはプロダクトマネージャーとして顧客との対話や製品指標の分析を担当した
- 最も驚いた観察は、「BigQuery」の利用者の大半が実際にはBig Dataを持っていなかったことだった
- 大きなデータを持つ顧客でも、ワークロードの多くはデータセット全体のごく一部しか使っていなかった
- BigQueryの登場時には高速処理はSFのように見えたが、その後はより伝統的な処理方式も追いついた
- 本文のグラフは正確な数値ではなく記憶に基づく手描きであり、重要なのは厳密な値よりも分布の形である
- 根拠は、クエリログ、取引後の分析、ベンチマーク結果、顧客サポートチケット、顧客との対話、サービスログ、公開ブログ記事、直感に由来する
ほとんどの組織はそれほど多くのデータを持っていない
- 「Big Dataが来る」という営業スライドは、やがて誰もがデータに圧倒されるというメッセージを伝えていたが、10年後になってもその未来は実現しなかった
- BigQuery顧客の規模を見ると、大多数の顧客の総保存データ量は1TB未満だった
- 数百PBのデータを持つ顧客もいたが、規模は急速に減衰するべき乗則分布に従っていた
- 月10ドル未満のストレージ料金を払う顧客が数千社あり、これは約0.5TBに相当した
- サービスを多く使う顧客の中でも、保存量の中央値は100GBよりはるかに小さかった
- GartnerやForresterのような業界アナリストとの会話でも、大半の企業データウェアハウスは1TBより小さいというフィードバックを得た
- 業界感覚では、データウェアハウスの妥当な規模は100GB程度だった
- BigQueryチームはこの規模をベンチマークの主要な焦点にしていた
- ある投資家がポートフォリオ企業を調査した結果、相対的にデータ量が大きい可能性の高いテック企業でも、最大のB2B企業は約1TB、最大のB2C企業は約10TBで、大半はそれよりずっと小さかった
- 中規模事業の例でも、データは簡単には巨大化しない
- 顧客1,000人が毎日1件の注文と100件のラインアイテムを作成するとしても、1日あたりのデータ量は1MB未満で、3年後でも1GB程度である
- マーケティングDBに100万件のリードと数十件のキャンペーンがあっても、リードテーブルは1GB未満で、キャンペーン追跡も数GB規模にとどまる可能性が高い
- SingleStoreが2020〜2022年に急成長していたSeries Eユニコーン企業だった時でさえ、財務ウェアハウス、顧客データ、マーケティングキャンペーン追跡、サービスログを合わせても数GB程度だった
ストレージとコンピュートの分離が生んだ錯覚
- 現代のクラウドデータプラットフォームはすべてストレージとコンピュートの分離を採用しており、顧客を単一のフォームファクタに縛らない
- この変化は、過去20年のデータアーキテクチャにおいて、スケールアウト以上に重要な変化だった可能性が高い
- 管理の難しいshared-nothing構造の代わりに、shared disk構造はストレージとコンピュートを独立して拡張できるようにした
- S3やGCSのような拡張可能で十分に高速なオブジェクトストレージは、データベース設計上の制約を緩和した
- 実際には、データ量はコンピュート量よりもはるかに速く増える
- データは時間とともに生成されるため、静的な事業でも保存量は時間に応じて線形に増加する
- 分析はたいてい最近のデータを対象とするため、コンピュート需要は保存量のように増える必要がない
- 古いデータは変化しないため、繰り返しスキャンするのは浪費に近く、重要な答えは集計によって作れる
- オンプレミスからストレージ・コンピュート分離型のクラウドへ移行した顧客では、保存量が大幅に増えてもコンピュート需要はほとんど変わらないケースが多かった
- BigQueryのある大手小売顧客は、オンプレミスのデータウェアハウスが約100TBだったが、クラウド移行後は30PBまで増えた
- 保存量は300倍になったが、コンピュート費用は同じ比率では増えず、分析に数十億ドルを費やしていたわけではない
- この構造は、拡張可能なオブジェクトストアを使えば、予想よりはるかに少ないコンピュートで十分かもしれず、分散処理が不要な場合すらあることを示している
実際のクエリワークロードは全データよりはるかに小さい
- 分析ワークロードが処理するデータ量は、直感より小さい可能性が高い
- ダッシュボードは集計データで構成されることが多い
- 利用者は直近1時間、1日、1週間のデータを見ることが多い
- 小さなテーブルほど頻繁にクエリされ、巨大なテーブルほど選択的にクエリされる
- BigQueryで年間1,000ドル以上使う顧客のクエリを分析したところ、90%のクエリが100MB未満を処理していた
- 特定顧客のクエリ量が結果を歪めないよう、複数の方法で分けて分析した
- データを読まないメタデータ専用クエリは除外した
- GB級クエリは高いパーセンタイルでようやく現れ、TB級クエリは非常にまれだった
- 巨大なデータ量を持つ顧客でも、巨大なデータをほとんどクエリしていなかった
- 大規模クエリを実行するのは主にレポート作成目的であり、性能は優先事項ではなかった
- ある大手ソーシャルメディア企業は、月曜の経営報告のために週末に非常に大きなクエリを実行していたが、それは平日に走る数十万件のクエリの中ではごく一部にすぎなかった
- 最新の分析データベースは、実際に読むデータを減らすためのさまざまな手法を使っている
- カラムプロジェクションで必要なフィールドだけを読む
- パーティションプルーニングで狭い日付範囲だけを読む
- クラスタリングや自動マイクロパーティショニングによるセグメント除去でデータ局所性を活用する
- 圧縮データ上での計算、プロジェクション、プレディケートプッシュダウンもクエリ時のI/Oを減らす
- I/O削減は必要な計算量を減らし、コストとレイテンシを下げる
- 関連資料: クラウドデータウェアハウスのコスト削減
- 関連資料: データウェアハウスの性能ボトルネック診断
データ処理コストは小さくクエリするよう圧力をかける
- スケールアウトで高速に処理できることは、安価に処理できることを意味しない
- 1,000ノードを使って結果を得るなら、コストは非常に大きくなり得る
- BigQueryのデモで実行していた1PBクエリは、小売価格ベースで5,000ドルだった
- このような非効率は、PB規模で運用していないチームにとって負担となる big data tax の一部である
- データ処理量を減らそうとする金銭的インセンティブは、バイトスキャン課金モデルでなくても当てはまる
- BigQueryのスキャン費用であれSnowflakeインスタンスのアイドル費用であれ、主要クラウドデータウェアハウスは請求額を膨らませうる
- クエリを小さくすれば、より小さなインスタンスを使え、クエリは速くなり、より多くの同時実行も可能になる
データの大半はほとんどクエリされない
- 処理されるデータの大きな割合は24時間未満の最新データである
- データが1週間ほど経つと、直近1日のデータよりクエリされる可能性は約20分の1になる
- 1か月が過ぎると、データはたいていそのまま残り、まれなレポート実行時にだけクエリされる
- 保存データの年齢分布は、アクセスパターンよりはるかに緩やかである
- 多くのデータはすぐ捨てられる一方で、多くのデータはテーブルの末尾に追加され続ける
- 直近1年分のデータが全体の30%しかなくても、データアクセスの99%を占めることがあり得る
- 直近1か月分のデータが全体の5%しかなくても、データアクセスの80%を占めることがあり得る
- データが時間とともに静かになっていくと、実際のワーキングセットは予想より管理しやすい大きさになる
- 10年分で1PBあるテーブルでも、実際によくアクセスされるのは当日データだけかもしれない
- 当日データは圧縮後で50GB未満かもしれない
単一マシンの限界は押し広げられ続けている
- Big Dataを「単一マシンに収まらないもの」と定義するなら、それに当てはまるワークロードの数は年々減っている
- 2004年にGoogle MapReduce論文が書かれた当時は、一般的なデータワークロードが単一の汎用マシンに収まらないことが珍しくなかった
- 2006年にAWSがEC2を公開した際、提供されたインスタンスはシングルコアと2GB RAMしかなく、多くのワークロードがそのマシンに収まらなかった
- 現在のAWSの標準インスタンスは、物理サーバーベースで64コアと256GB RAMを備えている
- 2006年初期のEC2インスタンスに比べ、RAMは桁違いに増えた
- メモリ最適化インスタンスに追加料金を払えば、RAMをさらに桁違いに増やせる
- 24TB RAMや445 CPUコア以上を本当に必要とするワークロードがどれほどあるのか、という問いが生まれる
- クラウドでは、大きなVMのコストはコンピュート性能に応じてほぼ線形に増える
- サーバー全体を使うVMは、サーバーの1/8を使うVMより8倍高いだけである
- かつてのDremel論文の3,000並列ノードのベンチマークに近い性能を、今日では単一ノードで得られると考えられる
データは資産ではなく負債になり得る
- Big Dataのもう一つの定義は、「何を捨てるか判断するコストより、データをそのまま保管し続けるコストの方が低い状態」である
- 多くの組織のデータレイクは、必要だからではなく削除してこなかったために大きくなった巨大な沼に近い
- 何が入っているのか分からない
- 整理しても安全かどうか分からない
- データ保管コストは、物理的なバイト保存コストより大きい
- GDPRやCCPAのような規制では、特定データの利用を追跡しなければならない
- 一部のデータは一定期間内に削除しなければならない
- データレイクのparquetファイルに電話番号が長く残りすぎると、法的要件に違反する可能性がある
- 古いデータは訴訟でも組織に不利に働くことがある
- 多くの組織が潜在的責任を減らすためメール保存期間を制限するのと同様に、データウェアハウスのデータも不利な証拠になり得る
- 5年前のログがコードのセキュリティバグやSLA未達を示しているなら、長く保管するほど法的露出期間が延びる可能性がある
- データもコードのbit rotのように意味が風化することがある
- 特殊なフィールドの正確な意味を人々が忘れてしまうことがある
- 過去のデータバグが記憶から消えることがある
- たとえば短期間だけすべてのcustomer idがnullに設定されていたり、巨大な不正取引によって2017年第3四半期の実績が実際より良く見えていたかもしれない
- 古い期間のデータを扱うビジネスロジックは、「2019年以前はrevenue、2019〜2021年はrevenue_usd、2022年以降はrevenue_usd_audited」のように次第に複雑化することがある
自分がBig Data 1%なのかを点検する
- Big Dataは実際に存在するが、大半の人は心配する必要がないかもしれない
- 自分がBig Data One-Percenterかどうかを判断するには、次の質問を投げかけられる
- 本当に膨大な量のデータを生成しているか
- そうだとして、本当に一度に膨大な量のデータを使う必要があるか
- そうだとして、本当に単一マシンに収まらないほど大きいか
- そうだとして、単にデータを積み上げているだけではないか
- そうだとして、要約した方がよいのではないか
- これらの質問のどれか一つでも「いいえ」なら、実際に持っているデータ規模に合った新世代のデータツールの候補になり得る
- 関連例として、現代的な BigQuery代替 が言及されている
- 組織は、いつか持つかもしれないデータ規模に怯えるのではなく、実際に持っているデータ規模と実際のクエリパターンに合わせて、ツールと保管ポリシーを選ぶべきである
1件のコメント
Hacker Newsの意見
以前の職場でデータサイエンティストを採用するときによく使っていたひっかけ質問が、「最大6TiBのデータがあるという要件なら、どんなスタック／アーキテクチャを作るか」だった
BigQueryやHadoopのような大げさな話を聞きながら、ハードウェア／ソフトウェア／ライセンス費用まで尋ねると、年間数万ドルの見積もりが出てくることが多かった
最終的に合格したのは、6TiBが部屋にいる6人のスマートフォンに分けて入れられる量であり、199ドルのエンタープライズ向けHDDが1台、冗長性のためなら3台あれば十分で、CSVとしてメモリに何度も載せて
awkスクリプトでも処理できる、と理解していた人だった自分もハンマーを覚えると何でも釘に見えてしまう誤りに陥りやすいが、採用で「本物のビッグデータ」の規模感が分かっていないことは不採用理由だった
その答えだけで、あらゆる仕事を過剰設計すると結論づけるより、面接官が優位にいる人工的な状況でひっかけ質問に引っかかった、と見るほうが正しい
最近、同じくらいの年次と経験の面接官と技術面接をしたが、回答をしくじり、面接官は私の悪い回答に対して決めつけるような態度を取った。役割が逆なら、私のほうが詳しいテーマで彼を同じように困らせることもできただろう
面接官なら、優位な立場を乱用しないように特に注意すべきだ。会社にとっても逆効果だし、目の前の人にとっても良いことではない
「コンサルティングサービス: あなたがビッグデータ問題を持ってきたら、私が『あなたのデータセットはRAMに収まります』と言い、あなたは50万ドルを節約した対価として私に1万ドルを払う」
数年前、あるディレクターがHadoop、APIゲートウェイ、複数の開発者、年間数十万ドルの費用でIT部門が作ったシステムを見せてくれたのだが、現在の規模と予測可能な将来の規模なら、彼のノートPCに挿したUSBドライブといくつかのPythonスクリプトでも十分に動かせると言ったところ、非常に不機嫌になり、その後そのプロジェクトに二度と関われなくなった
会社に蔓延する虚勢の循環の一部だと思う。「自分たちは単純なことをしている」と認められない構造なのだ
awkを求めていないし、仮に求めていたとしても、パーティショニングや列指向ストレージなしに6TBを毎クエリごとに単一CPUでなめるのは常に遅いこうした用途には、たいていBigQueryが悪くなかった。コンソールのインターフェイスはアドホック分析には十分で、MetabaseやTableauのようなツールも多く接続できる
適切にパーティショニングすればコストも過大ではなく、問題になればロールアップテーブルを追加すればよい
.parquetファイルは完全に過小評価されており、いまだにこの形式を知らない人が多いCSVと違ってデータ型を保持し、CSVより10倍小さいので6TBが600GBになり、読み取りは50倍速い。Apache Foundationの公開標準でもある
CSVのように簡単に中身をのぞけるわけではないが、そのトレードオフには価値がある。CSVをダウンロード提供しているところは、どこでも
.parquetも併せて提供してほしい全体として記事の多くの部分に同意するが、いくつか留保がある。第一に、MongoDBは基準点として不適切だ。MongoDBがやることでPostgreSQLのほうがうまくできないものを見たことがないし、ビッグデータの解決策はNoSQL/MongoDBではなく、普通は列指向データベース、MapReduce、Cassandraのようなものだ
第二に、成功を計画しなければならない。企業の95%はユニコーンになれないが、残りの5%を目指すなら、備えなしには到達できない。顧客が5人の時点でスケーラビリティを考慮して設計する理由は、指数関数的成長の瞬間が来たときにそれをつかむためだ
ただし核心的な教訓は正しい。ほとんどのデータは大きくなく、世界中の全員に関するデータでさえ100ドルのChromebookに収まる。ほとんどのデータはめったに参照されず、クエリも小さい。ビッグデータ作業の第一歩は、テラバイトを実際に必要なGB、MB、時にはKB規模に減らすことである場合が多い。規制によってデータコストも大きくなっている
人々は計画を立てるだけでなく、たいてい実装までしてしまう。次の3カ月を計画するほうが、はるかに俊敏で生産的でいられる。実行できなければユニコーンにはなれない
セカンドシステム症候群と生存者バイアスの組み合わせのように思える。良いMVPの混乱を片づけた人たちは「昔これをやっておくべきだった」と不満を言うが、実際に前もって計画し設計していた会社は生き残っていないので、不満の対象にすらならない
残りの内容にはほぼすべて同意するが、この部分は間違っているように見えたので、流すことができなかった
スタートアップのランウェイは限られており、エンジニアが数年後になってようやく報われることにお金を使っているなら、その時点が来る前に失敗する確率を高めているだけだ
製品がそこまで強いトラクションを得るのは、通常、ユーザーベースの存在とニーズから生まれる複合効果によるものだ。成長中に新規ユーザー追加でつまずいても、既存ユーザーが以前の製品に戻ったり、別のところへ移ったりする可能性は低い
昔のTwitterでは毎日fail whaleを見るのが日常だったが、ほとんどの人は離れず、よりよくスケールする代替サービスへの大規模移動も起きなかった。そうした指数関数的成長を経験する製品自体がまれで、その過程でスケーリングに苦労し可用性が悪くなるのはよくあることだ。スケールできなかったために失敗した指数関数的成長製品が、実際に何だったのか気になる
「ビッグデータ」が流行していたころ、Large Hadron Colliderの研究者だった。私たちにとっては全データを分析することが意味のあるユースケースで、頻度主義統計ではデータは多いほどよかった。
ところが世界中のスーパーコンピュータネットワークを使っていても、巨大なジョブが終わるのを待つより、高速なローカルストレージのほうがよいと分かった。結局、大学院生は全員、分析の柔軟性を大きく損なわずに、関連データをちょうど1〜5TBまで絞り込んだ。
ここにはAmdahlのスケーリング則に匹敵する、利便性の法則のようなものがあるように思う。
これは数学というより、人間の限界に近いように見える。私たちが活用できる柔軟性には明確な上限がある。新しい種類の分析をもっと簡単に実行する方法が生まれれば変わるだろうが、やりたいことの数に対して対数的に増えるように思う。
人々は毎年少しずつ良くする便利な方法を見つけるのが非常に得意だが、どんなアイデアにも実行には最低限の時間が必要だ。
記憶が正しければ、その装置の待ち行列は安価なハードウェアでジョブを走らせる時間と同じくらい、あるいはそれ以上に長く、Beowulfのような大規模並列処理システムはそうした取り組みから生まれた。
保存するデータベースと計算の規模を小さくすることは、顧客の月額請求額を最小化する優れた方法だ。
私の経験では、データは指数関数的に増え続けるが、情報量はそうは増えない。
金融では、望めば1つの時系列あたり1日1億個のデータポイントを簡単に得られるし、数千の時系列を扱うこともできる。だがそのサンプリング速度と時系列の数は、たいてい99.99%が重複している。固有値がだいたい10次元以降、ときにはもっと早い時点でほぼゼロに落ちるからだ。
決して参照しないティックデータをペタバイト単位で保存する理由はほとんどない。多くの場合、収集時点で思い切った損失ありの次元削減を行い、最初の数個の主成分と外れ値だけを保存し、以前は無視できた新しい要因が重要になっていないか固有値の安定性を監視するほうが、はるかに合理的だ。
結果としてデータセットははるかに小さく扱いやすくなり、実際に使えるため、むしろ洞察を与えてくれることが多い。
面白そうに聞こえるが、私にとってはまったく新しいテーマだ。
「ビッグデータ」のおかしな点は、ソフトウェアのレベルで最も基本的で明白な最適化すら避けさせる、ねじれたインセンティブがあったことだ。ハードウェア要件が大きいほど、自分がどれほどすごいかを証明できたからだ。
たとえば「ボス、データセット全体を計算する代わりにサンプルを読めば、このレポートの平均値はノートPCだけで計算できます」と言うと、ボスは「サンプルとはどういう意味だ？ その数学者/エンジニアみたいな戯言で何をほのめかしているんだ？ まさか私が何百万ドルも無駄にしたと言いたいわけではないだろうな？」と受け取る、という具合だ。
ビッグデータに関する営業上の誇張とノイズ、そして誰のデータが十分に大きいかを競う見栄の張り合いが、しばらく非常に激しかった。
長い間、1台のマシンで64GBを超えるメモリを得るのは非常に難しく、ハードな上限があると実装の複雑さは急速に跳ね上がる。
データが少し大きくなっただけで50回に1回失敗するプロセスは、非常に破壊的だ。チームはこうした定期cronジョブを何十個も回しており、それぞれが頻繁に壊れると、オンコールで断片を切り分けるだけの仕事になってしまう。
HadoopとMapReduceは極端に効率的ではなかったが、正しく使えば悪くなく、安定して動くことのほうがはるかに重要だった。つまり、誰も信頼も保守もできず、毎週木曜日に奇妙なセグメンテーションフォルトで死ぬビット最適化されたC++コードよりはましだった。
今なら単にSnowflakeを使うだろうが、当時としては合理的なツールだった。
この記事は完全に正確というわけではない。もともとビッグデータは3つの次元で定義されていた：容量、速度、多様性
容量はおおむね解決され、速度も解決されたが高価だ。多様性はまだ解決されていない
今日のビッグデータは「ストレージやコンピューティングが足りない」というより、「これを統合し理解する認知能力が足りない」に近い
関連する講演も強くおすすめする。ほとんどはYouTubeにある
[1] https://www.youtube.com/watch?v=KRcecxdGxvQ
[2] https://amturing.acm.org/award_winners/stonebraker_1172121.c...
各航空機にはレーダーシステムが1つあり、その中には20TiBの16ドライブRAID-0 SSDストレージ装置が8台ある。通常RAIDを満杯にはしないので、1日あたり約176TiB、2週間で7回飛行すると1バッチあたり1.2PiB、年間では約7.2PiBを生成する
飛行の合間に1日休まなければならない理由は、エプロン横の格納庫の隅に適当に押し込んだストレージサーバーへ、光ファイバー経由でデータをダウンロードしなければならないからだ。その後、安全のために2台目のサーバーへ複製し、任務が終わるとすべて本部へ送って保存・処理する
このデータには価値があるが、「数十億ドル」級ではない。資源採掘、地図作成、環境および測地研究などに使われ、2008年以降すべてのバイトを保管してきた。新しいアルゴリズムが出れば、古いデータを新しい標準で再処理できるからだ
ファイルは800GiB〜2TiB単位でGPU処理サーバーへストリーミングし、圧縮は効かない。捕捉している大半である宇宙マイクロ波背景放射はかなりランダムだからだ。かつてテープに書けばインフラを半分に減らせるだろうと勘違いしたことがあるが、テープ容量は、0だけでできたギガバイト級テキストファイルを保存するときのように計算されているようだった
GPUも遅く、CPUも遅く、PCIeバスも遅く、RAMも遅く、私のタイピング速度も遅い。すべてが常にもっと速くならなければならない
すべてが遅すぎ、難しすぎ、小さすぎる。ハードディスクは小さすぎるし、Linuxカーネルのチューニングや処理クラスタへの高速で安定したネットワーク設定は難しすぎる。単なる内部動作の変更であるカーネル／パッケージ更新でさえ、私たちだけが遭遇するような形でシステムを壊す
デフォルト設定はRAMが希少だという幻想の中にあり、ネットワーク作業でメモリを節約するようになっている。しかしファイルサーバーにはRAMが0.5TBあるのだから、ネットワークとファイルシステムを高速化するために全部使ってほしい。結局、ネットワークスタックのドキュメントを6時間読み、入出力を2024年水準の常識に引き上げなければならない
おそらく地球上のほとんどの人よりも
sysctl.confに詳しいと思う自称ビッグデータ向けの分散永続オブジェクトストレージは、私たちのワークロードでは完全に崩壊するか、数億ドルかかる。オブジェクトサイズがだいたい1TBだと言うと、分散ファイルシステムの営業担当者たちは返事をしなくなる。あるベンダーは要件を読んで、情報機関顧客担当者につないできたこともある。私はNSAではないし、NSAの予算もない
ときどきBloombergでクラウド記事を読んだMBAやPMPが、オンプレミスのデータセンター費用を見てAWSやAzureへの移行を尋ねてくるが、金額と時間の両方の数字を見せると、吐きそうな顔をして話題を変える
そのうえベンダーは皆AI／クラウドの流行に乗って、私たちに合う製品ラインを廃止している。今では顧客データを掘り起こして広告を見せようとするヘッジファンドやAIスタートアップと、GPUをめぐって競争しなければならない
ストレージとコンピューティングが足りず、手元にあるストレージとコンピューティングも遅すぎる。DPU/IPUは興味深いが、オブジェクトがSQLデータベースクエリや圧縮ストリーミング動画の断片より大きくなると、すぐ限界にぶつかる
以前、1日に20GBの分析データを作る会社で働いていたが、おそらく私が扱う中で最大のデータだったと思う
ジュニアプロジェクトとして、バッチ集計とリアルタイム集計を行うデータ処理ジョブを書き、結果をAzureのParquet blobに保存していた
上司は、何を保持し何を捨てるかを議論するために定期的にステークホルダー会議を開かせるほど賢く、優れたアルゴリズムのおかげでデータを1日あたり約200MBに圧縮できた
直近2か月分はSQL Serverに載せ、直近2年分はさらに集計して別のサーバーに入れ、会社全体がExcelで妥当な時間内にクエリできた。元のビッグデータは、いつか必要になった場合に備えてテープストレージで朽ちている
上司は悪いマネージャーだったがデータには詳しく、振り返ると多くのことを正しくやっており、私も多くを学んだ
何年にもわたり、「大きな」データツールやパイプラインの過剰エンジニアリングを見てきた。多くのユースケースではデータウェアハウスやデータレイクはGBまたは1桁TBの範囲なので、そこそこのEC2インスタンスでDuckDBを動かすような形で、はるかに単純化できる
私の経験では、こうすると他のシステムがクエリ実行を開始する前に結果が出る。Athenaのことを言っている
最近はブラウザでも多くのクエリを実行できると思っているので、DuckDB WASM（https://github.com/duckdb/duckdb-wasm）とperspective.js（https://github.com/finos/perspective）の助けを借りて、https://sql-workbench.com/を作った
その流行サイクルは結局「死の高原」に到達したようだ。流行に極端に振り回されるこの業界では、珍しくない結末だ
AIもすべてのデータを使い、その意味を見つけ出すために魔法のようなニューラルネットワークを付ける
個人的には、ビッグデータの主な原動力は会社創業者たちのエゴだったと思う。自分たちの会社は当然、爆発的に成長して地球規模の成功を収めるはずだから、その規模に合わせて設計すべきだ、というわけだ。
製品がシリーズCに到達する前なら SQLite DB 1つで十分なのに、こうした過ちを犯すのは悲劇的だ。すべてのエネルギーは、まだスケールではなく製品に集中すべきだ。
Hadoop は Google にあったものに着想を得て始まり、Oracle より安く、より良い方法でデータを扱おうとする世界中の企業で人気を得た。
Spark は Hive/Pig などの複雑さへの解決策として登場し、企業が信頼できるデータパイプラインを作れるようになると、その上に AI を載せられるようになった。
リンクのクリック、メッセージ送信、購入のように、意図的な人間の行動から生成されるデータモデルは一般に小さい。人間の数と、人間が1秒あたりに生成できる意図的なイベント数には限界があるからだ。
一方で機械が生成するデータモデルは、速度と容量が何桁も大きくなり得るし、データモデルのサイズにも境界がない。こうしたデータは、人間の意図的なデータモデルでは得られない世界についての多くの事実を明らかにしてくれるため、最も興味深く、過小活用されているデータである場合が多い。