【2章】実践的データ基盤への処方箋を現場で活かすために
概要
「 データ基盤システムの作り方」
第2章ではデータ基盤を開発するために具体的な概念やツールが記載されています。この第2章は最も重要な内容になっているので、時間がない方はこの章だけでも読むことをオススメします。
データ収集方法
データフォーマット
データ取得時の注意点
ツールの選定方法
などが記載されています。この記事では、本の内容に加えて現場の罠に引っかかった私の経験談も交えて行きます。
第1章は、以下の記事に書いています。
データ基盤の全体像と分散処理の必要性を理解する
データ基盤には基本的な構造構成が存在します。 それが下記の画像のようになります。
必ずしもこの形になるわけでは無いですが、基本的にはデータレイク、データウェアハウス、データマートの3層構造になります。
この3層構造になる理由は、主にコスト面が考えられますが、分散処理ソフトウェアが簡単に利用できるようになったことも1つの要因となります。
（データ収集のことをデータインジェストと記載する文献もあります）
また第1章でも書きましたが、この3層構造をデータ基盤初期は作成しない方が良いと思います。データレイクとデータマートの2層構造にすることをお勧めします。頻繁にデータ要件が変わることが多いためです。
分散処理を使う1つの基準としては、扱うデータが1テラバイトを超えてくることになります。これは1台のコンピューターでは時間がかかったり集計ができなくなったりするためです。 また、集計だけではなく、データの収集や蓄積においても分散処理が必要になってきます。
データソースごとに収集方法が違うこと、その難しさ
データソースからの収集方法は非常に多種多様になります。データソースの例としては、ファイル、API、ウェブサイト、データベースログ、端末データが挙げられています。 これは事業形態でも変わってきます。
ここでポイントなのが、データの収集方法はできるだけ簡潔に、 誰でも運用ができ、スケールにも耐えることができるような設計を考えることが重要です。 特にデータベースの収集に関してはリアルタイム連携なのか、日時連携なのか、全件連携なのか、差分連携なのかでアーキテクチャが大きく変わってきますので、初期の頃から基準をチームで設けることをお勧めします。
ファイルを収集する場合は最適なデータフォーマットを選択する
ここでは、音声、画像、動画、CSVデータなどのファイルをどのように連携していくかが記載されています。
連携方法にもよりますが、基本的にはキューイングとトリガーを使った設計になることが多いです。例えば、AWSのS3や、Google CloudのGCSトリガーなどが挙げられます。
そしてデータ構造を厳格に管理したい場合は、Apache AVRO を使っていきます。これはデータ構造に厳格なJSONと思ってもらえれば良いです。特にリアルタイム処理で使うケースが多いと思います。
JSON Schemaを用いれば、データを収集したあとでデータ構造の不正に気づくところ、AVROはデータを生成する時点でデータの構造の不正に気付くことができます。 ただし、AVROのデメリットとして、バイナリフォーマットなのでデータの中身を確認することが困難です。
集計処理やSQLを使用するときに、データ量が気になるケースがあります。集計スピードやコストが非常にかかってしまう場合があります。そういった時に、Apache Parquetを使うことで、データ量を抑えることができます。 Parquetは、データフォーマットの1つでデータをテキストではなく、バイナリとして表現します。 また、こちらのデメリットとしても、データの中身を確認することが困難になります。
SQLを利用したデータベース収集ではデータベースへの負荷を意識する
SQLを発行してデータを取得するにはいくつかの方法があります。
シンプルに1回のSQLを発行する
フェッチを使って分割する
並列実行して分散処理する
基本的にデータ量が多いと差分連携を用いるケースが多いので、 差分連携を前提とします。差分連携時にデータ量が多い場合（例えば100GBのようなメモリに乗り切らないデータ量）は1回のSQLだとデータを取得できません。
（私の経験上では、フェッチを使うことの方が多いですが、どちらが良いかは システムに依存するかと思います。 ）
また、複数回データを参照する場合はデッドロックに注意をする必要があります。
次にDBへの負荷について考えなければなりません。
データベースに対して クエリを発行し続けるとアプリケーションで問題（DBが落ちてしまう事象）が発生するケースがあります。ですので、データベースのレプリカを作って、レプリカDBをデータ基盤専用としてクエリを叩くようにするのが一般的です。
ただし、最近はわざわざレプリカを作成することなく、マスターのデータベースに負荷をかけないという仕組みが出てきています。
例えば、Google Cloud Spanner Data Boost がそれに当たります。
更新ログ経由のデータベース収集
何かしらの変更がテーブルにあった場合、その更新内容もデータ基盤に反映しないといけません。更新ログを収集する方法の1つにCDCツールの利用があります。CDCとはChange Data Captureの略称であり、データの変更を検知して取得します。 このツールの最大の利点としては、リアルタイムにデータを収集できる点があります。
そしてこの本には書いてありませんが、更新ログを貯めるテーブルの設計は注意が必要です。データソースのレコードが更新されたからといって、データ基盤のレコードも更新するのは良くありません。トランザクションデータのように更新データも1行としてデータ基盤へ挿入することをお勧めします。
例えば、あるユーザの口座の残高が10,000円から20,000円へと変更があった場合、データ基盤では10,000円のレコードと20,000円のレコードの2行が存在することになります。
このメリットとしては、データ分析時に、いつからいつまでがその残高だったのか、ある時点での分析手法を使うことができるためです。
データレイクでは収集したデータをなくさないようにする
データレイクからデータを紛失しないようにするのは、基本中の基本になります。ただし、機密情報や個人情報については別になります。これらのような外に出ていくと、問題のあるデータに関してはデータレイクで情報を少なくしていく必要があります。
データレイクでは、基本的に生データを蓄積し、加工しない方が良いとされているのですが、セキュリティ面で匿名化をしないといけないケースがあります。私も間違えたケースがあったのですが、基本的にデータレイクには匿名化された状態でデータを保存する必要があります。よって、データ収集の中でデータの匿名化処理を行う必要があります。
処理の量や開発人数が増えてきたらワークフローエンジンの導入を検討する
ワークフローエンジンとはデータ基盤で発生する一連の処理について、処理全体の流れを管理する製品です。主な機能は起動時刻と起動順序の制御になります。
製品例だと「Airflow」「Digdag」「Argo」「Prefect」などが挙げられます。特に最近よく使われているのがAirflowになります（個人的観測です）。
長期間にわたってデータ基盤を運用していくと、毎日異常終了するが業務上は影響がないため無視したい処理が出てきます。このとき、「この処理の異常終了は1週間無視」や「この文字列を含む場合は無視」といった機能も欲しくなってきます。
ワークフローは、データ基盤専用なのか、それとも業務システムに既に存在するものを使うのかを考えます。
これはワークフローエンジンが停止すると、その後の処理も全て止まるため、常に稼働し続けたり、プロジェクトのエンジニアがより簡単に運用できたりするかどうかという観点が求められます。
また第1章でも述べましたが、このワークフローエンジンを使ってデータレイクらデータウェアハウスやデータマートへの連携時の処理を行うケースをよく見ます。しかし、これはデータ基盤初期にはあまりお勧めしません。ビジネスでは集計や分析するデータが常に変化しやすいからです。そのたびに処理の中身を変更するのは非常に手間であるため、ある程度成、熟してから使うのが良いと思います。
まとめ
この第2章は特に 重要かつ運用を見据えてすぐに現場に導入できるような知識やツールの紹介があります。時間がない方はこの第2章を特に重点的に読むのをお勧めします。この第2章の内容を現場に導入するとスケールした時によくあるエラーや変更にも対応できるかと思いますので、実践してみて下さい。
続きの3章はこちら
いいなと思ったら応援しよう！
