データレイク構築に関する基本的な考え方

はじめに

Insight Technologyさんの年次カンファレンス「db tech showcase」に参加してきました。
気がつけば前身のカンファレンス時代も含め、10年以上このイベントに通い続けていることになります。
最初期の頃は非常にコアなこんな技術検証してみました感のある意味ユーザ会のような雰囲気のカンファレンスでした。今でも主要DBMSのベンチマークや比較的ざっくばらんに導入ユーザさんの話が聞ける場ではあります。データベースという分野において、さまざまな製品を横並びに見られる貴重なカンファレンスですので、今後も継続していただけると参加者としてはうれしい限りです。
さて、今回受講したセッションの中には、AWS界隈では「週刊AWS」で有名な下佐粉さんがデータレイクを題材に登壇されているものがありました。内容はAWSに特化した内容ではなく、データレイクを構築する際、皆さんが意識した方が良い大事なお話でしたので、この記事でその辺の内容をまとめてお伝えできればと思います。
細かいところは、資料が公開されると思いますので、そちらを見ていただければと思います。

処理系とデータの分離の話

今回の話の入りは「処理系とデータの分離」というテーマ。
処理系というのは業務サービスと言い換えてもいいかもしれないけど、データを生成するSoRな存在です。データはサービスが生成するデータ自体。
この2つはライフサイクルが違うから、疎結合にしておく必要があって、処理系に依存する形でデータを保存―RDBの中とかね―しているとサービスの終焉とともにデータも消えてしまう。だから分析の源泉となるデータは処理系から分離して別に保存しましょう、っていう話です。
AWSの場合、連携のしやすさやコストの観点からとりあえずS3に何らかの形でデータを出力させておくことが必要。たぶん他のクラウドサービスでも同じようなオブジェクトストレージに生データをとりあえず保存するところからスタートする。

データ保存から始めよう

溜めたデータを解析して何かしらのインサイトを得ようと思っても、溜まっているデータが少なかったら使われないですよね。さて、どうやってデータレイクにデータを増やしましょう？
データを生成する側、業務サービス側は既存サービスにデータを出力する機能の追加や負荷はかけたくない。それにサービスの運用や開発で忙しい。データを受けるデータレイク側の開発者としては、データソース事に取り込み方法、データ成形、変換といった対応を個別に対応するのはしんどい。…けど、しんどい部分をソリューションで解決することはできるから、バックアップ用のエクスポートファイルなどを流用してデータレイク側で仕組みを作る方が望ましいんじゃないか、という話をされていました。
それを支援するサービスとして、AWSとしてサービス提供してますよっていう流れですね。
ここで面白かったのが、昨年のre:Inventで発表されていろんなデータベースなどに実装された「Zero-ETL」の話。Zero-ETLを使うとS3にデータ蓄積するのをすっ飛ばして、いきなりDWHにデータが行ってしまうので、DWHからデータレイクにデータを還流させる必要があるって話がありました。
これは後の話にもつながるんですが、きちんとS3に生データを格納するアーキテクチャにしておく、これがとても大事です。

なぜ生データをS3をためるのか？

Zero-ETLを使っても最終的にS3に生データを還流させると書きましたが、これは生データが残っていれば、成形して分析に使えるデータを何度でも作り直すことができるからですね。
生データさえ残っていれば、何度でも蘇るのだよ！
ということで「生データを残す」。これはとても大事なことだと今日、学びました。

使えるデータにするための前処理

データ分析するのに前処理って大事ですよね。これであとあとの分析の精度が決まるといっても過言じゃない。でも、面倒で地味。
この前処理についても効率的に行う方法をセッションの中でご紹介されていました。テクニックによっては、AWSサービス依存なものもありますが、Sparkなんかで並列分散処理を効率的に行う方法として非常にまとまっていて参考になる話でした。ぜひ資料を見ていただけるとイイなと思います。

まとめ

非常に参考になる話の多かったセッションでした。
基調講演の畠山さんもそうでしたが、この年代のDB屋さんって熱量が凄い気がします。こういう人のセッションは聞いてて楽しいですし、活力になりますね。