云计算安全参考架构是基于角色的分层描述,将角色分层几大类？

来源：蜘蛛抓取(WebSpider) 时间：2022-06-10 03:25 标签： 云计算的层次架构为哪三层

数据湖的起源，应该追溯到2010年10月，由 Pentaho 的创始人兼 CTO， James Dixon 所提出，他提出的目的就当时历史背景来看，其实是为了推广自家产品 Pentaho。当时核心要解决的问题是传统数据仓库报表分析面临的两个问题：

  • 只使用一部分属性，这些数据只能回答预先定义好（pre-deteined）的问题。
  • 数据被聚合了，最低层级的细节丢失了，能回答的问题被限制了。

技术概念的提出，本质都是为了业务场景服务的，是为解决某类特定场景的问题。

而我们当前所讨论的数据湖，已经远远超过了当初 James Dixon 所定义的数据湖，各厂商之间也对数据湖有了更多的不同定义。

    Lakehouse 是一种新的数据技术架构，它在数据湖的基础之上，吸收了数据仓库，数据库的一些特性。这些特性最核心的一个特性是对 ACID 的支持。

    Lakehouse 方案简化了整个数据链路，并提高了数据链路的实时性。它从原来的 Lambda 架构，升级到了 Kappa 架构：

    从上述 gartner 报告来看，无论是开源社区还是云厂商之间，对于 Delta Lake 都已经有了成熟的解决方案，但 Lakehouse，目前一些技术还是初步应用阶段，但从去年开始已经很多公司将其逐步应用到了各自的业务系统中，并为业务带来了更多价值。从后续我们的应用场景案例中大家也可以看到关于开源的湖格式 Delta Lake/Hudi/Iceberg 的一些具体应用。湖格式为大家带来了更多的可能，更多人愿意尝试，相关技术讲解可参考我们后续的系列文章。

    下图是从各个维度对三种架构的对比，方便我们更好的理解他们的差异以及解决的问题。

    基于阿里云OSS 产品，可以为数据湖提供稳定的存储底座，它具备高可靠、可扩展、已维护、高安全、低成本、高性能等特点。并提供了版本控制，生命周期等能力。

    JindoData 是阿里云开源大数据团队自研的数据湖存储加速套件，面向大数据和 AI 生态，为阿里云和业界主要数据湖存储系统提供全方位访问加速解决方案。JindoData 套件基于统一架构和内核实现，主要包括 JindoFS 存储系统（原 JindoFS Block 模式），JindoFSx 存储加速系统（原 JindoFS Cache 模式），JindoSDK

    阿里云数据湖构建（Data Lake Formation，DLF）是一款全托管的快速帮助用户构建云上数据湖的服务，产品为云原生数据湖提供了统一的元、统一的权限与安全管理、便捷的数据入湖能力以及一键式数据探索能力。用户可以通过快速完成云原始数据湖方案的构建与管理，并可无缝对接多种计算引擎，打破数据孤岛，洞察业务价值。

    结合访问控制与云监控两款产品，可以为数据湖提供用户管理、权限控制、监控审计等能力。

    数据集成可以通过 Dataworks 的数据集成能力，DLF 的数据入湖，以及 Flink 产品的 CDC，完成数据的全链路入湖，支持多种数据源的数据入湖能力。

    离线作业的数据开发、任务调度可以使用 Dataworks 产品实现，也可以使用开源系列方案如 airflow+zeppelin/jupyter 等实现。

    实时作业的数据开发、任务调度管理可以通过 Flink 产品实现。

    数据质量、数据治理等功能可以通过 Dataworks 产品实现。

    数据湖的构建、管理与应用过程

    传统大数据平台升级为数据湖架构

    • 传统IDC机房的大数据平台存在以下的问题：
      • 物理机自建集群，日常成本较高
      • 业务发展迅速, 流量压力, 计算压力不断增加，资源不足，补货周期长
      • 数据分散，不同项目之间标准混乱
      • 数据定义模糊，没有有效分层,分析使用困难
      • 存量数据通过 Jindofs 迁移到阿里云的OSS
      • 基于 EMR+DLF 构建整个数据平台的基础服务
      • 使用 EMR 弹性伸缩满足计算量需求
      • 使用 DLF 快速构建数据湖所需服务
      • 极大的减少了成本, 运维人员减少30%
      • 使用 EMR 弹性伸缩大大缩减了计算成本，减少10%-20%
      • 构建统一的数据标准, 对数据进行分层, 极大的提升了业务方使用效率


    新零售公司全托管数据湖

      • 线下 Hadoop，组件多，平台运维困难、成本高
      • 数据开发、运维难度大，任务稳定性差
      • 统一存储：对象存储 OSS，可存储任意规模的数据，可对接业务应用、各类计算分析平台
      • 数据湖构建与管理：数据湖构建 DLF，解决数据入湖、统一元数据管理、统一权限控制等关键问题
      • 数据湖格式：Deltalake，该格式支持数据的增量更新和消费，从而避免了使用 Lamda 架构的两条链路来支持离线和实时的数据计算
      • 数据分析计算引擎：DDI 数据洞察+EMR-Presto 交互式分析，在保证软件产品功能和性能领先的基础上，提供了全托管免运维的服务，同时有极高的 SLA 保证
      • 数据开发与调度：EMR Studio 是 E-MapReduce 用于开源大数据开发场景的集群类型，提供交互式开发、作业提交、作业调试和工作流一站式数据开发体验
      • 存算不分离，无法进行灵活指的组件升级，很多新的组件特性没法使用
      • 存储在本地盘上，运维难度搞，有坏盘的经历。存储成本高，没法做冷热分层
      • 元数据管理在单一的集群上，快集群使用不便，集群稳定性直接影响元数据服务稳定性流批不分离，相互干扰，带来作业稳定性问题
      • 存算分离，简化了价格，随时可以升级最新版本，使用Flink, Hudi的最新特性
      • 对存储在 OSS 上的数据进行冷热分层，节约成本
      • 使用 DLF，进行元数据管理，同时管理数据权限。同时快速支持Flink, Hudi等新特性
      • Flink 和 Hbase 等业务分离，提高了业务的稳定性
      • 使用 Hudi 的数据湖格式，实现了数据的快速插入，支持了快速的元数据变更，也能支持业务的准实时分析场景


    互联网金融公司湖与仓的融合，湖仓一体

      • 公司的第一代数据湖是基于 Hadoop + OSS 搭建的，同时引入的数据中台的执行引擎和存储是 Maxcompute，两套异构的执行引擎带来存储冗余、元数据不统一、权限不统一、湖仓计算不能自由流动
      • 如图架构 和 EMR 不同引擎用于不同的业务场景，使用阿里云数据湖构建 DLF 统一做元数据管理和统一用户权限管理。通过 DataWorks 进行全链路数据治理，提升数据质量与应用能力
      • 将 EMR 的元数据统一到DLF，底层使用 OSS 作统一存储，并通过湖仓一体打通EMR数据湖和 MaxCompute 数仓两套体系，让数据和计算在湖和仓之间自由流动
      • 实现湖仓数据分层存储。数据中台对数据湖数据进行维度建模的中间表存储在 MaxCompute上，EMR 或其他引擎消费 ADS 层

    更多关于数据湖方案及技术的解析，请参考我们后续文章。

    欢迎钉钉扫码加入数据湖交流群一起参与讨论~

风险提示：本站所提供的资讯不代表任何投资暗示。投资有风险，入市须谨慎。
世链粉丝群：提供最新热点新闻，空投糖果、红包等福利，微信：rtt4322。

我要回帖

更多关于 云计算的层次架构为哪三层 的文章

 

随机推荐