データ分析基盤入門（基本編）勉強ログ①

データ基盤初心者がデータ基盤用語を勉強してまとめてみた

AIやデータサイエンスを専門としていますが、仕事でデータ基盤系の知識が必要になったので、
斎藤友樹さん著書の「改訂新版　エンジニアのためのデータ分析基盤入門　基本編」をもとに勉強してみました。
用語をまとめているだけですが、同じように勉強したい方の参考になれば幸いです。
※本記事は0~2章の一部をまとめています

筆者のバックグラウンド

• AWSを入門で触ったことがある（Dynamo DBなど）
• RDBを触ったことがある
• pythonでテーブル処理をしたことがある
• API/MCPの知識あり
• テスト肯定やCI/CDについて知識あり

第0章　［速習］データ分析基盤と周辺知識　データ分析基盤入門プロローグ

0.1

• SoR(System of Records)：基本的なデータの蓄積や管理を担当するシステム
• SoE(System of Engagement)：組織と顧客やステークホルダーとの対話やコミュニケーションを強化するためのシステム(顧客の閲覧履歴など）
• SoI(System of Insight/Intelligence)：SoR/SoEで発生したデータを活用した新たな発見や、SoR/SoEと連携してプロダクトの最適化をサポートするシステム

関係性について（上記画像左側から）

• コレクティングレイヤー：主にSoR/SoEからデータを収集
• プロセシングレイヤー：SoR/SoEからデータを適切に処理
• ストレージレイヤー：SoR/SoEからデータを適切に保存
• アセスレイヤー：データサイエンティストやデータアナリストが主にSoE/SoRなどを参照する
• アクション：得られたインサイトから価値提供を助言する
• フィードバックループ：データ提供によって得られたデータを分液基盤に取り込み巡回利用する

本書では、SoR/SoEを便宜上「スモールデータシステム」や「データプロダクト」と呼ぶこともある。

0.2

データベースとストレージ

• オブジェクトストレージ：SoR/SoE/SoI全てにおいてログの保管から処理に至るまでのデータの保管を担当する要。保存容量が実質無制限で安価なため、raw dataや加工後のデータを格納する場所（データレイクやDWHなど）としても利用される。
• RDB：テーブルという、行と列からできている表形式のデータの集合体。データ分析基盤においては、SoRやSoE内のRDBからデータをETL(Extract/Transform/Load)を行い、オブジェクトストレージに格納するという流れが頻繁に行われる。
• KVS（Key-Value Store, No SQL)：データをキーとバリューの形でデータを保存するデータベース。ドキュメント型、グラフ型、キーバリュー型などあるが、本書ではドキュメント型に絞る。データの保存はバリューだけであり、他のデータとリレーションは作らない。シンプルなデータモデルのため、高速なデータの読み書きと、スケールアウトによるスケーラビリティの高さが特徴。例は、MongoDB、DynamoDB、Bigtable、Firestore、Appache Cassandra。
  分析基盤では、主に、分析後のデータを格納して、APIのバックエンドとして利用するケーづがメジャー。

Web API

• システムを疎結合するためのインターフェース

0.3

2つの方法について、連携方法を考える。

データの可視化

1. コレクティングレイヤー：社内に点在するデータをかき集める
2. プロセシングレイヤー：データ統合し扱いやすくする
3. ストレージレイヤー：扱いやすく統一化したデータをS3などの分析向けのストレージに保存する
4. アクセスレイヤー：保存したデータをBIツールなどのツールを通して傾向を可視化する
5. アクション：可視化した結果を用いて施策を実施
6. フィードバックループ：施策結果を確認するために必要なデータを再度分析基盤に取り込む

外部への付加価値の提供

モデルを用いて興味を算出し利用する場合の、連携方法を考える。

1. コレクティングレイヤー：社内に点在するデータをかき集める
2. プロセシングレイヤー：モデルを既存データに適応する（ユーザーの興味判定モデル）
3. ストレージレイヤー：モデル適応後データをKVSなどのデータベースへ保存する。また、後々の利用に備えて、S３などのオブジェクトストレージにも保存する（3')
4. アクセスレイヤー：保存したデータをAPI利用して取得し利用する
   4-1.　ユーザーがAページを表示しようとすすると同時に、ユーザーごとにリクエストを投げる。そして6-1として、同時にAページにアクセスした「表示前アクセス」というログがデータ分析基盤へ収集される
   4-2. ユーザーのリクエストの応じて、KVSから一致する今日データを検索して返却する
