第2回Tokyo Apache Drill Meetup　LT

1. Apache Drillを
業務利用してみる
(までの道のり)
2015/11/12
Tokyo Apache Drill Meetup
Future Architect,Inc. Keigo Suda

2. 今回のLTで伝えたいこと
『SQL on Hadoop』って聞いたことあるなー
導入を検討しているが実際どんなものなのか知りたい方
こんな方向け
プロダクト選定を通じて思ったところ
導入にあたってSQL on Hadoopを触ってみてどうだったか

3. 自己紹介
 須田桂伍(スダケイゴ)
 株式会社フューチャーアーキテクト
 インフラよりのDev
 基幹業務領域でのHadoop利用(最近はもっぱらEMR+Hive)
最近はQiita記事に技術ネタ投稿してます
(でもHadoopネタないボソッ)

4. お話すること
SQL on Hadoopの基礎(かるーく)
選定にあたってのポイント
今後のアクション
導入の経緯

5. SQL on Hadoopの基礎

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

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

8. データソース
SQL on Hadoop
SQL
各種フォーマットのファイル
最近のSQL on Hadoopの進化がすごい
あらゆるデータストアにSQLでアクセスできる!

9. 導入の経緯

10. 導入の背景
業務DB
(RDBMS)
アーカイブDB
(RDBMS)
過去データ
最新データ
過去データ
過去データ
業務DB
(RDBMS)
Hadoopクラスタ
過去データ
最新データ
過去データ
過去データ
過去データ
過去データ
過去データ
過去データ
データレイクとしてデータの一元管理
+ 過去データの抽出が必要
抽出業務 抽出業務
アドホッククエリ アドホッククエリ
HDFS
リプレース
これまで これから

11. それ、SQL on Hadoopで!!

12. 本当に大丈夫なの？

13. 選定にあたってポイント

14. 操作性
今回の選定にあたって特に重視したポイント
業務移行の容易さ
既存プログラムの改修コストをおさえたい特殊な文法はあんまり書きたくない
システム運用性
SQL on Hadoopレイヤはシンプルにしたい

15. 操作性 業務移行の容易さ
特殊な文法はあんまり書きたくない
システム運用性
SQL on Hadoopレイヤはシンプルにしたい
既存プログラムの改修コストをおさえたい
今回の選定にあたって特に重視したポイント

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

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

18. やってみた

19. 候補は君だ!!(なかなかマイナーな選択？)
そもそもHiveQLだし
今回は対象外・・・
当時はまだちょっと不安が
あったので机上でパス

20. 簡単にHAWQの説明
 最近OSS化されました！
 PostgreSQLと同じ文法が利用可能
 操作性はほぼRDB!ってかポスグレ!
 (実は結構なダークホースなのでは・・・)

21. 実施してみた結果
利用可否の検証項目
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に設定

22. 実際触ってみて分かった特徴
ってかもうポスグレ!
バージョン1.2で一人前になった感じ
標準SQLでの記述はほぼカバーできている(と思う)

23. 操作性 業務移行の容易さ
既存プログラムを極力改修しない特殊な文法はあんまり書きたくない
システム運用性
SQL on Hadoopレイヤはシンプルにしたい
今回の選定にあたって特に重視したポイント

24. アプリレイヤーからみたスキーマレス
スキーマレス=柔軟な検索が可能

25. 下回り視点で考えてみると・・・
スレーブ スレーブ スレーブ
DB
スタンバイ用のプロセスのことも考えないとな…
構成要素(プロセス)もシンプルになりそう!
ただでさえHadoopって構成する台数もプロセス数も多いから…
スレーブ スレーブ スレーブ
実行プロセス 実行プロセス 実行プロセス実行プロセス 実行プロセス 実行プロセス
マスタ
マスタプロセス メタデータ
マスタレス!!
CTASやVIEWで
スキーマの固定も可能!!

26. 選定の結果
今回はApache Drillを選択!!
標準SQLが結構ちゃんと使える(ようになった)
マスタレスだから比較的障害ポイントが少ない
完全OSS(当時はHAWQが商用だった)
将来性!!!!!!!!!
CTAS,VIEWで固定スキーマとしても操作できる柔軟性

27. でもちょっと不満も・・・
YARNによるリソース管理が部分的・・・
YARN
HWリソース
CPU CPU CPU CPU CPU CPU
クエリによってはクラスタのCPUリソースを
大量消費してしまうかも・・・
→ユーザ側の意図せぬクエリがクラスタ
リソースを食いつぶしてしまうおそれ
YARN管理対象
のアプリケーション
もっとCPUリソース使いたい・・・

28. 意外と大きな差がつくと思ったポイント
 いろいろ情報を見てるとオンメモリで処理しきれなかった際の挙動が極端
 DrillとHAWQはその点安定して処理できていた印象(途中に落ちない)
ディスク
メモリ
SQL
大きなデータの結合処理も両者とも安定してこなせていた

29. 今後のアクション

30. 今後の検討課題
 いざエンドユーザが使ってみてどうか…
 パフォチュー・・・
 認証認可どうしようか・・・(GRANT分などのオブジェクト単位での制御ができない)
俺たちの戦いはこれからだ!!
また機会があれば「実践編」をお話しできたらと思います!

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