NTTデータ Hadoop/Spark エンタープライズソリューションセミナー2016

プログラム

markdown記法の練習のために、セッション中にメモした内容。

  • メモが間に合わなかったため、大切なところが抜けている
  • 打ち間違い、聞き間違い
  • 理解できていないための間違い

などなど色々あると思いますが、とりあえず残します。

概要

  • 日時：2016-11-16 10:00-17:30
  • 場所：秋葉原コンベンションホール

基調講演

1. NTTデータ 10:00-10:30

  • ビッグデータ処理（Hadoop, Sparkにより可能となったこと）
    • サンプリングでなく、全量データを扱う
    • 個々に対してアプローチする
  • 流通・小売
    • POSデータ解析
    • CRM・電子クーポン・ポイント付与
    • O2O (Online to Offline)
    • デジタルマーケティング
  • 先頭を走る人のアプローチ
    • リスクを許容して、先行者利益を取りに行く
    • ニーズの多様化
  • 追従する人のアプローチ
    • 投資効果を最大化、効率よくトレース
    • 既存技術でまかなえない箇所をピンポイントで埋めて差し切る

2. 三井住友カード 10:30-11:00

  • メインフレーム上のバッチ処理をHadoopでオフロードする取り組みの紹介
  • クレジットカード業界のトレンド
    • 決済手段の多様化
    • ネットチャンネルでの決済の増加
    • 決済金額の少額化
  • 課題
  • Hadoopに対して
    • もともと会員番号帯により処理を分散化させることを行っていた
    • ホストのCOBOLをJavaに置き換えることへの不安
    • 2014年度、PoCの実施（ホスト処理の負荷軽減、コスト削減、性能）
    • 顧客影響の少ない処理から実装
    • 2015年から開発開始、2016年7月から並行本番、10月本番稼働
  • 目的
    • ホストの負荷軽減
      • すでに30年以上稼働
    • 月次処理削減によるコスト抑制
    • プラットフォームの最適化
  • 判断
    • 高負荷ジョブの抽出を支援するツールの開発
    • 高負荷ジョブのHadoop移行試験（PoC）
  • 目標
    • Hadoop基盤の構築
    • ホストAPのオフロード・汎用検証機能
      • 100MIPSの削減
      • 6時間30分から10分11秒の削減
    • 共通機能・運用機能開発
  • 今後、Hadoop基盤の拡充

3. 大東建託 11:00-11:25

  • ゆるキャラグランプリ2016総合160位だいとくん
  • プロジェクトの背景（7つのリスク）
    • 空室、家賃下落、家賃滞納、退去時費用負担、建物老朽化、火災・地震被害、借入金利変動
    • 賃貸経営受託システム
      • 「家賃収支」と「修繕収支」のリスク管理
      • 現状の課題
        1. 予め定義した軸でしか見られない
        2. 営業所単位など粗い分析
        3. 個人スキルに依存している
        4. タイムリーな分析ができない
      • 採用
      • Hadoop、NTTデータ
      • 効果
        • 部屋単位を積み上げて建物単位の精緻な分析
        • 個々のスキルに依存しない
        • 分断されていたデータ抽出・加工・分析を自動化することでタイムリーな分析
      • 展望
        • 活用実績の積み上げ
        • 外部データの取り込み

4. トレジャーデータ 11:25-11:50

  • 5年目、3度目の増資、100名、カリフォルニア、東京、ソウルの3拠点
  • Live Data Management
  • fluentd
    • 事例
      • 大量の証券取引ログ収集を高信頼化・ゼロデータロスに
        • 監査・統計用のログデータロス、配信遅延の問題をfluentdで解決
      • Atlassian
        • jira, hipchat等のログをkinesisに渡す
      • Microsoft
        • OMSのLinuxに標準で採用、Azureに採用を検討
      • Google
  • embulk
    • fluentdは、逐次（デフォルトで5分）転送
    • embulkは、バッチ転送（バルクロード）のためのツール
    • 事例
      • Tresure Data Connector
        • ユーザがS3にデータを置くと、embulkのワーカーがデータを取りに行く
          • 従来は、ユーザ側でキックする必要があった
  • 今年6月から、NTTデータとエンタープライズ向けのサポートを開始した

午後のセッション

