关于分布式:离线实时一体化数仓与湖仓一体云原生大数据平台的持续演进

简介：阿里云智能研究员 林伟：阿里巴巴从湖到仓的演进给咱们带来了湖仓一体的思考，使得湖的灵活性、数据品种丰盛与仓的可成长性和企业级治理失去有机交融，这是阿里巴巴最佳实际的贵重资产，是大数据的新一代架构。

林伟，阿里云智能研究员、阿里云智能通用计算平台 MaxCompute、机器学习 PAI 平台技术负责人

本篇内容将从三个局部为读者讲述离线实时一体化数仓与湖仓一体—云原生大数据平台的继续演进。通过从数据湖到数仓的历史，反思为什么要做湖仓一体，以及湖仓一体在明天这个阶段为什么开始做离线和实时湖仓一体化的数仓。

• 湖仓一体
• 离线在线数仓一体化
• 智能数仓

心愿这次的分享让大家进一步了解咱们为什么做湖仓一体。

一、湖仓一体

(1) 阿里巴巴从数据湖到数仓历程

2007 年的宁波策略会议确定建设一个开发、协同、凋敝的电子商务生态系统，其中生态系统的外围是数据。但这个时候各个业务部门都在垂直式倒退数据能力，用数据撑持商业的决策服务。这些数据中台撑持了业务部门的倒退。但咱们倒退到一个阶段的时候，心愿进一步挖掘出各个业务部门数据之间的关联性，从而利用这些高阶数据分析开掘更高商业价值，咱们遇到了很多的艰难，因为数据来自不同的部门，不同的人会提供你不同的数据集，没有清晰数据品质监控，你也不晓得这些数据是不是残缺的，你就须要破费很多工夫不停的去校准数据。这个过程耗时太长且少数状况会做了十分多的无用功，这样其实整体降落了公司的效率。

所以到了 2012 年，咱们决定将所有的业务部门的数据都关联起来，信心做『One Data，One Service』。其实这个过程就是典型一个数据湖降级到数仓的过程，然而因为咱们不足很好湖仓一体的零碎积淀，这个过程十分艰巨，咱们称之这个过程为“登月”。大家能够从这个名字可见两头的艰巨。在这个时间段，各个团队甚至须要停下日常的本身业务倒退来配合整顿数据，把所以原来已有的数据分析过程，搬到对立一套数仓零碎下面。最终咱们历经 18 个月，在花了十分大的代价，于 2015 年的 12 月实现建设了对立大数据仓库平台建设，这就是阿里巴巴的 MaxCompute。通过这个对立数仓平台，无论是业务团队、服务商家还是物流或其它环节都能够不便，迅捷，更好的开掘商机。所以大家能够看到在阿里巴巴对立的大数据平台实现后，业务成长也进入了快车道。这正是因为有更好的数据撑持，才使得商家、客户都能疾速的进行一些商业决策。

(2) 数据仓库和数据湖的关系

从开发人员的角度看，数据湖更为灵便，更喜爱这种得心应手的模式，任意的引擎都能够去读、写，没有束缚，启动也非常容易。

从数据管理者角度看，数据湖能作为起步，但达到特定规模时，把数据当作资产或者须要做更大的商业决策的时候，都心愿有一个很好的数仓。

(3) 数据仓库和数据湖零碎的增长曲线

上图的增长曲线，基本上也是阿里倒退的曲线，最开始也是数据湖状态，各个业务部门独立倒退，起步快、灵活性强。但当达到特定规模时，数据无人治理、每个业务部门的数据的逻辑语言不统一，很难对齐。所以过后花了 50%、80% 的有效工夫在校验数据，随着规模的不断扩大，这样的损耗越来越大，迫使咱们推动公司对立数据仓库的建设。

(4) 湖仓一体

正是因为咱们经验过堪比“登月”的苦楚，所以咱们不心愿 MaxCompute 将来的企业客户也经验这么苦楚过程，所以咱们构建湖仓一体的开发平台。当公司规模较小的时候，能够使用数据湖能力更快定制本人的剖析。公司成长到肯定的阶段，须要更好的数据管理和治理形式的时候，湖仓一体平台能够无缝把数据以及数据分析进行无效的降级治理，使得公司对于数据管理更加标准。这就是湖仓一体整体设计背地的核心思想。

