View on GitHub

Today I Learned

Software Engineering Blog

第1章 データ分析基盤

データ分析基盤の変遷

シングルノード → マルチノード → クラウド

シングルノード時代は、個人のPCで分析していたがデータが増えてきてマルチノード(クラスタ)で複数のノードでデータを操作する必要が出てきた。Apache Hadoop、Apache Spark、Apache Hive、Apache Kafkaが代表的なプロダクト。

マルチノードの課題は、ユーザや処理の増加によるリソース不足。ストレージと計算能力を分離できるので無限にスケールできる。主なクラウドサービスは、AWS、GCP、Azure。

主なビッグデータシステムのサービス

処理基盤、クラスタの変遷

分散処理の初期は、自前でコンセンサスアルゴリズムを実装していた。

シングルノードではスレッド処理で分散していたが、スケールさせるためにはノードのスケールアップが必要。CPUやメモリをスケールアップできてももディスクのread/writeに限界がある。分散処理ではスケールアウトで複数ノードでスケールできる。

Apache ZooKeeperでノード間のやりとりの技術が進化し、Apache Hadoop, Apache Hive, Apache SparkなどのHadoopエコシステムによって大きく分散処理が認知され始めた。

MPPDB(Massively parallel processing database)。RDBのような構造化データを処理するDB。Amazon RedshiftやGoogle BigQueryなど。

HadoopやMPPDBがクラウドで使われ始める。クラウドによってストレージと計算能力が分離したので、k8sなどのコンテナサービスなどでも使われるようになった。

データの変遷

データの増加は、データによる意思決定の増加、データの機密性の増加、データの種類(決済データ、ログデータ、ストリーミングなど)の増加、活用方法の拡大(不正検知、パーソナライズ、AIなど)などをもたらした。

データエンジニアのスキルセット

データにおける開発の変遷

個人 → データプロフェッショナル → 全員参加

データエンジニアが分析基盤を構築した後、データの利用者がなにかしたいときにデータエンジニアへの依頼が殺到し、本来のシステム作り以外のことにリソースを割くことになってしまった。

このためDataOpsとセルフサービスモデルいう考えが生まれた。

DataOpsは、分析基盤の保守運用ではなく開発に集中する。

セルフサービスモデルは、データ利用者がデータエンジニアに依存せず自身でデータ活用の処理を行う。

第2章 データエンジニアリングの基礎知識

コレクティングレイヤー、プロセッシングレイヤー、ストレージレイヤー、アクセスレイヤー

コレクティングレイヤー

ストリーミング、バッチ、プロビジョニングの方法でデータを集めるレイヤー。

ストリーミングは、絶え間なく流れるデータをプロセッシングレイヤーへ渡す。データが途切れないのでリリース難易度が高い。

バッチは、データのまとまりをプロセッシングレイヤーへ渡す。ジョブが多いのでスループットが大事。

プロビジョニングは、データパイプラインに乗せる前にとりあえずデータ分析基盤にデータを送ってみる。自由度は高いが、不要なデータが溜まるので、ライフサイクルなど検討が必要。

プロセッシングレイヤー

保存されたデータやメタデータに対して操作を行うレイヤー。

ETL、データラングリング、暗号化、データ品質計算/メタデータ計算

データラングリングは、非構造化データを構造化データにしたり、データに付加価値を付ける作業。データストラクチャリング、データクレンジング、データエンリッチングに分かれる。ETLのほうが正規な」ワークフローで定義されるのに対して、データラングリングはワークフローで定義できないような方法でデータから価値を見つける。

データストラクチャリングは、非構造化データを構造化データに変換。

データクレンジングは、重複データや壊れているデータ、特定のフォーマットに沿っていないでデータを排除する。

データエンリッチングは、分析に必要な情報を付与。JOINなどによる特定のカラム追加など。

暗号化の方法として、ディアイデンティフィケーションと呼ばれる、データを残しつつ個人を特定されにくくする方法がある。コーホートパターンで似た情報のデータ同士を入れ替えたり、サブトラクトでデータを四則演算をして元の値を分からなくして特定しにくくする。

ストレージレイヤー

データやメタデータを保存するレイヤー。対障害性が高く高速な処理を行えるディスクが求められる。

