Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

2,349 views

Published on

第2回Tokyo Apache Drill Meetup LT

Published in: Engineering

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

  1. 1. Apache Drillを 業務利用してみる (までの道のり) 2015/11/12 Tokyo Apache Drill Meetup Future Architect,Inc. Keigo Suda
  2. 2. 今回のLTで伝えたいこと 『SQL on Hadoop』って聞いたことあるなー 導入を検討しているが実際どんなものなのか知りたい方 こんな方向け プロダクト選定を通じて思ったところ 導入にあたってSQL on Hadoopを触ってみてどうだったか
  3. 3. 自己紹介  須田桂伍(スダケイゴ)  株式会社フューチャーアーキテクト  インフラよりのDev  基幹業務領域でのHadoop利用(最近はもっぱらEMR+Hive) 最近はQiita記事に技術ネタ投稿してます (でもHadoopネタないボソッ)
  4. 4. お話すること SQL on Hadoopの基礎(かるーく) 選定にあたってのポイント 今後のアクション 導入の経緯
  5. 5. SQL on Hadoopの基礎
  6. 6. ググってみると最近だとこんなにいっぱい!!
  7. 7. そして何かとHiveが犠牲にされている もうやめて!Hiveのライフはゼロよ!
  8. 8. データソース SQL on Hadoop SQL 各種フォーマットのファイル 最近のSQL on Hadoopの進化がすごい あらゆるデータストアにSQLでアクセスできる!
  9. 9. 導入の経緯
  10. 10. 導入の背景 業務DB (RDBMS) アーカイブDB (RDBMS) 過去データ 最新データ 過去データ 過去データ 業務DB (RDBMS) Hadoopクラスタ 過去データ 最新データ 過去データ 過去データ 過去データ 過去データ 過去データ 過去データ データレイクとしてデータの一元管理 + 過去データの抽出が必要 抽出業務 抽出業務 アドホッククエリ アドホッククエリ HDFS リプレース これまで これから
  11. 11. それ、SQL on Hadoopで!!
  12. 12. 本当に大丈夫なの?
  13. 13. 選定にあたってポイント
  14. 14. 操作性 今回の選定にあたって特に重視したポイント 業務移行の容易さ 既存プログラムの改修コストをおさえたい特殊な文法はあんまり書きたくない システム運用性 SQL on Hadoopレイヤはシンプルにしたい
  15. 15. 操作性 業務移行の容易さ 特殊な文法はあんまり書きたくない システム運用性 SQL on Hadoopレイヤはシンプルにしたい 既存プログラムの改修コストをおさえたい 今回の選定にあたって特に重視したポイント
  16. 16. ANSI準拠SQLが利用可能・・・だと!? 多くのSQL on Hadoopの謳い文句
  17. 17. で、実際どれぐらいANSI準拠なの?
  18. 18. やってみた
  19. 19. 候補は君だ!!(なかなかマイナーな選択?) そもそもHiveQLだし 今回は対象外・・・ 当時はまだちょっと不安が あったので机上でパス
  20. 20. 簡単にHAWQの説明  最近OSS化されました!  PostgreSQLと同じ文法が利用可能  操作性はほぼRDB!ってかポスグレ!  (実は結構なダークホースなのでは・・・)
  21. 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. 22. 実際触ってみて分かった特徴 ってかもうポスグレ! バージョン1.2で一人前になった感じ 標準SQLでの記述はほぼカバーできている(と思う)
  23. 23. 操作性 業務移行の容易さ 既存プログラムを極力改修しない特殊な文法はあんまり書きたくない システム運用性 SQL on Hadoopレイヤはシンプルにしたい 今回の選定にあたって特に重視したポイント
  24. 24. アプリレイヤーからみたスキーマレス スキーマレス=柔軟な検索が可能
  25. 25. 下回り視点で考えてみると・・・ スレーブ スレーブ スレーブ DB スタンバイ用のプロセスのことも考えないとな… 構成要素(プロセス)もシンプルになりそう! ただでさえHadoopって構成する台数もプロセス数も多いから… スレーブ スレーブ スレーブ 実行プロセス 実行プロセス 実行プロセス実行プロセス 実行プロセス 実行プロセス マスタ マスタプロセス メタデータ マスタレス!! CTASやVIEWで スキーマの固定も可能!!
  26. 26. 選定の結果 今回はApache Drillを選択!! 標準SQLが結構ちゃんと使える(ようになった) マスタレスだから比較的障害ポイントが少ない 完全OSS(当時はHAWQが商用だった) 将来性!!!!!!!!! CTAS,VIEWで固定スキーマとしても操作できる柔軟性
  27. 27. でもちょっと不満も・・・ YARNによるリソース管理が部分的・・・ YARN HWリソース CPU CPU CPU CPU CPU CPU クエリによってはクラスタのCPUリソースを 大量消費してしまうかも・・・ →ユーザ側の意図せぬクエリがクラスタ リソースを食いつぶしてしまうおそれ YARN管理対象 のアプリケーション もっとCPUリソース使いたい・・・
  28. 28. 意外と大きな差がつくと思ったポイント  いろいろ情報を見てるとオンメモリで処理しきれなかった際の挙動が極端  DrillとHAWQはその点安定して処理できていた印象(途中に落ちない) ディスク メモリ SQL 大きなデータの結合処理も両者とも安定してこなせていた
  29. 29. 今後のアクション
  30. 30. 今後の検討課題  いざエンドユーザが使ってみてどうか…  パフォチュー・・・  認証認可どうしようか・・・(GRANT分などのオブジェクト単位での制御ができない) 俺たちの戦いはこれからだ!! また機会があれば「実践編」をお話しできたらと思います!
  31. 31. ありがとうございました!!

×