分析基盤のテーブルと連携方式
分析基盤においては様々な連携手法があります。
これは、データ量が多いか少ないか、データソースが最新か履歴か、によって変わってきます。
今回は、連携手法を紹介しながら、その連携に必要なテーブルの特徴について話したいと思います。
連携元と連携先のテーブル
連携元のテーブルは、最新テーブルになっている場合も履歴テーブル（インサートオンリー）の場合もあります。これはアプリ側の仕様によって異なります。多くの場合は、UPDATEができて、データ量が少なくなる最新テーブルになります。
基本的に連携先のテーブル（データレイクやレイクハウス）は、履歴テーブルになっています。これは、分析する上で時系列データを扱えたり、集計時に多くのデータを扱えることができるためです。
最新テーブルや履歴テーブルの作り方や必要なカラムについての詳細は下記の記事をご覧下さい。
連携方式
全件連携
全件連携とは、データソースから全てのデータレコードを抽出し、データ分析基盤に取り込むことを指します。
この連携は最もシンプルで実装も比較的楽なのですが、分析要件(変更前データが必要な場合)の条件を満たす事ができない場合があります。よって、多くの場合は連携元が履歴型になっていないと不便になってしまいます。
連携元：履歴（インサートオンリー）
連携先：履歴（インサートオンリー）
（余談ですが）
昨今は、DWHからデータソースに対してクエリを投げるフェデレーテッドクエリがあります。外部ソースが変更されるたびに手動でデータを取り込む必要もなくなります。
差分連携
差分連携とは、前回のデータ取り込み時点からの差分データのみを抽出し、連携(取り込み)することを指します（またはバッチ指向CDCと呼ばれる）。ほとんどのケースでは、この差分連携を使用することになるのではないでしょうか。
差分連携には、主に2つのケースで使い分けることがあります。
それは、①連携元が履歴テーブルの時、②連携元が最新テーブルの時、です。
①連携元が履歴テーブルの時
こちらは全件連携と同じです。
しかし、全件連携をしてしまうと処理に時間がかかってしまうようになれば、差分連携を使用します。
連携対象のレコードが膨大になって連携処理に非常に時間がかかってしまう問題が発生した場合です。長時間の処理によって、業務要件（特定の時刻までに集計を終了するなど）を満たせなくなってしまいます。
このケースでは全件連携と同様に以下のテーブルの場合が対象です。
連携元：履歴（インサートオンリー）
連携先：履歴（インサートオンリー）
②連携元が最新テーブルの時
最新テーブルは、差分連携を実施しないと抜け落ちてしまうデータが発生してしまいます。
連携元テーブルが最新テーブルの時、更新の時にはUPDATEされてしまう（レコードが追加されない）ので、UPDATE前の情報が消えてしまいます。
例えば、連携処理は1日に1回とします。しかし、連携元のテーブルは1日に2回更新(UPDATE)されてしまうと、連携できるのは2回目(最新)のレコードのみになります。1回目の更新(UPDATE)は、連携できないことになってしまいます。A→B→Cと更新した時にCのみ連携して、Bは連携できません。
このケースでは以下のテーブルの場合が対象です。
連携元：最新テーブル
連携先：履歴（インサートオンリー）
リアルタイム連携
リアルタイム連携とは、連携元でデータに変更があった際に、すぐにその変更をデータ分析基盤に反映する連携方式のことを指します。
リアルタイムに可視化、集計、分析をしたい場合にこの連携を行います。
前述の差分連携はバッチ or マイクロバッチであり、どうしてもデータの鮮度は落ちてしまいます。
昨今は、このあたりのツールも非常に発展してきています。
CDCだと、DebeziumやOracle GoldenGateやGoogle CloudのDatastream等が出てきています。
この連携では、以下のテーブルの場合が対象です。
連携元：履歴（インサートオンリー） or 最新テーブル
連携先：履歴（インサートオンリー）
関連書籍
データアーキテクチャの設計やETLパイプライン、データモデリングについての記載があります。この本の内容を理解できれば、データエンジニアリング業務で必要な単語や概念は一通り浚うことができるはず。
いいなと思ったら応援しよう！
