AWSでデータレイクを構築するには
近年、急速に変化していく生活様式・ビジネススタイルに対応していくために企業ではDX推進が喫緊の課題になっています。DXを実現するためには企業では今まで利用されていないデータの可視化、そしてデータから知見を得る試みが進んでいます。それに合わせて、企業のITシステムの基盤も複雑で大量のデータを扱うためにクラウドサービスの積極的な活用がされています。
本記事では、アマゾン ウェブ サービス(AWS)の各サービスを利用して、多様なデータを活用するために使用される手法のデータレイク、また組織として必要になる体制について解説していきます。
データレイクとは
企業がデータを元にしたビジネス判断を行うためには、まず企業内の様々な情報を収集して蓄積し、分析を行い、可視化をするというプロセスを行う必要があります。データレイクとは、データの蓄積の段階で様々な形式・種類のデータをそのままの形で保存できる一元化された領域(レポジトリ)を指します。
一般的に、ビッグデータを格納して分析する場合、そのデータの格納先としてデータレイクとデータウェアハウスが検討候補となります。以下、表:データウェアハウスとデータレイクの比較」を記載します。
表:データウェアハウスとデータレイクの比較
特徴 | データウェアハウス | データレイク |
---|---|---|
データ | トランザクションシステム、業務データベース、基幹業務アプリケーションからのリレーショナルデータ | IoTデバイス、ウェブサイト、モバイルアプリケーション、ソーシャルメディア、企業アプリケーションからの非リレーショナルデータとリレーショナルデータ |
スキーマ | DWの実装前に設計 | 分析時に書き込み |
料金/パフォーマンス | 高コストのストレージを使用、クエリ結果の取得は最速 | 低コストのストレージを使用、クエリ結果をより早く取得 |
データ品質 | 高度にキュレートされたデータで、事実の情報源として機能 | 任意のデータで、キュレートできるかどうかは不明 |
ユーザー | ビジネスアナリスト | データサイエンティスト、データ開発者、ビジネスアナリスト |
分析 | バッチレポート、BI、可視化 | 機会学習、予測分析、データ検出、プロファイリング |
※引用元:https://aws.amazon.com/jp/big-data/datalakes-and-analytics/what-is-a-data-lake/
データウェアハウスは、データの加工、変換などを実施し、構造化します。SQLクエリなどによる検索性を高めて分析を高速化することが可能ですが、保持させるデータは、事前にデータを構造化したリレーショナルデータに変換しておく必要があります。データを構造化する過程で、必要なデータの取捨選択や形式の変換などが必要となり、保持できない要素は格納をあきらめざるを得ない場合があります。そのため、分析に必要と判明したデータを後から補うなどのプランが取りにくい手法となります。
一方、データレイクは、様々なデータ形式を保管し大規模に集積する役割を持ちます。構造化したデータに加え、非構造のデータをそのまま格納することが可能となります。将来的に「どのようなデータを分析するか」などのデータ形式の設計を慎重に実施する必要性がほとんどなく、取得したデータをそのままの形式でデータレイクへ格納することが可能となります。また、これらの2つの手段は組み合わせることも可能です。データレイクに格納された膨大なデータから、必要なデータのみをデータウェアハウスに移行し、SQLクエリによる高速な分析を実施することもできます。
このように、データレイクとは将来的な分析に備え、データ保持することが一番の役割となります。まずはデータをそのままの形式で保持し、分析したい内容・手法に応じて、データを変換・活用していくことが、データレイクを用いたデータ分析の基本戦略となるのです。
AWSで構成するには
データレイクを構成する上で重要になるのは以下3つの要素となります。
- ストレージの容量・耐久性
- データのカタログ化
- 権限管理
ストレージの容量・耐久性
まずストレージの容量について、データレイクには様々な形式のデータが格納されることが想定されます。データレイクの将来的な利用計画に基づいて、ストレージの容量を事前に確定することは、格納データによっては困難となってきます。
また、格納データは最新のデータのみではなく、古いデータも必要となる可能性があります。そのため、長期的に保持するデータであっても損失されないようにしておく必要があります。AWSで利用する場合には、Amazon S3を利用することで、データ容量の伸縮拡張性、データ耐久性を容易に得ることが可能です。
データのカタログ化
様々なデータ形式を保管することがデータレイクの役割となりますが、ただ保管出来れば良いわけではなく、欲しい時に欲しいデータが閲覧できるように格納されたデータをカタログ化しておくことが必要となります。
AWSでは、データのカタログ化にはAWS Glueを活用します。AWS GlueにてGlueテーブルと呼ばれるリソースを構成し、データレイク上に配置されるファイルの形式や、そのファイルに含まれるデータカラム、各カラムの形式などのメタ情報を設定することで、AWS AthenaやAWS Glueなどから、容易なデータ検索・変換が可能となります。また、Glueテーブルはあらかじめデータ形式が確定していれば、手動で設定することが出来ますが、Glueクローラを活用することで、自動でファイルやデータ形式を識別し、Glueテーブルの作成や修正が可能となります。
権限管理
データレイクに格納されたデータには、個人情報などの繊細なデータが格納される可能性もあります。データレイクへのアクセスには、適切な権限を適用し管理することが求められます。AWSを利用する場合は、一般的な権限認可を管理するAWS Identity and Access Management (IAM)に加えて、データレイクの権限管理に特化したAWS Lake Formationを利用することで、データレイクへのデータの格納や、その閲覧などの付与すべき権限の管理が可能となります。
権限管理に関しては後述でも解説していきますが、これらの要素より、AWSでデータレイクを構成する場合、関連するAWSのサービスを利用していくことで、効率的に環境を構成することが出来ます。
システム構成例と役割
データレイクのアーキテクチャを考えていく上では、データレイクへのアクセス(収集、変換、分析など)に対して適切な権限を付与することが出来るかどうかは一番重要な要素となります。例として、以下の図のようなAWS Glue、Amazon Athena、Amazon Redshiftを使用して、データレイクの管理・分析を実施する構成で考えてみます。
データの流れは以下の通りとなります。
- データレイクへ格納するデータを、各システムのデータ用Amazon S3バケットに配置する
- データ収集用AWS Glueを用いて、各システムのデータ連携用Amazon S3バケットよりデータレイク用Amazon S3バケットに格納する
- データレイク上のデータから必要データのみを読み込み、データを構造化し、分析用Amazon Redshiftに書き込む
- 任意の分析アプリケーションを使ってAmazon Redshiftのデータを参照する
また、データレイク上のデータの簡易な分析として、Amazon Athenaからデータレイクを参照可能な構成としています。
このような構成の場合、以下のような役割を持った担当者が必要となります。
- 各システムの管理者:担当システムからのデータ連携
- データレイク管理者:データレイクへのデータの取り込み・データの変換
- 分析者:データの分析
複数の担当者が必要となりますが、各システムの管理や、データレイクへのデータの取り込みなどを弊社でサポートすることも可能です。また、システムの運用体制によっては、上記の役割を同じ人間が兼務となる場合もあります。今回は上記の役割を持った担当者が存在している前提とします。
AWSアカウントの分離
まず検討すべきは、AWSアカウントの分離となります。各システム、データレイク基盤、分析基盤と役割の異なる人間やシステムが、不正にデータにアクセス・改変などが出来てしまわないように、適切な権限管理が必要となります。
IAM権限によって権限を制限する方針もありますが、このような構成では、各システム・データレイク基盤・分析基盤それぞれをAWSアカウントにて分離した方が、権限分離の観点ではよりシンプルな構成となります。
AWS Lake Formationの導入
続いて、AWS Lake Formationを導入するかどうかの検討が必要となります。AWS Lake Formationとはデータレイクに特化した権限管理のためのAWSサービスとなり、IAMポリシーを意識せずに使用することが出来る権限管理の仕組みとなります。
Amazon S3上に多種多様なデータが格納され、適切なAWS GlueやAmazon Athenaに対して、適切な権限(適切なデータ・操作)を管理していくことは、データレイクの規模によっては、IAMでは困難となり得ます。そこで利用できるのがAWS Lake Formationです。
通常のIAMポリシーでは、どのAmazon S3のどのパスに対して、どの操作を許可するかといった、IAMやAmazon S3のAPIに熟知した人間以外では少し難解な表現で権限管理をしていく必要があります。また、IAMそのものの習得が困難なために誤った権限が付与されてしまうことや、時間をかけてIAMを熟知した人間を育成し、設計・レビューすることが求められます。AWS Lake Formationを使用した場合は、データのカタログ化のためにあらかじめ設定しておいたGlueテーブル対してCREATE TABLE、SELECT、INSERTといった権限などが定義されており、データ分析者にとっては馴染みやすい権限管理の仕様となっています。
データレイクの権限管理をIAMで管理するか、AWS Lake Formationで管理するかは、利用者による判断で選択することが出来ますが、将来的にデータレイクの規模が大きくなる見込みであれば、AWS Lake Formationによる管理が推奨と言えます。
最後に
本記事では、データレイクやそれを構成するAWSサービス、そしてデータレイクのための権限管理のサービスであるAWS Lake Formationについてその概要を解説しました。関連するAWSのサービスを適切に利用していくことで、専門知識などのハードルが下げながら高度なデータレイク基盤を構成できることが分かるかと思います。
ここまでAWSサービスを中心に解説しましたが、ビッグデータ、データウェハウス領域ではSnowflake社のSnowflakeが出現し、AWSをはじめとした既存クラウドとの差別化が可能なサービスとして認知されています。従来型のデータウェハウスサービスでは、限りある計算リソースを複数の分析アプリケーションで取り合ってしまう課題がありました。Snowflakeでは共有型ストレージを利用することで、ワークロードと計算リソースを1:1で設定でき、同時アクセス時の実行優先度などの管理が容易になるという新しい特徴があります。また、Snowflakeはマルチクラウド対応という点もあり、AWSだけでなく、Microsoft AzureやGoogle Cloud Platformの利用者であってもSnowflakeを選択できるというメリットがあります。
各社のクラウドサービスを利用するユーザーとしては、こういった市場の動向は見逃さずに、実施したいことに対してベストな構成は何かといったところはユーザー目線でしっかり考えていきたいです。今回解説した、ビッグデータの利用、データレイク基盤については、TISのAWS関連サービスにてご相談を受け付けておりますので、是非お気軽にお問合せください。
著:TIS株式会社 IT基盤技術事業部 IT基盤エンジニアリング第1部 栗谷本 賢志