zoukankan      html  css  js  c++  java
  • 贾扬清谈云原生让数据湖加速迈入3.0时代

    简介: 摘要:2021云栖大会云原生企业级数据湖专场,阿里云智能高级研究员贾扬清为我们带来《云原生--让数据湖加速迈入3.0时代》的分享。

    摘要:2021云栖大会云原生企业级数据湖专场,阿里云智能高级研究员贾扬清为我们带来《云原生--让数据湖加速迈入3.0时代》的分享。

    image.png

    本文主要从存储服务化、计算多元化、管理智能化等方面讲述了数据湖的演讲历程。

    以下是精彩视频内容整理:

    数据湖演进历程

    数据湖1.0   2019年以前

    • 存储:存算分离,冷热数据分层,以Hadoop生态为主
    • 管理:无官方管理服务,用户自行处理扩缩容、磁盘运维等管理工作
    • 计算:初步实现计算云原生化,但缺乏计算的弹性以及多样性

    数据湖的概念想必大家都不陌生。2019年以前提到数据湖概念时,一定程度上是基于存算分离这样一个朴素的想法,能够弹性的做存储规模的扩缩,根据计算需求灵活配置计算资源。在那个时候,存储基本可以服务化标准化,计算也可以和存储分开规划,如何更好管理上层数据和计算弹性则相对比较缺乏。

    数据湖2.0   2019~2021

    • 存储:以对象存储为中心,统一存储承载生产业务,大规模、高性能
    • 管理:提供面向OSS/EMR等垂直湖管理系统,缺乏产品间联动
    • 计算:计算弹性化,用户根据负载进行计算伸缩

    基于数据湖1.0的基础,我们进一步构建了很多能力。尤其在存储标准化后,像阿里云对象存储OSS,开始成为一个数据湖非常标准的底层的存储解决方案,它本身的稳定性、规模和性能,为数据湖底座提供了一个很好的基础。可以在上面做一些单集群,比如拉起 EMR 这样一个集群,进行一些数据的管理、控制,不过还是一个比较初步的状态。只要有计算集群,就可以在计算集群里引用数据湖的数据,对元数据进行管理。同时,因为云原生这样的方式,更加弹性的计算也变得更有可能。在存储、计算、管理三个指标中,存储是走的最快的;计算多元化是走的比较好的;管理也在逐渐构建。

    数据湖3.0   2021

    • 存储:以对象存储为中心,构建企业级数据、全兼容、多协议、统一元数据
    • 管理:面向湖存储+计算的一站式湖构建和管理,做到智能“建湖”和“治湖”
    • 计算:计算不仅云原生化、弹性化,同时实时化、AI化、生态化

    在提到数据湖3.0的时候,基本上的思考是在存储、计算、管理这三个指标上面都有进一步的发展。存储,需要做更多的兼容性、更好的一致性,以及更好的持久性。更加重要的一点是在管理上,数据湖不光是百川汇聚,扔在那的一堆数据,而是能够井井有条的管理。湖上存储了哪些数据、这些数据在如何被使用、使用的频率如何、数据的质量又怎么样,这些在传统的数据仓库领域经常考虑到的问题在数据湖中也同样存在。湖也应该有像仓一样的完整成熟的管理体系。至于计算,不仅是计算体量的弹性,更是一个计算的多样化的过程。以前我们更多的在做ETL,现在则更多的开始做实时的计算、AI的计算,以及非常多的生态计算引擎和湖的结合。以上是数据湖3.0需要解的一些核心问题。

    存储从「成本中心」到「价值中心」的升级

    • 平滑上云--100% 兼容 HDFS,存量数据平滑迁移上云
    • 降低运维难度--全服务化形态,降低运维难度
    • 极致性价比--冷热分层,单桶万亿级文件数量,成本降低 90%
    • 加速 AI 创新--数据按需流动,大幅降低计算等待时间,高效管理

    基于对象存储OSS这样一个底层的存储,我们实现了非常平滑的迁移上云,降低了运维、管理等难度。一个统一且标准的存储状态使得很多技术可以沉淀。比如冷热分层,在用户不需要关心的情况下,自动依赖OSS的冷存和热存的分配,以此降低存储成本。包括在AI领域,很多时候大家可能对于不同的存储形态不熟悉,更喜欢像 CPFS 这样传统的文件系统。CPFS 跟 OSS 的打通,在存储上提供了很多新功能,可以解决用户的迁移烦恼。

    image.png

    「建湖」 「管湖」 「治湖」的智能化升级

    • 数据智能入湖

    多数据源一键入湖,支持离线/实时入湖方式

    • 数据计算的元数据服务化

    服务化元数据,满足单表百万分区元数据管理

    • 统一的数据权限管理

    对接多引擎,支持库/表/列等细粒度数据访问控制

    • 湖仓一体数据治理

    数据湖与数据仓库的统一数据开发与全链路数据治理

    我们花了一年多时间构建了一个新的产品,阿里云数据湖构建(Data Lake Formation,DLF),在建湖、管湖、治湖方面,更好的管理数据湖。首先关注的是数据如何更加标准化体系化的入湖,不光是写一堆的脚本,还要更好的管理起来,以更简易的方式将多元的数据汇聚到数据湖里。第二个就是元数据服务。在数仓里,元数据是和数仓整个建在一起的。构建一个数据湖时,存储放在OSS里面,针对元数据的管理,尤其是元数据的服务跟更加上层的例如 BI 之类的工具的组合,DLF 提供了一个更加服务化、标准化的元数据管理这一层。元数据所带来的数据权限、数据质量等更好的治理了这一层。而Dataworks 跟数据湖的打通,也使我们可以做更好的数据治理。在一个企业里面,数据形态非常多,有些在数据湖里,有些在仓库里。大家或许在业界听到过 LakeHouse 这样一个词语。很多时候是说,在湖上面来建立一个仓库。其实一个企业的需求,不光是从0开始在湖上建仓,因为有很多传统的数据仓库的存在,包括很多时候井井有条的像excel表一样的数据仓库其实还是有用的。所以如何把湖的灵活性跟仓的结构更好的联系在一起,支撑了我们在治湖、管湖、建湖的时候用到的一些工具和方法论。

    image.png

    「单一计算」到「全场景智能计算」的升级

    • 实时数据湖

    实现实时数据入湖,分钟级别实时更新

    • 湖仓一体

    打通湖与仓,提升企业数据业务能力,一份数据智能流动

    • 数据科学

    从BI到AI场景,支持深度学习和异构计算框架

    • 计算引擎多元生态

    支持Databricks、Cloudera 等多元化计算分析能力

    数据湖如何更好的实时化?通过像 Hudi 这样的开源组件来实现实时的数据湖的功能。如何更好地结合数据科学的需求?比如在AI这个领域,大家经常使用到一些数据科学家们比较喜欢的基于python、基于编程的一些开发的体验,怎样把它和底层的数据湖存储、管理的这套体系结合起来?怎样把像 Databricks,Cloudera 这种非常成熟的企业级的生态产品和我们底层的数据湖结合起来?这些是我们在过去一年中,在不断的构建的一些企业级的能力或者说让我们的开发者们、工程师们更加容易地使用数据湖的一些能力。怎样做存储?怎样来做管理?怎样做更多样化的计算?这些都是数据湖发展到3.0阶段,比较核心的点。

    image.png

    万千企业和阿里云一起开启数据湖 3.0最佳实践

    • 6000+数据湖客户
    • EB 级数据湖容量
    • 分钟级数据实时入湖
    • TB 级但数据湖吞吐

    在阿里云上,有非常多的企业在使用数据湖。在上面用到了非常大体量的存储和非常多样化的计算。在使用过程中,一起打磨了这样一个产品。从19年开始至今,数据湖的不断迭代离不开合作伙伴的信任。感谢大家。

    原文链接
    本文为阿里云原创内容,未经允许不得转载。 

  • 相关阅读:
    case when完成不同条件的显示
    联行号不正确的触发器
    |待研究|委托付款的支付状态触发器
    待解决:新增客商校验触发器|两个错误|
    C#.NET和C++结构体Socket通信与数据转换
    C#中struct和class的区别详解
    C#与C++数据类型比较及结构体转换[整理]
    surging+CentOS7+docker+rancher2.0 入门部署教程
    Google Maps API Key申请办法(最新)
    开源的api文档管理系统
  • 原文地址:https://www.cnblogs.com/yunqishequ/p/15507440.html
Copyright © 2011-2022 走看看