8月29日，为云计算优化的用于机器学习和分析的现代平台厂商Cloudera 全面推出Cloudera Workload XM，一个为当今的数据仓库设计的智能工作负载体验管理云服务。与传统的性能管理工具不同，Workload XM提供引导式自助服务工作负载分析，以便在整个生命周期内对分析工作负载提供可见性和控制。
随着企业开始意识到其数据资产的价值来以推动创新和竞争力，各种分析用例以及为其提供支持的应用程序工作负载正在以前所未有的速度增长。如何将分析工作负载需求的增长与业务用户对自助服务分析的期望相结合，大多数IT组织正处于挣扎的局面。尽管加强了传统的数据仓库，但大多数人发现他们无法监控和跟踪业务关键型应用程序，来满足预期的SLA或控制成本。企业需要提升规模，可靠性和分析体验，而这只有现代数据仓库才能提供。
Cloudera Workload XM专为Cloudera强大的混合云数据仓库而设计和优化，提供智能工作负载管理。它可以在不升级或安装任何软件的情况下工作，这意味着您可以马上开始使用而不必又安装一个软件工具。借助此服务，组织机构可以主动识别并消除瓶颈，最大限度地减少故障并提供超出预期的系统性能。通过自助服务故障排除和根由分析实现更快，更无缝的迁移。与单独的工具不同，Workload XM提供整个数据仓库的端到端可见性，有助于提高性能，减少停机时间并优化分析工作负载整个生命周期的利用率。
以下为Workload XM的产品演示视频。
作为全球领先的现代化平台，Cloudera转变了托管于多个租户间的关键性业务应用和工作负载，使客户能够做出以数据驱动的决策。这些客户不能发生应用故障或非计划性停机, 因此主动监测和优化工作负载表现就变得非常重要。
尤其是方案架构师，他们所面临的关键性挑战是无法通过统一的工具主动监测、分析和管理大数据应用及其产生的工作负载。
通过这个短片，我将为您演示Cloudera Workload XM是如何帮助客户应对这一挑战的。
我们以一个典型的中型金融服务机构作为示例客户，其元数据显示：
公司的文件或目录数量超过750万，非重复性数据达到196TB，大部分用户数据均生成为小文件，有223个数据库，近7000张表，仅四周就运行了大约200万条查询。
对于该公司的高级方案架构师来说，监测如此环境下的应用程序和工作负载表现的确是个挑战，那么他能满足所有SLAs的要求么？
用户会不会抱怨启动作业等得太久呢？
系统能否始持续的良好运行？
如何避免应用程序发生故障？
是否有事故根由分析的有效方法？
回答这些问题并且优化企业数据仓库的关键就是更好地了解工作负载。下面我们就来看看Workload XM是如何帮助解决这些问题的。
首先，在这2万个独立作业中，有将近2%的任务执行速度很慢，这意味着面临SLAs失效的高风险。这些是示例客户两周内所运行的全部作业，健康状态都不好。假设收到来自客户的SLA，要求所有任务的执行时间不能超过10小时。
这里可见，有相当一部分作业不仅不健康，而且无法满足客户的SLAs要求。
我们取一条执行超过11个小时的HIVE insert override查询做深入分析，看看能否找到有用的信息。这里我们看到，有4个任务的执行用时存在很大偏差，而643个任务中有2个耗时超过了10小时。进一步查看可见，这里不仅有一个失败的尝试, 而且处理的数据也比一般任务要多得多。如果没有这个问题，reduce stage 只需13分16秒就可以完成，和其他任务差不多
与此同时，应用程序开发却一直面临另外一个问题：
就是执行查询有时候要等很久，等很久而且还会以失败告终。
首先，我们看看有没有未完成的作业。
这里的确有几个未完成的作业，我们取一条运行超过13小时且最终执行失败的查询做深入分析。点击这个查询链接，就可以看到查询失败发生在reduce stage。
Execution Details那里会提供更多信息，点击这个失败任务，原来失败原因是出现了一个HIVE Runtime Error。打开相关的日志文件，可以进一步分析任务失败的根本原因。
架构师需要解决的另一个问题是，公司的应用开发人员和其它用户一直在抱怨查询等待过长，或是执行速度太慢。
我们再次利用Workload XM来探查原因。
首先，发现完成这个作业耗时19小时40分钟
仔细看在任务层级上的具体执行过程时，发现该作业的等待时间长达19小时15分钟，而执行成功只用了24秒。这说明信用风控小组可能缺乏资源，可能没有为他们分配足够的资源。
另一组的团队经常用该系统来生成BI报告，他们发现查询的执行用时会突然超出预期
我们先对运行过的查询进行过滤。这个操作叫作“账户分析”，用时已将近2小时。然后我们深入分析看看具体原因。执行过程中的确出现了一个时间峰值。我们可以通过查看trends来验证先前关于查询过慢的说法。这里可以看到，通常平均耗时32分钟的作业却突然需要3倍时间来完成，尽管作业处理和生成的数据量与之前并无不同。
现在我们打开Execution Details，查看运行详情。
可以看到，任务启动了1个多小时，map stage 却依然没有开始。这可能意味着该系统存在资源不足或并行性较差的问题。
总结来说，我们可以看到Workload XM对Cloudera通用数据平台上各种工作负载的影响，并利用这些功能如全面的风险评估，自助服务分析，来更快的产生价值。
更多资讯，请点击“阅读原文”
