データエンジニアの勧め　を読んで

# データエンジニアの主戦場

企業システムは
・業務システム(SoR,SoE(System of Record,System of Engagement))
・分析システム(SoI(System of Insight))
に分類でき、データエンジニアはSoIが主戦場となる

https://e-words.jp/w/SoR-SoE-SoI.html

## SoR(System of Record)

情報の記録を主目的とする。メインフレーム時代に大量のデータを効率的に記録、蓄積して用途に応じて計算・加工し、必要な形式で出力する

## SoE(System of Engagement)

情報の記録の他人間、組織、物事の結びつき、関与を作り出す

## SoI(System of Insight)

蓄積された情報の加工や分析を通じて何らかの有用な洞察を得ることを主目的とする。通常SoRやSoEと組み合わせて用いられる


# 分析システムの３層構造

分析システムでのデータエンジニアの主な仕事はシステム利用者(データサイエンティスト、アナリスト、意思決定者など)に対して
適切な状態でデータを取得することができるデータ基盤を構築すること

データ基盤は以下の３つの層に分割して考えることができる

1. データ活用層(BI層)
２. データ蓄積層(DWH層)
３. データ連携層(ETL層)

## 1. データ活用層(BI層)

この層ではデータ利用者がデータ基盤のデータを利用するための層である
この時、システム観点で考えたときに２通りの利用方法がある

### データ分析の専門家(データサイエンティスト、アナリスト)でない意思決定者が利用する時

ダッシュボードなどを利用して業務上の意思決定に役立てる使い方ができる
システムは意思決定者の意思決定ができるようなダッシュボードをBIツールなどを使用し作成しておく必要がある
※セルフサービス型と呼ばれるBIツールでは利用者がデータ分析をBIツールでできるようになっている
　→結果をサーバーにアップロードすることで他のビューワーからは閲覧が可能となっている(Tableau(タブロー)等)
意思決定者はダッシュボードの内容から意思決定を行うことができる
データ分析の自由度は低い分、意思決定に必要となるデータがなんであるか明確なとき等にこのようにして利用できる

ダッシュボード：必要な情報、データが一目で理解することができる画面のこと


### データサイエンティストなどデータ分析の専門家が利用する時

様々な切り口でデータを分析してアルゴリズム手法を検証する自由分析の使い方
これは、分析を行うための目標やテーマをたて、それに対して分析に適したデータをデータ基盤は提供することになる
それからデータサイエンティストがモデルを作成し、評価を行い、結果を共有、展開する流れになる


また、BIツールにも特性によって分けて考えることができる(世代)

### 第一世代BI(DWH統合型)

DWHに蓄積したデータを可視化することを目的に作られた最初期のBIツール
システム管理者がBIツール上にダッシュボードを作成し、OLAPによる様々な切り口でデータを確認して利用できる
OLAP操作の性能向上のためにはDWH/データマートにデータ集計処理の内容に合わせたOLAPキューブを定義する
→同じダッシュボードを何年も利用する分には良い(OLAPに依存したキューブ等を定義するので、それに依存するため)
→ダッシュボードやデータソースを頻繁に更新したりすることによる、DWH層やETL層の対応が追い付かなくなることがデメリット

### 第二世代BI(セルフサービス型)

利用者自身による分析に主眼を置いたBIツール
DWH統合型のようなOLAP以外にもセルフサービスによるデータ分析を行うことができる
デスクトップ型で提供される場合が多く、アナリストが作成したダッシュボードは共有サーバーにアップロードすることで
他の分析者や意思決定者と共有することもできる
→意思決定者に情報をどのような型委で提供するか不明で、データ分析スキルを有するアナリストが存在する場合に有用
→事前にダッシュボードで提供したい情報が決まっている場合は第一/第三世代を利用するほうが効率的

### 第三世代BI(ガバナンス型)

接続先データソースを一元的にBIサーバーに登録
アクセス権限やダッシュボード管理の設定をBIサーバーで仮想的に管理できる
→ダッシュボード変更時やデータソース変更時の管理者側の対応が楽
→データレイクや**大量のデータソース**が存在する環境でデータ活用層の認証認可や監査ログを一元的に管理したい場合に力を発揮する(大規模向き)

### 要求スキル

・ダッシュボード
　→利用者の要望をヒアリングしてダッシュボード設計に落とし込む能力(要件定義～設計の能力)
・自由分析
　→業務データ理解(分析に必要なデータを理解してまとめ上げる能力)
・運用設計
　→認証認可の設計、分析結果管理(？)



## 2. データ蓄積層(DWH層)

