注：本文英文原文在google开发者工具组的博客上[需要FQ],以下是我的翻译，欢迎转载，但请尊重作者版权，注名原文地址。
之前的文章，介绍了Google在分布式构建软件过程中，如何把构建过程分发到许多台机器上并复用之前构建的结果来大幅度提高构建的速度。这种分发和复用会凸显出性能瓶颈。尤其是一个大工程的一次完整构建会产出几个G的输出文件，所有的这些文件都需要从云端传回到开发者的机器上。这加重了网络和开发者本地硬盘的负担，延迟和有限的带宽会拖慢构建的速度。
而且，开发者通常不需要访问一次构建的所有的输出。她可能只关心构建结果中最后的可执行文件，而一点也不关心中间的对象文件。另外一个例子是当开发者使用分布式构建系统来在云上构建并执行测试。这种情况下，她不需要访问构建的结果，只需要简单的知道测试是通过了还是失败了就足够了。所以每次都把构建结果从云端拉回到开发者本地机器是没必要而且也是非常浪费的。相反，仅仅把开发者需要使用的构建结果拉回本地即可。
为了解决这个性能瓶颈，我们的分布式构建系统把所有的构建输出结果都写入到一个持久化，分布式的存储系统里。这个存储系统处理持续的读写请求的速度，相比本地磁盘而言要快好几倍。分布式构建系统与这个存储系统之间的网络连接比跟本地磁盘相比，带宽更大，延迟更小。构建结果通过内容指纹, 来提供简单的机制去索引和检索文件的。（这个云端的存储系统也在分布式构建系统中扮演第二级缓存的角色，当构建结果没有命中第一级缓存时，这个云端的存储系统可以提升性能）。在云上使用这个分布式存储系统，我们可以让构建的速度比构建系统直接在开发者本地磁盘上存储构建结果要快至少2倍。
使用基于云的存储来存储构建结果可以显著的提高构建速度，剩下的挑战是仍然能够让开发者的本地机器在构建完成后，可以按需访问这些输出结果。我们通过编写的一个定制的文件系统来提供构建结果的视图。像我们第一篇文章所描述的那样，用户空间文件系统(FUSE)内核模块提供了方便的方法来使用一个用户空间的守护进程来实现这样一个文件系统。随着各个构建步骤的完成，分布式构建系统通知守护进程新的构建结果产出了，同时提供文件的相对路径和内容的指纹。这样，当开发人员访问这些路径下的某个文件，守护进程会从云上把文件下载下来，使用内容指纹作为键，然后通过用户空间文件系统(FUSE)来提供给开发人员(通过在开发人员的机器上缓存下载下来的文件来加快后续访问的速度)。内容指纹本身是作为用户空间文件系统(FUSE)的一个扩展属性来存储的，这样构建系统就能够轻松获得内容指纹了，正如我们在第二篇文章里所介绍的那样，这是构建系统执行增量构建的必要条件。
本地守护进程除了通过云存储来获得构建结果，从本地构建输出的元数据，还执行了很多额外的重要工作来保证系统正常工作。例如，输出结果只要有一台开发者的本地机器引用了，就会一直保存在云上。守护进程周期性地为开发者机器上的所有构建的构建结果进行续约。另外一个例子，如果顺序地获取开发者想访问的巨大的构建结果，虚拟文件系统的性能会很差。相反，守护进程会并发地从云上的多个存储服务那里下载文件块。守护进程也需要负责本地数据的完整性校验，本地磁盘管理和缓存更新以及其他维护性任务。
下面的这张图总结了Google的构建系统[译者注：就是Blaze系统]整体是如何工作的，包含了本系列四篇博客中的内容。
开发人员在自己的工作站上调用构建系统的客户端，指定一个或多个要构建的目标。客户端协调并分发独立的构建行为到云端去执行，通过用户空间文件系统(FUSE)的守护进程来读取所需的源代码的元数据，作为云端执行系统的输入。这些行为的构建结果（例如可执行文件）会存储到云端存储系统，用户通过用户空间文件系统(FUSE)来按需下载。所有这些构成了一个能够把构建结果在数秒之后而不是几个小时之后就呈现给开发的构建系统。