关于云原生:贾扬清谈云原生让数据湖加速迈入30时代

6次阅读

共计 2777 个字符,预计需要花费 7 分钟才能阅读完成。

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

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

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

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

数据湖演进历程

数据湖 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 的买通, 在存储上提供了很多新性能,能够解决用户的迁徙懊恼。

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

  • 数据智能入湖

多数据源一键入湖,反对离线 / 实时入湖形式

  • 数据计算的元数据服务化
    服务化元数据,满足单表百万分区元数据管理
  • 对立的数据权限治理
    对接多引擎,反对库 / 表 / 列等细粒度数据访问控制
  • 湖仓一体数据治理
    数据湖与数据仓库的对立数据开发与全链路数据治理

咱们花了一年多工夫构建了一个新的产品,阿里云数据湖构建(Data Lake Formation,DLF),在建湖、管湖、治湖方面,更好的治理数据湖。首先关注的是数据如何更加标准化体系化的入湖,不光是写一堆的脚本,还要更好的治理起来,以更繁难的形式将多元的数据汇聚到数据湖里。第二个就是元数据服务。在数仓里,元数据是和数仓整个建在一起的。构建一个数据湖时,存储放在 OSS 外面,针对元数据的治理,尤其是元数据的服务跟更加下层的例如 BI 之类的工具的组合,DLF 提供了一个更加服务化、标准化的元数据管理这一层。元数据所带来的数据权限、数据品质等更好的治理了这一层。而 Dataworks 跟数据湖的买通,也使咱们能够做更好的数据治理。在一个企业外面,数据状态十分多,有些在数据湖里,有些在仓库里。大家或者在业界听到过 LakeHouse 这样一个词语。很多时候是说,在湖下面来建设一个仓库。其实一个企业的需要,不光是从 0 开始在湖上建仓,因为有很多传统的数据仓库的存在,包含很多时候东倒西歪的像 excel 表一样的数据仓库其实还是有用的。所以如何把湖的灵活性跟仓的构造更好的分割在一起,撑持了咱们在治湖、管湖、建湖的时候用到的一些工具和方法论。

「繁多计算」到「全场景智能计算」的降级

  • 实时数据湖
    实现实时数据入湖,分钟级别实时更新
  • 湖仓一体
    买通湖与仓,晋升企业数据业务能力,一份数据智能流动
  • 数据迷信
    从 BI 到 AI 场景,反对深度学习和异构计算框架
  • 计算引擎多元生态
    反对 Databricks、Cloudera 等多元化计算剖析能力

数据湖如何更好的实时化?通过像 Hudi 这样的开源组件来实现实时的数据湖的性能。如何更好地联合数据迷信的需要?比方在 AI 这个畛域,大家常常应用到一些数据科学家们比拟喜爱的基于 python、基于编程的一些开发的体验,怎么把它和底层的数据湖存储、治理的这套体系联合起来?怎么把像 Databricks,Cloudera 这种十分成熟的企业级的生态产品和咱们底层的数据湖联合起来?这些是咱们在过来一年中,在一直的构建的一些企业级的能力或者说让咱们的开发者们、工程师们更加容易地应用数据湖的一些能力。怎么做存储?怎么来做治理?怎么做更多样化的计算?这些都是数据湖倒退到 3.0 阶段,比拟外围的点。

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

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

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

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

正文完
 0