不要なデータは、削除するか、コストの安いストレージへアーカイブする。

データは5つのゾーンに分割して配置することが一般的。これによって、ライフサイクルの設定や、プロセッシングレイヤーでの処理、コレクティングレイヤーからの配置、アクセスレイヤーからのアクセス権限管理が容易になる。

アクセスレイヤー

データ分析基盤とユーザのインターフェースを持つレイヤー。

GUI、BIツール(SQL)、ストレージへの直接アクセス、メッセージキューのインターフェースがある。

GUIの提供する機能は、メタデータ参照/更新、データ分析基盤へのオペレーション。また、これらのAPI提供も

ストレージへの直接アクセスは、都度テーブル作成をせずにスキーマオンリードでアドホックに直接読み書きする。

第3章 データ分析基盤の管理＆構築

セルフサービス、SSoT、タグ/ゾーン、メタデータ管理について

セルフサービス

ユーザごとに適切なインターフェースを提供する。BIツール、SQLなど。

SSoT(Single Source of Truth)

小さなデータ基盤を複数作るような、データのサイロ化を避けるべき。

物理的にデータを集めることができなくても、インターフェースは統合して論理的に一つの場所にデータが集まっているような見せ方もできる。

タグ

データはSSoTを維持しつつゾーンに分けて配置する。ゾーンによる管理のためにタグが使われる。

タグによって論理ゾーン化できたり、アクセス権限管理などもできる。

メタデータ管理

RDBのようにデータをテーブル単位で分けて、各データにカラム名、ロケーション、パーティションなどのメタデータをつけて管理する。

アクセス制御は、ゾーン単位、データベース単位、テーブル単位、カラム/レコード単位で設定できる。できればオープンにしたい。

メタデータ管理の代表的なプロダクトは、MySQL、Amazon Glur Data Catalog、Google DataCatalog、Google Dataproc Metastore。

One Size Fits All問題

One Size Fits All問題は、一つのクラスタに複数のアプリケーションを並べて管理すること。

障害時の影響の最小化、計算リソースの最小化のために、ストレージレイヤーとプロセッシングレイヤーを分離したい。

ネットワーク越しのやり取りになるデメリットもあるが、それ以上にメリットが大きい。

ハイブリッド構成

オンプレ+クラウド、Aクラウド+Bクラウドのような構成。

基本的には一つのクラウドで完結することが望ましいが、そうもいかないこともある。データソースがオンプレにあってネットワーク負荷を減らしたい場合など。

データ統合のコストを削減できるメリットがある。データバーチャライゼーションによるロジカルSSoTによって、ユーザは同じインターフェースでデータにアクセスできる。

デメリットとして、データのownerが不明になりやすい、管理対象増加による管理コストの増加、などがある。

第4章 データ分析基盤の技術スタック

データ分析基盤のクラスタ

HA環境下のLinuxサーバはコレクティングレイヤー、それ以外をMPPDBが担当すると、データ分析基盤としてはかなりシンプル。

クラウドで簡単に分析環境を作ることができるので、今後のデータエンジニアは、チューニングや適切な設定、クラスタの組み合わせなどのスキルが重要になってくる。

コレクティングレイヤー

バッチ処理

ストリーミング処理

プロセッシングレイヤー

バッチ処理

ストリーミング処理

ワークフローエンジン

選ぶポイント

  1. ETL処理を定義ファイルベースで記載することができる (CI/CDが実行しやすくなる)
  2. 再実行時に、同じ結果が保証される冪等性があること
  3. 途中からリトライできる機能があること

ストレージレイヤー

データ保存のフォーマット

圧縮形式

データストレージ

データストレージへのデータ配置には、スモールファイル、データスキューネスに気をつける。

Apache Sparkでhintを使ってスモールファイル問題を回避: https://spark.apache.org/docs/latest/sql-ref-syntax-qry-select-hints.html

アクセスレイヤー

BIツール

クエリエンジン

ノートブックは直接ストレージレイヤーにアクセスする。Jupyter Notebook。

APIは、メタデータやオペレーションをラップする用途で使われる。

アクセス制御

第5章 メタデータ管理

メタデータは以下の3つに分類される

ビジネスメタデータ

テーブルやデータベースの特性のメタデータ