5. アクション：レスポンスを取得した結果によりAページの表示内容を変更する。
6. フィードバックループ：循環したデータは１へと戻り、２などの工程に利用される。

第1章　［入門］データ分析基盤　データ分析基盤を取り巻く「人」「技術」「環境」

1.1

データ部赤基盤の変遷

• シングルノード時代：ExcelやRDBを用いた単一PCの分析が主。
• マルチノードの時代：ビッグデータ時代の往来とともに移行。複数ノードを１つの処理のために結合したもの。
• クラウド時代：マルチノードの、管理運用の複雑性や、容量確保のリードタイム、利用複雑化に伴い、移行。

シングルノード時代

• ノード：サーバーを示す単位。

マルチノード /クラスター時代：

• 2010年代になり始まる。データをできる限り集め、複数のシングルノードを束ねて１つのノードのように操作を行う。
• このビッグデータ時代から、ストリーミングデータやアドホック分析などが生まれる。
• この頃はオンプレミスが主流。
• 代表的なプロダクトは、Apache Hadoop,Apache Spark,Apache Hive,Apache kafka（Google Cloud Pub/Sub や　Amazon Kinesisの先駆け）
• リソース不足が課題に）

※アドホック分析：その場限りで完了する分析

クラウド時代
-2010年代後半から2020年代にかけて、クラウドへの移行が始まり、クラウドでデータ分析基盤を構築するようになった。

• ストレージと計算能力がでカップリング（分離）可能な選択肢を持てるように。
• これにより、計算能力は実質無限にスケール可能。
• オンプレミス時代に育んでき技術を（フル）マネージドサービスに置き換えている。

主要なクラウド関連のプロダクト

• データを保存するサービス
• データを処理するサービス
• メタデータ（データを補足/説明するデータ）と連携するサービス
• SQLでデータを参照するサービス

AWSを例に挙げると、データ利用までは以下の流れ

• データ保存：スケーラブルなオブジェクツとレージに配置を行う（S3など)
• データ処理：配置されたデータを処理して表形式に対応できるよう構造データに変換する（EMRで変更）
• メタデータとの連携：構造化データに対してスキーマを付与（Glue Data Catalog)
• データの利用：SQLでデータを参照し分析する（Athenaで参照）

データレイク

• ローデータやローデータに近い形のデータをそのまま配置する場所。
• csv,jsonだけでなく、excel,PDF、動画データなども。
• PythonやApache Sparkといったプログラミング言語が活躍する領域。

データウェアハウス

• 構造化されたデータを保持する役割を持つ領域。データがある程度整理されて管理番号（メタデータ）が振られた状態で配置される。

データマート

• データが加工され売りに出されている状態。
• データウェアハウスとの境界に明確な線はない。　ただし、データマートの方がよりユーザーに近い。
• イメージとしてはかなり整理されたダッシュボードとしてのデータ。

1.2

分散処理

• 分散処理の走りはノードを複数並べて自前で記載したコンセンサスアルゴリズムでノードの間のやり取りを行なっている。
• Apache Zookeeperによって、分散処理がコモデティ化。

※コンセンサスアルゴリズム：ノード間で整合性を保つためのアルゴリズム。

スレッド処理vs分散処理

• 「I am fine.I am good.」のamの数を数える処理を考える。
  • スレッド処理の場合は、スレッドと呼ばれる別プロセスを立ち上げ、それぞれでamの数をカウント。
  • 分散処理は、別々のノードでカウントし答えを出す。
• 両者の違いは、処理性能を無限にスケールでいるかどうか。
  • スレッド処理：スケールアップ（CPU、メモリーそれぞれの単体性能を増強）することしかできない。。
  • 分散処理：スケールアウト（ノードの数を増やすことで能力増強）が可能。理論上無限。

Hadoopの登場

• 分散処理が簡単にできるようにする製品。
• Hadiioエコシステムを連れて、ビッグデータの世界を圧巻する。

MPPDB(Massiveley paralle processing database)

• MySQLやPostgreSQLの技術要素も分散処理化。

