云原生 + AI 时代已至，大数据底座何去何从？

大家都知道，对于很多架构师而言，做技术选型是一件“常态化工作”。要找准一项技术是否适合某个场景，最核心的是要看这项技术当初是因为什么而诞生的，这个最初始的需求往往就是这项技术的基因。随着技术的持续发展，往往功能会越来越多，枝繁叶茂，但这个基因是我们对这个技术认知的根本。

1.深入谈谈 Hadoop

Doug Cutting，一位大佬，也是 Apache Lucene 项目的作者。Apache Lucene 是现代开源全文检索方案的核心，我们知道的 ElasticSearch、Solr 等很多项目都是基于 Lucene 开发的。同时，Lucene 下面还有一个子项目，是一个爬虫项目，叫 Nutch。所以 Doug Cutting 做的事情，和 Google 做的事情是有很多重叠的。Google 成功之后，有海量的用户点击数据要进行分析，所以 Google 内部搞了一个很大的分析平台。Doug Cutting 根据 Google 相关的论文启发，又做了一个新的开源项目，也就是大数据圈几乎无人不知的“大象”——Apache Hadoop。

Google 是一家搜索公司，同时也是一家互联网公司。互联网公司往往面对海量的用户交互数据，传统的数据库是没办法分析的，同时这些数据还有相似的特点，就是量大但不可变。根据这一特点，Google 搞了一个内部的分析系统，而 Hadoop 又是参考这套系统做的，所以 Hadoop 最原始需求就是——分析海量的不变用户数据。

为了分析这些数据，我们需要把数据汇总在一个地方，所以有了分布式存储 HDFS，接着我们需要对这些数据做分布式计算，所以有了 MR 计算框架，为了能够管理和调度 MR 计算框架，有了 Yarn 资源管理器。这三驾马车是 Hadoop 最开始的核心，可以说分析互联网的行为数据，就是 Hadoop 的基因，Hadoop 是因为互联网公司的兴起，突然面对海量数据需要进行横向扩展而诞生的。

随着技术的发展，人们又发现大量的数据文件实在难以管理的，所以就有了大数据的数据仓库（Apache Hive）,毕竟大家都熟悉了管理数据库表而不是零散的文件。然而数仓其实也是通过一堆目录来管理文件的，只不过这些目录结构和文件信息会被保存到元数据库中（例如 MySQL），这样就可以通过库表形态让用户来操作了。

Hive 最大的价值之一就是确定了以 SQL 为主要数据分析手段，而不是手写 MR 代码。不要以为这件事是很自然的，在 Hive 之前，其实社区有非常多的尝试，比如发明一些新数据操作语言，诸如 Pig 等。数仓最原始的文件格式其实是文本文件，后面为了存储和速度，才慢慢有了二进制文件（Sequence File），再然后才有了列式存储 ORC/Parquet 等。

整个 Hadoop 的时代，其实就是围绕以 Hive 数仓为主、以不变数据为核心的一个批处理分析系统。BI 报表则是 Hadoop 系统里发展得不错的一个场景应用。以前的报表系统，都是通过 Hive 任务提前计算结果放到数据库里这种模式，这是因为 Hive 需要解析 SQL，然后生成 MR 任务，之后再运行。这种“批处理”的性能很差，可能拉起任务就需要十几秒甚至几十秒，根本没办法做交互式查询。所以为了解决 Hive 这个问题，就发展出了一些新的计算框架，诸如 Spark/Flink 去提升性能。Spark/Flink 是 Hive 的继承者，此外还有很多 On Hadoop 的 MPP 计算引擎诸如 Impala、Presto 等。

不过“现用现算”对资源的消耗还是太大，为了解决这个问题，市面上有三种主流做法：

• 数据格式和索引的优化

比如采用列式存储的 Parquet 格式，还有引入 Z-Ordering 等 File/RowGroup Skip 技术。其实最原始的 File Skip 技术是 Hive 提出来的，就是根据日期分目录，查询时会自动 Skip 掉不匹配日期的目录从而减少计算，粗暴但有效。

• 挖掘 CPU 的计算能力

也有一种做法是更好地控制内存的存取和格式。比如采用 CPU 支持的 SIMD 以及向量化技术、代码生成技术等，还有就是采用 Arrow 等存储格式，对 CPU 会更友好。

• 预计算技术

最原始的预计算技术是啥？就是通过 ETL 把结果直接算出来，但是灵活度太差了，无效计算太多，前端不灵活。所以聪明的工程师们又发明了在大数据平台上建 Cube（多维立方体），它会把数据按 Cube 格式重新组织，SQL 查询会被转换对 Cube 的查询，从而提高查询速度和并发能力，其中代表如 Apache Kylin。

