擦除码计算器 
参考硬件 从 Hadoop 迁移到云就绪的数据分析架构
这篇文章是UCE Systems的Kevin Lambrecht和Raghav Karnam合作撰写的。
云操作系统模型，特别是Kubernetes，已经成为当今大规模基础设施的标准。更重要的是，它们正在以前所未有的速度发展，对数据科学、数据分析和AI/ML产生了重大影响。
这种转变对Hadoop生态系统产生了重大影响。虽然Hadoop生态系统在开创大数据时代方面功不可没，但其底层架构已不再适用。新的架构已经取代了它，并且这些架构还在不断发展，要求企业也进行升级以保持竞争力。和Kubernetes原生方式。
本文重点介绍如何构建一个利用现有Hadoop硬件的混合云策略，许多企业都拥有这些硬件。虽然这种方法并非理想，尤其是在高性能用例中，但它可以作为通往云原生架构的桥梁，以及更雄心勃勃的部署的基础。
简介
云操作系统模式定义了当今的数据分析格局。组织越来越多地采用云的原则，无论是用于交钥匙分析的软件即服务（SaaS）数据平台，还是利用云基础设施和软件工具实现高效的可扩展性。
多云和混合云兼容的数据基础设施实际上是企业的必要条件。 这种方法确保了访问数据和应用程序的一致且可移植的接口，允许它们在各种环境中无缝部署，而无需修改代码。因此，组织可以灵活地在任何地方运行其工作负载，从边缘设备到公共云环境和私有云部署，同时保持一致的用户体验和运营效率。
然而，像任何技术变革一样，云原生方法也引发了一些必须解决的关键考虑因素和挑战。
- 数据治理：组织必须确定哪些数据允许存储在云中，以及是否可以将所有数据迁移到云中。
- 迁移方法：在“提升和迁移”方法或全面数据平台重组之间进行选择，需要仔细评估对现有系统和应用程序的影响。
- 用户群：向云的过渡会影响用户访问、权限和整体用户体验，因此需要仔细规划和沟通。
- 灾难恢复：确保充分的灾难恢复控制变得至关重要。组织必须评估他们是否可以信任云供应商的能力，或者是否需要采取其他措施。
- 迁移时间表：迁移过程包括多个阶段，包括数据传输、应用程序测试和用户验收测试。了解每个阶段的时间表对于有效规划至关重要。
- 现有数据湖基础设施：组织必须评估其对当前数据湖基础设施的投资的命运，并确定它如何与新的基于云的架构保持一致。
- 数据管道调整：迁移可能需要修改数据管道、应用程序、ETL流程和脚本，以确保与云环境的无缝集成。
- 成本管理：在云中采用“按需付费”模式需要仔细的成本控制策略，以避免意外支出。组织应分析长期成本影响并据此进行规划。
- 成本与收益：必须评估迁移过程中的挑战和人力投入是否能为组织带来成本节约和整体收益。
对于大量投资于Hadoop数据湖模型的组织而言，直接迁移到云仍然是一个复杂且耗时的项目，存在技术和非技术挑战。
但是，存在另一种方法，即采用利用现有Hadoop硬件的混合云策略。通过将本地基础设施与云功能相结合，组织可以实现更平滑的过渡，同时规避上述许多挑战。
实施混合云方法允许组织拥抱数据分析架构的现代趋势，同时利用其当前的投资。它提供了一种务实的解决方案，平衡了云的优势与需要进行渐进和可控的过渡。
案例研究：简化金融机构的数据架构
一家大型金融机构认识到需要简化运营并降低其大型Hadoop集群相关的成本。随着技术的过时以及成本随着行业从Hadoop转向更分散的技术栈而不断上升，该机构面临着众多挑战。尽管向云迁移似乎是一个可行的解决方案，但内部企业需求和监管要求阻碍了进展，使得可行性存在不确定性。
在现有环境中，使用了多种查询工具，其中Dremio作为核心查询引擎，用于在Hadoop（HDFS）中解耦计算和存储。Dremio被证明是一个合适的选项，它在Hadoop上提供了令人印象深刻的性能，其计算引擎作为基于Yarn的应用程序与Hadoop生态系统共存。这种架构允许Dremio的内部元数据收集将查询路由到本地包含相关数据的Hadoop Worker节点。通过利用Hadoop商品硬件上的大规模并行处理，该硬件包括低成本的旋转磁盘、有限的网络速度和中等规模的服务器，在架构合理的情况下可以实现极高的速度。但是，过渡到具有解耦数据和计算的架构需要更快的驱动器、高速网络和更强大的服务器才能保持相当的性能。
第一个挑战涉及替换Hadoop中的HDFS存储。考虑到基于对象的存储选项（如AWS S3、Azure ADLS和Google GCS）在云中更受欢迎，因此金融机构专注于基于对象和与S3兼容的存储。在测试了各种选项后，他们选择了MinIO作为存储平台，原因有很多，包括拥有成本、稳定性和一个关键因素，即它可以在Hadoop硬件上运行。这最后一个方面显著降低了迁移到这个现代数据存储平台的总成本。
在架构上，当从Hadoop迁移时，设想计算和存储分离至关重要，这不仅能够选择适合工作负载的硬件，而且还能计划工作负载的弹性。虽然计算需求具有很强的弹性，但必须计划大规模扩展和收缩以满足突发工作负载，以及根据需要启动计算以满足基于需求的工作负载，这纯粹出于经济原因提供了巨大的财务激励。存储需求几乎是线性扩展，应该允许从100TB扩展到EB级的水平可扩展性，而MinIO作为对象存储在商品硬件上部署时大放异彩。
虽然由于商品旋转磁盘（平均180 Mib/s读写）和20 Gbit网络速度，硬件对于S3存储来说并非最佳选择，但MinIO的存储架构能够在具有24个5.5TB驱动器的四节点服务器上实现大规模并行读写，从而导致吞吐量显著提高。
MinIO建议将存储明确部署在存储优化的服务器上，从而使计算分离能够从100TB扩展到EB级。但是，在本案例研究中，我们需要一个针对给定网络挑战的现成解决方案。
难题的最后一块是将两个Dremio工作节点与运行MinIO的四台服务器中的每一台服务器共置，并将Dremio数据端点设置为本地MinIO节点。虽然与现代数据平台架构相比，这种设置并非最佳选择，但它提供了一些优势
- 显著减少了Dremio和MinIO之间的网络流量。
- 允许将多个数据请求线程（每个Dremio节点32个CPU线程）发送到本地MinIO端点。
- 更有效地利用CPU、内存和可用网络带宽。
MinIO最小的处理占用空间允许Dremio利用大部分本地节点的计算能力（CPU）和内存。但是，Dremio工作节点被限制在16个CPU内核和128 GB的RAM，剩余的资源足以让MinIO和操作系统正常运行，而不会降低性能。因此，性能指标证明了CPU/内存需求（Dremio/Hadoop与Dremio/MinIO）至少具有同等水平，并且时钟时间性能总体提高了20%。
需要注意的是，Hadoop在Yarn中的配置时间是区分因素。由于计算专用于MinIO和Dremio，因此Hadoop的设置时间被最小化。此外，查询计划时间也减少了，因为与Hadoop/HDFS相比，Dremio不需要考虑MinIO的数据本地性。
所有上述成就都是在节点上没有任何其他性能调整或Hadoop和MinIO之间查询修改的情况下实现的。
展望未来
打算迁移到MinIO的现有Hadoop硬件缺乏Dremio利用其云列缓存（C3）所需的NVMe驱动器。在我们未来的工作中，我们将探索C3缓存的实现，该缓存已证明能够通过此磁盘缓存层为多达80%的查询提供服务。这种优化通过减少磁盘I/O和网络流量来显著提高速度。
此外，我们将进行测试以评估在相同或其他MinIO节点上共置其他应用程序（如Spark）的可行性。
MinIO不建议将此方法作为标准，这应该被视为一次性操作以抵消企业的网络限制。理想情况下，组织最好解决这些网络故障，这些故障导致组织中所有应用程序的性能下降。