大数据计算技术秘史（下篇）

上周太可研究所（techinstitute）发布了大数据中的计算机技术（上），主要沿着 Spark 梳理了计算引擎技术的部分变革。今天，我们将沿用上期的思路，继续回顾计算机引擎的技术发展及格局。

Vol.1

尽管大家一直强调“算法、算力、数据是 AI 的基石”，但 AI 和大数据技术栈在 10 年代并没有太多交集。一方面，大数据技术对只会写 Python 的算法同学来讲太难了；另一方面，数据方向的同学不太了解算法的场景。Spark 倒是很早之前就开发了 Spark ML 模块，社区里有 Spark NLP 这样的项目，且 Databricks 也一直声称自己是一家 AI 公司。不过，以太可研究所（techinstitute）的经历来看，之前诞生的计算引擎都很难满足 AI 的需求。

AI 场景确实需要分布式计算框架，以满足 AI 负载的特点。总体来看，从大方向来看，AI 包括数据清洗、训练、推理，需要处理结构化、非结构化数据，需要用到 GPU、CPU，而面向结构化、半结构化的而设计的计算引擎也只能做到数据清洗这一步。而 AI 需要更契合自身的计算框架，这两年新兴的 Ray 项目填补了这一空缺。

Vol.2

数据系统最大的问题是没有一个系统能解决所有的用户需求。Hive 太慢，Spark 更专注离线处理，Presto 对数据更新不友好，Flink 批处理能力太弱，ClickHouse 存储太封闭、join 不友好。总之，每个计算引擎都有自己专注的领域，也都有自己的局限性，所以大一点儿的公司都会集成很多产品，数据集成、统一的查询入口就成为了必需品。

由于离线计算、交互式查询、AI训练、流式计算等需求加在一起，光计算引擎就得部署好几个，再加上存储、调度、数据治理、BI、AI 等产品，让构建数据架构成为了一个非常复杂的任务。

其实，如果想要让架构简单，最理想的状态是一个产品可以满足所有需求。当前有两个方向的产品有希望实现这一目标，一是从数据处理起家的 Spark，另一个是从数据库起家的 ClickHouse 和 Doris。

Spark 的优势在于各方面都做得不错，劣势在交互式分析偏慢，以及不是以服务的形式对外提供服务。目前， Spark 社区有 Gluten 这类 Native 执行引擎，用 C++ 或 Rust 重写执行引擎部分提升交互式查询的性能。同时， Spark 3.4 之后增加了 Spark connect 模块，可以提供对外常驻服务。此外，Apache kyuubi 还在 Spark 之上构建了一层多租户、交互式的 JDBC 服务。

关于数据库起家的 ClickHouse 和 Doris，我更看好 Doris，不过 Doris 最大的问题是主要开发、运营人员都在国内，能不能走出亚洲、冲向世界还有待时间验证。相比于 Spark、Presto，数据库们的优势在于存储、索引、查询都在一个体系内，可以做最大程度的优化。但是成也一体化败也一体化，数据库的封闭性让系统很难扩展，对于AI、更令灵活的使用数据的场景很不友好。

Vol.3

以 Databricks 为首的一派做大数据起家的产品，现在一直在吹 LakeHouse 的概念。就像 Spark 什么都能干一样，LakeHouse 的概念里融合了 Data Warehouse 和 Data Lake，可以接任意类型的负载，例如基于 SQL 接口的在交互式查询、使用 Java/Python/SQL 的数据处理任务、面向 AI 场景的数据应用等，都在 LakeHouse 里完成。LakeHouse 的概念如下图所示，Spark 技术在其中作为计算引擎：

图源｜https://dipankar-tnt.medium.com/onetable-interoperability-for...

LakeHouse 最大的卖点在于灵活、扩展性以及开放。虽然各 LakeHouse 产品的代码不一定开源，但会支持开放的表格式，即表的访问不一定通过 LakeHouse 的 SQL 接口，可以使用任意计算引擎对接。比如，如果用户嫌弃 SQL 接口能力太弱，完全可以基于 Spark、Presto、Arrow 等技术自己实现一套计算逻辑，同时无缝对接 LakeHouse 的存储。

以 ClickHouse 为首的数据库派系则走上了另一条道路，主打开箱即有的高性能，架构简单。毕竟数据库的特点是存储计算都有自研引擎，所以优化空间很大，是自成一体的体系，完全不用管社区如何使用自研存储的问题。这些 OLAP 数据库也在逐渐支持 LakeHouse 存储，支持以外部表的形式读写，但性能可能比原生的存储要差一截。所以，现在又有不少数据库厂商把数仓理论中分层的理念捡了起来，把 LakeHouse 层的数据作为 ODS 层， ods 之上的 dwd、dm、ads 层要高性能就用内部表。

以上两个方向在很多大厂内部也是互相卷的状态，自研 OLAP 数据库团队和大数据平台团队，一时之间难分胜负：自研数据库时间肯定更长，使用 LakeHouse 可以快速与现有生态对接，不过自研数据库的天花板肯定更高。因此，架构师们在做技术选型时需要做一些取舍，根据自身的业务特点决定方向。

Vol.4

至此，我们以 Spark 技术为引子，串联了一些其他计算引擎技术，帮助大家重新回顾了一段大数据计算引擎的历史和现有格局。

虽然我一直在唱衰 Hadoop 生态，鼓吹数据库和 LakeHouse 技术，但不代表 Hadoop 一无是处。Hadoop 的出现为业界提供了分布式存储和计算的大门，尽管技术在现在看来没那么性感，但它的徒子徒孙依旧发挥着重要作用，还在使用 Hadoop 技术的同学依旧可以无缝转移到其他衍生技术栈；而准备入行 Hadoop 的同学还是要慎重一点。可以说，计算技术一直在持续演进，即使在寒气逼人的 2023 年，依旧有新的计算引擎出现，保持一颗学习和研究的心态很重要。