上周太可研究所（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 年，仍旧有新的计算引擎呈现，放弃一颗学习和钻研的心态很重要。