共计 5002 个字符，预计需要花费 13 分钟才能阅读完成。
豆瓣成立于 2005 年，是中国最早的社交网站之一。在 2009 到 2019 的十年间，豆瓣数据平台经验了几轮变迁，造成了 DPark + Mesos + MooseFS 的架构。
由机房全面上云的过程中，原有这套架构并不能很好的利用云的个性，豆瓣须要做一次全面的从新选型，既要思考将来十年的发展趋势，也须要找到与现有组件兼容且平滑过渡的解决方案。一番革新后，豆瓣数据平台目前造成了 Spark + Kubernetes + JuiceFS 的云上数据湖架构，本文将分享此次选型降级的整体历程。
01 豆瓣晚期数据平台
在 2019 年，豆瓣所应用的数据平台次要由以下组件形成：
Gentoo Linux，外部应用的 Linux 发行版；MooseFS，分布式文件系统；Apache Mesos 负责整个集群的资源管理，以及 Dpark 作为分布式计算框架提供给开发者应用。
从上图能够看到在这个数据平台中，计算和存储是一体的，每个计算工作是由 Mesos 进行调度的。计算工作的 I/O 操作都是通过 MooseFS 的 Master 获取元数据，并在本地获取须要计算的数据。此外，GPU 计算集群也是通过 Mesos 进行治理，不同的是，GPU 会基于显存进行共享。
平台组件介绍
Gentoo Linux
Gentoo Linux 是一个较为小众的 Linux 发行版，具备简直无限度的适应性个性，是一个原发行版。Gentoo Linux 采纳滚动更新的形式，所有软件包都间接从社区中获取二进制包，咱们则通过源代码构建咱们所需的软件包。Gentoo Linux 有一个弱小的包管理器，应用它也会带来很多便当，也同时存在一些问题。比方，滚动更新的速度十分快，但对于服务器来说，可能存在肯定的不稳定性。
应用源代码构建软件包的益处是当社区没有预编译好咱们所需的软件包时，咱们能够非常简单地构建出本人所需的软件包，并且当已有的软件包无奈满足咱们的需要时，也能够很容易地进行定制调整。但这也会带来较高的保护老本。
另外，如果所有软件包都能依照标准进行编写的话，依赖抵触问题简直是不存在的，因为在打包过程中就曾经能够发现。但理论状况是并不是所有软件包都能恪守一个好的依赖形容的约定，因而依赖抵触问题可能依然存在。
Gentoo Linux 是较为小众的抉择，只管社区品质很高，然而用户也比拟少，一些新我的项目可能没有用户进行足够的测试，咱们在理论应用过程中会遇到各种各样的问题。这些问题大部分须要咱们本人解决，如果期待其他人回复的话，响应会比较慢。
MooseFS
MooseFS 是一个开源的、合乎 POSIX 规范的分布式文件系统，它只应用 FUSE 作为 I/O 接口，并领有分布式文件系统的规范个性，如容错、高可用、高性能和可扩展性。
对于简直所有须要应用规范文件系统的场景，咱们都应用 MooseFS 作为替代品，并在其根底上开发了一些本人的小工具。例如，咱们能够间接应用分布式文件系统来解决 CDN 的回源。在晚期版本中，MooseFS 没有主节点的备份性能，因而咱们开发了一个 ShadowMaster 作为元数据的热备节点，并编写了一些剖析 MooseFS 元数据的工具，以解决一些运维问题。作为一个存储设施，MooseFS 整体比较稳定，并且没有呈现重大的问题。
Apache Mesos
Mesos 是一个开源的集群管理器，与 YARN 有所不同，它提供偏心分配资源的框架，并反对资源隔离，例如 CPU 或内存。Mesos 早在 2010 年就被 Twitter 采纳，IBM 在 2013 年开始应用。
Dpark
因为公司全员应用 Python，因而应用了 Python 版的 Spark，即 Dpark，它扩大了 RDD API，并提供了 DStream。
公司外部还开发了一些小工具，例如 drun 和 mrun，能够通过 Dpark 将任意 Bash 脚本或数据工作提交到 Mesos 集群，并反对 MPI 相干的工作提交。Dgrep 是用于疾速查问日志的小工具，JuiceFS 也提供了相似的工具。尽管 Dpark 自身能够容器化，但公司次要的数据工作是在物理服务器上运行的。反对容器化能够让场内工作更好地利用线上业务的模型代码。
02 平台演进的思考
在 2019 年，公司决定将基础设施转移到云端并实现计算和存储拆散，以进步平台的灵活性。因为以前的计算工作在物理机上运行，随着工夫的推移，呈现了越来越多的依赖抵触问题，保护难度一直减少。
同时，公司心愿外部平台可能与以后的大数据生态系统进行交互，而不仅仅是解决文本日志或无结构化、半结构化的数据。此外，公司还心愿进步数据查问效率，现有平台上存储的数据都是行存储，查问效率很低。最终，公司决定从新设计一个平台来解决这些问题。
平台演进时，咱们没有十分强的兼容性需要。只有老本收益正当，咱们就能够思考将整个平台替换掉。这就像是环法自行车较量中，如果车有问题就会思考换车，而不是只换轮子。在更换平台时，咱们如果发现现有平台的工作无奈间接替换，能够先保留它们。在切换过程中，咱们有以下次要需要：
- Python 是最优先思考的开发语言。
- 必须保留 FUSE 接口，不能间接切换到 HDFS 或者 S3。
- 尽可能对立基础设施，曾经选用了局部 Kubernetes，就放弃了 Mesos 或其余备选项。
- 新平台的学习老本应尽可能低，让数据组和算法组的共事可能以最低的老本切换到新的计算平台上。
03 云上构建数据平台
目前的云上数据平台简直是全副替换了，Gentoo Linux 的开发环境变变成了 Debian based container 的环境，MooseFS 是换用了当初的 JuiceFS，资源管理应用了 Kubernetrs，计算工作的开发框架应用了 Spark，整体进行了彻底替换的，其余的设施是在逐步缩容的过程，还会共存一段时间。
JuiceFS 作为对立存储数据平台
为了更好地满足不同的 I/O 需要和安全性思考，咱们会为不同的应用场景创立不同的 JuiceFS 卷，并进行不同的配置。JuiceFS 绝对于之前的 MooseFS，创立文件系统更加简略，实现了按需创立。除了 SQL 数据平台外，咱们的应用场景基本上都是由 JuiceFS 提供的服务。
在 JuiceFS 中，数据有几种类型：在线读写、在线读取离线写入、在线写入离线读取、离线读写。
所有的读写类型都在 JuiceFS 上进行，比方日志汇聚到卷中，Spark 可能会读取并进行 ETL，而后将数据写入数据湖。此外，从 Kafka 数据源读取的数据也会通过 Spark 进行解决并写入数据湖。
Spark 的 Check Point 间接存储在另一个 JuiceFS 卷中，而数据湖的数据则间接提供给算法组的同学进行模型训练，并将训练后果通过 JuiceFS 写回。咱们的运维团队则通过各种脚本或工具来治理 JuiceFS 上的文件生命周期，包含是否对其进行归档解决等。因而，整个数据在 JuiceFS 中的流转过程大抵如上图所示。
新数据平台组件介绍
Debian based container
首先，运维团队抉择了 Debian based container 作为根底镜像，咱们就间接应用了。咱们的计算平台的镜像很大，为了解决工作启动速度的问题，团队在每个节点上预拉取了镜像。
JuiceFS
切换到 JuiceFS 存储系统时，用户感触不到变动，JuiceFS 十分稳固。JuiceFS 比 MooseFS 更好的一点是，它领有 HDFS 的 SDK，不便了团队未来切换到 Spark 等工具。团队在 Kubernetes 上应用了 JuiceFS CSI，间接实现了 KV 存储的状况，按需创立 volume 也很不便。JuiceFS 团队沟通高效，解决问题迅速。例如，当 stream 的 checkpoint 频率太高时，JuiceFS 团队早早告诉并迅速解决。
Kubernentes
咱们早在 1.10 版本的时候就开始试用 Kubernetes。起初豆瓣对外的服务集群在 1.12 版本开始逐渐迁徙到 Kubernetes，基本上是在现有机器上实现了原地的替换。计算集群则是在上云后开始搭建的，基于 1.14 版本。咱们在版本升级方面可能比其余公司更为激进，目前咱们的 Kubernetes 版本曾经降级到了 1.26 版。
咱们抉择 Kubernetes 作为计算平台的起因之一是它有比拟对立的组件。此外，通过 scheduling framework 或者 Volcano，咱们能够影响它的调度，这是咱们比拟心愿领有的一个个性。
咱们还能够利用社区的 Helm 十分疾速地部署一些须要的货色，比方 Airflow、Datahub 和 Milvus 等服务，这些服务都是通过 Helm 部署到咱们的离线 Kubernetes 集群中提供的。
Spark
在最开始测试 Spark 时，咱们像应用 Dpark 一样将工作运行在 Mesos 集群上。之后咱们选定了 Kubernetes，应用 Google Cloud Platform 上的 spark-on-k8s-operator 将 Spark 工作部署到 Kubernetes 集群中，并部署了两个 Streaming 工作，但并未进行大规模的部署。
随后，咱们确定了应用 Kubernetes 和 Airflow，打算本人实现一个 Airflow Operator，在 Kubernetes 中间接提交 Spark 工作，并应用 Spark 的 Cluster Mode 将工作提交到 Kubernetes 集群中。
对于开发环境，咱们应用 JupyterLab 进行开发。厂内有一个 Python 库对 Spark Session 进行了一些小的预约义配置，以确保 Spark 工作可能间接提交到 Kubernetes 集群上。
目前，咱们应用 Kubernetes Deployment 间接部署 Streaming 工作，这是一个很简略的状态，将来可能会有一些改良的中央。另外，咱们正在筹备试用 Kyuubi & Spark Connect 我的项目，心愿可能为线上工作提供更好的读写离线数据的体验。
咱们的版本升级十分激进，但的确从社区中获益匪浅。咱们解决了日常计算工作中许多常见的优化场景。咱们激进降级的起因是心愿可能尽可能多地利用社区的资源，提供新个性给开发者。但咱们也遇到了问题，例如 Spark 3.2 的 parquet zstd 压缩存在内存透露。为了躲避这个问题，咱们提前引入了未公布的补丁。
当初，咱们应用两种形式来读写 JuiceFS 数据：FUSE 和 HDFS。FUSE 次要用于 ETL 工作，例如读写日志和 CSV 文件。咱们也会将 Hive 表转存为 CSV 文件下载供未切换到 Spark 的工作进行计算。其余的数据，则间接通过事后配置好的 HDFS（如 Hive Table 和 Iceberg Table）进行读写，这大大简化了咱们的工作。
在数据湖的抉择上，咱们一开始思考了 Delta Lake，但因为它不反对 Merge on Read，在目前的应用场景存在写放大，咱们放弃了它。取而代之，咱们抉择了 Iceberg，并将其用于 MySQL CDC 解决。咱们将数据间接存储在 JuiceFS 上进行读写，并且目前没有遇到任何性能上的问题。将来，如果咱们须要扩充规模应用，可能须要与 JuiceFS 的团队沟通一下，看看有哪些优化措施。
04 播种与瞻望
咱们切换到新的计算平台之后，取得了很多原来没有的性能。例如，咱们当初能够应用基于 SQL 的大量工作，这些工作的性能比以前好得多，各种报表的实时性也更好了。
与 Mesos 的状况不同，Spark 申明了多少资源就应用多少资源，这与以前的 Dpark 相比有很大的差别，因为以前大家都是偏心分享，相互之间会有影响。当初，每个工作的执行工夫都比拟可预测，工作评估也比拟容易预测，整个新平台对于业务数据的读取也有更好的时效性。
以前的历史包袱是相当惨重的，当初咱们曾经赶上了社区的步调。去年年末的各种统计和排名都曾经迁徙到了新的计算平台上，并且运行十分稳固。
咱们正在优先思考采取一些老本降落措施，以实现整个计算集群的动静扩缩容。咱们正踊跃努力实现此指标，并心愿提供更加稳固的 SQL 接口。为此，咱们打算采纳反对 Multi-tenant 的 SQL 服务器，并尝试引入 Spark 3.4 的最新个性。
久远来看，咱们心愿通过 Spark Remote Shuffle Service 进一步实现存算拆散，以便更无效地利用资源。兴许将来咱们会开发一个“Spark as a Service”，提供给开发者应用。总之，咱们正在追赶社区的步调，并一直致力晋升咱们的技术水平。
如有帮忙的话欢送关注咱们我的项目 Juicedata/JuiceFS 哟！(0ᴗ0✿)