Skip to main content

ビッグデータを支える技術

書籍リンク​

読んだ時期​

  • 2023-06-01 頃

目的​

  • 「分散処理」周りにどんな技術があるのか、の概要を確認したくて読んだ

全体的な感想​

  • 分かったような分かってないような、みたいな気持ちにだけなった（目的通り）
  • numpy, pandas などの python ライブラリが使われるのはこういう文脈なのね、と分かったり
  • あとは具体的に触ることがあってから考えよう
  • 手を動かしてみたければ 7 章をやってみるのが良さそう

〜〜

以下は読んだとこメモ。関連して調べたことも追記

データパイプライン​

  • ビッグデータはまず最初に「データレイク」へと格納され
  • そこから一部のデータを「データマート」として取り出します

というのが「データパイプライン」の流れ

Hadoop と NoSQL​

  • Hadoop と NoSQL の関係
    • 「NoSQL データベースに書き込み、Hadoop で分散処理する」
  • Hadoop
    • MapReduce を参考に作られている
      • Google で開発された分散処理のフレームワーク
    • Hive
      • SQL のようなクエリ言語を Hadoop で実行するためのソフトウェア
  • NoSQL データベース
    • データの種類ごとの分類
      • キーバリューストア (KVS)
      • ドキュメントストア (JSONなど構造を持ったもの)
      • ワイドカラムストア
    • 代表的なアプリ
      • Mong DB : ドキュメントストア
      • Cassandra : ワイドカラムストア
      • Redis : キーバリューストア

ビッグデータとデータウェアハウス​

  • エンタープライズデータウェアハウス (EDW)
  • データウェアハウス

↑

これ自体はもともとあったが、Hadoop で分散処理するような文脈で、
「ビッグデータ」というキーワードが使われるようになった

・・・

多くのデータウェアハウスは製品として安定した性能を提供するために、
「アプライアンス」といって、抱き合わせて提供される。

データの柔軟性を考えて、以下のような使い分けがされたりするそうだ。

  • 増え続けるデータは Hadoop に任せる
  • 比較的小さなデータ、重要なデータなどは データウェアハウスに入れる

データ処理のためのクラウドサービス​

  • クラウド向け Hadoop
    • Amazon Elastic MapReduce
    • Azure HDInsight
  • データウェアハウス
    • Google BigQuery : 共有リソース
    • Amazon Redshift : 占有リソース

Hadoop 後継​

  • Hadoop + Hive の問題
    • 遅い
    • 汎用的だが保守管理が難しい
  • Hive 代替 : クエリエンジン ← SQL がが使えれば良いケース
    • Impala : Hive 互換
    • Presto : S3 + RDB のようにまたがって使いたいケース
      • Amazon Athena で採用
  • Hadoop (MapReduce) 代替 : 分散データ処理
    • Apache Spark
    • Google Cloud Dataflow

HTAP​

HTAP : Hybrid Transactional/Analytical Processing

  • OLTP : トランザクション処理 ← RDB の役割
  • OLAP : 分析処理 ← DWH の役割

T と A のハイブリッドということか。

OL は オンラインの略

Spark や Cloud Dataflow は、RDB と データウェアハウスの橋渡しをする、というような位置づけ・・？

RDBMS の活用​

  • Amazon Aurora
    • MySQL や PostgreSQL のストレージ部分を分散する

データパイプライン 再び​

パイプラインの各段階

  • データソース
    • 中身はローデータ (raw data, 生データ)
    • 必要に応じて「データレイク」に格納
      • 生データを形式問わず一元的に格納する場所
  • データウェアハウス
    • 構造化・整形されたデータを保存し、分析に適した形にする
  • データマート
    • ユースケースごとに抽出・整形されたサブセット
    • 多くの場合、SQL でアクセスされる

ETL ツールで「データソース」→「データウェアハウス」→「データマート」と次のフローにつなげる

  • ETL ツールは下記の処理をするツール
    • Extract (抽出)
    • Transform (変換)
    • Load (格納)
  • ETL ツールの具体例
    • AWS Glue
    • Google Cloud Dataflow
    • ...など

