クラウドサービス進化によってデータレイクの運命が決まる
前回、データレイクとはどういうものか、データベースと何が違うかについて触れました。今回はクラウドサービスがデータレイクにどの様に影響しているか、そして、今後、データレイクはどの様に変わって行くかについて、クラウド3サービス(AWS、Azure、Google Cloud Platform)の各サービスを例に出しながらご説明したいと思います。
クラウドサービスのデータレイク
Hadoopフレームワークサービス
前回記事で大量のデータファイルを高速にデータ参照するためにはHadoopなどの分散処理基盤が必要なことの説明させていただきました。しかし、Hadoopはアプリケーションではなく、分散処理フレームワークです。単純にパソコンにインストールだけでは環境構築することはできません。そのため、Hadoop関連の高い技術力と環境構築時間が必要になり、更に複数台のパソコンで分散処理するために同様の作業を繰り返すため、作業時間は倍以上に膨らみ、機器導入コストも膨大になります。
これらの手間とコストを抑え、誰でも使いやすくしたのが「Hadoopフレームワークサービス」です。Hadoopフレームワークサービスは、マネージドサービスとしてHadoopの実行環境を提供しています。また、環境構築したHadoop環境はスケールアウト(台数を増やす)も簡単に行えますので、1台のHadoop環境実行環境を構築すれば、同じ作業も何度も行う必要はありません。
Hadoopフレームワークサービスに該当するクラウドサービスとして、Amazon EMR、Azure HDInsight、Google Cloud Dataproc があります。これらを使用することでHadoop環境構築作業が軽減されるだけでなく、高い稼働率とセキュリティも得ることができます。これらと容量無制限の Amazon S3 などのクラウドストレージを組み合わせることで、大容量に耐えられるデータレイク環境を構築することができます。
データレイクサービス
Hadoopフレームワークサービスによって環境構築の手間を省けます。しかし、以下のようなデータレイク環境をクイックに使うためのハードルが残ってしまっています。
- Hadoopフレームワークサービス上でのデータレイク環境構築の手間
- Hadoopフレームワークサービスの高額な使用料金
これらのハードルを取り除くのがデータレイク専用のデータレイクサービスです。データレイクサービスの処理本体はHadoopベースの分散処理ですが、Hadoopを全く意識せずに以下の手順のようにデータレイク環境がクイックに準備することができます。
- クラウドストレージにデータファイルを保存
- データレイクサービスに接続してデータファイルの参照定義作成
- データレイクサービスに接続してSQL類似の命令でデータ参照
また、データレイクサービスの課金方法は参照先のデータサイズによる従量課金になっています。Hadoopフレームワークサービスは使用時間による従量課金だったため、アイドリングタイムも無駄な課金が発生しました。しかし、データレイクサービスはデータ参照した時だけデータサイズに応じてピンポイントで課金が発生します。そのため、Hadoopフレームワークサービスよりも運用コストを抑えることができます。
データレイクサービスに該当するクラウドサービスとして、Amazon Athena、Azure Data Lake Analytics があります。Amazon Athena は「HiveQL」と呼ばれる Hadoop関連技術で頻繁に使われるSQL類似のデータ操作言語を採用しているため、Hadoopやデータベース技術者は抵抗なく使えます。また、Azure Data Lake Analytics のSQL類似のU-SQL命令は、T-SQL命令(Microsoftの拡張SQL命令)に簡易プログラミング命令を付けた仕様のため、データ参照結果をクラウドストレージに加工して書き込んだり、Python言語やR言語を使用して高度な処理が行えます。
Google Cloud Platform にはデータレイクサービスはありませんが、類似のサービスとして Google BigQuery があります。Google BigQuery はデータ保存先が上記の2つのサービスのようにストレージが独立していないため、データ保存するときはデータインポートになってしまいますが、参照先のデータサイズによる従量課金を採用しています。他のデータレイクサービスが充実する前、大容量データを高速かつ安価に分析するためにはBigQueryが良く使われていました。(BigQueryの正式リリースは2012年。上記2つのデータレイクサービスは2016年です)
データベースの外部参照テーブル
データレイクサービスのデータ参照機能によって、大量データの抽出・集計処理は行えるのですが、その結果をデータレイクサービスに簡単に登録することはできません。また、データ分析の試行錯誤で何度もデータ参照を繰り返した場合、参照先データファイルのサイズで課金されるデータレイクサービスだけでは使用料金が高額になる恐れがあります。
そのため、データレイクサービスでデータを確認し、そこで判断した分析に必要なデータのみをビッグデータ用データベースのAmazon Redshiftなどにインポートし、データベース上でデータ分析の試行錯誤を行う必要があります。この手順を行うことで、必要なデータだけがデータベースに登録されるため、データベースの負荷が抑えられ、従来の方法でデータの抽出・集計結果をデータベースに登録できるため分析者の負荷も少なくなります。
この様にデータレイクとデータベースを使い分ける必要があるのですが、データレイクサービスには、他のデータベースへのインターフェースを持ってないため、簡単には大量データをデータベースにコピーすることはできません。
このデータレイクとデータベースのデータコピーをクイックにできる機能／サービスが「データベースの外部参照テーブル」です。Amazon Redshift、Azure SQL Data Warehouse には、外部データの参照機能としてAmazon Redshift Spectrum、PolyBase(Microsoft SQL Server の機能) があります。これを利用することでデータベースサービスにデータベース接続して、データレイクサービスと同じ要領でクラウドストレージ上のデータファイルを参照できます。そして、クラウドストレージ上のデータファイルは外部参照テーブルとなり、普通のテーブル同様にデータ参照やテーブル結合ができます。(Redshift Spectrum は参照先データファイルサイズによる従量課金がRedshift本体とは別に発生するため、試行錯誤する時はRedshift内のテーブルにコピーすることをお勧めします)
データレイクは始まったばかり
このようにデータレイクはクラウドサービスを利用することで比較的簡単に安く利用できるようになりました。これで完璧のように感じられるクラウドサービスですが、まだ始まったばかりです。
データレイクの概念としては、ログファイルなどのテキストファイルだけではなく、画像ファイルや音声ファイルも扱えるとなっています。しかし、現段階では、CSVファイルなどの構造化データ、そして一部の非構造化データしか対応していません。(「一部の非構造化データ」とは、JSONデータやXMLデータなどの規則性があるデータのことです）
現在、クラウドサービスでは、データレイク以外にAI関係のクラウドサービスが出始めてきています。その中には画像データや音声データのテキスト変換サービス、画僧データから車や猫、個人を特定する物体検知サービスなどがあります。これらの画像や音声分析のクラウドサービス、そして、Deep Learningなどがデータレイクサービスとうまく連携できれば、テキストファイルだけでなく様々なデータファイルをデータとして扱えるかもしれません。
次回はデータレイクサービスを使う場合のクラウドストレージの管理方法のポイントについてご説明します。
関連記事
- データレイクとクラウドサービス ～①データレイクの今までをおさらい～
- データレイクとクラウドサービス ～②クラウドサービスが支えるこれからのデータレイク～ (本稿)
- データレイクとクラウドサービス ～③クラウドストレージの賢い管理方法～
- データレイクはビッグデータのストレージ：データウェアハウス(DWH)やデータマートへの取込口です
- 「データレイク」のコンセプトを理解しよう｜Treasure Data（トレジャーデータ）は、まさにデータレイクだ
- Amazon Athena の分析サービスとしての位置付けについて考えてみる
- Amazon Redshift Spectrum を使ってみた ～Redshift Spectrum は Redshift のデータレイクの入り口になる～
- PolyBaseを使ったAzure SQL DWへの高速インポート ～図解で分かりやすく説明～
- Google BigQueryは「速い・安い・シンプル」の3拍子揃ったビッグデータ処理サービス
