イーベイ|道のパフォーマンスを2倍に実践Hadoopのタスク

概要： eBayのCAL（中央アプリケーションログ）ログデータ収集システムがeBayの様々なアプリケーションのための責任があるとのHadoopのMapReduceジョブによってログレポートを生成し、アプリケーション開発者や保守担当者は次のレポートを介して取得することができます。

• パーセンタイルAPI呼び出しの応答時間

• サービスコールの関係

• データベース操作

eBayは、データの量は日々増加して、毎日PB CALログ大きさを生成しました。データ量の増加のために、コンピューティングリソース最適化するためのHadoopのMapReduceジョブがかなりの節約になります。この記事では、HadoopのMapReduceの（MR）の実務の問題に対処するために、開発者を鼓舞するために希望をこれらのHadoopジョブを最適化するためにどのようにeBayのチームを共有します。

 なぜ最適化  

ステータスは次のようにHadoopジョブCALレポートは次のとおりです。

 

• データセット：CAL PBはオーダーのために一日あたりに記録し、年間70％の割合で増加し、CALコレクトログ異なるアプリケーションから、そのログの内容が異なっています。データベース集中型の操作に属し一部、およびいくつかの複雑なアプリケーションごとに、ネストされたトランザクションが含まれており、データの量に大きな差をログに記録します。

   

• コンピューティングリソース：CALを共有Hadoopクラスタを使用。最適化の前に、CALのHadoopジョブが完了するために、クラスタ全体のリソースの約50％が必要です。そのうち9時間のみ、この9時間の終わりまで、この時点でキュー内で待機します仕事を実装するためのリソースを得ることができない、クラスタコンピューティングリソースの19％を使用することができますがあり、日中のHadoopジョブを報告CAL、それは80を持つことができますクラスタコンピューティングリソースの％を使用することができます。

   

• 成功率：92.5％のみのCALのMapReduceジョブの成功率。

 

 eBayのチームを最適化する方法 

私たちの経験を共有する前に、我々は簡単にHadoopのMapReduceのプロセスを説明します。

 

HadoopのMRジョブは、一般に5つのステージ、すなわちCombineFileInputFormat、マッパー、コンバイナ、パーティション分割、および減速に分割されています。

私たちの仕事は、の最適化から、主である実行時間とリソースの2点に。

 

1）実行時間

 

Hadoopのジョブの実行時間が最も遅いマッパータスクと長い最も遅い減速の使命で決定するとき。 

仮定：

• ：マップタスクの実行時間

•  ：タスクの数の地図

• ：タスクの実行時間を削減

•  ：タスクの数の地図

 

まあ、MRジョブ実行時間Tは次のように表すことができます。

タスクの実行時間をマッピングし、マップタスクの入力の数を記録し、出力は、レコードの数に比例しています。

 

また、Hadoopのジョブの計算の複雑さも、Hadoopのジョブの実行時間に影響します。いくつかの極端な仕事のために、同時に、我々は、GC時間の仕事を心配する必要があります。

 

要約すると、我々は、以下の三つの側面からのHadoopの実行時間を短縮する必要があります。

•  GC時間 

•  回避の傾きや減速のデータマッパー

•  最適化アルゴリズム

2）資源の使用

 

メモリリソース、仮定の使用を考慮すると：

•  ：メモリサイズのマッパーコンテナのMRジョブ

• ：減速メモリサイズのコンテナ

• ：アプリケーション・マネージャのコンテナメモリサイズにおけるMRの仕事

•  ：タスクのMRの仕事では、マッパー番号

• ：タスクの数リデューサー

 

次に、実行時間、メモリリソース及びRマッパー/ Hadoopのジョブの減速タスクの量に比例し、次式で表すことができます。 

そのため、リソースの使用を減らすために、我々は以下の点で努力をすることができます。

• 数マップを減らすか、タスクを削減

• マップまたはコンテナのサイズを縮小する作業を削減

• 実行時間ジョブの最適化

 

ソリューション

 

  1.  GC