Apache Sparkのエッセンス 13:20-14:00

  • 今年7月に2.0リリース。2年ぶりのメジャーアップデート
  • まずHadoopの説明
    • MapReduceの課題
      • ジョブ間のデータ受け渡しにHDFSへのI/Oが発生
  • Sparkの登場
    • RDDと呼ばれるデータコレクションに抽象化
    • キャッシュによって、ジョブ間のデータ共有を効率化
  • Sparkの今
    • DataFrame/Dataset
      • DataFrame
        • RDBMSにおけるテーブルのようなデータ構造
        • SparkSQL
        • オプティマイザにより最適化されて実行。開発言語の違い（バックエンド処理が異なる場合がある）による性能劣化が起きづらい
      • Dataset
        • DataFrameを発展
        • JVMのオブジェクトをDatasetの行
        • 型名や列名の間違いをコンパイル時に検出可能
    • Data Tungsten
      • ストレージ、ネットワーク性能の向上。一方CPU性能は頭打ち
      • CPU利用効率の改善
        • 独自のメモリ管理機構の導入
          • JavaのUnsafe APIを用いて自前でアロケート
        • キャッシュアウェアなデータ構造/アルゴリズムの導入
          • アルファソート
          • BytesToBytesMap
        • Codegen（実行時コード生成）
          • カスタムコードを生成して式の評価を単純化
      • Spark 2.0での取り組み
        • Whole Stage Codegen
        • Vectorization
          • SparkSQLにおいて、パーケーを用いた場合の高速化
      • 今後
        • Project Tungsten 2.1+
        • DataFrame/Dataset向けライブラリの拡充
          • Structured Streaming

Apache Kafka 14:10-14:50

  • 複数台のサーバで多くのデータを処理するメッセージングシステム
  • よそから送られたメッセージを受け取り、よそにメッセージを送る
  • エンタープライズで有用な特徴
    • 幅広いユースケース
      • リアルタイム処理基盤のメッセージングシステム
        • ここでいうリアルタイム処理とは、収集から数百ミリ秒から数秒でデータが処理される処理方式のこと
        • データの収集先が増えたときなどの変更の容易さ
        • バーストトラフィックなどが発生したときにもデータを失いにくい
        • 異常時の再処理にも対応してくれる
        • Server -> Kafka -> Spark(リアルタイム処理基盤) -> 結果
      • ログ収集/集約基盤
        • ここでのログとは、各サーバで発生するアプリケーションログだけでなく、顧客の行動ログ（購買記録など）なども含む
        • 複数のサーバや部署、複数の場所からのログ収集が容易
        • 複数人/複数システムで同時利用が行いやすい
        • リアルタイムの分析
        • ログの一元管理
      • Webサービスの処理基盤の一部としての利用
        • Event Sourcing / CQRS
        • 大量のメッセージを処理でき、リアルタイム処理との相性も良い
        • スケールアウトの特性から、性能の増強が行いやすい
    • 堅牢かつ柔軟な構造
      • 分散メッセージングシステム
      • 数台の故障でデータを失わない
      • 数台の故障で停止しない
      • 受信に失敗した場合もリカバリ可能
      • 送信に失敗した場合もリカバリ可能
      • スケールアウト
        • サーバ台数の増減で全体性能を調整していく仕組み
    • 他プロダクトと容易に連携
  • 利用状況
    • Web系、テレコム系、金融系など
    • Uber
      • リアルタイム処理、アドホック分析
      • ロストの許されない大量データを扱っている
      • 一旦Kafkaに入れることで、リアルタイム処理、アドホック分析それぞれに利用
    • あるWebサービス（NTTデータ支援）
      • 全世界を対象としたサービス。リアルタイム処理が必要
      • イベントの受け取りにKafkaを採用
      • 同時にHBASEも採用。全体をスケールアウト可能な構成で構築