マネージレスなクラスターの登場

• 2010年代後半になり、クラウドがオンプレミスに台頭。
• ストレージと計算の能力がでカップリングしたことでKubernetes(k8s)などコンテナを使ったサービスもビッグデータ技術が適応されるように。

1.3

データの変遷について。内容省略。

1.4

データエンジニア

• データを集めて、統合し、分析をサポートするような付加価値をつける職責。
• データから「パターン」や「関係」といった知識を抽出するためのデータ分析基盤の整備、データを取り込むためのデータパイプラインの整備

TIP
-　データソース：データの源。2進数で表すことが課のヌナデータの生成源。
-　主に次の３種。①自社データ②サードパーティデータ③オープンデータ

データエンジニアリング領域

• 分散システムの構築管理
• データの取り込みやETLを通じたデータパイプラインの最適化
• データが格納されているストレージの管理
• ユーザーへのアクセス環境提供

第2章　データエンジニアリングの基礎知識　4つのレイヤー

2.1

パフォーマンスとコストの最適化

• 適切なパーティション、ファイルフォーマット、圧縮、処理エンジンを利用して、データパイプラインの処理速度を上げるのが大事。

データドリブンの土台

• 長期的かつ自律的にデータ活用するためには、モニタリングとKPI設定を行う。

シンプルイズベスト

• より少ないプロダクトで、より障害が発生しにくく、すぐ復旧できる。
  を意識する

2.2

コレクティングレイヤー

• 次の4つのアクティビティを通して、データをプロセシングレイヤーやストレージレイヤーへ渡す。
  • ストリーミング：絶え間なくデータを収集
  • バッチ：一定以上の塊のデータを収集
  • プロビジョニング：ひとまず仮にデータ配置
  • イベントドリブン：イベントが発生したタイミングでデータ収集

プロセシングレイヤー

• 保存されたデータやメタデータに対して「関係」「パターン」を見つけるために操作する
• アクション
  • ETL
  • データラングリング
  • データ品質計算/メタデータ計算
  • 暗号化/難読化/匿名化
  • モデル作成
  • モデルを利用した推論（オンライン推論 or バッチ推論）
• 処理後のデータは各ゾーンやメタデータストアに格納される

ストレージレイヤー

• データ/メタデータを保存するレイヤー
• 役割が広く、扱うデータの種類や用途によって利用する技術スタックが変わる
• よりスケール可能かつ故障耐性が高く、高速な処理を行えるディスクであることが求められる

アクセスレイヤー