GCは、私たちが遭遇した明らかな問題です。理由ジョブの失敗は、通常、「GCオーバーヘッド」または「メモリ不足」です。ジョブが成功し、Hadoopのジョブカウンタによって、あなたは、GCの時間を見ることができたとしても、非常に長いですが、GCは、CPUリソースを大量に消費します。

 

1)  Mapper中的GC

 

所有发到CAL的日志，都会使用CALrecord的数据结构。CAL事务是由多个CALrecord组成的逻辑概念。

 

CAL事务一般可以对应到用户的请求上。当应用程序对用户的请求作出响应时，应用程序都会记录CAL事务到CAL服务，而为了完成用户请求，这个CAL 事务往往会调用多个子CAL事务协同完成。也就是说，CAL 事务是一个树状结构，每个CAL事务都是这个树状结构的一个节点，而报告中需要的指标（Metrics）需要让每个节点知道其根节点信息，而在构建这个树状结构的过程中，节点是无序的。因此，需要保留所有节点信息以便帮助后来节点追溯其根节点。

 

例如，下图展示了典型的树状事务层次结构。CAL事务 F是根。它会调用B和G来处理用户请求。如果我们已经有了F、 B、 C，C要等到D节点出现，才能找到根 F。同时，这棵树上的所有节点都需要保存在内存中，否则其子节点将不能找到其根。

 

显然，这种情况没有清理机制，会导致OOM。为了解决这个问题，从日志的业务逻辑上，CAL事务应该具有时间窗属性，涉及同一个用户请求的所有CAL事务都应该发生在一个时间窗内。如果时间窗为t，并且CAL 事务的开始时间戳为ts，则所有子CAL事务应在ts + t之前发生。

 

在我们的实验中，我们假设时间窗为5分钟。我们对12个日志量最大的应用程序的日志数据来验证此假设。即，若现在正在处理数据时间戳为ts的CAL事务，则时间戳在ts-5分钟之前的 CAL事务都将从内存中移除。12个应用程序日志中，有10个可以保证几乎100％的准确性。同时，其他2个应用程序，此功能将会影响其正确性，我们对其设置了白名单，暂时不对其做处理。

 

时间窗口的设置有效地减少了Hadoop job执行时间，并将其成功率从93％提高到97％。

 

CAL日志与指标

 

优化之前，Mapper在处理一个CAL事务的时候，将组成该事务的CAL record完全读取到内存中，然后提取出CAL事务有关的所有指标，如上图左侧所示。而CAL事务的原始信息并不完全需要保存在内存中，我们只需要保存必要的指标即可，如上图右侧所示。

 

Combiner可以减少Mapper和Reducer任务之间的数据传输。在实际应用中，由于Mapper的输出数据量很大，Hadoop对Mapper的输出数据做排序时，将带来较长的GC。我们的解决方案是在Mapper端使用Combiner做预处理，减少Mapper与Reducer间的传输数据量，有效降低执行时间。 

 

2)  Reducer中的GC

 

Reducer与Mapper具有类似的GC问题。

 

用于生成CAL报告的Hadoop job输出两种类型的数据——15分钟粒度的指标数据和用1小时粒度的指标数据。其中Mapper负责将日志映射为对应的指标，指标格式为三元组<时间戳，指标名称，指标的值>，其中时间戳粒度为15分钟，当Mapper将这些信息发送给reducer时候<时间戳，指标名称>将作为键值，<指标的值>作为值，在reducer中，将不同Mapper任务输出的指标聚合（如计数，求和等），聚合的结果包括15分钟和1小时两种粒度。

 

在MR中，Reducer收到的数据，Hadoop将根据其键值排好顺序。优化前，Mapper发送给Reducer的数据以“时间戳+指标名称”作为键值，Reducer收到的数据格式和顺序如下图左侧部分：

 

Reducer 收到的数据

 

当计算指标Metrics1一小时粒度的值时，需要得到当前小时最后15分钟（Timestamp4）的数据，并保存Metrics1的其他时间的数据。即为了计算N个指标的一小时粒度的值，需要保存3N条数据在内存中。当N很大时，内存溢出在所难免。

 

