HadoopTimes

ストリーミングアーキテクチャ Apache Kafka とMapR Streams による新しい設計手法
技術情報

Apache SparkとApache DrillのSQL機能・性能比較

こんにちは。私はクリエーションラインの木内と申します。今回はApache SparkとApache Drillの機能・性能を比較し、想定される活用方法について書いてみることにします。

Apache Spark、Apache Drill誕生の背景

データベースの世界ではリレーショナルモデルが考案された1970年代から、構造化されたデータベースに対してクエリを実行し結果を取得するという作業が一般的なものでした。ユーザーは今でも、解析対象のデータを構造化・正規化し然るべきデータベースに投入することで有意なデータと見なし、諸々の解析を行っています。
現在ではほとんど全ての企業活動がコンピュータを使用して行われています。日々取り交わされる電子メールや、オフィス文書、画像、音声といったデータは企業の資産であり、そこから価値が取り出せるのであればより競争優位を確保することができるかもしれません。

少し乱暴に言ってしまえば、リレーショナルデータベースに入っているデータを構造化データ、入っていないデータを非構造化データと呼びます。企業で取り扱うデータは年々増加していますが、その増加ペースはまったく異なっています。最近の調査では、2015年現在における構造化データは約3.5ZB(Zetta Byte)に対して、非構造化データは約1.4倍の5ZB。この差は2020年頃には構造化データ約5ZBに対して、非構造化データは約6倍の約30ZBに及ぶと予測されています[1]。これらの膨大な非構造化データを分析せずに放っておくことはもったいないことなのですが、どのように解析するかということはデータ分析者の大きな悩みになります。なぜなら非構造化データはそのデータ種類の多様性とともに、実際のデータ(つまりオフィス文書の中の言葉や、動画の中の1フレームの画像)の意味が多分にそのデータそのもののセマンティックス(文脈)に依存するものであるからです。データそのものが依拠するセマンティックスに加えて、もしかしたらデータが含まれているデータパスもセマンティックスの一部と理解する必要があるかもしれません。(例えば”C:\Users\kiuchi\My Pets\whale\johnny.jpg”と、”http://kiuchi.local/My Pets/cat/michelle.jpg”というデータパスは、データパスが指し示す画像そのものの意味もさることながら、私のペットに鯨と猫がいることを想起させます。つまりデータパスとはネストしたカラムであると解釈することができるかもしれません。)

またインターネットを活用した情報交換の発達に触発され、より軽量なデータ交換方式であるXMLやJSONといった”セミ構造化データ”による情報量が増えたこともより状況を複雑にしています。これらのセミ構造化データは柔軟なスキーマ構造を取れるためにRDBのような事前に厳密なスキーマを定義するデータストアには適合しない一方で、電子メールやオフィス文書などのデータと比べれば明らかに構造化されたデータであると言えます。このようなセミ構造化データをどのように蓄積し、解析するかという問題もデータ分析の現場が直面する課題の一つです。

読者の方で”Polyglot Persistence”という言葉を知る方はおそらく少ないと思います。これはScott Leberknightが考案した概念で、2011年にXP(eXtreme Programming)の提唱者Martin Fowlerが取り上げたことで一躍脚光を浴びることになりました。これは様々なデータソースに格納された様々なフォーマットのデータを横断的にアクセスすることを示す概念です[2]。これが実現されると、データ分析者は分析しようとするデータがどのような場所にあり、どのような形式であるかということを意識してデータを変換するコストが劇的に削減されます。

つまり昨今バズワードとして広く露出しているビッグデータの分析において、多様なデータをいかに扱うかという課題は、現在も進行中の状況であると言えます。Apache Drill、Apache Sparkはこのような文脈の中で産まれた、ビッグデータ解析ソフトウェアです。この記事ではApache DrillとApache Sparkの機能・性能の比較をすることで、両者の特徴や、想定される活用方法について考察します。

機能比較

Apache Drill、Apache Sparkはデータ読み込み元として、CSV, JSONといったセミ構造化データや、JDBC経由のRDBに対応しています。Apache DrillはMongoDBのようなJSON DBや、HBaseなどにも対応しています。

対応するデータソース
Apache Drill CSV, JSON, Parquet
Hive, HBase
MongoDB, MapR DB, Amazon S3
Apache Spark CSV, JSON, Parquet
HiveQL互換
JDBC

従来のSQLエンジンと明確に異なる点は、構造化データソースとセミ構造化データソースを混在させて分析対象にすることができるという点です。加えてローカルファイルとしてのデータソース、従来のデータベースコネクションプロトコルに沿ったリモートデータソース、さらにはインターネット上のJDBCとは異なる接続手続きを必要とするデータソースに対してもアクセス手段を確保しています。さらに特筆すべきは、両者ともに「プラグイン」機能を有しており、対応するデータソースを追加することができるという点です[3]

これは明らかに多様化するデータソース、データの横断的な分析を前提とした設計であり、”Polyglot Persistence”を意識したデータソース混在のビッグデータ環境に対応する次世代SQLエンジンであるということができます。

性能比較と考察

それでは両者のクエリパフォーマンスを比較してみましょう。ここではミネソタ大学の研究プロジェクトで収集されている映画の視聴者による評価データベースである”MovieLens”データセットを使用し、JOINを含む3種類のSQLクエリを実行してその性能を検証します。

使用するプログラムはGitHub(m-kiuchi/MovieLensSQL)から利用することができます。

以下の実行結果は私のPC(2core, 6GBメモリ)で実行した結果です。

CASE-1: Aggregation Query: 評価”3”以上の評価データ数を合計
Spark spark-submit –class AggQuery –conf “spark.driver.memory=3g” sql1/target/scala-2.11/sparksqldemo1-assembly-1.0.jar
real 0m52.631s
user 1m31.097s
sys 0m1.002s
Drill drill-embedded -f sql1.sql
(ALTER SYSTEM SET `store.json.read_numbers_as_double` = true;
SELECT COUNT(MOVIE) FROM dfs.`ratings.json` WHERE RATE > 3.0;)
real 0m23.917s
user 0m26.819s
sys 0m0.703s
CASE-2: Join Query: ユーザ、映画名をJoinさせて、評価を行っている女性ユーザの上位10人を抽出
Spark spark-submit –class topTenWomen –conf “spark.driver.memory=3g” sql2-1/target/scala-2.11/sparksqldemo2-1-assembly-1.0.jar
real 0m57.671s
user 1m40.031s
sys 0m1.152s
Drill drill-embedded -f sql2-1.sql
(ALTER SYSTEM SET `store.json.read_numbers_as_double` = true;
SELECT RATtbl.UID, COUNT(RATtbl.UID) as NUMEVALS FROM dfs.`ratings.json` as RATtbl JOIN dfs.`users.json` as USRtbl ON RATtbl.UID = USRtbl.UID WHERE USRtbl.GENDER = ‘F’ GROUP BY RATtbl.UID ORDER BY COUNT(RATtbl.UID) DESC LIMIT 10;)
real 0m27.576s
user 0m28.370s
sys 0m0.803s
CASE-3: Join Query: ユーザ、映画名をJoinさせて評価されている映画の上位10個の名前を列挙
Spark spark-submit –class topTenMoviename –conf “spark.driver.memory=3g” sql2-2/target/scala-2.11/sparksqldemo2-2-assembly-1.0.jar
real 0m57.982s
user 1m41.480s
sys 0m1.246s
Drill drill-embedded -f sql2-2.sql
(ALTER SYSTEM SET `store.json.read_numbers_as_double` = true;
SELECT TMP2.MOVIE, TMP2.NUMRAT, TITLE FROM ( SELECT MOVIE, COUNT(MOVIE) as NUMRAT FROM dfs.`ratings.json` GROUP BY MOVIE) TMP2 JOIN dfs.`movies.json` AS MOVtbl ON TMP2.MOVIE = MOVtbl.MOVIE ORDER BY TMP2.NUMRAT DESC LIMIT 10;)
real 0m28.217s
user 0m29.263s
sys 0m0.658s

さて、これらの結果の相違はどこから来たのでしょうか。私はSparkとDrillの思想の相違に起因するものと考えています。Drillはデータソースを走査しフィルタすることを念頭に開発されているため、それ以外の余分な処理はそもそも入っていないと思われます。データは走査した部分からパイプライン処理で次のステップに送られ、最も短い時間で最終的な結果を得ることにフォーカスしています。短時間のクエリ処理が前提のため、処理途中に障害が発生した場合には再実行になります。一方Sparkにおけるデータソース走査はあくまで並列処理の前段階という位置づけで、結果が再利用されることを前提に、MapReduce的なデータ分割やステージングを都度行っています。Sparkではプログラム内でデータフローをより柔軟にコントロールすることが可能であり、長時間のバッチ処理中の障害の際は中間データを使用した処理の再開が可能であるため耐障害性も向上します。これによるパフォーマンスの相違が発生したと思われます。もちろん十分なマシンリソースが利用できれば、もしくはワークフロー全体の処理時間を考えれば、これらの処理時間の相違は結果的に誤差の範囲に収まるかもしれません。

上記の結果によってDrill・Sparkのどちらがより優秀であるかということを言うつもりはありません。DrillとSparkが多様なデータソースからのデータを透過的に取り込みクエリを実行できること、SparkがSQLクエリ以上に多様な処理を行うことができるということが重要であって、これら2つのソフトウェアが実現できることは従来のRDBの領域をはるかに超えているということこそ、私がこの記事で伝えたいことなのです。

ベンチマーク結果:SAS Visual Analytics on MapR Converged Data Platform

ベンチマーク結果:SAS Visual Analytics on MapR Converged Data Platform
この資料では、SASVisualAnalytics( 以下SASVAと略す)のインフラとなるMapR Converged Data Platform における環境構築および性能評価について評価・考察します。

評価・考察の目的

  • インストール検証においては、OS、MapR、SAS のインストール作業手順の確立、およびインストール時の設定値を洗い出しインストールの標準設定/個別設定を明確にし安定したインストールを支援する事を目的とします。

  • 機能検証においてはHadoop 機能にフォーカスしてSASVA のデータロード機能がMapR
    と連携して製品が所定の機能を提供できる状態であることを確認します。

  • MapR Hadoop ディストリビューションを採用することで、Apache Hadoop と比較し、
    システムの性能向上、システムの安定稼働、システム管理の用意性が実現出来ることを
    確認します。

  • 本検証報告は、製品導入における判定・補足資料として使用されることを希望します。


是非ご覧ください。

無料ダウンロードはこちら