X

Big Data、Data Integration、Data Lakeに関するテクノロジー、製品・サービス情報、セミナー情報などをお届けします

データレイクにおける対話式クエリ

Data lakes(データレイク)は、今まで長年にわたり、ビッグデータ領域の重要な一員でした。 それは、あらゆる種類の新しいデータを取得・管理し、そのデータで新しいエキサイティングな潜在的なユースケースを提供します。詳細情報についてabout what a data lake is(データレイクは何か)とwebcast about building a data lake in the cloud(クラウドでデータレイクを構築するウェブキャスト)をご覧ください。

しかし、その最初の段落の重要なキーワードはおそらく「潜在的」かもしれません。 なぜならデータの価値を実現するために、あなたがまず新しいデータを理解し、対話的に探索する必要があります。その上に仮説を形成し、検証することも必要です。

データレイクに対する対話式クエリとは

大規模の対話式のデータレイククエリは簡単ではありません。 この記事では、すべてのデータを完全に活用するために克服する必要があるいくつかの問題を見ていきます。そのため、Oracle acquired SparklineData(オラクルはSparklineDataを買収し)、対話式のデータレイククエリに大規模で対応できるようになりました。 この記事の後半にもっと詳しく説明します。

Hadoopはデータレイクの標準的なプラットフォームでしたが、もともとは 対話式の作業ではなく、バッチ用に設計されました。 Apache Sparkは、最新の分散コンピューティングプラットフォームとして、対話式のクエリに対する新しいアプローチを提供し、MapReduceを使用するHadoopより10倍あるいは100倍の高速処理を持ちます。HDFSをOracle’s object storage(オラクルのオブジェクトストレージ)(AmazonはS3、MicrosoftはBlob Storage)に置き換えると、大規模の対話式のクエリを潜在的にサポートするmodern data lake(現代的データレイク)の基盤が得られます。

完全に機能するデータレイクを無料で構築しましょう

大規模データの対話式クエリの困難さ

例え現代的なデータレイクを持っていたとしても、データレイクの対話式クエリは非常に難しい問題が伴います。下記に、その課題となるポイントをあげます。

•パフォーマンス

•事前集約

•スケールアウト

•柔軟性

•ツールの選択

これらを順番に見てみましょう。

(パフォーマンス)
対話式のクエリには、高速なレスポンスが必要です。 ユーザーはワークシートやダッシュボードをナビゲートする際に快適に分析を行える必要があります。 しかし、多くのユーザーがデータレイクのデータセットに同時アクセスしようとすると、パフォーマンスが低下します。さらに、ファクトテーブルとディメンションテーブルを結合すると、追加のパフォーマンスボトルネックが発生する可能性があります。 多くのツールはインメモリ層の構築で問題の解決を図りますが、このアプローチだけでは十分でありません。

(事前集約)
パフォーマンス問題に対処するもう1つの方法は、データレイクからデータを抽出して事前に集計することです。 多次元データの分析を容易にするため、OLAPキューブや分析データの絞り込み、およびマテリアライズド事前集計テーブルなどが実績ある手法として用いられてきました。 しかし、ここでは制限があります。この事前集計は、ダッシュボードやレポートをサポートしますが、アドホックのクエリの場合は対応が難しくなります。カギとなる情報はサマリされたデータの中には現れません。これは、デジタル写真を拡大し、不明瞭なピクセルを取得するようなものです。 あなたが望むのは、すべての生データにアクセスでき、必要なものを自由に拡大して見渡すことができることです。 Pre-aggregating data for deep analysis(ディープ・アナリシスのためのデータ事前集計)で詳細説明をご覧ください。

(スケールアウト)
データはかなり大きくなる可能性があります。 そして、遅かれ早かれ、一度に1ギガバイトのデータではなく、テラバイトの分析を行う必要があるはずです。 このような規模への対応として、Sparkは分散コンピューティングエンジンを持ち、ネイティブに大規模処理で動作するように設計されているため、スケールアウト可能ですが、他の多くのツールはストレステストで失敗してきました。

