データレイク解説シリーズ 第 4 回: 実践的なデータレイク構築方法とポイント

AWS ではデータレイクのストレージとして、Amazon S3 をオススメしています。そこで、ログデータを何らかの方法で収集して S3 にアップロードする必要があります。

ログデータはその性質上、いろんなところに点在しがちです。AWS で構築したシステムでも、EC2 インスタンスのローカルディスクにあったり、S3 にあったり、CloudWatch Logs にあったりするかと思います。このため、それぞれの場所に応じた収集方法が必要になります。

といっても、特別な心配は要りません。AWS の各種サービスの連携機能やオープンソースソフトウェアを組み合わせて、さまざまな場所のデータを簡単に集めることができるのです。

S3 に収集したデータはそのままでも活用できますが、実際に "使える" データレイクにするには押さえておきたい大切なポイントがあります。

たとえば、データの保管方法。
S3 では目的に合わせてコストと耐障害性のバランスをもとにストレージクラスを選べます。また、ライフサイクルの機能によって、保存期間のコントロールや、一定期間経過後のアーカイブ化などもできます。ログデータの場合、保存期間が要件で決まってることも多いと思いますので、要件を満たすように設計します。

たとえば、セキュリティ。
今日、データの暗号化、アクセスコントロール、監査などは、データレイクの実践に欠かせないポイントになっています。S3 は、通信路においても保管時においても暗号化できます。

データレイクのアクセスコントロールのキーとなるのは、Lake Formation です。RDBMS ライクな権限管理で、テーブルレベル、カラムレベルで、ユーザーからのアクセスを許可・拒否できます。一度 Lake Formation で権限管理を集約してしまえば、Athena、Redshift Spectrum、EMR、Glue といったサービスでも権限管理を一元化できます。

ログデータの場合、ログの内容によっては機密性の高いデータが含まれることもあるので、セキュリティ要件を満たすように設定します。

たとえば、カタログ化。
データレイクをさまざまな属性のユーザーに幅広く使ってもらうためには、データの使い方、性質を誰にでもわかるように "カタログ" 化して共有することが大切です。

データ界隈でカタログというと、まず基本になるのは SQL でクエリできるテーブルの定義です。

データレイクでは、どのようなフォーマットのデータであっても自由に加工できるところがポイントになります。一方で、実際にデータを活用するシーンを踏まえると、例えばこのテーブルのこのカラムはマスク処理が必要、このカラムは別のカラムと組み合わせた計算が必要、このカラムは時刻が入るので日本時間に変換するといった、ビジネス観点の加工が必要になることが多いです。

また、パフォーマンス観点でも、分析時にクエリが想定した時間内に完了するように、分析に適したデータフォーマットに変換したり、配置方法を工夫したり、小さいファイルを集約したりといった加工が必要になることがよくあります。

このように、ビジネスとパフォーマンスの両面で、目的に合わせて加工することが大切です。

第 4 回では、ログデータを例に実践的なデータレイクの構築方法とそのポイントを学びました。

少しハードルが高く感じた方もいらっしゃるかもしれませんが、書籍では実際のログデータとサンプルコードをもとに手を動かしながら学べるように執筆しましたので、初めての方でも大丈夫です。最後まで読み終え、動作確認を終える頃には、一歩進んだデータレイクを構築する一連の流れを体感し、ご自身のユースケースに合わせてデータレイクを構築できる実践的なスキルを習得できると思います。

本連載ならびに本書がみなさまが、実践的なデータレイクを構築し、データのちからをもっと引き出すための一助となることを願っています。