apache drillを業務利用してみる(までの道のり)

Apache Drillを

業務利用してみる (までの道のり)

2015/11/12 Tokyo Apache Drill Meetup

Future Architect,Inc. Keigo Suda

今回のLTで伝えたいこと

『SQL on Hadoop』って聞いたことあるなー

導入を検討しているが実際どんなものなのか知りたい方

こんな方向け

プロダクト選定を通じて思ったところ 導入にあたってSQL on Hadoopを触ってみてどうだったか

自己紹介

須田桂伍(スダケイゴ)

株式会社フューチャーアーキテクト

インフラよりのDev

基幹業務領域でのHadoop利用(最近はもっぱらEMR+Hive)

最近はQiita記事に技術ネタ投稿してます

(でもHadoopネタないボソッ)

お話すること

SQL on Hadoopの基礎(かるーく)

選定にあたってのポイント

今後のアクション

導入の経緯

SQL on Hadoopの基礎

ググってみると最近だとこんなにいっぱい!!

そして何かとHiveが犠牲にされている もうやめて！Hiveのライフはゼロよ！

データソース

SQL on Hadoop

SQL

各種フォーマットのファイル

最近のSQL on Hadoopの進化がすごい あらゆるデータストアにSQLでアクセスできる!

導入の経緯

導入の背景

業務DB (RDBMS)

アーカイブDB (RDBMS)

過去データ

最新データ

過去データ

過去データ

業務DB (RDBMS)

Hadoopクラスタ

過去データ

最新データ

過去データ

過去データ

過去データ

過去データ

過去データ

過去データ

データレイクとしてデータの一元管理 + 過去データの抽出が必要

抽出業務 抽出業務

アドホッククエリ アドホッククエリ

HDFS

リプレース

これまで これから

それ、SQL on Hadoopで!!

本当に大丈夫なの？

選定にあたってポイント

操作性

今回の選定にあたって特に重視したポイント

業務移行の容易さ

既存プログラムの改修コストをおさえたい 特殊な文法はあんまり書きたくない

システム運用性

SQL on Hadoopレイヤはシンプルにしたい

操作性 業務移行の容易さ

特殊な文法はあんまり書きたくない

システム運用性

SQL on Hadoopレイヤはシンプルにしたい

既存プログラムの改修コストをおさえたい

今回の選定にあたって特に重視したポイント

ANSI準拠SQLが利用可能・・・だと!? 多くのSQL on Hadoopの謳い文句

で、実際どれぐらいANSI準拠なの？

やってみた

候補は君だ!!(なかなかマイナーな選択？)

そもそもHiveQLだし

今回は対象外・・・

当時はまだちょっと不安が

あったので机上でパス

簡単にHAWQの説明

最近OSS化されました！

PostgreSQLと同じ文法が利用可能

操作性はほぼRDB!ってかポスグレ!

(実は結構なダークホースなのでは・・・)

実施してみた結果

利用可否の検証項目 Drill

(検証当時は1.0) HAWQ

(検証い当時は1.3)

SELECT文によるデータ抽出 • CSVファイル上の空文字「″″」は空文字として扱われるみたい PostgreSQLと 基本同じ

SELECT分での関数利用 • TO_CHARで日付型を変換する場合、日付の部分を「DD」ではなく小文字で「dd」にする必要があった

ORDER BY によるデータソート • SELECT * で検索した場合、ORDER BYは1しか指定できない

UNION(ALL)によるクエリの結合 • UNIONはサポートしていないので、UNION ALLとDISTINCTを使用して対応する

→バージョン1.1でUNIONに対応!

CTASによるテーブル作成

• DROP TABLEがサポートされていないため作成したテーブルを削除するにはHDFS上のファイルを直接削除する。

→バージョン1.2でDROP TABLEに対応!

等価結合を使用した検索 • できる

外部結合を使用した検索 • できる

集合関数 • できる

重複削除(DISTINCT)の利用 • できる

GROUP BY、HAVINGを利用した検索

• GROUP BY句でCASE文を使用した場合、NULLを返すとエラーになるため、CASE文で空文字を返すように変更する(GROUP BY CASE WHEN TOUROKUDATE IS NULL THEN ’’)

WINDOW関数の利用 • 現在のバージョンでサポートされていないが、バージョン1.1で下記が対応となる予定。(DRILL-3200)

→1.1で対応! 1.2でさらに追加!

その他 • 日本語を扱う際はDrillのデフォルトキャラクタセットをUTF-16LEに設定

実際触ってみて分かった特徴

ってかもうポスグレ!

バージョン1.2で一人前になった感じ

標準SQLでの記述はほぼカバーできている(と思う)

操作性 業務移行の容易さ

既存プログラムを極力改修しない 特殊な文法はあんまり書きたくない

システム運用性

SQL on Hadoopレイヤはシンプルにしたい

今回の選定にあたって特に重視したポイント

アプリレイヤーからみたスキーマレス

スキーマレス=柔軟な検索が可能

下回り視点で考えてみると・・・

スレーブ スレーブ スレーブ

DB

スタンバイ用のプロセスのことも考えないとな…

構成要素(プロセス)もシンプルになりそう! ただでさえHadoopって構成する台数もプロセス数も多いから…

スレーブ スレーブ スレーブ

実行プロセス 実行プロセス 実行プロセス 実行プロセス 実行プロセス 実行プロセス

マスタ

マスタプロセス メタデータ

マスタレス!!

CTASやVIEWで

スキーマの固定も可能!!

選定の結果

今回はApache Drillを選択!!

標準SQLが結構ちゃんと使える(ようになった)

マスタレスだから比較的障害ポイントが少ない

完全OSS(当時はHAWQが商用だった)

将来性!!!!!!!!!

CTAS,VIEWで固定スキーマとしても操作できる柔軟性

でもちょっと不満も・・・

YARNによるリソース管理が部分的・・・

YARN

HWリソース

CPU CPU CPU CPU CPU CPU

クエリによってはクラスタのCPUリソースを

大量消費してしまうかも・・・

→ユーザ側の意図せぬクエリがクラスタ

リソースを食いつぶしてしまうおそれ

YARN管理対象 のアプリケーション

もっとCPUリソース使いたい・・・

意外と大きな差がつくと思ったポイント

いろいろ情報を見てるとオンメモリで処理しきれなかった際の挙動が極端

DrillとHAWQはその点安定して処理できていた印象(途中に落ちない)

ディスク

メモリ

SQL

大きなデータの結合処理も両者とも安定してこなせていた

今後のアクション

今後の検討課題

いざエンドユーザが使ってみてどうか…

パフォチュー・・・

認証認可どうしようか・・・(GRANT分などのオブジェクト単位での制御ができない)

俺たちの戦いはこれからだ!! また機会があれば「実践編」をお話しできたらと思います!

ありがとうございました!!