(柔軟性)
正常にスケールアウトすることは課題の一部です。処理が完了した後にスケールバックする必要もあります。一言でいうと、柔軟な処理環境が必要です。例えば、最近実施したキャンペーンの分析または毎月のダッシュボードの更新の場合、新しいデータセットが突然使用される可能性があります。その作業負荷が時間とともに変化する特徴に対応するため、柔軟な環境は必要です。柔軟性は、modern data lake where compute and storage can scale independently(計算とストレージが独立で拡張できる現代データレイク)の機能の一部です。ただ、柔軟性はデータレイクを使用するツールたちが分散型のアーキテクチャを持つことも要求します。

(ツールの選択)
最後に、データを最大限に活用することは、個人や特定の組織だけの仕事ではありません。データサイエンティストやビジネスアナリストらの協力も必要であり、彼らはそれぞれ異なるツールを使用する要件もあります。ツールごとにデータを独自に準備することを避け、すべてのツールを同じデータに対応できることが必要です。

データレイクのクエリ問題を解決

2018年4月にオラクルはSparklineData社を買収しました。その代表的なツールであるSparkline SNAPはいくつの革新的なソリューションで上記の問題を解決できます。

  • パフォーマンス、スケーラビリティの課題に対し、Apache Sparkを使用してインメモリでスケールアウトを処理します。
  • テラバイトのデータセットでも1秒未満でクエリを実行完了できます。
  • 完全に分散した計算エンジンアーキテクチャでインメモリインデックスを使用するため、データの事前集計や抽出は不要です。
  • オブジェクトストレージとSparkクラスタに基づいて動作するため、データレイクでの分析を柔軟に伸縮・縮小し処理します。
  • さまざまなユーザーが、自分のツールでデータにアクセスできます。例えばPythonやRを実行するノートブックZeppelinやJupiterなど、BIツールのTableau、Oracle Analytics Cloudなどです。言い換えると、自分のツールでSparkline SNAPインメモリ層に接続することができます。

オラクルは現在Sparkline SNAPをOracle’s own data lake and analytics solutions (Oracle独自のデータレイクと分析ソリューション)への統合を進めており、すみやかな市場への提供を計画しています。

対話型クエリの使用例

このようにデータレイクによる真の対話型クエリが実現された環境において、どのようなケースで、この技術を使うべきでしょうか? 多くのユースケースがありますが、ここでは3つについて考えてみましょう:

1.データ量予測が難しいIoTなどのケース
マシンおよびクリックログなどのイベント/時系列のデータは、サイズと複雑さが急速に変化します。現代的なデータレイク基盤であっても、そのテラバイト以上のデータに対するアドホッククエリのパフォーマンスをBIツールで保証することは不可能です。Sparkline SNAPは、パフォーマンス向上のためにデータの移動や事前集計が不要で、直接データレイク上でその大規模なデータセットをストレスなく操作および分析することができます。

2.分析対象のデータソース数が多いケース
分析用データは、全てデータレイクに揃っていない可能性があります。 ERPだけではなく、様々なデータストアを横断的に分析することは非常に困難が伴います。個々のスキーマに最適化されているため、横断的なクエリには全体最適なスループットが得られないためです。もし、全てのデータをオブジェクトストレージに移動してSparkline SNAPでアクセス可能にした場合は、十分なアドホッククエリ性能を提供できます。データソースは単一でも、60種類のソースからでも分析できます。

3.BI分析用のデータマート作成が煩雑なケース
最後に、おそらく、あなたは今どうやって新しいインメモリBIツールで既存のクエリと事前集計結果にアクセスできるかを悩んでいるかもしれません。 Sparkline SNAPを使用することにより、データマート作成作業を省略して、あらゆるレベルの細かいライブデータを分析できます。したがって、データを準備する時間と労力を節約できるだけでなく、より良い分析を行うことができます。pre-aggregating data for deep analysis(ディープ・アナリシスのためのデータ事前集計)で詳細説明をご覧ください。

データレイクを使い始めたい場合、このguided trial(ガイド付きトライアル)を参照してください。ほんの数時間で、データを蓄積し、それを視覚化と機械学習できる環境が手に入ります。

本資料は、Oracle Big Data blog(https://blogs.oracle.com/bigdata/interactive-data-lake-queries-at-scale)を抄訳したものです。

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.