• データ分析基盤とユーザーとの接点をもつレイヤー
• 以下のインターフェースの種類がある
  • GUI
  • BIツール（SQL）
  • API
  • ストレージへの直接アクセス（スキーマオンリードという機能を使う）
  • 分散メッセージングシステムに対するアクセス(分散メッセージングシステムはストリーミングデータを保存している）

2.3 コレクティングレイヤー

ストリーミング

• 絶え間なくデータをプロセシングレイヤーに引き渡す方法
• データが途切れないため、ストリーミングサービスのリリース難易度は高い
  • フルマネージドなサービスを利用することである程度難易度を下げることが可能
• バッチ処理に比べてコストが数倍になる場合もあるため、ROIの観点も大事。

バッチ

• ある程度のファイルの塊を取り込む方式
• RDBヤファイルナドヲトリコム
• ストリーミングと違い速度は求められないが、ジョブ数が多くなりがち
  • ジョブスループットなどを上げる工夫が必要

プロビジョニング

• ひとまずデータを分析基盤へ取り込んでみる方法
• データパイプラインとして入れる前に、手動などで「仮に」取り込むイメージ。
• 自分自身で必要なデータを取り込めるため、分析の幅が広がる一方で、不要なデータが蓄積してしまう場合がおおおい。ライフサイクルなど運用面を事前検討する必要あり。

イベントドリブン

• イベント発生時に処理
• 例
  • ユーザがxlsxファイルを配置
  • 上記のイベントを検知し、データ処理プログラムを起動
  • プログラムでxlsxをテーブルへ変換
  • ステージングゾーンへ配置して処理を終了
• 利点
  • 応答性の向上、時間分散可能、リソース分散可能

2.4 プロセシングレイヤー

ETL

• データを整形し、分析向けの形にしたり、精度の高いデータを作成する行為。
• バッチ処理ではAppache HiveやApache Sparkなどが使われる
• ストリーミング処理では、Apache SparkのようなストリーミングフレームワークとApache Kafkaのような分散メッセージングシステムを組み合わせて利用する。

データラングリング

• 非構造データを構造データにしたり、付加価値をつける作業（ラングリングは「こねくり回す」のいみ）
• データプレパレーションとも呼ばれる。
• 難易度が高いため、Pythonなどに習熟している必要があり、また社内のドメイン知識が必要。
• 次の3つの作業をおこなう
  • データストラクチャリング：非構造化データを構造化データにする
  • データクレンジング：重複したデータや壊れているデータ、フォーマットに沿っていないデータを取り除く
  • データエンリッチング：分析に必要な情報を付加

暗号化/難読化/匿名化

• トランスペアレントエンクリプション
  • ディスクに書き込まれたときに暗号化され、読み出されるときに自動的に複合化される仕組み。
  • サーバーサイドえんくリプションとも呼ばれる。
  • 弱点：データが読み込めれば誰でも見える
• エクスプリシットエンクリプション
  • データが全く使えないものに暗号化。
  • エクスプリシット＝「明確に」
  • 読み込みも、書き込みも全く元のデータがわからないようにしてしまう。
• ハッシュ化
  • 現像計算困難性：ハッシュ値から元のデータを復元できない同じハッシュあ
  • 衝突発見困難性：同じハッシュ値になる別データを求められない。
  • 同じデータを入れれば同じハッシュ値が出てくる。
• ディアイデンティフィケーション
  • ユーザー内でデータを入れ替えたり、別の値に置き換えを行い、データを特定しにくくする手法
  • コホートパターン：住所が近いデータ間で、相手とデータを入れ替える
  • サブトラクトパターン：全てを同じ値段で引いたりと四則演算処理をして元の金額がわからないようにする。
• 匿名化と匿名加工
  • 個人情報から、個人を特定できる情報を取り除く。
  • 難読との違いは、データを取り除くことを前提としている点。
  • k-匿名化；同じ属性値を持つデータがk件以上存在するようにデータを変換し、個人が特定される確率をk分の１以下にする。

データ品質/メタデータ計算

• データプロファイリング：データに関する情報のサマリーを取得
• データ品質の測定：データが好ましい状態であるかを確認

モデルを利用した推論

• バッチ推論：事前に大量のデータに対してモデルを適応する方式
  • 　DWHにデータを保存
  • 　プロセシングレイヤーにて、モデル適用
  • 　推論後データはDWHやKVSへ書き込み
  • 　提供：DWHにはBIツールやファイル形式での取得、KVSへのアクセスであればAPIからのアクセスにて推論した結果を取得
• オンライン推論：到着したデータに対して順次モデルを適用する方式
  • 分散メッセージングステムに対してストリームデータが順次流れてくる
  • 流れてきたデータはプロセシングレイヤーにて順次取得され、モデルを適用し、再度分散メッセージングシステムへ格納
  • 推論後のデータを分散メッセージングシステムとDWHやデータレイクに書き込む
  • 最後にユーザーがサブスクライブして、推論後データがユーザーに届く
  • コンポーネントの例：Amazon SageMaker ,Vertex AI ,Apache Spark

リバースETL

• データ分析基盤からデータを取り出し、適切な形式に変換した上で外部のツールやシステムにデータを送り込む処理
• ETLと逆の動きなのが名前n由来
• アウトプット後の処理がデータ活用の上で非常に重要

2.5

プロセスデータ/プレゼンテーションデータ/メタデータ

• プレゼンテーションデータ：ユーザーが最後に触れるデータ
• プロセスデータ：プレゼンテーションデータを作成するためのデータ
• メタデータ：データを捕捉するデータ

データ量とデータ取り出し速度の特徴

# データ量
データレイク>DWH>プレゼンテーションデータストア>（メタデータストア）

# データの取り出し速度
プレゼンテーションデータストア>（メタデータストア）>DWH>データレイク

2.6 ストレージレイヤー

• マスターデータ管理

  • データ活用型：
    データ分析基盤以外のシステムでマスターデータを生成し、それらのマスターデータを集約し統合することでデータ分析基盤としてのマスターを作成する方法

• データのライフサイクル管理

  • データがデータソースから発生し、削除またはアーカイブされるまでのデータの流れ
  • データ分析基盤では、不要なデータは容赦なく削除され、不要と判断されるデータはコストの安いストレージへアーカイブされる。

-　データのゾーン管理
-　5つのゾーンに分割して配置することが一般的
-　①ローゾーン：文脈によってはブロンズゾーンと呼ばれる
-　②ステージングゾーン：イミュータブル（不変）なデータの提供、文脈によってはシルバーゾーンと呼ばれる
-　③ ゴールドゾーン：データ分析における主要なゾーン。BIツールなどに利用される。
-　④クォレンティーンゾーン：機密情報を保持する隔離されたゾーン。
-　⑤テンポラリーゾーン：プロビジョニン具によって配置されるデータ。自動的にデータが消えるような設定を入れると良い。

• プレゼンテーションデータストア
  • 目的１：システム連携に備え、高速な応答速度を求められる場合
    • KVSに格納されることが多い
  • 目的２：BIツールやノートブックなどからの分析利用に備え、大量のデータの効率良い処理が求められる
    • DWHに保管しBIツールなどからDWH内のデータを参照することで利用する
• メタデータストア
  • 次のようなメタデータを管理する
    • ビジネスメタデータ（テーブル定義やドメイン知識）
    • テクニカルメタデータ（ローデータや技術詳細、データ品質、データプロファイリング情報）
    • オペレーショナルメタデータ（操作履歴）

2.7　アクセスレイヤー

ストレージへの直接アクセス
- スキーマオンライト：事前いスキーマを定義しておく方式
- スキーマオンリード：で０田を利用する際に事前に定義されたテーブル定義を必要としない形式

API連携

• 役割１：データ分析基盤へのオペレーションを提供
  • ETL処理用のクラスター起動、ジョブ実行、ステータス確認をAPI経由でする
• 役割２：プレゼンテーションデータストアに格納したレコメンド結果や機械学習データなどの推論結果の提供
  • 方法１：スモールデータシステムが必要に応じてKVSに格納されているデータを取得
  • 方法２：ヘッドレスBIへデータを連携し、ヘッドレスBIが提供するAPIにアクセスしてデータを取得
• 役割３：メタデータの取得/更新

分散メッセージングシステム

• 複数のシステム間で大量のデータを効率的に送受信するために、データを分散して管理/配信するミドルウェア。（分散メッセージングシステム関連のデータは「メッセージ」と呼ばれることもある）

• 高いスループットとスケーラビリティをもち、データの耐久性や可用性を確保しながらリアルタイム処理を実現する。

  • プロデューサー： 分散メッセージングシステムへ送信する側
  • コンシューマー：メッセージを取得する側
  • パリッシュ：プロデューサがデータを分散メッセージングシステムへ格納
  • コンシューム/サブスクライブ：パブリッシュしたデータをコンシューマーが利用

• トピック：分散メッセージングシステムの内部に存在するデータを格納する場所

• 例

  • IoTデータやWeb回遊ログなどのストリーミングデータをトピックで受け取る
  • プロセシングレイヤーからトピックのデータをサイブスクライブ、ETLを行う
  • 別トピックにパブリッシュ。

• サブスクライブの２種の方法

  • Push型：プロデューサーがパブリッシュした後に分散メッセージングシステムからコンシューマに送信する方法
  • Pull型：コンシューマ地震のタイミングで取得しにくる方法

• パーティション：

  • 各トピック内にあるデータを保持する領域
  • パーティションを複数作成することで応答速度を上げられる

• データ保存期間：７日間程度なので注意が必要

2.8 セマンティックレイヤーとヘッドレスBI

セマンティックレイヤー

• ストレージレイヤとアクセスレイヤーの間に入り、両者の間のやり取りを円滑にする存在
• 複雑なデータを理解可能な共通のビジネス概念に変換/翻訳するレイヤー
• データ品質向上に根ざしたアクセスレイヤーを拡張するレイヤー

ヘッドレスBI

• DWHやデータマートのデータをセマンティックレイヤーを通じて標準化し、その結果をAPIで返却するソリューション
• ヘッドレスの由来は可視化や分析機能を持ち合わせず、データを提供する点に特化していること