大多数大型组织都实现了一个或多个大数据应用程序。随着他们积累越来越多的金融交易、销售数据和客户交互，他们就可以生成更加准确的销售预报和预测客户需求趋势。这将转换为更大的市场份额和更高的收益。

然而，随着积累的数据越来越多，内部用户和分析师会执行更多的报表和预报。这些都会导致额外的查询、分析及报表。这个循环还在继续：数据增长带来更好的分析，而分析又会产生更多的报表。最终，大数据应用程序会充满大量的数据，从而影响查询性能。

如何避免这个问题呢？

大数据信息获取与存储

信息技术（IT）支持人员可以从几个方面去主动解决大数据应用程序的性能问题。第一个是数据获取与存储，有时候也称为提取、转换与加载（ETL）。

大数据应用程序会将它们的数据存储在一个大型数据库或者一个特殊的混合硬件/软件设备中。有时候也会混合使用这两种方法。大型数据库可能是关系数据库（如IBM DB2）或数据库机器（Teradata）。设备是一种整合大规模并行I/O通道和超大磁盘阵列的新数据存储手段。在很多时候，它们还需要与一个现有数据仓库协同工作，因为可能组织中大量现有分析数据都已经存储在这个数据仓库中。

数据的最后一个方面是帮助我们确定需要对运营数据执行多少预处理。这有时候称为数据整理。常见的例子包括处理缺失或无效的数据，将代码替换为描述性分类数据，以及为具有唯一自然键的实体分配代理键。

数据从运营系统和外部数据源到达应用程序。IT必须保证来自运营系统的数据元素的正确性，其格式要适合批量加载。数据通道既要有足够快的数据传输速度，也要有足够大的带宽去支持多数据流的交行传输。大数据应用程序的日常增长每天都会增加GB数量级的数据。一定要保证这些数据能够快速高效地传输。

大多数据数据库管理系统（DBMS）和设备都有一些用于加载数据的专有工具。这些工具有时候要求输入数据使用一种固定的格式。要检查这些需求及其他选项，确定是否有一些方法可以保证数据加载速度满足要求。对于关系数据库，有一种常用方法是合适分区表。例如，在表中定义用4个分区来存储一天的数据。这样IT人员就可以设计一个加载流程来并发加载4个分区。

最后一领域是数据存档和净化。虽然表面上数据量越多就自然可以推出分析更好，但是一些历史数据可能变老或失效。例如，一些已停止销售产品的销售数据，公司停止服务地区的客户数据等。这些数据应该净化或存档。净化可以减少所需要的数据存储量，而存档则允许在将来需要数据时重新加载数据。无论是哪一种情况，减小工作数据库的大叔都可以加快查询速度，因为它不再需要过时的数据。

大数据用户

谁是你的用户，他们如何查询你的数据？典型的用户是一位业务分析师和主题专家，他们理解你的业务数据，具有高明又高效地访问大数据应用程序的技术知识。这可能意味着他们精通SQL等查询语言。另一个方法是安装分析软件，展示图形化业务数据视图，并且基于用户界面来构建查询。

在许多组织中，他们安装的第一个大数据应用程序就是为了解决一些特殊问题，或者为了分析预定问题，即用例。分析师已经知道哪一些查询可以产生有用且可操作的智能。

接下来，第一次分析的结果是产生“如果……将会怎么样（what if）”的问题，这会导致需要访问更多数据的更多查询。随着这些查询提供数量更多的有用结果，管理层自然会开始将它们调整为常规报表。

IT支持人员必须规划查询在数量与复杂度方面的增长需求。这比规划未来数据存储容量增长要复杂得多。复杂查询要求数据库管理系统选择一条高效的数据访问路径。这可能要求增加给数据库一些提升性能的特性，如索引或数据分区。有可能多个查询使用同一个数据集合，如按区域划分的销售数据或按月份及客户类型划分的客户数据。在这些情况下，就有可能预先计算好这些数据集合，将它们单独存储在不同的位置，从而大大提升查询性能。

另一个关注的问题是系统资源。可能有一些资源是有限的或受性能约束，如CPU或磁盘存储。这一类资源的可用性将决定大多数可见的性能指标和查询耗时。

IT人员应该监控资源消耗和收集常规性能测量数据。将这些指标制成分时图表就可能反映出一些趋势。在一些时候，使用一种资源就有可能减轻另一种资源的结束。例如，如果CPU资源紧张，导致查询速度变慢，那么就可以给数据表增加索引。这样会占用更多的磁盘存储空间，但是可以加快数据访问速度。其他可用的方法包括增加专用于排序处理的磁盘存储，给DBMS增加内存，以便有更多的内存用于缓冲数据。

大数据查询

这自然就到了使用查询优化方法的时候。大多数DBMS都有一个分析查询访问路径的特性，它称为解释。解释的输入是一个查询，它会分析多个可能的数据访问路径，然后每一个路径指定成本，然后执行具有最低成本的访问路径。在这里，成本是指数据查询时所需要的CPU使用率和磁盘I/O。

这种查询路径优化要求DBMS提供一个关于数据库或设备所存储数据的统计模板。这种统计信息包括每一个数据元素的最大值和最小值、平均值、最常见值及其他数据分布信息。

假设有一个表包含按日期划分的销售数据，其中交易日期从01-01-2014到12-31-2014。只查询01-01-2014的数据查询可能只需要访问数据表中很小的一部分；因此，这时很可能需要增加一个索引访问路径。

类似地，在上面这个表中，假设将数据分割为12个数据集或分区，其中每一个分区对应一个月份。那么查询一月份数据的查询可能只需要访问其中一个分区，从而筛选数据时不需要扫描整个数据表。

显然，分析的需求会对所生成查询的类型产生重大影响；同时，可用的存储方法和数据访问路径将会影响查询性能。最明显的结论是IT支持人员必须与分析人员紧密协作，定期开会一起审查报表需求和文档可行的数据访问策略。此外，IT人员还应该开发一种捕捉所有已提交查询的方法，这样通过对它们分析就可能得到通用模式。

小结

为了避免大数据应用程序潜在的性能问题，IT人员应该主动与分析人员协调，收集数据访问指标。在技术方面，要用文档记录数据提取、转换和加载流程，确定有一些方法可以提升数据查询速度或处理更大的数据容量。要考虑净化过时数据，并且确定是否有一些提升数据性能的通用手段，如分区或索引会很有效。

开发一个用户库概要。用户数量有多少，他们创建查询的技术水平有多高，以及他们提交查询的频率有多快？这些数据在将来是否会继续增长？

捕捉用户查询，执行解释流程，然后保存访问路径。要用这些数据去分析性能问题和趋势。

要监控用于支持大数据应用程序的系统资源。预报趋势，特别是那些已经或可能会成为约束的资源。在这些情况下，要使用现有资源开发一些方法，抵消其中一些约束。

最后，要定期与业务分析人员会面，讨论你得到的结果和将来可能的变化。这种交流和协调是与用户保持良好关系的重要条件。