データエンジニアリングについて ~AWS re:Invent 2019 データ分析に関するセッションより~

海を越えてブログをお届けできて嬉しい限りです。個人的には4日目にしてやっと、時差ボケがなくなりました。AWS re:Invent 2019は最終日を終え、翌朝のフライトを待っているところです。

 

本記事では私が参加したセッションのうち、データ分析に関するものをご紹介します。

Data lakes and data integration with AWS Lake Formation

 

※紹介する内容について基本動作は確認済みですが、今回の記事にて画面キャプチャやコードは無しです
※操作や設定の詳細については、弊社別記事 Lake Formationでデータレイクを作成する をご参照ください!

xp-cloud.jp

 

セッション概要

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 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!

 

 

 

このブログの著者