咱们把湖的零碎和仓的零碎有机联合在一起，一开始是没有元数据，你想要建设数仓的时候，咱们有能够在湖下面来抽取这个元数据，这个元数据是和仓的元数据放在一个一体化的元数据的剖析平台下面。在这个元数据之上能够建设很多数据仓库的数据管理平台。

同时，在数据仓库湖仓一体的平台下面，咱们无效反对很多剖析引擎，有工作型的计算引擎，包含像 MaxCompute 是批处理、Flink 是流式解决、机器学习等，还有开源的组件能够剖析咱们的数据；也有服务性质数据引擎能够反对交互式查问服务，可能去更加实时性很好的展现咱们的数据，从而使得用户能够在这个服务性引擎下来构建本人数据服务利用。

在引擎之上咱们构建丰盛数据管理工具从而可能让业务部门可能进行高效整体的数据治理。而这都得益于咱们把湖和仓的数据买通，这也是整体湖仓一体设计的外围。

二、离线在线数仓一体化

现今社会越来越便捷，客户须要更快的做出商业决策。在双十一 GMV 实时大屏、春晚直播实时大屏等数据分析，以及机器学习从离线模型走向在线模型的趋势中咱们都能够看到。这些需要推动了实时数仓的倒退。

其实实时数仓和离线数仓有着类似的倒退过程。过后实时零碎倒退的晚期，咱们首先思考的是引擎，因为只有先有引擎了你才能够进行实时数据分析，所以阿里巴巴把研发精力放在 Flink 这样的流计算引擎上。然而只有流计算引擎，相似数据湖的阶段，咱们不足将剖析进去的后果数据进行治理，所以到了第二阶段，咱们利用咱们离线数仓产品来治理这些剖析后果，从而把剖析后果纳管到咱们整体数据仓库和数据管理中。然而把实时剖析之后的后果放在离线数仓外面，显然这样是对于实时商业决策是不够的及时。所以咱们当初倒退第三个阶段：实时数仓。

咱们会把流式引擎的剖析后果后果实时的写到实时数仓 Hologres 外面，从而可能让剖析的后果更实时的进行 BI 的剖析，从而无效的反对客户实时商业决策。

这就是离线和在线数仓一体化的设计。

总结一下，原有的剖析在离线和在线的数仓一体化之前是一个很纷纷的过程，有离线、有在线的、有很多不同的引擎，当初把它总结到或者简化成上图的架构。咱们会用实时的引擎做预处理，做完预处理后，咱们把这些数据写入到 MaxCompute 离线的数仓，也能够同时写入到 Hologres 实时数仓中外面，从而能够做更加实时的服务化的 BI 剖析。而 MaxCompute 离线的数仓存储的老本更低，吞吐的性能更好，能够做大量的离线数据分析，这就是离在线数仓一体化的设计。

有了一体化的设计，就能够给客户带来一个十分均衡的零碎。依据数据的场景或者是业务的场景，你能够用批处理。并且通过数据的压缩、冷存，数据依据热和冷的形式做不同梯度的存储，就能够失去更低成本的离线剖析。

当对于数据的实时性的价值更加器重，能够用流计算的引擎去做。同时又心愿有很快的交互式，心愿疾速通过各种形式的、各种维度、角度去察看已生成好的报表。这时候能够利用交互式引擎，在高度提纯过数据后的进行各个维度的洞察。

心愿用湖仓一体化平台就可能达到一个好的均衡，依据理论的业务体量、要求、规模老本达到更好点。

总的来说，心愿湖仓一体零碎上，不论是离线还是在线。通过不同的剖析引擎，反对各类剖析，同时通过在线服务型引擎可能实时进行 BI，可能达到低成本、自定义能力，以及实时和在线服务的各种均衡。让客户可能依据理论业务场景抉择。

三、智能数仓

有了对立的数仓平台，咱们就能够在此之上建设弱小的数据治理或者是剖析平台，这个就是咱们的 DataWorks。在这个平台下面有很多数据建模工具，提供数据的品质和规范、提供血统的剖析、提供编程助理等等。正是因为湖仓一体在线和离线的一体化的底座能力，才赋予了咱们有这样的可能性去做到大数据开发和治理平台更加智能化的形式。从而将更多通过验证过无效数据治理教训分享到咱们企业客户上。

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