9

专家视点：数据无处不在的云原生路径

 3 years ago
source link: https://www.51cto.com/article/705319.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client
专家视点：数据无处不在的云原生路径-51CTO.COM
专家视点：数据无处不在的云原生路径
2022-03-30 15:31:07
在分布式数据云中，企业数据仓库将不仅用于为公司中的数百名业务分析师或数据科学家提供分析，而且最终能够为企业端直接使用的实时分析应用提供支持数以万计的客户。

44c599b549a1ccbdbfe535308f9cbae8a725b8.png

使用 Kubernetes 进行架构是必不可少的核心部分，它使数据分析异常灵活，可在业务需要的任何地方运行，并以高并发、高性能、效率和可用性大规模运行。

从金融服务和保险到制造和医疗保健等垂直领域的无数企业发现，他们需要公共和私有云、混合和边缘部署来最好地满足他们的数据管理和分析需求。因此，分布式云的概念是云成熟的一部分也就不足为奇了。将数据仓库、数据湖和高级分析引入分布式云架构是市场的发展方向。扩展此架构以包含更高级别的数据管理和分析服务自然会产生分布式数据云的想法。

在分布式数据云中，企业数据仓库将不仅用于为公司中的数百名业务分析师或数据科学家提供分析，而且最终能够为企业端直接使用的实时分析应用提供支持数以万计的客户。这些数据将可以在任何地方立即访问并产生洞察力。

终极目标探索

云原生(Cloud-native)是一个被广泛使用的术语，但当软件架构从头开始设计以利用分布式云的优势时，它具有真正的意义。一个完全实现的云原生数据仓库应该在逻辑上利用分布式数据云架构。从最广泛的意义上讲，这将分析带到数据所在的任何位置，降低集中风险，显着提高效率，并为控制支出和竞争优势带来现代化。

更详细地说，云原生数据管理和分析技术应显示五个关键特征，以与分布式数据云蓝图保持一致：

  • 与平台无关的运行时，允许在任何地方提供数据和分析。
  • 随时随地的通用用户体验。
  • 任何部署目标上的通用安全和治理功能。
  • 任何地方的成本和技术效率，最大限度地减少资源并允许强大的成本管理 (FinOps) 和支出限制。
  • 单个控制界面，将所有部署、公共云、本地和网络边缘捆绑在一起。

可在任何需要的地方部署，遵循此模式的完全实现的云原生数据仓库还将从最终用户那里抽象出云、本地和网络边缘基础设施的复杂性。关键是将他们从基础设施细节中解放出来，让他们专注于从分析和管理数据中产生价值，同时仍然赋予云的原生力量。

选择正确的方法

那么，这个终极目标是如何实现的呢?开源容器编排工具 Kubernetes 提供了最流行的云原生操作路径。虽然 Unix 中对工作负载进行分区的想法自 1970 年代就已经存在，但仅在大约十年前，容器才被广泛实施，以使应用程序开发更容易、更便携且资源使用效率更高。但事实证明，在庞大的微服务架构中部署数百或数千个应用程序非常棘手。虽然存在其他选择，但 Google 的开源 Kubernetes 项目(现在由云原生计算基金会维护)在解决微服务应用编排方面声名远扬——使应用能够在通用基础架构上运行，以标准方式进行监控和管理，并通过使用开放标准。

这对应用来说很好。但是数据世界呢?云原生数据仓库需要相同的基础容器编排，以提供跨公共和私有云、网络边缘、混合和完全分布式云的弹性和部署灵活性。

横向扩展 Web 应用的云原生重新架构是很常见的，但数据库大多只是被“提升并转移”到云原生世界中。将数据库放入容器中允许它在现代基础设施中运行，但它并不能提供展示云所有好处的体验。该软件在很大程度上不知道它是在容器环境中运行的，并且管理弹性集群等操作必须使用 Operators 和破解 Helm 图表从数据库外部笨拙地处理。允许多个弹性按需计算集群共享对象存储中相同的底层数据等功能通常不可用。寻求从基于云的弹性数据仓库获得业务价值的用户不想了解 Helm 图表、pod、节点或配置文件。他们只想配置数据仓库、管理弹性集群并从数据中获得洞察力。

答案是在 Kubernetes 上提供 SQL 接口来按需配置多个弹性集群，并向 DBA 和最终用户隐藏 Kubernetes 的复杂性。

通过这种方式，可以分配不同的用户在不同的计算集群上运行工作负载，并且可以在运行时通过 SQL 更改正在使用的计算集群，但需要获得许可。集群可以配置为在空闲期后自动挂起，并根据需要重新启动。例如，可以创建一个单独的计算集群来在需要时运行 ETL 流程，一个用于临时商业智能 (BI) 和多个数据科学集群。计算集群可以在使用量大的时候在线扩展，或者在安静的时候关闭以节省资金。可以创建集群来运行仅在这些时间段内活动的每日、每周或每月批量报告任务。

在该模型中，计算集群中节点的大小以及节点的数量都是可控的，并且可以在实例级别建立资源消耗限制以实现可预测性。同样，可以建立一个低成本的副本系统，从主数据仓库实例接收复制流量，然后在需要使用副本时按需扩展。

这种弹性不仅通过与 Kubernetes 的深度集成来实现，还通过使用 SQL 本身作为创建、挂起、恢复和管理集群的“用户界面”而不是开发人员工具来实现。 Kubernetes 是所有集群状态的权威信息来源。显示集群状态的系统视图使用其 API 从 Kubernetes 获取数据。当输入集群管理 SQL 语句时，云原生数据仓库向 Kubernetes 伸出援手，改变实例所需的状态;然后 Kubernetes 实施必要的更改。如果集群中的某个节点变得不健康，Kubernetes 会带一个替代品上线。

这代表了与 Kubernetes 的一种独特的、由内而外的关系：Kubernetes 不再是驱动集群状态的“用户界面”，而是由 Kubernetes 管理的数据库本身成为用户界面。这种架构创建了一种共生关系，可提供独特的、完全实现的云体验。 Kubernetes 的强大功能和跨平台灵活性可用于数据仓库，完全通过 SQL 驱动。

随着更多数据的生成和更多用例的部署，企业很容易进入恶性循环，其生态系统在特定云中越来越根深蒂固。系统性风险可能出现在单一云中，这对金融服务和保险等受到严格监管的行业的关键 IT 基础设施造成了过多的风险。使用 Kubernetes 进行架构并不是将完全实现的云原生数据仓库带入生活的唯一核心概念。它不是唯一符合分布式数据云模式的架构组件。但它是必不可少的核心部件，它使数据分析异常灵活，可在业务需要的任何地方运行，并以高并发、高性能、效率和可用性大规模运行。结果是，任何给定企业中的数千名用户，跨越不同的业务线和地理区域，都可以做出极其快速的决策，并通过近乎实时的动态分析产生价值。


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK