共计 4196 个字符，预计需要花费 11 分钟才能阅读完成。
在之前的文章《2024 年，一个大数据从业者决定……》《存储技术背地的那些事儿》中，咱们粗略地回顾了大数据畛域的存储技术。在解决了「数据怎么存」之后，下一步就是解决「数据怎么用」的问题。
其实在大数据技术衰亡之前，对于用户来讲并没有存储和计算的辨别，都是用一套数据库或数据仓库的产品来解决问题。而在数据量爆炸性增长后，状况就变得不一样了。单机零碎无奈存储如此之多的数据，先是过渡到了分库分表这类伪分布式技术，又到了 Hadoop 时代基于分布式文件系统的计划，起初又到了数据库基于一致性协定的分布式架构，最终演进为当初的存算拆散的架构。
最近十几年，Data Infra 畛域的计算技术以及相干公司层出不穷，最终要解决的基本问题其实只有一个：如何让用户在既灵便又高效，架构既简略又兼具高扩展性，接口既兼容老用户习惯、又能满足新用户场景的前提下应用海量数据。
解读一下，需要如下：
数据量大、数据品种多、数据逻辑简单
反对 SQL 接口，让习惯了 SQL 接口的 BI 老用户们实现无缝迁徙，同时要想方法反对 AI 场景的接口——Python
交互式查问提早要低，能反对简单的数据荡涤工作，数据接入要实时
架构尽量简略，不要有太多的运维老本，同时还能反对纵向、横向的程度扩大，有足够的弹性
据太可研究所（techinstitute）所知，目前市面上没有哪款产品能同时满足以上所有要求，如果有，那肯定是骗人的。所以在计算畛域诞生了泛滥计算引擎、数据库、计算平台、流解决、ETL 等产品，甚至还有一个品类专门做数据集成，把数据在各个产品之间来回同步，对外再提供对立的接口。
不过，如果在计算畛域只能选一个产品作为代表，那毫无疑问肯定是 Spark。从 09 年诞生起到当初，Spark 曾经公布至 3.5.0 版本，社区仍旧有很强的生命力，能够说穿梭了一个技术迭代周期。它背地的商业公司 Databricks 曾经融到了 I 轮，估值 430 亿💲，咱们无妨沿着 Spark 的倒退历史梳理一下计算引擎技术的改革。
Vol.1
大数据计算的场景次要分两类，一是离线数据处理，二是交互式数据查问。离线数据处理的的特点产生的数据量大、工作工夫长（工作时长在分钟级甚至是小时级），次要对应数据荡涤工作；交互式查问的特点是工作工夫短、并发大、输入后果小，次要对应 BI 剖析场景。
工夫拨回 2010 年之前，彼时 Spark 还没开源，过后计算引擎简直只有 Hadoop 配套的 MapReduce 能够用，早年间手写 MapReduce 工作是一件门槛很高的事件。MapReduce 提供的接口非常简单，只有 mapper、reducer、partitioner、combiner 等寥寥几个，工作之间传输数据只有序列化存到 hdfs 这一条路，而真实世界的工作不可能只有 Word Count 这种 demo。所以要写好 MapReduce 必定要深刻了解其中的原理，要解决数据歪斜、简单的参数配置、工作编排、两头后果落盘等。当初 MapReduce 曾经属于半入土的技术了，但它还为业界留下了大量的徒子徒孙，例如各个云厂商的 EMR 产品，就是一种传承。
Spark 开源之后为业界带来了新的计划，RDD 的形象能够让用户像失常编写代码一样写分布式工作，还反对 Python、Java、Scala 三种接口，大大降低了用户编写工作的门槛。总结下来，Spark 能短时间内取得用户的青眼有以下几点：
更好的设计，包含基于宽窄依赖的 dag 设计，能大大简化 job 编排
性能更高，计算在内存而非全程依赖 hdfs，这是 Spark 晚期最大的卖点，直到 Spark2.x 的官网上还始终放着一张和 mapreduce 的性能比照，直到这几年没人关怀 mapreduce 之后才撤掉
更优雅的接口，RDD 的形象以及配套的 API 更合乎人类的直觉
API 丰盛，除了 RDD 和配套的算子，还反对了 Python 接口，这间接让受众晋升了一个数量级
但晚期的 Spark 也有很多问题，例如内存治理不当导致程序 OOM、数据歪斜问题、继承了 Hadoop 那套简单的配置。Spark 诞生之初十分踊跃地融入 Hadoop 体系，例如，代码里依赖了大量 Hadoop 的包，文件系统和文件拜访接口沿用了 Hadoop 的设计，资源管理一开始只有 Hadoop 的 Yarn。直到现在这些代码仍旧大量应用，将来也不可能再做批改，所以说只管 Hadoop 可能不复存在，但 Hadoop 的代码会始终保留上来，在很多计算引擎外面施展着不可代替的作用。
Vol.2
无论是十分难用的 MapReduce 接口，还是绝对没那么难用的 Spark RDD 接口，受众只是研发人员，接口是代码。
无论是做数据荡涤的数据工程师，还是应用 BI 的数据分析师，最相熟的接口还是 SQL。
因而，市面上便诞生了大量 SQL on Hadoop 的产品，很多产品直到现在也还很有生命力。
最早呈现的是 Hive，Hive 的影响力在大数据生态里太大，大到很多人都认为它是 Hadoop 原生自带的产品，不晓得它是 Facebook 开源的。Hive 次要的能力只有一个就是把 SQL 翻译成 MapReduce 工作，这件事说来简略，如同也就是本科生大作业的程度，但想把它做好却是件十分有挑战性的工作，晚期也只有 Hive 做到了，而且成为了事实上的规范。
要把 SQL 翻译成 MapReduce 工作，须要有几个必备组件，一是 SQL 相干的 Parser、Planner、Optimizer、Executor，基本上是一个 SQL 数据库的标配，二是 metadata，须要存储数据库、表、分区等信息，以及表和 HDFS 数据之间的关系。
图源|https://www.interviewbit.com/blog/hive-architecture/
Hive 的这套思路影响了起初泛滥的计算引擎，例如 Spark SQL、Presto 等默认都会反对 Hive Metastore。Hive 的架构最大的瓶颈就在 MapReduce 上，无奈做到低提早的查问，也就无奈解决用户低提早、交互式剖析的需要。有个很直观的例子，每次用户提交一个 Hive 查问，能够去喝一杯咖啡再回来看后果。此外，哪怕是离线数据荡涤的工作应用 Hive 也绝对较慢。
Spark 在 2012 年公布的 0.8 版本中开发了 Spark SQL 模块，相似 Hive 的思路，把 SQL 编译成 RDD 工作，同期间的 Presto 也进入了 Apache 孵化器，指标也是解决大数据场景下交互式剖析的场景。Spark 和 Presto 反对 SQL 的工夫相仿，但起初走上了相当不同的路线，Presto 的定位更靠近一个 OLAP 数据库，重心在交互式查问场景，而 Spark 则将注意力放在数据处理工作上，是一个开发分布式工作的框架，从头至尾都不是一个残缺的数据库，市面上基于 Spark 开发的数据库产品，倒是有不少。
通过 SQL 交互在 10 年代晚期，逐步变成了支流应用大数据产品的支流范式，包含离线工作、交互式查问的接口都逐步对立到了 SQL。随着数据量进一步增长，查问性能始终解决得不好，哪怕是 Spark SQL、Presto，也只能把提早升高到分钟级别，还是远远无奈满足业务的需要。
这种状况直到 2015 年 Kylin 开源才得以解决，基于 Cube、预计算技术第一次将大数据畛域的交互式查问提早升高到了秒级，做到了和传统数仓达相似的查问体验。但 kylin 的做法代价也很大，用户须要自定义各种模型、Cube、维度、指标等等概念非常复杂，还要学会设计 rowkey 否则性能也不会很好。Kylin 的呈现让业界看到了秒级提早的可能性，至此内业一些同学甚至感觉大数据场景下 Hadoop + Hive + Spark + Kylin + HBase 可能就是最优解了，顶多还须要加上 Kafka + Flink 去解决实时数据的问题。
然而，2018 年 Clickhouse 横空出世，通过 SIMD、列存、索引优化、数据预热等一系列的暴力优化，居然也可把查问提早升高到秒级，而且架构极其简略，只有 Zookeeper + Clickhouse，就能解决下面一堆产品叠加才可解决的问题。这一下子戳中了 Hadoop 体系的痛点——Hadoop 体系产品太多、架构太简单、运维艰难。
自 ClickHouse 后，数据库产品们便开始疯狂排汇其优良教训，大数据和数据库两个方向逐步交融，业界从新开始思考「大数据技术真的须要独自的一个体系吗？」「Hadoop 的方向是对的吗？」「数据库能不能解决海量数据的场景？」这个话题有点巨大，能够放在当前探讨。
Vol.3
说回计算引擎，晚期的引擎无论是 Hive 也好，Spark 的 RDD 接口也罢，都不适宜实时的数据写入。而在大数据技术演进的这些年里，用户的场景也越来越简单。晚期的离线计算引擎只能提供离线数据导入，这就使得用户只能做 T+1 或近似 T+0 的剖析。但很多场景须要的是实时剖析，到当初，实时剖析曾经成为了新引擎的标配。
Spark 在 0.9 本版里提供了一套 Spark streaming 接口尝试解决实时的问题，但扒开 Spark streaming 的代码，不难发现它实际上是一段时间触发一个微批工作，对于提早没那么敏感的用户其实曾经够用了。当然也有想要近乎没有提早的用户，例如金融交易监控、广告营销场景、物联网的场景等。
实时流数据的难度要远高于批处理，首先，如何做到低提早就是个难点。其次，流数据自身品质远低于批数据，具体体现在流数据会有乱序、数据失落、数据反复的问题。此外，要做流解决还须要确保工作能长期稳固地运行，这与批处理工作跑完就完结对稳定性的要求很不一样。最初，还有很简单的数据状态治理，包含 checkpoint 治理、增量更新、状态数据一致性、长久化的问题。
Apache Flink 对这些问题解决的远比 Spark streaming 要好，所以在很长时间内 Flink 就是流计算的代名词。Spark 直到 2.0 公布了 structured streaming 模块之后，才有了和 Flink 同台竞技的资格。Flink 尽管在流计算场景里是无可争议的领导者，但在流计算的场景和市场空间远小于离线计算、交互式剖析的市场。能够这样认为，其在数据分析畛域精益求精的性能而非必备能力，Flink 背地的团队和 Databricks 差距也很大，曾守业两次，又先后卖给阿里和 Confluent，这可能也是 Flink 的影响力远小于 Spark 的起因。
好了，本次的大数据计算技术漫谈（上）就先谈到这里，下周同一时间，咱们持续！
