【.com快译】关于现代数据分析师在分布式计算环境中的有效性一直存在长期争论。分析师习惯用SQL在短时间内查询问题的答案。当查询在数小时内没有返回结果时，RDBMS用户通常无法理解根本原因。Hive和Spark等查询引擎对于高级工程师来说很复杂，但有些人并不这么认为。在Acceldata上，我们可以看到在多TeraByte表上运行全表扫描来获取行数，这至少在Hadoop中是不允许的。事实上，数据需要转化为洞察力来做出业务决策。值得一提的是，大数据的价值需要实时获取。Hadoop管理员/工程师准备解释大量指标并分析性能不佳的原因以及从集群中获取的资源导致：?失控资源问题?失控计时问题?泄漏导致停机，然后才能启动纠正步骤必须提供以下详细信息：?历史查询性能（在重复查询的前提下）?执行视图-映射器（mapper），减速器（reducer），连接效率?数据视图-哪些表（事实维度）?YarnContainerEfficiency?执行计划——（逻辑和物理计划）历史查询性能：AcceldataAPM对在交互式BI队列上运行的每个SQL进行指纹识别。这是通过解析AST并记住经常使用的查询的参数不断变化来完成的，例如，在每日报告的情况下。下次运行SQL时，Acceldata能够将查询的过去性能与最近运行相关联。查询执行参数中的异常（如下所示）直观地指示异常：?持续时间过去了?从HDFS读取的数据?写入HDFS的数据?VCore的使用?内存利用率执行视图：在某些情况下，当Reducer花费很长时间时，查询耗时很长，像个“散兵游勇”，消耗了90%以上的时长。这种识别有助于补救；但是，如果不登录多个服务器并且没有跨层的横截面视图的帮助，要实现这一点是非常具有挑战性的。Acceldata结合Yarn诊断日志来可视化Mappers和Reducers的持续时间、顺序。以下是纱线诊断数据，显示纱线应用程序从开始到结束的执行阶段。这提供了一个清晰的思路，即如果Yarn应用程序被抢占，内存和VCore分配是多少，以及这些应用程序中可以处理作业的容器数量是多少。还提供了诊断消息，允许用户在作业失败的情况下识别异常情况而无需离开UI。SQL和数据视图AcceldataQuery360提供SQL视图、正在查询的表和正在运行的连接。除此之外，还有有关过滤条件、过滤谓词是否准确以及特定连接是否对查询产生不利影响的详细信息，这是SQL诊断的最重要方面之一。查询计划任何查询的最终诊断都需要了解查询计划。Acceldata支持Hive和MapReduce-Tez、MapReduce和LLAP的所有类型的查询计划。这为管理员和数据工程师提供了一种简单的方式来了解——TableScans，操作行为是有意还是无意，广播连接发生的位置，是否启动了CBO，是否为特定查询设置了PPD，以及是否进行了哪些连接优化完毕。表Hive表的布局会对查询性能产生重大影响。在没有数据压缩或准确分区的情况下，很可能会对表进行端到端扫描，或称为TableScan，因此Mappers将花费更长的时间来完成，尽管有过滤谓词。然而，为了对分区策略做出明确的决定，需要了解表和列的组合使用。分析师不是运行一个查询，而是运行多个查询的组合，以确定哪个是理想的分区键以及表是否可以静态或动态分区。该视图如下所示：结论Hive和Spark用户和管理员很难获得表示查询/作业执行横截面的视图。可见性仍然是分布式计算领域的一个挑战，尤其是在Hive和Spark工作负载上。Acceldata支持360度数视图进行决策。从以上部分，我们可以清楚地看到管理员/工程师拥有所有可用于识别和纠正的信息：?同一查询的当前和过去运行的历史比较?执行查询的时间?有问题的表及其joins?Mapper和reducer性能异常?分区策略在物理文件系统上的数据布局?查询计划以快速轻松地做出决策
