另一个Hadoop峰会参加报告

1 年 ago

清, 宇

2 minutes

这篇文章是关于什么的？

这篇文章是2016年Hortonworks Advent Calendar的第17篇文章。

这篇文章讲了什么？

这是另一个Hadoop峰会的参加报告。
包括每个演讲的摘要（但实际上我们也有演讲资料，所以这只是补充说明）和我的感想。

推动数据应用的“Pivotal HDB（Apache HAWQ）”

马之内正幸（Masayuki Matsushita）推动数据利用的“Pivotal HDB（Apache HAWQ（鹰））”来进行演示。

HDFSに対する標準SQLによる高速クエリ処理
Hive、HBase、AvroなどHadoopデータとの連携
データローカリティ/ショートサーキットリード対応
各種統計解析関数に対応

元々はPivotal HDBだったものをOSS化し、Apache HAWQという形で公開したもの

MapReduceやHiveで処理をしていたが、GPDBで並列分散DBがある
並列分散DBのファイルをHDFS上に配置可能とするようにして開発したのがHAWQ

他プロダクトとの親和性

Ambariから既に統合管理が可能
YARN上でプロセスを実行可能

TPC-DS Performance Review –  比較: Pivotal HDB2.0 vs. Cloudera Impala 2.5

こちらについては公開なし。
実際のところこれは微妙な内容ですので、詳細は感想部分に。

どのような機能があるか？

マスター／スレーブ方式の構造
マスタは冗長化

何故早いのか？

データを各DataNodeに存在するHAWQセグメントサーバで受け取り、libhdfs3で書き込み。

良く使用されている用途は？

HDPと一緒に使っているケースが多い。SQLが高速なのが大きい。

「Pivotal HDB2.0与Cloudera Impala 2.5」的比较结果显示，HDB2.0的速度是Impala2.5的数倍。然而，Impala2.5已经是过去的版本，并且条件也不明确，所以不能太依赖这个结论。

这是一种使用所谓的原生API来驱动的SQL on Hadoop，通过HAWQ进行写入的数据无法从Hadoop的其他生态系统中读取（据我在社交活动中听说的），实际上它更接近于Impala + Kudu的存在。

因此，最終我希望能夠看到Impala on Kudu和Apache HAWQ在功能和實際速度方面進行真正的比較…是否有任何人可以幫忙呢？＾＾；

利用Spark Streaming进行系统验证的结果和设计时的宝贵经验。

目前数据尚未公开。

もうおなじみなのでここでは省きます。

SparkStreamingで出来ること

Windowオペレーション
状態更新オペレーション（過去のデータの合計値に最新のデータを加算）

検証結果と設計時のノウハウ

モデルシステム

運動リズムに合わせた音楽を再生するシステム

携帯電話から加速度などを収集
動作状況を判定5秒間隔で動作状況を判定

システム構成

センサデータ＞Kafka＞SparkStreamimg(MLLib使用)＞ElasticSearch＆HDFS
YARN上で動作
SparkStreamingが5秒間隔で運動状態を判定
学習済みの学習モデルを使用して判定
SparkStreamingはDirectStreaming方式で実行

KafkaのParittion数と同数のTaskを実行

構築後のチューニング

使用するノードの数を調整して全体としてスループットが出るようチューニング

Kafka Producerの送信メッセージサイズ調整
ElasticSearchのリフレッシュ間隔を調整
Producer、Brokerを増やすことでKafkaの性能を積み増し

発生した問題

ノード間の通信量より、Kafkaクラスタのネットワーク帯域がボトルネックとなっている模様
KafkaBrokerの1ノードあたりの通信量が帯域（1Gbps）を超過
レプリケーションが遅延実行されるため、通信量はぎりぎりおさまっていた

設計時のノウハウ

KafkaのPartition数をSparkのExecutorに割り当てたCPUコア数以上に設定する必要がある

パーティション数少ないとコアを使いきれない

Kafkaのレプリケーションでネットワーク帯域がボトルネックとなりやすい

10GB回線にする

Kafkaはメッセージをディスクに保存するため、ディスク性能がボトルネックになる場合もある

レプリカ数を調整
ディスクを追加
SSD化

通过增加Kafka的分区数，可以增加Spark的吞吐量。但是，如果增加的分区数过多，可能会导致IO竞争，性能会受到严重影响。因此，我认为在调整这些方面时需要实际尝试来确定最佳配置。

Spark Streaming 是否基于响应式流？

Spark Streaming是否基于响应式流？来自chibochibo的发表资料。

そもそもBack Pressureとは

ストリーム処理にてデータのフロー制御用
過負荷であることを前段のコンポーネントにフィードバックする仕組み

何故重要なのか？

送信側で常に一定のデータ量を保つのは難しいため
一時的な増加などの波はあってもシステム全体として動き続けることの方が重要

Sparkは1.5からBack Pressureに対応

Reactive Streamsとは

非同期ストリーム処理の標準化を目指す規格
ScalaだとAkka Streamsがサポート
JDK 9でFlow APIとして導入予定
Spring 5はReactive対応になり、その際にback pressureにも対応
動作原理

Subscriber側でサイズを制限
過負荷に直面するとSubscriberはback pressureのシグナルを送信
Back Pressureのシグナルは非同期
負荷状況に応じてPull型かPush型かは切り替わる