アドホック分析​

あらかじめ定義されたレポートやダッシュボードではなく、
その場の目的・仮説に応じて都度実行する分析。

→ Python, R と言ったスクリプト言語がよく使われる

Python が使われる理由

  • Pythonは汎用のスクリプト言語
    • 幅広い分野のライブラリが入手可
    • 特に以下のようなことでデータの前処理するのに向いている
      • 外部システムのAPIを呼び出す
      • 複雑な文字列処理
  • Python は科学技術計算の分野で長年使われてきた
    • 数値計算 (NumPy や SciPy など) のライブラリが充実
    • 機械学習のフレームワークも充実
    • データ処理の「データフレーム」ライブラリ (pandas) も使用可能
      • 「データフレーム」自体は R の機能を Python で実現したもの

データフレーム​

表形式のデータを抽象化したオブジェクトのこと

KPI モニタリング​

  • KPI : Key Performance Indiator
    • 業界ごとの、重要な指標のこと
    • 何でも取り入れようとすると多くなりがちだから、主要なキーに絞るという意図か

例：

  • Web サービスの KPI
    • DAU (Daily Active User)
    • 継続率 (Customer Retention)
    • ARPPU (Average Revenue Per Paid User)
  • オンライン広告の KPI
    • CTR (Click Through Rate)
    • CPC (Cost Per Click)
    • CPA (Cost Per Acquisition)

関連用語

  • KPI モニタリングでは、「行動可能(actionable)」か、というのが重視されるそう
  • 客観的なデータに基づいて次の action を判断 → 「データドリブン」な意思決定

クロス集計​

  • クロステーブル (matrix)
    • これを k1 x k2 でセルの値が v のテーブルだとすると
  • トランザクションテーブル
    • これは (k1, k2, v) が1行の表
  • ピボットテーブル
    • これは「トランザクションテーブル」から「クロステーブル」に変換する操作のこと
    • または、変換されて「クロステーブル」状態になった表のこと
    • 逆のことはアンピボットだよ
  • クロス集計
    • カテゴリA × カテゴリB の出現数・合計・平均などを集計するもの
    • これは「トランザクションテーブル」から group by 集計しつつ、「クロステーブル」に変換するような操作のこと
    • ピボットと似ているが、ピボットは並べ替えてるだけ

pandas でのクロス集計

  • pd.merge(df1, df2, on='key1') のように merge 関数で集計後
  • pivot_table() でクロステーブル形式に出力
  • ちなみに アンピボットは melt()

SQL でのクロス集計

  • case などを使ってゴリゴリ。そこそこ面倒
    • 詳細は略
  • トランザクションテーブルを「縦持ち」、クロステーブルを「横持ち」というようだ
    • 「横持ち」といったら転置されたものを想像するが、そうではなさそう

実行時間のイメージ​

各段階で

  • データレイク → データマート
    • 数分から数時間
  • データマート → 可視化ツール
    • 数秒

関連用語

  • レイテンシ : 処理の応答にかかる時間(の遅延)のこと
  • スループット : 一定時間に処理できるデータの総量

目安

  • メモリに乗り切るデータ量 → RDB で完結
  • それを超えると ディスク I/O が発生する

高速化のための手法（それぞれ用語だけ）

  • 圧縮と分散
    • MPP (Massively Parallel Processing)
      • Amazon RedShift, Google BigQuery
  • データを集計に適した形に変換
    • 列指向ストレージ (カラムナーデータベース)
      • 同じ列のデータを圧縮することができる
      • 行指向ストレージの利点は失われる。つまり行追加/削除や行単位での検索(インデックスによる効率化)での速度を犠牲にする

行指向と列指向について

  • 列指向 → 分析向き
  • 行指向 → トランザクション向き