データプロファイリングによって、人を介さず機械的にデータの状況を抽出できる。

テクニカルメタデータ

データに対する技術的詳細のメタデータ

オペレーショナルメタデータ

システムの運用やデータの移動過程などで生成されるメタデータ。データの5W1H。

データプロファイリング

バッチで生成される場合、Sparkでストレージレイヤーのデータを読んで、Sparkでデータプロファイリング処理を実施後、メタデータストアに保存する。

カラムレベルからデータベースレベルまで。

データカタログ

データの一覧。ユーザにデータの存在を認知してもらうために使われる

ユーザはこれを見てデータオーナーとコンタクトを取り、分析基盤に取り込んで利用する。

データアーキテクチャ

コレクティングレイヤーからアクセスレイヤーまでの流れのアーキテクチャ。

リネージュ、プロバナンスを使って、テーブル同士の紐づきやデータのソース情報を表す。

第6章 データマート＆データウェアハウスとデータ整備

DIKWモデル

Data, Information, Knowledge, Wisdom。データ整備の流れを表す。

データマートの作成は、ドメイン知識が必要で、いざ作ってみても使われないこともある。

データエンジニアがユーザの代わりにデータマートを作成するのではなく、ユーザがデータマートを作成しやすいように、エンジニアリングを不要にしたり、トラアンドエラーが出しやすいような環境整備が必要。

スキーマ設計

スタースキーマ: ファクトテーブルを中心としてそれに紐づくディメンションテーブルを配置したスキーマ設計。

データ分析基盤の設計としては、パーティションごとにデータが更新されるので、RDBとは違って非正規化が用いられる。

データマートの生成サポート

データマートを効率よく作成してもらうためにサポートできること

第7章 データ品質管理

データ品質管理の三原則

  1. Prevension: 防ぐ、予防。ルール作り、ルールが守られているかの徹底。
  2. Detection: 見つける、検知。データ品質のチェック、ルールに合わないデータの検知および可視化。
  3. Repair: 修正する、修理。検知されたデータの最終形、データの修正、社内ルールの修正。

Prevension : Detection : Repair = 40:40:20の割合が望ましい

データ品質の測定

データ品質の定義「正しいデータが、正しいときに、正しいユーザに、正しい意思決定をするために存在していること」

データ品質の要素。これらを可視化し、データ品質を改善する。

  1. Accuracy: 正確性。データは実態を表しているか。
  2. Completeness: 完全性。データは全部揃っているか。
  3. Consistency: 一貫性。データは一貫しているか。
  4. Validity: 有効性。データはフォーマットに沿っているか。
  5. Timeliness: 適時性。データは正しく存在するか。
  6. Uniquness: ユニーク性。データは重複していないか。

dbtはymlでデータ品質のテストを記載できるため、デード品質のコードを書く必要性を少なくしてくれる。

https://docs.getdbt.com/docs/build/tests

version: 2

model: 
  - name: orders
    columns:
      - name: order_id
        tests:
          - unique
          - not_null

Sparkなどのエンジンを利用せず、dbtでデータ費陰湿のチェックを簡単にできる。

Data QualityとData Profilingの違いは、事実を元に行動するかの違いがある。Data Profilingはあくまで事実を表現することが目的、Data Qualityは、データ品質管理を達成するために行うデータのテストとしての手段。

第8章 データ分析基盤から始まるデータドリブン

データドリブン

狭義のデータドリブン: データ分析基盤やデータ系組織からユーザへの一方通行。

広義のデータドリブン: データ系の人とデータ系でないユーザが相互に作用するデータ分析基盤。

データドリブンを実現するための準備

データドリブンを実現していくためのPDCA

SLO

SLOを公開することのメリット

コレクティングレイヤーのSLOは、稼働率など。データ取得のレスポンス応答率、有効なデータが90%以上存在している、など。

プロセッシングレイヤーのSLOは、エラー率が一定数以下など。バッチであれば、7日間のバッチのエラーが1件以内で20日間で3件以内。ストリーミングであれば、7日感の正常応答レスポンス率が99.9%以上。

ストレージレイヤーのSLOは、可用性など。

アクセスレイヤーのSLOは、稼働率など。APIのレスポンス応答率、メタデータを提供しているGUI画面の稼働率。