Spark StreamingのBack Pressure実装

Reactive Streamsには準拠していない。

Reactive Streamsの設計方針からインスピレーションを受けているものの、Sparkの内部がこの仕様を遵守するつもりはないとのこと。

ではどうやってBack Pressureを実現しているか？

StreamingListener#onBatchCompletedメソッド

ミニバッチが終了した段階で実行
下記のような情報が取得可能

ミニバッチ実行時間
処理開始時刻、処理終了時刻
スケジュール済～実行開始までの待ち時間
処理時間（ミニバッチ自体の処理時間）
スケジュール済～完了までの総所要時間

上記の値をRateEstimatorに渡して新しい取得Rateを計算し、次の受信量を決める方式

感想：
似乎并不符合规范。
实际上，Spark的Subscriber本身是基于Pull模型的，
所谓的延迟是指“小批处理执行间隔不符合定义的执行间隔”。
因此，遵守规范本身可能是一件困难的事情，这是我的看法。

也许，基于临时流量增长的基本流数据处理平台产品可以通过类似Kafka、Kinesis、Cloud PubSub这样的消息队列来处理。这意味着可能不需要遵循Reactive Streams的立场。

用AWS创建小中型Apache Kafka和各种烦恼

数据：
来自Keigo Suda的关于使用AWS构建Apache Kafka和各种问题的资料。

どのようなポイントがあったか
どのようにそのポイントに対応したか

IoTのためのデータプラットフォームを開発中

工場内の各センサーデータを収集加工蓄積分析するための基盤

IIoT(Industrial Internet of Things)

世界中にある工場に対して展開

そもそもなぜKafka on AWSなのか？

機密なデータも扱うのでVPCに対してDirectConnectで投入したかった

Amazon KinesisやAmazon IoTでは暗号化されているとはいえ、インターネットに出てしまう。それは避けたい。

Amazon Kinesis EndPointはないため、インターネットに出ない経路を保証することができない。

KafkaでマルチAZをどうするのか？

AZのどれかが障害発生しても全体としての停止は避けたい

東京リージョンは2AZのため、AZ毎にクラスタを配置することに

どうやってKafkaにデータを投入するのか？

API/Producer処理はGoで開発、クライアントライブラリはSaramaを利用
Brokerは内部向けELBにアタッチし、接続先クラスタを切り替える

トピック設計

トピックを細かく分割すると爆発的に増えていくため、工場単位に集約し、後段のストリームデータ処理部で分割

データの欠損が無いことをどうやって保証する？

各工場のデータと、最終的な出力データの数を突きあわせ
各工場からKafkaに対して投入したデータと、Kafkaに対して投入されたデータの数を突き合わせ

工場のデータを集約してKafkaに投入するため、突き合わせる個所は２か所

感想：
「由于缺乏Amazon Kinesis EndPoint，无法保证不经过互联网的路径」以及
「由于东京地区只有两个可用区，难以配置需要准备奇数个节点的集群」等等，
AWS的苦恼故事真是琳琅满目的…

然而，他并没有做出特别突飞的事情，而是稳定地积累和建设了应该做的事情，这是非常有参考价值的一次会议。

Hortonworks Data Cloud的概要

資料：
由姜一峰提供的介紹Hortonworks Data Cloud for AWS

Ambariによって、クラスタに対するデプロイの手間は大幅に軽減された。
だが、そもそもマシンを用意するのに時間がかかることが多く、導入に時間がかかる。
ならクラウドだ！

クラウド上でHortonworksのDataクラスタを構築

使用した分だけの課金
Privateなフォーラム上でのコミュニティサポートを無償提供

デモ

クラウド上にクラスタを即展開し、S3上のデータを外部テーブルとしてHiveにインポートし、即読むことが出来た！

オンプレミスのクラスタと異なる点

クラスタ自体が一時的なものとなるため、永続化する必要があるものはクラスタを跨いで保存

HiveServer用データなどのメタデータ
S3上に配置したデータ

コンピュートノードとストレージノードを分離

S3へのアクセスがリモートとなるため、性能特性が異なってくる。
レスポンスは劣るが、スループットは出る。

S3へのホットスポットを避けるためにランダム順で取得しに行くなどの対処が入っている
クラスタ単位にIAM Roleを割り振り、アクセス可能なデータを制限することも可能
Apache Ranger、Apache Atlasと組み合わせることでデータ権限管理が柔軟・容易に

Apache Ranger、Apache Atlasはマルチクラスタに対して対応可能になっている。

今後追加される機能

コンピュートノードの自動復旧

感想：
由於AWS已經存在Elastic MapReduce，因此它不僅僅是將分發放在雲端上，還採取了支持多集群和從外部讀取元數據等措施，以實現差異化。

我实际上觉得，在将数据放入云端时会产生与亚马逊或谷歌原有的大数据基础设施的竞争，所以确定自己的优势位置非常重要。

总结

整体而言，Hadoop峰会的内容和趋势多样，真可谓是作为Hadoop峰会的番外篇呢。
特别是最后一次演讲，尽管云计算也成为一个选择，但是并非竞争相同的功能和性能，而是期待未来更加突出差异化的演讲。