Hadoop / Spark Conference Japan 2016 に参加してきました
2/8に開催されたHadoop / Spark Conference Japan 2016に参加してきましたのでメモなど残しておきます。
午後からの参加で見たセッションのみなので一部だけになりますが。。
www.eventbrite.com
データドリブン企業における、Hadoop基盤とETL ～niconicoでの実践例～
嶋内 翔（Cloudera）志村 誠（ドワンゴ）
従来データは主に経営層やマネージメント層向けにETLの結果を見せるケースが多かった。
ところが、現在では分析をする人やエンジニアなど現場で見たいケースが増えていて、ETLの結果を待たずに直接データに触りたいという要望が増えている。
→ 生データをHadoopに入れて誰でもアクセスできるようにする
hiveのスキーマオンリードの活用
- データの投入時ではなく読み込み時にスキーマを使う機能？特性？
- クエリを実行する側がスキーマを決められる
Keiser Permanenteの事例
- Hadoopに生データを入れて、ユーザ定義領域を挟むことで使いたいデータを取得できるようにしている。
niconicoでのETL事例
→ データを一箇所に集める必要があるのでHadoop基盤の活用
www.slideshare.net
www.slideshare.net
ビッグデータ可視化の性能を徹底検証 ～SparkSQL、Hive on Tez、Hive LLAPを用いた既存RDBデータ処理の特徴～
新郷 美紀（NEC）蒋 逸峰（Hortonworks）
3つのデータストアに対してtableauで可視化する際の性能検証
SparkSQLでは
- ブロードキャスト変数を使うとジョブ開始前に全ノードに小さなテーブルのようなデータを投げることができるので、うまく使えばシャッフルがなくなる=ステージが減る。
- テーブルをメモリ上にキャッシュできるが、今回の実験では効果がなかった
メモリ量、データ量、処理内容との兼ね合い？
実行時間の比較
- ヒットするデータが少ない場合は、hive on tezとLLAPが速い（全体のデータ量ではなくヒットしたデータ量）
hiveのチューニング
- tableauからの実行時間の検証でクエリは自動生成されるため、クエリのチューニングはできないのでhive側のチューニングに集中した
- 時間がかかる箇所の特定 → yarn上のアプリケーションマスターの立ち上げに4,5秒かかるなど
- hiveは正しくデータロードすることが重要 → パーティションとORC形式でのストアがキーになる
LLAPは常時起動しているコンテナを持っていて、コンテナ立ち上げのオーバーヘッドを減らすのと、インメモリなキャッシュを聞かせられるメリットがある。
www.slideshare.net
Spark MLlib Now and Beyond
石川 有（リクルートテクノロジーズ）
Apache Sparkの機械学習パッケージMLlibの現状と今後のロードマップについての発表。
MLlibの中にmllibとmlの2つのパッケージがある。
- mllibではRDD形式でデータを扱う。mlではDataFrame形式で扱う。
- mlはML Pipelinesと連携できて、前処理、チューニング、検証などの枠組みが用意されている。
- 学習モデルの永続化サポートがされるようになった。
→ Pythonで学習したモデルを永続化して、Scalaで予測に使ったり、Spark Streamingに使ったりできる。
www.slideshare.net
基幹業務もHadoopで!! ～ローソンにおける店舗発注業務へのHadoop + Hive導入と、 その取り組みについて～
須田 桂伍（フューチャーアーキテクト）
店舗発注業務 = 店員がタブレットで商品棚を確認しながら発注する業務 → 本部センターで一括処理したい。
エンタープライズでは扱うデータ量は少ない割にバリエーションが多い。
- 常時処理は常時起動しているEMRでupdate insertして、ピーク時のバッチ処理の時にテーブルを洗い替えする
- 途中で何かあった場合の再処理
→ 1店舗の処理を1ワークとして、その中に必要なSQLを全部書いておく。途中で止まった場合は最初から実行する。
ちなみに、Sqoopを使ってMySQLにインポートする場合、MySQLimportで文字化けが発生する
→ Sqoopのコード中のMySQLUtilの中のISO...と直書きされているところをUTF8と書きなおしてビルドすれば動くらしいです。
www.slideshare.net
Maintainable Cloud Architecture of Hadoop
佐々木 海（Treasure Data）
maintainableなHadoopに必要な条件として、
- stateless
何か起こった場合に置き換え可能。状態を持つのは一箇所に集約する。（クラウド上など安心できるところへ） - mobility
場所を移動できる（データとかジョブとか） - queueing
リトライできる
PlazmaDBを使った構成では、statefulなのはPlazmaDBのみに集約する
- PlazmaDBの内部はPostgreSQLとS3(またはRiak)で構成されている。
- 変更があった場合、S3(またはRiak)に順次書き込まれて、commitメッセージが来たタイミングでPostgreSQLに入れる。
- S3(またはRiak)はimmutableで変更されることがないため、整合性が保たれる。
クラスタのバージョンアップ対応
- クラスタ(CDH, HDP, Apache) のバージョンが変更された場合、worker(APIサーバ)が全クライアントを持っていて、接続時に接続先のクラスタのバージョンに合わせてconfigを切り替えて接続する。
- CircleCIでクラスタのバージョンも管理していて、バージョンアップした場合には対応するクライアントをS3にアップロードする。workerが実行する際に対応するクライアントをS3からダウンロードして使う。
www.slideshare.net
感想
導入事例の紹介が多かったため、アーキテクチャまわりのチューニングや性能検証について聞けて勉強になりました。個人的には、春頃にSpark2.0が出てくるそうで、速度10倍とフロント側API導入で大きく変わりそうで楽しみです。
午前のセッションだったので見れなかったのですが、、、
