我们认为正确的方法是接受它们，而不是试图消除资料孤岛。
多年来在大资料和机器学习领域的工作，我们经常听到资料工程师从资料中提取价值的最大障碍是能够有效地访问资料。资料孤岛，孤立的资料孤岛，经常被资料工程师视为关键的罪魁祸首或公敌。已经有许多尝试消除资料孤岛，但这些尝试本身导致了另一个数据孤岛，资料湖就是这样一个例子。我们认为正确的方法是接受它们，而不是试图消除资料孤岛。
资料孤岛存在的原因
资料孤岛存在的原因主要有三个。首先，在任何组织内都存在用于不同用途的具有不同特征的资料（物联网资料，行为资料，交易资料等），并且一些资料将比其他资料更具业务关键性。以上推动了对不同储存系统的需求。此外，历史表明，每隔五到十年，储存技术就会出现新浪潮，从而生成更快，更便宜或更好地为某些型别的资料设计的储存系统。组织也希望避免供应商锁定，因此他们将使资料储存多样化。最后，有些法规要求对资料进行孤立。由于上述所有原因，每个新的储存系统不可避免地成为资料环境中的另一个数据孤岛。
试图消除筒仓
多年来，已经有许多尝试来解决资料孤岛带来的挑战，但这些尝试导致了更多的资料孤岛。例如，资料工程师经常使用Apache Spark或Apache Hive构建管道，以便将资料从一个Hadoop丛集处理和汇出到另一个Hadoop丛集（可能是远端的或由不同的部门拥有），以便聚合下游资料处理应用程序所需的资料集。但是，这种型别的资料迁移管道（通常是ETL管道）构建和维护很复杂，并且还会在不同的丛集之间建立重复。拥抱资料孤岛
我们认为资料孤岛本身并不是挑战; 最根本的挑战是如何在不增加复杂性或重复性的情况下使资料工程师可以访问资料。我们建议利用位于计算框架和储存系统之间的资料编排系统来解决资料访问挑战，而不是消除孤岛。我们将资料编排系统定义为一个层，用于抽象跨储存系统的资料访问，虚拟化所有资料，并通过带有全域性名称空间的标准化API将资料呈现给资料驱动的应用程序。通过资料编排系统，资料工程师可以轻松访问储存在各种储存系统中的资料。例如，资料工程师可能需要连线最初储存在两个不同区域中的两个表 - 本地Hadoop丛集和远端Hadoop丛集。在这种情况下，该工程师可以将Alluxio部署为资料编排层，并将Hive Metastore中的表位置更改为Alluxio URL而不是每个单独的物理Hadoop丛集。
因此，在Alluxio中快取远端表比直接重复读表提供了更好的效能。此外，储存团队可以做出最佳的储存购买决策，而不会受到他们的决策对应用程序团队的影响的束缚。
