从 Hadoop 到云原生（1）：Kylin 在云原生巨浪中的思考

我们首先从一张图开始:

上图是从 Google Trend 上获取的近五年的关于 Data Warehouse（蓝色）、Data Lake（红色）、Redshift（黄色，AWS 的著名云原生数据仓库）和 Hadoop （绿色）这四个关键字的热度趋势。可以观察到，最近的五年内，Hadoop 关键字的热度迅猛下降，Data Warehouse 的热度保持稳定，而 Data Lake 和 Redshift 的热度都有显著提升。另外值得一提的是，早在 2016 年初前后，Redshift 的热度就已经超过了 Data Warehouse，并且在最近超过了疲态明显的 Hadoop。

这也与我们的观察和感受一致：越来越多的企业客户正在从 On-Premise 的数仓方案，转向基于云（包含公有云和私有云）的解决方案，这种趋势在美国 2B 市场已经被广泛接受，在国内 2B 市场也已方兴未艾。由于无可取代的弹性扩展性、容灾性、低 TCO 和几乎无限量的存储空间，基于云平台的数据仓库技术正在逐渐让所有人相信拥抱云原生才是数据仓库技术以及相关数据分析技术未来。云原生的巨浪正在席卷全球的软件产业，包括开源软件和商业软件。在数据仓库这个细分领域，我们能明显的感受到数据仓库正在经历以下几代体系的演进：

1. 传统的数据仓库

最早出现的是数据库一体机，是由单独的硬件软件所构成，这种数仓的问题主要在两个方面：第一，它需要专有的硬件，成本较高；第二，它的扩展性不高。在过去这样的问题是可以被用户接受的，但是在现今的大数据时代，有很多开源的技术可以用来在普通硬件上构建大数据平台，不愿意被单独的供应商或者硬件平台绑定，所以一体机模式的数仓越来越难得到普及。

这样的背景很自然地催生了第二类数据仓库的兴起：

2. 基于通用硬件的分布式数据仓库

这类的数仓方案通常可以基于通用硬件（Commodity Hardware），在可扩展性上相比较传统的数仓有了质的飞跃。在笔者看来，这类的数仓也可以分为两大类，即 MPP 数仓（在商用数仓软件的代表是 Greenplum，在开源数仓的代表有 Presto 等）和批处理数仓（典型代表是 Hive 和 Spark）。MPP 和批处理的区别有点超出本文的主要范围，在此就不展开了。值得注意的是，和 Hadoop 有近亲关系的 Hive 虽然非常有可能随着 Hadoop 的巨轮一起慢慢消失，但是它却为第二类数仓带来了一种极其通用的数据表元数据定义的标准，并被 Presto，Spark 等技术全面地沿袭，成为了事实上的标准。

第二类的数据仓库获得了巨大的成功，放眼国内，无论是一线大厂还是不知名的小公司，都围绕这类技术开发除了完整的数仓和分析平台，大大地提高了大小企业对数据资产的发掘能力。但是这类数仓的弊端也慢慢地暴露出来：因为数据不断增加，需要不断增加节点，导致企业不得不自行投入扩建机房，继而进行全面的迁移数据工作。运维团队和业务团队无奈承受着背后的繁琐和低效，苦不堪言。此时不断成熟的云厂商给大家带来了新的可能：

3. 第一代云原生的数据仓库

以 Amazon Redshift, Azure SQL DW 为代表，在云计算开始之初，云厂商就为用户准备好了用于分析型业务的云上数据仓库产品。这类数仓产品一般都需要申请一个固定节点数量的集群，都配有列式存储技术、分布式查询等特性。但是，由于云上有无限的计算节点资源可以申请，用户可以随时调节集群中的计算节点数量。无论是集群的启停、扩容、升级，这些操作都可以在云厂商的界面上通过几次点击完成，已经在云原生度上与第二类数仓有显著差异。

这一类数仓依托云上无限扩容的基础硬件设施，免除了运维人员在集群规模扩容时的空间困扰，需要更多的资源只需要在网页界面上点击即可完成。但是这类数仓数据和计算没有完成分离，会导致什么问题呢？比如某个用户已经申请了一个 10 台机器的节点，这 10 个节点每个都有计算资源（CPU）和存储资源（磁盘）。由于 workload 的增加，用户发现需要增加更多的计算资源才能满足，于是不得不把数仓配置从 10 个节点升级为 15 个。但是，这额外的 5 个节点的存储资源也是要收费的，即便用户的数据在原来的 10 个节点中完全够存。在这种情况下，用户的诉求是买更多的计算资源，但实际情况是他不仅购买了更多的计算资源，还购买了用不上的存储资源。这就大大增加了这样的数仓方案的 TCO，限制了企业在数据资产的有效利用。