再后面又有物化视图技术（这里不是说新发明，而是慢慢被人关注），物化视图其实最大的价值是解决多表关联查询，本质也是改写 SQL  查询，把查询转化到事先已经 Join 好的宽表去。

随着技术的发展，业务变得越来越敏捷，人们实时分析的需求不断发展，从而对 T+1 越来越无法容忍，这个时候就引发了流计算（包括 CDC）的兴起，但是之前的 Hive 数仓并不能支持更新，也没有办法支持并发的读写操作，且 Hive 数仓也不能作为流式数据源，这就发展出了一个中间形态：Lambda 架构。

Lambda 通过复杂化架构来解决流批的问题。常见的一个场景是引入一个支持更新的组件，诸如 Kudu、HBase 之类的，接受更新再将数据同步到数仓里，然而这种方式使体系架构愈加复杂，却依然无法解决实时性问题。大家知道，这里根本原因在于数仓存储层无法满足需求，这不是计算框架能够解决的问题，有需求就会有解决方案，于是数据湖应运而生。数据湖以原生格式存储各种数据，并运行不同类型的分析。

数据湖目前主流有三个实现，分别是 Deltalake，Iceberg 以及 Hudi。透过概念看本质，三者其实提供的是一堆文件 + lib 库，作为通用计算引擎诸如 Spark, Flink 等的数据源存在。这些引擎通过这些 Lib 库操作这些文件，最终提供了三个核心能力：数据更新，事务以及版本。

支持数据更新意味着数据湖更加接近数据库，可以实现业务数据的准实时同步，事务意味着有更好的读写并发控制，而版本可以让数据能够进行回溯和管理。

当然，我们前面也提到，数据湖提供的其实是一堆文件 + Lib 库，也就是说，它本身不是作为一个服务实例而存在的，这和 Hive 数仓以及传统数据库是存在比较大的差异的地方。这里核心还是考虑性能和灵活性问题，如果是以类似数据库形态存在，那意味着操作数据湖只能通过 RPC 之类的接口调用，计算也必须是数据湖自身来完成，不仅性能上可能不够强大，也会导致用户难以利用已有的计算框架操作数据，失去很多灵活性。

这种模式也会面临一些问题，比如这堆文件可能会被多个计算引擎实例同时操作，诸如 Compaction、Clean 一类的工作就会有点麻烦。这里会有多种选择，比如你可以启动一个独立的引擎专门做 Compaction 操作，亦或是分解在每次操作数据的时候。这是目前三个数据湖实现都会遇到的问题。此外，如果要访问这些数据也会遇到点麻烦，必须通过这些引擎才能完成。

Deltalake 的优势在于搞了一个 delta sharing server，其实就是启动一个进程，这个进程提供了一个类似 S3 的协议，这样就可以给各个语言封装一些库，从而让他们能够访问到对象存储，比如机器学习的同学可以直接用 Python 访问数据湖，而无需依赖诸如 PySpark 之类的东西。Apache Iceberg 目前看下来最大的优势是支持使用 Hive metastore 或者 JDBC 数据库作为元数据管理，所以它其实更像 Hive 数仓的进化产品。而 Apache Hudi 最大的优势是同时支持 merge on write 和 merge on read，也就是用户可以平衡写性能优先还是读性能优先，此外 Hudi 也是三者之中唯一引入了行存储（Avro）模式的，另外两个应该是纯列式（Parquet 格式）存储的。

2.Hadoop 为什么面临变局

Hadoop 最大的价值就是让人类具备了对海量数据的处理能力。但是前面的演进让我们看到，人们的需求总是越来越高的，“以 Hive 数仓为主”，“不变数据”，“批处理”等这些限制条件人们越发的无法容忍。但如果只是单纯如此，我们在 Hadoop 上修修补补，也是能满足用户需求的，就像数据湖其实也能很好地运行在 Hadoop 体系里。如果仅是这样，那么 Hadoop 应该还有很久的日子要走。

但是接下来的两件事，让我们知道，彻底的变革已经是无可避免了。

这两件事是啥呢？

首先是「云时代」的普及，

其次是「AI 时代」的爆发。

在过去十年，云计算以其灵活的部署方式、创新的商业模式、高效的协作性等诸多优势到了蓬勃发展，伴随数字化转型的深入，企业纷纷选择上云。云时代的普及要求数据处理能够在公有云、私有云、私有化部署等多种环境下，同时对象存储逐渐成为主流。实际上很多企业在使用云服务时，都会采用对象存储而非默认提供的 HDFS。

