BigData-JAWS 勉強会#2 参加レポート（Embulk/DigdagとRedshift）#bdjaws

はじめに

データインテグレーション部　大矢です。

2016年9月26日開催のBigData-JAWS 勉強会#2に参加してきました。 この記事はその前半、弊社川崎の発表した「EmbulkとDigdagで作るRedshiftデータマート」のレポートです。

EmbulkとDigdagで作るRedshiftデータマート

資料はこちらです。

発表者はクラスメソッド株式会社 川崎照夫。

• 参加者の比率の確認（挙手で）
  • OLTP系の人　　2名
  • 情報系、DWH系の人　　多数
    • ビッグデータの勉強会なので、やはり情報系の人がほとんど。
• データマネジメント概説書
  • JDMC（日本データマネジメント・コンソーシアム）という団体があり、（川崎も）以前参加していた。
  • JDMC知っている方？（挙手で確認）
    • ほぼゼロ
      • 残念ながら、知名度が低い。
  • JDMCでは「データマネジメント概説書」という書籍を出版している。
    • 「DMBOK Guide」もあるが、日本の企業にそのまま導入しても適応が難しいということで、作成された。
  • そこにはデータマネジメント構成要素を一枚にまとめた図があり、これがとてもよくできている。
  • 戦略、オペレーション、組織、人材など、データマネジメントに関わる構成要素は多岐にわたるが、真剣にデータマネジメントに取り組むと、これぐらいのことが必要になる。
    • データ分析に取り組もうと考えるお客様側に、このような意識が無いと、データ分析案件を進めるのが難しくなる。
• データマネジメントあるある
  • データ構造は建物のように目に見えない
    • データがきれいか、しっかりしているかは、目に見えない。
      • 地道な集計をすることでしか、見えてこない
  • 全部やろうとするからいけない
    • データ分析に取り組む際、「一度に全部きれいにしてしまおう」と考えがちだが、そうすると大変すぎて、途中で断念してしまう、ということになる。スモールスタート推奨。
  • （質問）実際にお客様にこういう話はしますか？
    • 「スモールスタートを推奨する」という点は、話します。（川崎）
• クラウドでデータ分析基盤構築
  • RedshiftはDWHの中心になってくると思う（EMRよりも）。
• 書籍「10年戦えるデータ分析入門」の紹介
  • 11章以降に、データ分析基盤について書かれていて、これがとても参考になる。おススメです。
  • SQL中心アーキテクチャの条件
    • 必要なデータを1つのDBに集める
    • データの加工にはSQLだけを用いる
    • データベース内をソースデータ層、DWH層、アプリケーション層に区分する
• データ分析システムのソフトウェア構成
  • ETLツール　　Embulk
  • スケジュール実行の仕組み　Digdag
  • 可視化、分析　　Tableau
  • ドキュメント管理(メタデータ管理)　dmemo
    • リクルートさんでもメタデータ管理Webという取り組みをしている
• Embulk/Digdagに注目する理由
  • Embulkはバルクデータローダー
  • Digdagはワークフローエンジン
  • どちらもTreasureData発のOSSである。
  • ETLツールの代替えになる。
  • テキストベースの設定ファイルで、バージョン管理しやすい。
  • guess(推測)機能があり、データ型を推測して自動処理してくれる。
• ETL(Extract、Transform、Load)からELTへ
  • 先にRedshiftにロードしてから、変形、加工を行うことで、Redshiftの豊富なリソースを活用することができるので、ELTがよいと考える。
• サンプルデータ
  • TPC-Hはスケールファクタを設定することでデータを簡単に増やせる。
  • TPC-Hのスタースキーマ版であるSSBを使用する。
• デモで使用するAWS環境の構築は、CloudFormationを使って一発起動するようにしている。
  • CloudFormationのテンプレートを作成したので、後日ブログで紹介予定。
• Embulk/Digdagのインストール
  • インストールはどちらも数コマンドでできるので簡単です。
• Embulkの問題点
  • guess機能で、データ型を推測して、自動で作ってくれる。が、string型はVARCHARの最大長(VARCHAR(65535))になってしまうという問題がある。
    • 手動でDDLを直して、再度CREATE TABLEを行う必要がある。
• (Redshift)MPPとシェアードナッシングがスケールアウトの鍵
  • MPP(Massively Parallel Processing)
    • 1タスクを複数ノードで分散処理する。
  • シェアードナッシング
    • ノード間でディスクを共有しない。よってスケールアウトできる。
• Redshiftベストプラクティス
  • ソートキーには、以下のような列を選択するとよい。
    • タイムスタンプの列
    • 範囲フィルタリングする列
    • JOIN条件の列
  • 分散キーを設定する際は、ファクトテーブルはキー分散、小さいテーブルはALL分散を推奨。
• デモ
  • Embulk、Digdagを使って、S3上のデータをRedshiftにアップロードする。
  • テンプレートを起動するシェルスクリプトを起動すると、5分ほどで、RedshiftとEC2インスタンスが起動した。
• Redshift Try!
  • クラスメソッドでは、Amazon Redshiftの利用料が最大$2,000無料に！導入検証支援プログラム「Redshift Try!」を開始します
  • https://dev.classmethod.jp/cloud/aws/redshift-try/

質疑応答

• Digdagはどれくらい利用されているか？Digdagをすでに使っているが、ドキュメントなど情報が少なくて苦労している。
  • まだ利用に向けて取り組んでいる最中。他社では事例があるようだ。（川崎）
• DigdagでETL処理を行ったとき、処理が途中でエラーになった際リカバリーはできるのか？
  • べき等を担保するようにし、再実行で対応する方針である。（川崎）
• ジョブスケジューリングもDigdagにまかせているのか？
  • Digdagのジョブスケジューリング機能を使用しているが、問題なく動作している。（参加者）
• ジョブスケジューリングに何を使用しているか（挙手で確認）
  • digdag　2
  • Luigi　　1
  • JP1　　　2
  • Rundeck　1
• Embulkをインストール入れるときは、どうしてる？
  • AMIにあらかじめ入れておく（川崎）
• 「必要なデータを1つのDBに集める」という話だが、ドキュメントデータ等、非構造化データも集めるのか。
  • 分析対象とするデータは、基本的には構造化データを想定している。（川崎）
  • ソースデータ層には、非構造データを置いておくのもアリ。その中で分析に必要な部分は、構造化したテーブルに抽出して使用する。（川崎）
• Embulkで不得意なところはあるか。それにどう対応しているのか。
  • 文字列処理などはやりづらい。別のツールを使うなどで対応している。（川崎）

さいごに

質疑応答でも活発な議論がありましたが、この勉強会は、ビッグデータ関連の技術について語り合える貴重な場なのだと思います。 参加者のみなさんの貪欲な姿勢がうかがえました。

また参加したいと思います。