海を越えてブログをお届けできて嬉しい限りです。個人的には4日目にしてやっと、時差ボケがなくなりました。AWS re:Invent 2019は最終日を終え、翌朝のフライトを待っているところです。
本記事では私が参加したセッションのうち、データ分析に関するものをご紹介します。
Data lakes and data integration with AWS Lake Formation
※紹介する内容について基本動作は確認済みですが、今回の記事にて画面キャプチャやコードは無しです
※操作や設定の詳細については、弊社別記事 Lake Formationでデータレイクを作成する をご参照ください！
セッション概要
Data Lakeという概念の概説となり、入門レベルのセッションです。
なお、関連するAWSサービスであるLake Formationは昨年のre:Invent2018で発表され、東京リージョンでは2019年8月にGAとなったものです。
https://aws.amazon.com/jp/about-aws/whats-new/2019/08/aws-lake-formation-is-now-generally-available/
Data Lakeの定義は立場（企業）やシステム的な文脈によっては定まらないことも多く、広範な意味を持ちがちです。キーワードだけ書くとしても、次の通り。セッション中でも触れられた単語です。
- centrized（データが一元化されている）
- integrated（データソースやBIツールと統合しやすい）
- collaboration(様々なエンドユーザが使用できる)
- secure（エンドユーザがアクセス分離されている）
- governed（方針に沿って運用されている）
上記のような前提条件が定まっていることが、データ分析をシステム化するうえでの理想像だ、というお話でした。また、別のデータ分析系セッションですが、"実際の顧客ではデータがgovernedされていないケースが本当に多い"という話も聞きました。
Data Lakeに関わる人
- Data engineer: データの加工、スクリーニング
- Data Steward: セキュリティ設定
- Data scientist: データの分析、機械学習
個人的には割と意識したほうがいい役割と思っています。特にData engineerとData scientistは違う、というあたりでしょうか。上記のような名称は「ビッグデータ」が流行した後に初めて聞いた用語ですが、いわゆるデータ分析基盤をつくのがData engineerです。
アメリカでは実際に職業(job title)として求人されてるようですが、現在でも日本ではあまり見かけない印象があります。Data Stewardは冗談みたいな名称ですが、システム運用フェーズで必要になる観点かと思います。
AWSのData Lake
Lake FormationはAPIとしては新しいですが、使ったところでAWSリソースが作成されるものではありません。データ分析にかかわる各AWSサービスに対して、統合されたインターフェースが提供され、ベストプラクティスをAPIとしてまとめてAWSサービスとしてリリースした印象です。
そして、Lake Formationの機能としてコアとなるAWSサービスはAWS Glueです。
Data Lakeを構築するためのひな形(Blue Print)やアクセス権限の管理(IAM認証)をLake Formationは提供し、データカタログ/クローラ/ETL/ワークフロー/ジョブ、等の機能は全てGlueが元々もっているものです。個人的に目新しい機能としては、Lake Formationに登録したData Lake(カタログやソースデータ)ごとにIAM認証ベースでアクセス権限を簡単に設定できる点でした。データカタログやDMLごとにアクセス制御でき、Data lake locations単位でアクセス権限が確認(プレビュ)ーできるようになっています。
なお、Lake Formationを使用する際は、まず、作成するData Lakeに合う"Blue Print"が存在するかを確認します。Blue Printと目的が一致しない場合、ワークフローをマニュアル定義したりLake Formation data importers という機能（※）を使って data engineeringすることができます。
※Category: AWS Lake Formation の記事では"discuss later"と記載があるため、後続リリースされる機能なのかもしれません。
DBがソースになるのであれば、Glueでのデータベース接続設定が前提です。CloudTrailログのようにS3に保存されるソースであれば、該当するS3パスを Data lake locations として登録することが前提です。現在、S3保存のログでLake Formationがサポートしているものは次の通り。
- CloudTrailログ
- CLBログ
- ALBログ
最後に
余談ですが、往路のロサンゼルス→ラスベガス間では、ロス在住のインド人エンジニアと隣になりました。
お互いAWS re:Inventの参加者だったので少し雑談したところ、彼はData Engineerでした。そしてData Scientistとの違いを明確に（おそらくエンジニアとしては常識的に）意識していました。現実的にData Engineerは必要な一方で、（個人的見解ですが）日本では職業として確立していると感じたことがありません。アメリカと日本ではデータ分析の格差が思った以上にあるのかも、と考えさせられる経験でした。
Lake Formationは新機能というものではない、というのが個人的印象です。技術的にも真新しい構成要素はありません。ただ、問題意識として、増え続けるAWSサービスを統合する必要があった、ということかと思っています。
今年のKeynote3日目（CTOのWerner Vogels）から発表された内容で気になったことの1つをここで紹介します。"Amazon社内のlibraryをbuilders向けに公開する"ということです。
システム開発に便利なpythonライブラリでもあるのかと期待していたら、読み物でした。（会場でも一瞬歓声があったので誤解した人は相当数いたのでは...）
ただ、技術的な内容でアーキテクチャや検証内容を解説しているので、これから読み進めようと思います。
Check out The Amazon Builders’ Library – This is How We Do It!
