本文探讨了Hadoop技术从最初的互联网数据处理需求出发，如何演化成批处理分析系统，以及面对云计算和AI时代的挑战，如何转变为云原生大数据平台的过程。作者强调了数据湖和Kubernetes在技术革新中的核心角色。
作者 | 祝海林
转载 | Kyligence
大家都知道，对于很多架构师而言，做技术选型是一件“常态化工作”。要找准一项技术是否适合某个场景，最核心的是要看这项技术当初是因为什么而诞生的，这个最初始的需求往往就是这项技术的基因。随着技术的持续发展，往往功能会越来越多，枝繁叶茂，但这个基因是我们对这个技术认知的根本。
#01
深入谈谈 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 等。
再后面又有物化视图技术（这里不是说新发明，而是慢慢被人关注），物化视图其实最大的价值是解决多表关联查询，本质也是改写 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 格式）存储的。
#02
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 在最近的每个版本里都有大幅的特性增强。
#03
云原生是大势所趋
鉴于云原生技术对大数据的良好助推作用，已经有不少技术嗅觉敏锐的玩家在此尝到了甜头。例如，华为云推出 FusionInsight MRS 实现云原生数据湖；Cloudera 推出 CDP Private Cloud Data Services 与 Kubernetes 结合提升资源利用效率；AWS 推出 EMR on EKS（Kubernetes），其效果据称能够提升 EMR 中 Spark 任务计算性能 68%，成本下降 61%；智领云自主研发的Kubernetes Data Platform（KDP），作为市场上首个可完全在Kubernetes上部署的容器化云原生大数据平台。
由此可见，无论是出于性能提升还是成本优势，与云原生相结合都是未来大数据的发展趋势。要怎么理解呢？简单来说，就是将我们的数据、AI 和业务应用都统一放到一个底座上来，也就是 Kubernetes ，通过这个底座，我们可以很容易将其部署在公有云、私有云亦或是自建 IDC 中；至此，云原生的灵活性得以充分发挥。在其之上，亦可以搭建更开放，更具经济效益的大数据架构。
作为国内云原生大数据核心技术的先行者和倡导者，智领云KDP深度整合了云原生架构的优势，在Kubernetes上使用原生的分布式功能搭建及管理大数据平台，将Hadoop、Spark、Kafka等一套组件构建在统一的数字底座上，进行统一管理，从而达到资源共享。
扫码关注云原生大数据平台KDP
- FIN -
更多精彩推荐
👇点击阅读原文，了解更多详情。
扫一扫
1070
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
