翻译|连然百度和谷歌一样，不仅仅是一个搜索引擎巨头。
与谷歌一样，百度也在探索自动驾驶，并在机器学习、深度翻译、照片识别和神经网络等领域拥有重大科研项目。
这些项目充满了大数据计算挑战，很少有公司能够在自己的数据中心管理如此多的信息。
为了追求大数据成为未来世界的核心，百度吸引了全球领先的大数据和云计算专家来帮助其管理爆炸性增长的数据并构建服务其数亿客户的基础设施。
以及新的业务需求。
可见百度非常重视I/O和数据流量高峰的影响。
百度还支持加州大学伯克利分校的一个新开源项目Alluxio（原名Tachyon）。
Alluxio受到了全球银行巴克莱银行、阿里巴巴、英特尔和IBM等大数据先驱的工程师和研究人员的广泛关注。
最近，Alluxio发布了1.0版本，它可以像可编程接口一样为大数据应用和底层存储系统提供惊人的内存能力。
ReadWrite采访了百度高级架构师刘少山，谈论了Alluxio的生产和运营。
ReadWrite：当您加入Alluxio时，您遇到了哪些需要解决的问题？刘少山：如何管理数据规模并快速提取有意义的信息一直是一个挑战。
我们希望提高关键查询的数据吞吐量性能。
由于查询量巨大，每个查询需要几十分钟甚至几个小时——产品经理需要等待几个小时才能进行下一个查询。
更令人沮丧的是，修改查询系统需要重新运行整个过程。
大约一年前，我们意识到对 ad-hoc 查询引擎的需求，因此我们开发了新的 ad-hoc 规范：查询引擎需要管理 PB 级数据，并能够在 30 秒内查询 95% 的数据。
我们改用 Spark SQL 作为查询引擎，许多用例都证实了它在延迟方面相对于 Hadoop MapReduce 的优势。
我们很高兴 Spark SQL 将平均查询时间缩短到了几分钟。
但它并不完全是我们想要的地方。
虽然 Spark SQL 确实帮助我们实现了平均查询速度 4 倍的提升，但每个查询仍然需要大约 10 分钟才能完成。
经过深入挖掘，我们发现了问题所在。
由于数据分布在多个数据中心，因此对数据的查询很有可能需要到达远程数据中心来提取数据——这应该是用户运行查询时延迟的最大原因。
但正如您可以想象的那样，解决方案不会像将计算节点引入数据中心那么简单。
RW：那么突破怎么样？ SL：我们需要一个以内存为中心的存储层，它可以提供高性能、高可靠性并管理 PB 级数据。
我们开发了一个查询系统，使用Spark SQL作为计算引擎，Alluxio作为内存中心的存储层——我们进行了长达一个月的压力测试。
在测试中，我们使用百度内部查询标准从远程数据中心传输了6TB数据，并对数据进行了额外的分析。
测试结果令人惊讶。
Spark SQL单独运行时，完成一次查询需要-秒；使用Alluxio，数据可能会到达本地或远程Alluxio节点，这需要10-15秒。
如果所有数据都存储在 Alluxio 节点本地，则平均只需要 5 秒，这意味着速度提高了 30 倍。
基于这些结果和系统的可靠性，我们围绕Alluxio和Spark SQL构建了一个完整的系统。
RW：这个新模型在生产中如何运作？ SL：在系统开发过程中，我们使用典型的百度查询来衡量其性能。
使用原来的Hive系统，完成一个典型的查询需要很多秒的时间；使用 Spark SQL-only 系统，只需要几秒钟；但使用我们新的 Alluxio 和 Spark SQL 系统，只花了 10 秒。
我们实现了 2 倍的加速，并满足了我们在设置此项目时的交互式查询要求。
在过去的一年里，该系统已部署在集群中的100多个节点上，提供了由Alluxio管理的2PB空间，使用了Alluxio的高级功能之一（分层存储）。
这个特性让我们能够充分利用存储层，比如内存作为顶层，SSD作为第二层，硬盘作为最后一层；结合所有这些存储介质，我们可以提供 2PB 的存储空间。
除了性能的提升之外，更重要的是它的可靠性。
在过去的一年里，Alluxio 在数据基础设施中一直稳定运行，几乎没有出现任何问题。
这给了我们很大的信心。
事实上，我们正在为大规模部署Alluxio做准备。
首先，我们布置了一个Alluxio工作集群来验证Alluxio的可扩展性。
近一个月来，集群运行稳定，提供超过50TB的RAM空间。
据我们所知，这是世界上最大的 Alluxio 集群。