この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
データアナリティクス事業本部インテグレーション部コンサルティングチーム・新納（にいの）です。
Amazon Athenaやデータレイクについて調べていると「スキーマオンリード」という言葉を目にすることがあります。データを読み込むときにはじめてスキーマ定義に合うかどうかわかる仕組みなのですが、これだけだと理解できるようなできないような気持ちになりますよね。私がそうでした。
そこで、スキーマオンリードとデータレイクの関係性をおさらいし、Amazon Athenaのアーキテクチャについて理解を深めるための情報を整理してみました。
スキーマオンライトとデータウェアハウス
スキーマオンリードの話をする前に、まずはスキーマオンライトについて解説します。
Amazon Redshiftのように、データウェアハウスではスキーマオンライトという仕組みを取っています。データをインサートする前にスキーマを定義しておき、定義に合うようにデータを入力する形式です。定義と合致するデータでないとデータウェアハウスへのインサートができないため、インサート前にデータの前処理を行うのが一般的です。スキーマオンライトだとデータは必ずSQLを介してインサートする必要がありますが、定義と必ず合致するクエリ可能なデータであることが保証されます。
スキーマオンリードとデータレイク
一方、データレイクにクエリするAmazon Athenaはスキーマオンリードを採用しています。テーブル定義するメタストアを別途用意し、クエリが実行されたときにはじめて事前に準備したテーブル定義と合致するか判断します。これは、S3のようなデータレイクにはSQLでデータロードする処理を介さず、データファイルをそのまま置けることが関係しています。テーブル定義と合致するデータファイルが置かれるとは限らないため、実際にクエリを実行してデータを読み込むときに定義と合うかどうか判断します。
Amazon Athenaでテーブルを作成する際、SerDe（Serialize/Deserialize：どんな形式でデータを読み書きするのか定義すること）や、データファイルが置かれたS3のロケーション、圧縮形式などをいちいち設定するのはこのメタストアにテーブルの情報を定義しておくためです。
「スキーマ定義に合致したクエリ可能なデータであることが保証されるデータウェアハウスのほうが便利なのでは？」と疑問に思うかもしれません。しかし、データレイクはスキーマオンリードの特性を生かしたメリットがあります。
- あらゆる種類のデータファイルを加工しないまま蓄積しておけるため将来的に変化する分析要件に対応できる
- データウェアハウス内のディスクよりも比較的安価なストレージサービスにどんどん増えていくデータを蓄積することでストレージコストも抑えられる
Amazon Athenaのエンジンとメタデータの管理
スキーマオンリードについて理解した上で、Amazon Athenaのアーキテクチャをおさらいしてみましょう。
Amazon Athenaでは、CREATE TABLEなどのDDL機能にはHiveを、クエリエンジンにはPrestoを採用しています。
Q: Athena で Hive クエリを実行できますか? Amazon Athena では、Hive を DDL (データ定義言語) 用や、テーブルおよび/またはパーティションの作成、変更、削除にのみ使用します。
（中略）
Amazon S3 で SQL クエリを実行する場合、Athena では Presto が使用されます。Amazon S3 のデータをクエリする場合、ANSI 準拠 SQL SELECT ステートメントを実行できます。
PrestoのおかげでHiveQL（Hiveで使えるSQL風の言語）ではなく、標準SQLでS3上のデータファイルをクエリできるようになりました。ただしテーブル定義を保持するメタストアはHiveの仕組みのため、DDL機能にはHiveが使われています。
最後に
分かるようで分からないスキーマオンリードを理解し、Amazon Athenaへの理解を深めるの巻でした。そもそもスキーマオンリードについて調べることになったのはAmazon Athenaで思いがけずUnsupported Hive type: jsonに直面してしまったからなのですが、結果的に理解が深まってラッキーです。データウェアハウスとデータレイクは決して対立するものではないので、両方の良いところを活かせるように一緒に運用するのもいいですね。
0