4. 新一代的云原生数据仓库

以 Snowflake, Amazon Athena, Azure Synapse, Amazon Redshift Spectrum（严格地说 Amazon Redshift Spectrum 只是一个 Redshift 的插件）为代表的新一代云原生的数据仓库，进一步实现了云上数仓计算与存储的分离。在第三类数仓中，即使用户已经在对象存储中准备好数据，仍然需要将数据导入到数仓后，才能进行查询。而第四类数仓可以直接查询用户在对象存储中的数据。在第三类数仓中，用户如果发现集群空间不足，不得不对集群进行扩容，这样不仅是在为更多的存储支付成本，而且在为更多的计算支付成本，即使他不缺少计算资源。而在第四类数仓中，用户在对象存储中的数据按量计费，在数仓节点中的计算按量计费，两者相互独立。

这种新一代的存储和计算分离的数仓架构催化了我们耳熟能详的数据湖数仓架构体系。在这种架构下，所有的数据都可以可靠、廉价、方便地存储到对象存储上（Amazon S3，Azure blob storage, ADLS），云厂商提供了完整的配套工具来确保用户的应用数据库、日志、APP 的数据可以顺利地落地到对象存储上。这种区别于块存储和文件系统的存储方式从根本上决定了云原生数仓的存储形态乃至设计形态：数据不再保存在某个节点的磁盘中，存储和计算天然分离，计算所需的一切存储，都来自遥远的、无限的、透明的对象存储中。下图是 Redshift Spectrum 的架构图，可以看到对象存储在其中的基石地位。

当我们意识到对象存储在云上数仓的基石地位和它能为数据分析带来的无限可能之后，我们不禁感慨 Data Lake 这个词是多么生动。只有云上的对象存储，才能够将用户如湖水一般的数据承载下来。关于数据湖的定义确实是一个业界有较多争议的地方：狭义的数据湖指数据湖储存，即可以存放海量数据的地方，也就是我们说的云上对象存储（一般来说 Hadoop HDFS 也可以做数据湖的存储，但是相比对象存储，它在灵活性和可扩展性上还是相距甚远）；广义的数据湖除了数据湖存储，还包括支撑了数据湖的管理、数据处理、监控、调度、分析的一整套工具系统。下图是 Azure 官方提供的基于 ADLS 的数据湖架构的典型架构：

在上图中，所有的活动围绕 ADLS 展开：通过批量或者流式的数据导入，数据被落地到了 ADLS 中。Azure Data Factory 可以在这个过程中帮助用户完成对数据的 ETL 加工，加工的过程中可以用到各种外部的计算引擎，例如 Databricks 提供的 Spark 和基于开源 Hadoop 的 HDInsight。在过去，用户完成加工后，数据可以被导入到 Azure SQL DW 或 Power BI 中供数仓分析师直接使用，也可以被下载另作他用。有了第四类数仓，用户可以通过 Azure Synapse（用官方自己的话说，这就是 Azure SQL DW 的进化版）直接与 ADLS 中的数据进行交互操作，如下图 Azure Synapse Architecture 所示。

有了对基于数据湖架构的新一代云原生数仓的初步理解，我们大致可以看清数据仓库今后的发展脉络:

基于云平台提供的基础架构，无论是来自公有云还是私有云；

基于无限容量的数据湖存储；存储与计算分离，独立按需计费；

计算资源具备较强弹性，可以随时扩容缩容，有必要时可暂停所有计算节点（在这方面 Serverless 的服务架构更有优势，但即使不是 Serverless 也一样能做到）；

同时支持查询数据湖中的结构化和非结构化数据等等。

经过一番梳理，我们可以看到数据仓库正在慢慢向云原生的、存储计算分离的方向上发展。企业做技术选型，以及我们自身做技术战略投入的时候，自然也需要尊重并拥抱这样的时代趋势。Kyligence 诞生于 Hadoop 时代，在这样的行业趋势下，要对原有的 Hadoop 平台体系做哪些方面的重新思考和设计呢？与我们面临相同挑战的企业又能借鉴哪些经验呢？我们将在本系列的下一篇文章中展开。

作者介绍：

马洪宾，Kyligence 创始合伙人 & 研发副总裁，Apache Kylin 核心开发者及项目管理委员会成员 (PMC)。专注于大数据相关的基础架构和平台设计。在从事大数据和数据仓库相关工作之前，曾经是微软亚洲研究院的图数据库 Trinity 的核心贡献者。目前担任 Kyligence 企业级产品的研发负责人，帮助客户从传统数据仓库升级到云原生的、低 TCO 的现代数据仓库。