データ分析に利用するためのデータを蓄積するための場所
目的により３種類に分けられる

### データウェアハウス

データ基盤の中心的な蓄積先となるスキーマオンライト(データ保存前にデータモデリングを行いスキーマを定義する必要がある特性)なDB
→通常はDWHにはRDBを採用し、表形式でデータモデリングを実施してER図を作成する
→その後に業務システムの履歴データなどをDWHのスキーマに合わせてデータを変換して投入する

#### DWHを多くの企業が苦労して構築する理由

日次、週次、月次などのレポートを作成するための大量データの集計処理(OLAP)を実行するため
　→元データのDBに対して実行すると、元データ側のシステムリソースを占有することになる
　→DWHはOLAP性能向上のためにカスタマイズされているので、こちらで処理したほうが元データ側のシステムリソースも占有せず、且つ素早く処理できる
　→近年はクラウドDWHもあるのでクラウドで構築できる場合はデータモデリングやクエリチューニングなどの部分を
　マネージドなサービスを使用することで導入のハードルも下がって、且つスケーラビリティに構築することができる

### データマート

特定のデータ利用に向けてDWHを小分けにしたスキーマオンライトなDB
DWHでは特定用途に使いにくい場合、半集計済みのデータを利用したい場合に作成する
　→DWHをそのまま参照できるのであれば作成しなくてもいい

### データレイク

スキーマオンリード(JSONやログファイルのようなデータでもデータモデリングをせずにそのまま蓄積できる特性)のデータ蓄積先
　→むしろ利用時に信頼性を確認しやすいようになるべく生データのままで保存することが推奨される
一般にはオブジェクトストレージ(S3など)が採用される(RDBなどのリレーショナルデータベースではない)
　→データモデリングを必要としないため、RDBなどには逆に格納できない

メリット
・あらゆるデータを簡単に蓄積できる
デメリット
・無計画に蓄積すると管理不能になる(データスワンプ)
　→データカタログを作成し、データレイクに蓄積したデータのメタデータや認証認可を管理を行う等する

データカタログ：データモデルのメタデータに関する、カタログの作成(定義・抽出・蓄積)およびカタログの利用(探索・把握・共有・配信)によるデータガバナンス支援ツール
		詳しくは[これ](https://qiita.com/manabian/items/efc62ab7c3845bd6be11)

### 要求スキル

・性能設計
　→データモデリング、インデックス設計、チューニングスキル
・DB管理
　→RDBMSに関する知識、NoSQL、Hadoopに関する知識
　　→NoSQLやHadoopは半構造化データ、超大量データ(数十TB規模)のデータを蓄積するときに利用されることがある
・運用設計
　→メタデータ管理(データカタログ等)、認証認可設定


## 3. データ連携層(ETL層)

元データのDBから投入先DBへのデータ処理(データパイプライン)が実行される層
分析システムではデータのサイロ化という分析対象データが複数の業務システムに散在し、データ活用が困難な状況になる課題がよくある
→データパイプラインを作成し、DB間のデータ処理をつなぎ合わせることで散在した業務システムのデータをデータ活用層で利用できるようにする

データパイプラインはつぎ足しながら開発していくような方式となるため、徐々に複雑化して生産性が落ちる
→大規模な案件では、データパイプラインの開発でリネージを管理可能なETLツールを使用することを推奨している

リネージ(データリネージ)：データの生成元から利用先までの流れのこと
https://zenn.dev/koji_mats/articles/cbd1126dd9b3bb

データパイプライン処理には大きく２つの種類がある

### バッチ処理

一定時間ごとにひとまとまりのデータを一括で処理する方式のこと
データパイプラインにおけるバッチ処理は、
・Extract(抽出)
・Transform(変換)
・Load(投入)
のそれぞれの頭文字をとってETLと呼ばれる
→ETLでの大量データ移行の際には非機能要件的な規定時間内にデータ移行を完了できるようにするための性能面の検討が不可欠となる

### ストリーム処理

連続的なデータをリアルタイムに連携する処理方式のこと
→IoTデータやログ監視データ、SNSデータ等をこの方式で連携する

大量データの流入や投入先DBの障害によるデータ損失を防ぐためにメッセージキューイングを利用する

メッセージキューイング：システム間でメッセージやり取りを行う際に使用する非同期型通信プロトコルのこと
https://www.slideshare.net/hiratak1/mq-151749220

### 要求スキル

・パイプライン処理
　→バッチ処理、ストリーム処理を実装するスキル
・プログラミング
　→SQLで実装するスキル、Java/Python/Sparkで実装するスキル
・運用設計
　→性能や障害対応を考えた設計のスキル