战略、架构和基准测试报告：用于数据分析的“零拷贝混合云”

用于数据分析的“零拷贝”混合云 战略、架构和基准测试报告 WHITEPAPER 目录 1/业务场景 2/解决方案 3/比较分析 4/解决方案概述 5/解决方案架构 6/安装和基准测试执行 7/基准测试结果 8/结论 ©CopyrightAlluxio,Inc.Allrightsreserved.AlluxioisatrademarkofAlluxio,Inc. 本白皮书详细介绍了如何利用公有云（如AmazonAWS、GoogleGCP或MicrosoftAzure）直接在本地数据上扩展分析工作负载，而无需通过人工干预将数据复制和同步到云中。我们将以实例展示如何通过部署在公有云上的Alluxio，来自动把数据从HDFS缓存到运行Presto和Hive的机器内存上。此外，我们也将展示如何在位于两个不同位置的AmazonEMR集群中设置和执行性能基准，并给出我们的研究结果概述。 私有云：基础设施部署在本地，由公司拥有和管理，并承担计算、网络和存储资源成本。 公有云：基础设施由供应商（如AWS）作为托管服务提供，公司以按量付费的方式使用计算、网络和存储服务。 混合云：公有云或私有云结合使用。虽然我们重点关注从公有云访问本地私有云数据的场景，但本白皮书中的结论适用于任何混合云场景。 零拷贝：在公有云中进行数据访问，无需持久拷贝数据或与私有云同步。云延伸：通过在云中添加计算资源来扩展过载的本地集群。 数据编排：是一个通过虚拟化所有数据访问，在无需知道数据物理驻留位置的情况下，实现跨集群、云和数据类型的存储和计算分离的平台。 许多公司将数据存储在本地的Hadoop分布式文件系统（HDFS）集群中。作为数据驱动转型工作的一部分，存储的数据量和来自流行框架的额外工作负载正在迅速增大。这种不断增加的负载使得现有的大数据环境不堪重负。如果想要彻底摆脱昂贵的本地固定基础设施，挑战性显而易见。这里主要有以下几个方面的原因：首先是可能存在法规上的限制，阻碍数据在云中持久化，如果不利用现有的本地基础设施，解决方案的经济性可能较差。此外，过于专业的数据导入流程开发，阻碍了数据存储彻底转向纯公有云环境。 过去几年，随着数据洞察的框架数量增多，企业的数据平台团队不得不在其已经十分繁忙的数据湖上支持更新的流行框架。数据湖已成为所有企业数据的默认着陆区。基于Hadoop的数据湖满载运行的情况并不少见，这些都会导致Hadoop集群变得十分庞大和繁忙。 需要采用混合云部署的典型场景： •Hadoop集群的CPU容量超过100%； •由于主名字节点负载高，无法扩展Hadoop集群； •计算能力不足，无法为临时业务用户提供所需的服务级别协议(SLA)，且SLA和非SLA工作负载之间没有分离； •出现偶发性的分析争用稀缺资源的情况；（例如在生成每月合规性报告时需进行计算密集型作业） •扩展时存在的成本控制问题； •自行维护基础设施的运营成本使得总维护成本增加（尤其是考虑到包括程序员薪资在内的间接成本等）。 使用公有云带来的益处 •计算和存储的独立扩展和按需配置 •灵活使用多个（最适合该项工作的）计算引擎 •通过移动临时工作负载减少现有基础设施的过载 尽管本地基础设施和公有云的敏捷性存在一些问题，但使用其他方法来进行跨数据中心和公有云的数据管理也让企业望而生畏。随着架构向计算和存储分离的方向发展，有很多机会可以利用云中的计算或存储资源并减轻Hadoop集群的负担。企业可以利用数据编排技术实施混合云，实现二者的完美结合。 数据编排技术要通过从本地数据中心到公有云或另一个数据中心的网络连接，无缝启用计算和存储分离的架构，需要解决以下几个挑战： 数据一致性：混合云任一端的更新，在无人工干预的前提下，即可供另一端使用。本地数据中心的数据导入流程在启用公有云中的访问时应无需更改。 •案例A：在本地添加新数据或更新现有数据时，公有云中的应用程序应可看到更新的视图。 •案例B：公有云中的应用程序写入的新数据应可供包括本地应用程序在内的所有应用程序读取。 容量管理：一般而言，计算集群在与主存储集群分离后存储容量有限。此外，很难准确地预知需使用的数据。数据编排框架的一个可选要求是无需将数据完整复制到公有云，即可访问相关数据。 延迟：公有云和本地数据之间的高延迟链接对性能的影响应可以忽略不计。带宽：公有云和本地数据之间的低带宽对性能的影响应可以忽略不计。 安全：本地身份验证（例如LDAP/AD）工具和授权（例如Ranger）工具应可继续在公有云中使用，避免需要设置冗余策略和产生相关管理费用。 当前在混合环境中管理数据的方法存在的问题 一般认为，混合云两端的网络延迟会阻碍在云上使用本地数据运行分析工作负载。因此，大多数公司将他们的数据复制到云环境中并维护这些复制数据（也称为LiftandShift）。对于合规性和数据主权有要求的公司而言，他们甚至可能会阻止将数据复制到云中。这些都意味着如果要实现本地Hadoop数据可访问的效果，应用程序很难具备理想的性能。 跨云管理数据的两种方法 1.将数据从本地复制到云存储用以运行分析 通常，用户使用distCP等命令将静态数据从Hadoop集群复制到AWSS3等云存储。尽管该方法可能使得数据移动更加容易，但也会随之产生几个问题： •一旦数据被移动，便不再同步，变为陈旧数据，因为数据可能会在本地集群上发生变化，而同步数据并无简便方法。 •用户只能对复制到云中的数据运行只读分析工作负载，从而限制了混合部署的价值。 •现有数据集可能达到PB级，而实际用于运行工作负载的基本数据集可能要小得多，但是没有简单的方法可以预先确定工作负载所需的数据子集。 •数据导入流程很复杂，无法快速更改。很难调整流程来适应不断更新的云端数据。 使用类似distCP的解决方案管理自定义代码或维护数据呈动态变化的ETL管道非常复杂。WANdiscoLiveMigrator等一些解决方案，能够捕获数据变化并将本地数据与云存储同步。虽然该解决方案可以更轻松地处理不断变化的数据，但仍存在一些局限性： •现有工作负载可能无法直接在云存储上运行，可能需要更改应用程序。此外，性能可能明显低于本地部署。 •迁移到云存储可能无法实现。原因可能是监管限制或者很难确定云中的应用程序可能需要哪些数据。注意：如果使用同步工具，无法预测所需数据可能意味着必须将整个本地数据复制到云存储。另一方面，预测不准确意味着业务用户或分析师将拥有不完整的数据集，由于必须通过手动同步请求数据，因此获取数据洞察的时间会减慢。 2.NetappONTAP或AWSDataSync等托管服务 用户可以使用NetappONTAP等产品或AWSDataSync等服务，以自动化工具驱动的方式将本地文件系统数据移动到公有云中的对象存储。但是该方法也存在一些挑战： •这些技术可能很昂贵，而且只能使用有限的API，而这些有限的API，例如网络文件系统API(NFS) 等，并不适合数据分析。 •移动数据后，除了本地存储之外，用户还需要利用云存储来运行分析工作负载。 Alluxio是一个用于分析和机器学习应用程序的数据编排平台。通过Alluxio的数据编排，可实现跨混合云的高性能数据分析。那么如何实现呢？通过将本地数据源挂载到Alluxio。 Alluxio与本地私有计算环境和公有云计算环境集成，提供企业混合云分析策略。工作负载可以按需迁移到公有云，而无需事先在计算环境之间移动数据。使用Alluxio后，应用程序将按需读取数据，而迁移的工作负载的性能与数据共存于公有云中的性能相同。此外，私有计算环境的负载减轻，I/O的开销也得以最小化。Alluxio提供的一些核心功能如下： 数据局部性。使用Alluxio，本地数据可以按需迁移到公有计算环境中。Alluxio与Presto或Spark位于同一集群，提供高度分布式的缓存能力。 数据可访问性。数据一旦进入Alluxio后，用户可以通过多种不同方式访问相同的数据，包括HDFSAPI、S3API或POSIXAPI等API。这意味着为分析和AI/ML工作负载构建的所有现有应用程序都可以直接在此数据上运行，而无需对应用程序本身进行任何更改。 数据弹性。Alluxio可以与分析框架一起自动扩缩而不会丢失数据，例如在公有云计算环境中使用自动扩展策略时。 按需抓取计算驱动数据。尽管Alluxio可以挂载整个文件系统，但会视需要抓取工作负载所需的数据。临时计算集群几乎可以实时获取数据，而无需等待数据完成复制。此外，还可以根据工作负载预取、固定或设置数据过期时间。 数据隔离。Alluxio在抓取数据后，会提供一个隔离的沙箱来卸载本地数据源，并实现跨部门、团队或业务用户的数据分离。该数据隔离能力允许独立扩展以满足SLA的要求。 本节介绍了将Alluxio与Presto或Spark连接的部署架构，可将分离的计算集群连接到本地的HDFS存储集群。该架构的核心构建块也适用于其他混合云环境，尤其是当两个集群之间存在高延迟或低带宽链路时。Alluxio可以部署在AmazonAWS、GoogleGCP和MicrosoftAzure等多个公有云中。此处为保持一致性使用AmazonAWS术语。 显著特征 以下概述了适用于所有混合云环境的推荐架构的部分显著特征： 将Alluxio与计算集群放在同一位置。数据的局部性确保计算框架和数据编排层可通过手动或自动扩展策略一起扩展，没有额外的开销，同时确保性能得益于数据局部性。 挂载本地数据源。HDFS等本地数据存储可挂载到Alluxio命名空间，支持在公有云中按需访问，而无需复制数据。Alluxio从HDFS异步获取元数据，从而可以快速地提供数据。 本地存储作为事实来源。本地存储系统仍是持久数据源。来自公有云的所有更新都会同步或异步地传回本地源。 不复制HiveMetastore。公有云中的计算框架（如Presto）可以连接到本地现有的Hivecatalog，而无需重新定义表或保存Hive元数据的复制实例。这是由名为TransparentURI的Alluxio功能启用的。 Alluxio架构 点击此处可查看Alluxio架构的完整介绍。 AlluxioMaster(s)存储文件系统命名空间的元数据。HDFS等远程存储系统可挂载到Alluxio的命名空间中，从而可通过Alluxio进行访问。挂载位置的元数据，例如文件大小和位置，从远程存储加载到AlluxioMaster并无缝同步。在典型的设置中，从计算到AlluxioMaster的延迟低于到HDFS名字节点的延迟，而AlluxioMaster作为计算框架的元数据缓存。 AlluxioWorkers存储实际数据。从挂载的存储系统首次访问数据时，AlluxioWorkers就将数据进行了缓存，计算框架的任何后续访问都从worker节点上的本地存储获取。与通过高延迟和低带宽网络链接从远程存储系统检索数据相比，此设置可提供更高的I/O吞吐量。 计算和Alluxio共同位于AWS上 在此部署场景中，Alluxio与计算框架位于同一位置。在上图中，Alluxio和Presto位于一个AmazonEMR集群上。EMR集群中的节点既可以是长期运行的，也可以是临时的，可以根据应用场景作为On-Demand或Spot实例启动。 >注意：EMR集群由三种类型的节点组成：主节点、核心节点和任务节点。AlluxioMaster(s)存储文件系统命名空间的元数据并安装在主节点类型上。核心节点安装Alluxioworkers，在从本地HDFS读取一次数据后提供数据。任务节点不运行Alluxio服务，并且可以在不影响I/O性能的情况下始终处于临时状态。 针对不同的节点类型使用临时节点会产生一些后果。对于关键工作负载，我们建议使用持久节点。 •临时核心节点。对于根据需要频繁扩缩的核心节点，工作负载可能会