irisuinwl’s diary

サークル不思議(略)入巣次元の、数学や技術的なことを書きます。

chatgptをかなり使っている話、`Big Data is Dead`をchatgpt使って読んでみたり

最近、chatgpt を活用してます。

情報検索、要約、変換といったことがchatで出来て、かなり生活が変わったなと感じてます。

具体的なchatgptの活用方法として、以下を行っています。

  • プログラミングの支援:
    • 「~~したいんだけどクエリ書いてよ」とか「変数名悩んでるから教えてよ」とか「~~したいけど、実装例教えて欲しい」とか
  • 文書の要約
    • 読みたい論文の各節を要約してもらい、概観を掴む
  • 口調変換

この記事では、一例として、ChatGPTとDeepLを使って、最近話題の Big Data is Dead を読んでみました。

所感としては、ただ文章をコピペするだけで内容が把握できるのでかなり体験は良いです。

10分くらいで概観を抑えるならこの方法は有効なんじゃないかなと思いました。

ただし、chatgptの出力の信頼性があるかは不明なので、正確に把握したいならば、ちゃんと元の文章を読み、根拠となる箇所を抜粋するなどの工夫が必要だなと感じました。

(AIシステムにおける責任を誰が持つか、人間が使う上での説明性をどうするかという話 e.g. AIの意思決定で人死んだら不味いだろう)

以下に Big Data is Dead をchatgptやDeepLで要約と翻訳したアウトプットを貼ります。

Big Data is Dead

About This Post

この記事では、ビッグデータの時代は終わったと主張します。ビッグデータの時代は終わりましたが、これからはデータの大きさを気にするのはやめて、より良い意思決定をするためにデータをどう活用するかに集中しましょう。

全体の要約

  • ビッグデータ」に対するハイプにもかかわらず、ほとんどの組織のデータサイズは中程度である。
  • ストレージとコンピュートが分離されたクラウドデータプラットフォームでは、必要なコンピュート量が少なくて済む場合がある。
  • アナリティクスワークロードで処理されるデータの量は一般的に想像されているよりも遥かに小さい。
  • データ処理されるほとんどのデータは24時間以内に生成されたものであり、データストレージの年齢パターンは比較的フラットである。
  • 古いデータを保存しておくことは、コストアップにつながり、フィールドの意味を忘れたり、過去の問題が記憶から薄れたりする可能性があるため、重要なことは、なぜ古いデータを保存しているのか、集約して保存する必要があるのか、それとも単にデータを溜め込んでいるだけなのかを理解することである。

MOST PEOPLE DON’T HAVE THAT MUCH DATA

ビッグデータ」に対するハイプにもかかわらず、ほとんどの組織のデータサイズは中程度であると、SingleStoreの記事に記載されています。BigQueryの顧客データサイズを分析すると、多くは合計データストレージで1テラバイト以下でした。また、サービスを重く利用している顧客の中でも、中央値のデータストレージサイズは100GB未満でした。業界アナリストも、データウェアハウスの適正サイズは100GB程度であると指摘しています。記事では、中程度のビジネスが頻繁に顧客注文を受け取る場合やマーケティングデータベースを持つ場合でも、生成されるデータ量は比較的小さく、合理的なスケーリング前提では膨大なデータセットを蓄積することは困難であることを説明しています。

THE STORAGE BIAS IN SEPARATION OF STORAGE AND COMPUTE

クラウドデータプラットフォームでは、ストレージとコンピュートが分離されており、ユーザーは単一のフォームファクターに縛られることはありません。ただし、データサイズはコンピュートサイズよりもはるかに速く増加するため、多くの場合、ストレージとコンピュートのスケールを同じくする必要はありません。ビッグデータに対する誤解が生じることがあるが、それはストレージサイズがコンピュートサイズよりも優先される傾向があるためである。このバイアスは、スケーラブルなオブジェクトストアを使用することで、必要なコンピュート量が少なくて済む場合があることを意味する。

WORKLOAD SIZES ARE SMALLER THAN OVERALL DATA SIZES

この記事は、アナリティクスワークロードで処理されるデータの量は一般的に想像されているよりも遥かに小さいことを示唆している。ダッシュボードなどは通常、集計されたデータから作成されるため、大きなテーブルは選択的にクエリされる。多くの分析データベースでは、列プロジェクション、分割プルーニング、セグメント削減など、クエリ時に少ないIOを実行するためのテクニックが利用可能であり、これらはコスト削減とレイテンシー低減につながる。さらに、データ量を減らすことは、コスト削減のために強い経済的インセンティブがあるということが強調されている。

MOST DATA IS RARELY QUERIED

データ処理されるほとんどのデータは24時間以内に生成されたものであり、一週間経過するとクエリされる確率は20倍減少し、1か月経過するとほとんどアクセスされなくなる。一方、データストレージの年齢パターンは比較的フラットであり、最近の年だけでもデータの99%がアクセスされることがある。そのため、データ処理に必要なワーキングセットサイズは、想定よりも小さい可能性がある。例えば、10年分のペタバイトテーブルがある場合でも、現在の日付よりも古いデータにアクセスすることはほとんどなく、圧縮後50GB未満で済む場合がある。

THE BIG DATA FRONTIER KEEPS RECEDING

ビッグデータ」という言葉は、「単一のマシンに収まらないもの」と定義されることがある。しかし、この定義に基づくと、そのようなワークロードの数は年々減少している。今日の標準的なAWSインスタンスには、64コアと256GBのRAMを備えた物理サーバーが使用されており、かつてほど高価ではない。現在は、単一ノードで過去の大規模クラスターのパフォーマンスを実現できるようになってきている。

DATA IS A LIABILITY

"ビッグデータ "とは、「データを維持するためのコストが、何を捨てるかを考えるコストよりも低い場合」とも定義できます。古いデータを保存しておくと、規制上の要件により、ある種のデータの追跡や削除が必要になったり、そのデータが訴訟で不利に使われたりする可能性があり、コストアップにつながります。また、古いデータは、フィールドの正確な意味を忘れてしまう「ビット腐敗」や、過去に起きたデータの問題が記憶から薄れている可能性もあります。なぜ古いデータを保存しているのか、集約して保存する必要があるのか、それとも単にデータを溜め込んでいるだけなのかを理解することが重要です。

ARE YOU IN THE BIG DATA ONE PERCENT?

ビッグデータは現実のものですが、ほとんどの人は心配する必要はないかもしれません。自分が「ビッグデータ・ワンパーセント」であるかどうかを把握するための質問もあります。

  • 本当に膨大な量のデータを生成しているのでしょうか?
  • もしそうなら、本当に一度に大量のデータを使う必要があるのだろうか?
  • もしそうなら、そのデータは本当に1台のマシンに収まりきらないほど大きいのでしょうか?
  • もしそうなら、本当にデータを溜め込んでいないのか?
  • もしそうなら、本当に要約した方がいいのでしょうか?