为了解决这个问题，我们将键值从“时间戳+指标名称”调整为“指标名称+时间戳”。为了计算指标Metrics1的一小时粒度的值，我们仅需保存3条数据在内存中，解决了Reducer中内存过量使用导致的问题。

 

该方法解决了Reducer中的问题，并增强了Reducer的可扩展性。

 

 2. 数据倾斜

 

在检查Hadoop job里map任务和reduce任务时，我们发现一个Job中的多个map任务的执行时间从3秒到超过1小时不等。Reducer任务也有类似的问题。

 

由之前章节中的公式，我们将输入记录平均分配给Mapper或Reducer，以最小化和 。

 

CombineFileInputFormat可以帮助解决Mapper中的数据倾斜问题。之前，CAL MR job没有使用CombineFileInputFormat，使用CombineFileInputFormat后，其将多个小文件合并成一个分片，分片大小设置为256MB，每个Mapper处理一个分片，这使Mapper任务数量减少到之前的一半。

 

Partition能够处理Reducer中的数据倾斜问题。在CAL报告中存在着两个概念，一是报告名称，二为指标名称。对于每种报告，都有多个指标。优化前，分区策略是使用报告名称的哈希值。现在，使用报告名称和指标名称的哈希值作为分区策略，极大的改善了数据倾斜的状况。

 3. 优化算法

 

在Hadoop job执行时间的公式中，job执行时间与输入记录个数成正比。实验中，有两个数据集。数据集A为20MB，数据集B为100MB。数据集A的MR job需要90分钟才能完成。以B作为输入的job仅需8分钟就能完成。

 

分析CAL日志内容，有两种类型的日志：SQL日志和事件日志。SQL日志即数据库操作有关的日志。事件日志可能会引用SQL日志，而解析SQL日志则更为耗时。

 

因此，我们计算了A和B中的SQL日志数目，结果显示它们的数目接近。而在A中，引用了SQL的事件日志数目更多。显然，对处理引用了SQL的日志上，出现了一些重复的计算——每次引用都会重新解析被引用的SQL日志。为了解决这个问题，我们缓存了SQL的解析结果，在引用时直接使用缓存结果。优化之后，A的job可以在4分钟内完成。

 

优化结果

 

通过以上三个方面的优化，除了执行时间，任务的资源使用情况也得到了优化。

 

在优化之前，CAL报告job需要Hadoop集群中50％的资源才能执行完成。优化后，只需19%的资源就能执行完成。下图显示了Hadoop Cluster上的内存资源使用情况。左侧是优化前的情况，右侧是当前的情况。

 

Hadoop Eagle中的资源使用情况

 

Hadoop Eagle中的计算资源使用率

 

Job的成功率从92.5％增加到约99.9％。从 Hadoop平台服务质量考虑，Hadoop 将会终止执行时间超过1小时的job，而部分应用程序的数据需要更复杂的计算，所以很难在1小时内完成。优化后95分位的Hadoop job执行时间约为40分钟，远低于优化前的90分钟。

 

CAL报告MR job执行时间趋势

 

本次优化后，我们节省了超过60％的相对计算资源，相当于Hadoop集群中大约200个Hadoop节点，并且Job的成功率增加到99.9％。

 

总   结

 

当对线上项目做优化工作时，应始终关注数据质量。因此，在优化之前，应最先制定验证方案，使用具有幂等属性的数据来验证数据质量。

 

同时监控也是优化工作的重点——我们把所关心的KPI，如成功率、资源使用情况和job执行时间收集起来，有助于优化过程中观察优化效果。

 

最后，非常感谢eBay Hadoop team提供的支持与帮助，其中Hadoop技术专家金澜涛与徐冰泉深入分析用户场景，提出了很多非常有价值的建议和解决方案，使优化工作顺利进行，而Job优化不但可以让CAL提供更好的报告服务，也对Hadoop平台的稳定性与资源使用带来好处，是团队合作很好的实践。