目次：
1.データ分析基盤とは
2.データ分析基盤構築プロジェクトの基本ステップ
3.データエンジニアリング領域
4.データレイク・データウェアハウス・データマート
5.データパイプライン
6.4つのレイヤー
7.分散処理
8.データ品質管理
1.データ分析基盤とは
社内外で利用される単一のデータ利用統合プラットフォーム。社内外のありとあらゆるデータが混ざり合うことで、さまざまな知見をデータから得ようという動きがあり、データ分析基盤の主な役割は、それらのデータから「パターン」や「関係」を知るためのサポートを行うこと。
2.データ分析基盤構築プロジェクトの基本ステップ
１、プランニング
２、利用用途の決定
３、設計
４、構築
５、運用
１、プランニング
組織の目的と要望に沿って構築する必要があるため、プランニングにあたり、まず構築のための体制作りが重要。データ分析基盤構築の舵取りをするプロダクトオーナー、データ生成・蓄積・分析の現場担当者、ユーザーを巻き込み推進チームを構築する。その際、経営層も巻き込み現場主導の一過性で終わらないようにすることが重要。実際に構築するにあたっては、WBSを使用したスケジューリングを作成しタスクの棚卸し・納期の設定、担当者のアサインを行う。
２、利用用途の決定
プランニング後は要件定義を行い、「何のためにデータ分析基盤を構築するか」を明確にする。社内でデータ活用に困っているユースケースを活用すると良い。
３、設計
次にデータ分析基盤の技術的な設計を行う。
・どのデータを分析基盤上で使用したいか
・どのようにデータを収集するか
・収集したデータをどこに保管するか
・保管されたデータをどのように分析し、活用するか
ツールは様々あるため、目的に応じて選定を行う。
４、構築
実際に構築していく
・すでに自社内に蓄積されている構造化・非構造化データをデータレイクに移行する
・利用スコープに含まれるデータがデータレイクに蓄積されるようにデータ収集のワークフローを実装する
・汎用的に加工したデータをデータウェアハウスに配置する
・分析用に加工したデータマートを作成する
・データの可視化ツールを導入する
５、運用
一度構築したらそれで終わりではない。利用拡大に伴う機能改善や、モニタリング、効果測定をしていく。
・データ分析基盤が要望を満たす働きをしているか効果測定する
・データ分析基盤の利用状況をモニタリングする
・データ分析基盤の設計を定期的に見直す
・社内でコアユーザーを見つけ、データ分析基盤普及に協力してもらう
3.データエンジニアリング領域
・分散システムの構築管理
・データの取り込みやETLを通したデータパイプラインの最適化
・データが格納されているストレージの管理
・ユーザーへのアクセス環境提供
4.データレイク・データウェアハウス・データマート
データ分析基盤が持つ役割はいくつかある。
| 概要 | |
|---|---|
| データレイク | 非構造データを含むローデータをそのまま配置する場所 |
| データウェアハウス | 構造化されたデータを保持する役割を持つ領域。データがある程度整理されており管理番号（メタデータ）が振られた状態で配置 |
| データマート | データが加工され売りに出されている状態。より特定の人向け |
分別せずとりあえず全てのデータをデータレイクに貯める。貯めたデータを整理してデータウェアハウス配置。最終的に特定用途向けに個別にまとめたものがデータマート。データ量ではなく、役割で使い分ける。
5.データパイプライン
「データの物流」
データソースからデータ分析者の手元に届くまでのデータの流れ。データソース→データレイク→データウェアハウス→データマート→利用
データソース：データの源。2進数で表すことができる。
データパイプラインは以下４つの構成要素で成り立っている。
１、データを集める
様々な情報源からデータを収集する
２、データを貯める：
集めたデータをデータレイクに貯める
３、データを分析用に加工する：
蓄積された膨大なデータのうち、分析に使用するデータのみ取り出し最適な形へ加工する。データウェアハウスに個別にデータマートを作っていくイメージ
４、データを可視化して分析する
データマートのデータを可視化
| ステップ | 使用する主な技術 |
|---|---|
| データを集める | Talend、Fluentd、Embulk、Google Cloud Composer |
| データを貯める | Google Cloud Storage、Azure Data Lake Storage、Snowflake、Amazon S3 |
| データを分析用に加工 | Google BigQuery、Azure Synapse Analytics、Snowflake、Amazon Redshift、Alteryx |
| データを可視化して分析 | Tableau、Looker、SPSS、Power BI |
6.4つのレイヤー
データパイプラインの流れを「レイヤー」という概念で分けることができる。
| レイヤー | 概要 |
|---|---|
| コレクティングレイヤー | データを収集する |
| ストレージレイヤー | 収集したデータを保存するレイヤー |
| プロセシングレイヤー | 収集したデータを処理するレイヤー |
| アクセスレイヤー | ユーザーとの接点となるレイヤー |
コレクティングレイヤー：
データを集めるためのインターフェースの集まり。コネクテッドカー、RDB、CRM、支払い表などのExcelデータなど。
以下の3つのアクティビティを通し、データをプロセシングレイヤーやストレージレイヤーに受け渡す。
・ストリーミング→絶え間なくデータを収集
・バッチ→一定以上の塊のデータを収集
・プロビジョニング→ひとまず仮にデータを配置
アクティビティ詳細
ストリーミング：
途切れることなくシステムに届くデータを順次受付けプロセシングレイヤーへ受け渡して行く方法。車のセンサーデータ、IoTデバイス、Webサイトのユーザーの回遊ログなどがあたる。
バッチ：
ある程度のファイルの塊を取り込む方式。RDBやファイルのような数MB〜数GB単位のファイルを取り込むことになる。ストリーミングと違い、リアルタイムのような速度は求められないが、ジョブの数が多くなりがちなのでジョブのスループットを上げるなどの工夫が必要。
プロビジョニング：
バッチやストリーミングはチューニングなどを考え、正規のデータパイプラインに載せることが前提だが、プロビジョニングはとりあえず手動でも良いので「仮に」データを取り込んでみて見込みがなさそうであれば、そもそもバッチもしくはストリーミングでの取得を行わないという選択肢を取ることが可能。不要なデータを蓄積しないというメリットがある。
ストレージレイヤー：
データやメタデータを保存する。
コレクティングレイヤー、プロセシングレイヤー、アクセスレイヤーのアクティビティは全てこのストレージレイヤーに対し行われるため、より故障耐性が強く、高速な処理を行えるディスクが必要。
プロセシングレイヤー：
保存されたデータやメタデータに対して「関係」と「パターン」を見つけるために操作を行うレイヤー
下記アクティビティを通してデータやメタデータの往来が激しくなるレイヤー
・ETL
・データラングリング
・暗号化
・データ品質計算/メタデータ計算
アクティビティ詳細
ETL：
・Extract（抽出）
・Transform（変換）
・Load（転送）
データを整形してより分析の形（フォーマット変換や圧縮含む）にしたり、精度の高いデータを作成する行為。バッチ、ストリーミング両方に適用可能。
主な技術：Apache Hive, Apache Spark
データラングリング
データに対する付加価値をつける。
主に以下3つの作業がある
１、データストラクチャリング：データを構造化
画像データやPDFなど非構造データを構造化データに変換し、SQLなどで扱える形にする。
２、データクレンジング：データの精度を高める
重複データ、壊れているデータ、フォーマットに沿っていないデータを取り除く。
３、データエンリッチング：データ分析のための準備作業
例えば、特定のユーザーに紐づいたセッション情報を付加する。これによりデータ間のユーザー紐付けが容易になる。
ETLとデータラングリングの違い
ETL：正規のワークフローとして定義できる
データラングリング：手動でのタスクを含む
アクセスレイヤー：
データを利用するためには何かしらのインターフェースを通してのデータへのアクセスが必要。
例えば以下
・GUI
・BIツール
・API
・ストレージへの直接アクセス
・メッセージキューに対するアクセス
7.分散処理
ノード（コンピューター）を複数台並べることで処理能力を上げる。代表的な技術はHadoop。1台のノードで複数のスレッドで行う処理と比べ性能を無限にスケールアップさせることができる。
8.データ品質管理
「膨大なデータが価値を生み出すのではない。精度の良い、正しいデータが価値を生み出す」
データ品質管理の三原則
１、防ぐ/予防（prevention)
事前に防ぐことで、ルールづくりや作成したルールが守られているか徹底、品質チェックの結果を用いて根本からシステム的に改善していく。
２、見つける/検知(detection)
すでに存在しているデータについて品質チェックを行い、ルールに違反しているデータの検知、可視化を行いpreventionまたはrepairに繋げていく。
３、修正する/修理(repair)
dtectionで検知されたデータの不備を再集計などの手法を使い、想定した適切な値に戻す。データ修正のみならず、社内ルールやレギュレーションを作成/修正し、システム修正もrepairの段階で検討。
三原則の適切な割合
いずれか1つにこだわっても根本の解決にはならず、組織としても前に進んでいかない。
・防ぐ/予防（prevention)：40%
・見つける/検知(detection)：40%
・修正する/修理(repair)：20%
全てのデータは完璧に修正されるべきという考えは捨てる。
データ品質について
データ品質の定義：
「正しいデータが、正しいときに、正しいユーザーに、正しい意思決定をするために存在していること」
ただし、100%の品質は不可能であり、目指す必要はない。データは完璧ではないと認識することが、データ品質を理解するために重要。
データ分析基盤におけるデータ品質担保の難しさ
データ分析基盤と一般的なシステムとの違いは、データ分析基盤はアプリケーションを作成した人がそこに存在しないこと。一般的なシステムではAシステムはAさんが設計し、BシステムはBさんが設計をしたとする。しかし、それらをデータ分析基盤に統合しようとすると細かな設計の違いが品質に影響を与える。例えば、Aシステムでは論理削除としており、Bシステムでは物理削除としていた場合、データの統一が難しくなる。またカラム名もidとIDなど違いが出ていればSQLでJOINする際にミスが起きやすい。そのため、データ分析基盤では、ちょっとした定義の違いによりデータ品質が低下するということが当たり前に起きてしまう。
なのでデータ分析基盤は、 本来本社レベルで取り組むべき事項
データ品質を測定する6つの要素
| 概要 | 例 | |
|---|---|---|
| 正確性(accuracy) | データは実態を表しているか | 単価が100円、消費税が10%の時、税込価格110円となっているか |
| 完全性（completeness) | データは全部揃っているか | NULLばかりでは利用価値がない |
| 一貫性(consistency) | データは一貫しているか | 男性を表す際、male、manなど表記揺れがないか |
| 有効性(validity) | データはフォーマットに沿っているか | 日付を表す際、1991-06-03や1991/6/3などフォーマットに違いはないか |
| 適時性(timeliness) | データは正しく存在するか | すでに存在していない商品は含まれていないか |
| ユニーク性(uniqueness) | データは重複していないか | IDは一意になっているか |
システム観点での重要性＋コスト削減効果
1兆レコードあるデータを参照した時、全ての値が1円ずつズレていた場合、結果的に1兆円ズレることになる。この結果を元に意思決定をしてしまうとビジネスインパクトは非常に大きい。しかし、データを修正する場合、修正コストの壁にぶつかる。一般的なシステムと違いデータ量は1GB~1PB(ペタバイト)にも及ぶことがあり、データを横断的に全て修正することは現実的ではない。そのため、データ不備を早い段階で気づき、正しておく必要がある。
分析観点でのデータ品質の重要性
データを分析する立場に立つと、以下が気になる
・いつデータの集計（ETL）が終わるのか
・各テーブル間のデータに一貫性はあるか
・利用しているデータは重複があるか
・どのようなドメイン知識が必要か
これらを事前に定義/表現しておかないと、無駄にクエリを発行したり、1日中データを探し回ることになる。