Jupyter Notebook​

  • Jupyter Notebook : 「分析の過程をあとから再現できるようにノートを留めておく」というような作業をするためのツール。環境？
  • Jupyter の名前の由来は Julia + Python + R で、Julia 言語も使用可
  • Google Colab というサービスを使うとクラウドで実行できる？
  • 可視化ライブラリ matplotlib
  • ダッシュボードツール Metabase, Kibana, Google データポータル
    • Metabase X-ray によるダッシュボード 自動生成
    • Kibana : JavaScript製。 Elasticsearch (全文検索に対応したデータストア)のフロントエンド
    • Google データポータル: オンラインで使える可視化サービス

関連用語が分からない過ぎて、全くイメージわかない。 気が向いたら触ってみよう。

OLAP キューブ​

  • 2 次元のデータ ＝ クロステーブルで表現可
  • 多次元のデータ ＝ OLAP キューブ

OLAP キューブ用のクエリ言語 (MDX)

関連の用語

  • ファクトテーブル : トランザクションのように事実が記録されたもの
  • ディメンションテーブル : ファクトテーブルから参照されるマスタデータなど
  • 非正規化
  • スタースキーマ
  • 多次元モデルではカラムをディメンションとメジャーとに分類

データ形式と 列指向DB​

データ形式​

  • 構造化データ
    • スキーマが明確に定義されたデータ
    • RDB のテーブル定義のこと
  • 非構造化データ
    • テキストデータなど
    • CSV, JSON, XML など書式が決まってるものは「スキーマレスデータ」と呼び分けている

データ形式と列指向DB​

  • Apache ORC
    • 構造化データを扱う
  • Apache Parquet
    • スキーマレスに近いデータ構造を扱う
    • データ読み込みに計算リソースが消費される
      • そこで Hadoop, Spark の分散処理が活用される

Hadoop​

Hadoop は、分散システムを構成する多数のソフトウェアからなる集合体

基本コンポーネント​

  • 分散ファイルシステム : HDFS
  • リソースマネージャ : YARN
  • 分散データ処理 : MapReduce

YARN​

アプリケーションが使用するCPUコアやメモリをコンテナと呼ばれる単位で管理する

→ アプリケーションごとに割り当てを管理して負荷を見て分散する

MapReduce​

任意の Java プログラムを走らせる。

  • 大きなデータ読み込むのに適しているが
  • 小さなプログラムを実行するにはオーバーヘッドが大きすぎる

Hive on Tez という技術で高速化を目指しているとか

図を見ると、以下のようにやってるな。

入力データ → Map → 一時データ → Reduce → 中間データ → Map ...

ああ、map でデータ小分けして、そのデータで分散処理させつつ、結果を reduce で集計、みたいなことか・・？

Spark​

大量のメモリを活用した高速なデータ処理の基盤

  • MapReduce はメモリが足りずディスクI/Oを使う前提だった
  • 使えるメモリが増えてきて、できるだけメモリで処理を完結させるためのものが Spark

Spark は分散データ処理 (MapReduce) を置き換えるもの。（Hadoop を置き換えるものではない）

→ では枠組みだけ MapReduce 残して、MapReduce から Spark を使うようなイメージか？と思ったがそういうことではないらしい

→ そこで使われるのが「データフロー」のためのフレームワークということ？

→ Spark, Google Cloud Dataflow が その役割をするので、結局、Hadoop を使うことはない、ということになる？

※ AWS で完結させる場合は こんな感じらしい

[データ] → S3 → AWS Glue → Athena / Redshift → QuickSight

※ Python で完結させる場合は、Prefect + Dask?

MapReduce に代わる新しいフレームワーク​

DAG (diarected acyclic graph) :
新しいフレームワークに共通するデータ構造

「有向非循環グラフ」という

  • ノードとノードが矢印で結ばれる (有向)
  • 矢印をいくら辿っても同じノードには戻らない (非循環)

システムの内部的な表現なので、利用者が意識することはないそうだ。

遅延評価

5章​

→ いったん飛ばす

7章​

→ 手を動かしてみる・・？

Last updated on
以下広告