IoTを支えるインフラ技術 15:10-15:50

  • 撮影禁止
  • IoTの全体像
    • Webコンピューティング(information) -> ユビキタスネットワーク(people) -> モノのインターネット(things)
    • 単純にインターネットにつながると捉えるのでなく、インターネットのようにつながると捉えた方がよい
    • ユースケース
      • センサネットワーク
      • スマート工場
    • 「デバイス」がコネクティビティを持つということ
  • NTTデータの考えるIoTプラットフォーム
    • 「デバイス」と「ビジネス」をつなぐもの
      • つなぐ IoT Gateway, Devise Management
      • ためる
      • いかす Stream Analytics, Data Distribution
      • みまもる Real-time System Monitoring,
    • 高い性能・拡張性、可用性が求められるユースケースがターゲット
    • IoTならではの難しさ
      • 接続デバイス数が多いため、メッセージ処理件数・同時接続数が多い
      • 超大量のデータが発生する
      • データの種類（独自電文フォーマット）が多い
  • IoTプラットフォームのアーキテクチャと特徴
    • 複数の分析ニーズに対して、ストリーム処理用とバッチ処理用で系を分離
    • 分析用データストアを用とごとのデータストアを用意して独立性を高める
    • 収集
    • 蓄積・変換
      • ストリーム
        • Apache Storm 連続して送られてくるデータを数十ミリ秒で処理する
        • Redis インメモリのデータベース
      • バッチ
        • Spark Streaming メッセージブローカからのメッセージをある程度の単位にまとめてバッファリング
        • Openstack Swift PB、EB級のデータをアーカイブ用のデータストア
        • Hadoop HDFS バッチ処理用のデータストア
    • 分析
      • 分析ETL
  • 特長まとめ
    • 高性能
      • 分散処理で性能向上を図る
      • 基盤の監視・可視化で、基盤の処理の偏りを捉える
      • 可視化の例 platform -> fluentd -> elasticsearch -> grafana
    • 高スケーラブル
      • 必要十分なインフラ設計・構築が対コストで重要
    • 高フレキシブル
      • IoTでは、色々なモノがつながる
      • 千差万別なデバイスから送られるデータをスマートに解釈する
  • 例
    • BRIMOS 橋梁監視
    • ANYSENSE IoTプラットフォーム　上下水道分野、工場・プラント管理など

Fluentd & Embulk 16:00-16:40

  • データ処理基盤の構築における諸問題
    • 前提
      • Data Source -> Collect -> Store -> Process -> Visualize -> Reporting/Monitoring
      • プロジェクトごとにノウハウ共有しづらい
  • Fluentd / Embulk
  • Fluentd
    • オープンソースソフトウェアのログコレクタ
      • 例；syslog, flume, ...
    • サーバ常駐型のデーモンとして稼働
    • Input, Filter, Buffer, Output plugin
    • 可用性：耐データロスト・高効率
      • Batch
        • 転送エラーが起きた時、すべてやり直す必要がある
      • Stream
        • チャンクにわけて転送するため、転送エラーが起きてもその部分だけ再送すればよい
  • Embulk
  • 使い分け
    • Fluentd
    • Embulk
      • マスタデータの同期
      • 1日毎のデータ移動
      • AWS(S3)からの並列データダウンロード（CSVファイル）
      • DWHへのデータロード

PostgreSQL 9.6 16:50-17:30

  • 9月末にリリース, 9.6.1が10/27にリリース
  • PostgreSQLについて
  • 9.6の新機能
    • パラレルクエリ
      • 一つのSQLを複数のプロセスで分担して処理できる
      • 並列処理できるのは、検索と集計と結合
      • できないのは、更新、削除、インデックス作成、ソートなど
      • オラクルと異なり、CPU数を考慮せずテーブルサイズを元に並列度を算出
      • 200コアのマシンで検証したところ、60までは性能向上した
    • VACUUMの性能、運用性向上
      • Freeze Map
        • VACUUMの問題への対応
          • VACUUMは、全テーブルを問答無用でフルスキャン。ディスクI/OやCPUを消費
          • いつ発生するかは、PostgreSQL次第
          • キャンセルできるが、実行しないままでいると、PostgreSQLがある日突然停止する
          • 近年、DBに格納するデータが増大。数TB以上も普通になってきたため、問題が大きくなっていた
        • デフォルトで有効
      • Vacuum Progress Checker
        • Vacuumの進捗状況が見える
    • マルチ同期レプリケーション
    • 外部データ連携（FDW）
      • FDW 外部データをあたかもPostgreSQLのデータとして扱える機能
        • oracle_fdw, postgres_fdw, twitter_fdw など色々ある
        • postgres_fdwを使って、分散処理構成をとる
      • 結合やソート処理、更新、削除も外部サーバに依頼可能となった
  • 今後
    • 今年は、各社がロードマップを公開している
    • PostgreSQLのバージョニングが変わる