在新一轮科技革命和产业变革中，同样脱颖而出的还有人工智能（AI）等数字技术。AI 时代，这要求底座拥有更好的新资源管理（GPU/TPU 以及各种专有的 AI 芯片）以及隔离能力，同时需要更好地和业务系统融合的能力（Online Serving）的能力。

从技术角度我们一直在追求“统一”。所谓统一，就像之前我们追求的流批一体一样，希望一个引擎，一个存储就能完成。而现在业界能够提供统一底座的只有 Kubernetes。Hadoop 的体系其实是游离于业务系统之外的，基于裸金属服务器，和业务系统分开且难以形成有效互通。随着技术发展，大数据和 AI 必然会和 Web 应用系统一样普及。让他们运行在相同的底座上，做到资源共享对企业而言无论如何都是划算的买卖。

其次，越来越多的计算引擎开始从批处理走向服务化。如果你想在 Hadoop 体系里跑一个 7*24 小时对外的服务，其实是不符合 Hadoop 基因的，而在 Kubernetes  则属于自然而然的事情。

第三点，Hadoop 体系里资源隔离一直做的不好，尽管有很多企业尝试集成了 CGgroups 等，但显然 CGgroups 相比容器而言太底层，而且易用性也不足够。其次就是新硬件无法进行很好的管理和支持，诸如 GPU/TPU 以及各种专有的 AI 芯片。

最后一点，非技术的原因，但却是最重要的：云原生作为基础设施带来的巨大商业价值，大部分社区都调整了自己的重心，在往云原生方向走，比如 Spark 社区对 Kubernetes 在最近的每个版本里都有大幅的特性增强。

3.云原生是大势所趋

鉴于云原生技术对大数据的良好助推作用，已经有不少技术嗅觉敏锐的头部玩家在此尝到了甜头。例如，华为云推出 FusionInsight MRS 实现云原生数据湖；Cloudera 推出 CDP Private Cloud Data Services 与 Kubernetes 结合提升资源利用效率；AWS 推出 EMR on EKS（Kubernetes），其效果据称能够提升 EMR 中 Spark 任务计算性能 68%，成本下降 61%。

由此可见，无论是出于性能提升还是成本优势，与云原生相结合都是未来大数据的发展趋势。要怎么理解呢？简单来说，就是将我们的数据、AI 和业务应用都统一放到一个底座上来，也就是 Kubernetes ，通过这个底座，我们可以很容易将其部署在公有云、私有云亦或是自建 IDC 中；至此，云原生的灵活性得以充分发挥。在其之上，亦可以搭建更开放，更具经济效益的大数据架构。

还想了解更多关于云原生和大数据的未来发展趋势？欢迎报名 2 月 25 日 2023 全球人工智能开发者先锋大会的云原生时代下的数据智能化趋势论坛。本论坛特别邀请了来自华东师范大学、Kyligence、中国银联、Intel、联通、中电金信、Apache Kylin、Byzer、JuiceFS、Gluten 等机构、组织和社区的演讲嘉宾，将对「云原生时代下的数据智能化趋势」进行深入探讨。

Kyligence，将在 02 月 25 日 13:30 直播预约 2023 全球人工智能开发者先锋大会——云原生时代下的数据智能化趋势论坛视频号。

欢迎大家点击「链接」报名现场参会

关于 Kyligence

跬智信息（Kyligence）由 Apache Kylin 创始团队于 2016 年创办，是领先的大数据分析和指标平台供应商，提供企业级 OLAP（多维分析）平台产品 Kyligence Enterprise 和一站式指标平台 Kyligence Zen，为用户提供企业级的经营分析能力、决策支持系统及各种基于数据驱动的行业解决方案。

Kyligence 已服务中国、美国、欧洲及亚太的多个银行、证券、保险、制造、零售、医疗等行业客户，包括建设银行、招商银行、平安银行、浦发银行、北京银行、宁波银行、太平洋保险、中国银联、上汽、长安汽车、百胜中国、星巴克、安踏、李宁、阿斯利康、UBS、MetLife 等全球知名企业，并和微软、亚马逊云科技、华为、安永、德勤等达成全球合作伙伴关系。Kyligence 获得来自红点、宽带资本、顺为资本、斯道资本、Coatue、浦银国际、中金资本、歌斐资产、国方资本等机构多次投资。