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

JAWSBiGData

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

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

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

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

bigdata-jaws2

資料はこちらです。

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

  • 参加者の比率の確認(挙手で)
    • 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!

質疑応答

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

さいごに

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

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

AWS Cloud Roadshow 2017 福岡