FreeBSD/ARM64 上的数据科学
最后更新于
最后更新于
原文链接：
作者：MACIEJ CZEKAJ
最近，ARM64 成为了 FreeBSD 的一级平台。鉴于 Semihalf 在支持所有基于 ARM 的 FreeBSD 系统方面拥有悠久的历史，因此在生产环境中采用 ARM64 是水到渠成的选择。然而，这次的测试平台有些不同，因为它不仅仅是另一个 Web 服务器和 NFS 存储阵列（我们已经有很多了），而是功能完备的数据科学实验室。
此次任务是在 Marvell ThunderX2 ARM 服务器上运行一项大规模的模拟实验。该模拟实验最终促成了一篇科学论文的发表以及博士论文中的一个章节。工作负载涵盖了数百个 CPU 小时的定制模拟软件运行，同时还使用了诸如 SciPy、Pandas 和 Jupyter 等标准的开源科学工具包。模拟系统的主要瓶颈是内存，同时磁盘 I/O 和数据完整性也受到了同样的挑战。该软件套件最初是为 Linux 开发的，因此必须通过遵循 POSIX 标准将其移植到 FreeBSD 上。
本次实验中使用的 ThunderX2 是一款双插槽、56 核的 ARM64 平台。单个 CPU 芯片拥有 28 个核心，这些核心分布在八个核心组中，通过环形互连相连，并共享一个横截带宽超过 6TB/s 的 L3 缓存。每个核心最多可支持 4 个 SMT 线程，整个系统的线程总数达到 224 个。每个芯片的 8 通道 DDR4 接口为整个系统提供了超过 200GB/s 的内存带宽。各个 CPU 芯片之间则通过 CCPIv2 互连连接，提供 600 Gb/s 的带宽。从这些规格来看，它似乎是内存密集型工作负载的理想目标。
图 1. ThunderX2 设备架构。
最初用于 GNU Linux/x86 桌面环境的该模拟系统，必须适应并行环境，而且这一过程可能不需要太多编程工作。系统的核心部分是一个用 C++ 编写的定制模拟器软件。该模拟器接收记录的分组追踪（PCAP 流），并生成一个网络流数据库。这个流可以来自文件，也可以来自另一个将多个分组流合并在一起的程序（称为混合器）。该网络流数据库采用一种自定义二进制格式，其内存组织方式类似于 C 语言中的结构体表。这种格式既便于在 C/C++ 中序列化（通过 frwrite()），也便于使用 Numpy 解析（通过 fromfile()）。
图 2. 在 FreeBSD 上执行的定制数据科学管道
下一阶段由 Jupyter Notebook 中的统计软件控制。每次实验都会产生数百万条记录，占用数 GB 的内存，这就要求使用以内存数据库形式的 Pandas DataFrame 对象来进行数据分析。整个数据处理流程则以一组 GNU Make 任务定义的形式描述。
从 GNU/Linux 到 FreeBSD-12.2 的移植过程相对简单。C++ 代码库主要使用 I/O 系统调用，而这些调用是 POSIX 标准的一部分。从 GCC 移植到 Clang 的过程中暴露了一些代码库本身的问题，这也印证了“使用多种编译器可以提高代码质量”这一普遍看法。唯一的功能性问题是使用了标准 C++ 库中的哈希函数。由于具体算法依赖于实现，为了保持结果的可重现性，必须提供该哈希函数的源代码。FreeBSD 上的 C++ iostream 库几乎没有遇到性能问题。当然，使用基于文本的 I/O 本来就是一个设计上的失误，因此这次移植工作只不过放大了这一固有的弱点。总而言之，C++ 代码的移植工作并不成问题，而使其成为多平台软件的过程反而提高了整个模拟器的质量。
令人惊讶的是，使用流行的 Python 框架所遇到的挑战比移植 C++ 代码更大。常用的科学计算包依赖众多，并且通常不包含在标准操作系统专用的 Python 堆栈中。核心问题在于如何匹配合适版本的 Python、Numpy、SciPy、Pandas、Scikit-learn 以及数十个其他依赖项。在 GNU/Linux 下，解决这一难题最流行的方法是使用二进制发行版 Anaconda。令我失望的是，Anaconda 开发团队并没有透露出支持 FreeBSD 的兴趣。除了从头编译所有组件之外，唯一的替代方案是使用 Python Virtualenv。问题很快就暴露出来：部分包期望使用 GCC，而另一些则假定存在 Linux 特定的包含路径。经过这一痛苦的过程，所有必要的包最终都被成功编译。需要注意的是，Python 包在很大程度上依赖第三方的 C 或 C++ 库，许多 Python 包实际上只是对用 C 语言编写的库的语言绑定。每次安装这些包时，都必须重新编译这些第三方依赖项。需要牢记的是，整个 Python 堆栈并非完全独立于底层系统，因此更新 FreeBSD 有可能会面临重复这一过程的风险。
如果说部署 Python 堆栈如此繁琐，那是否真的值得呢？归根结底——是的——这主要得益于并行计算。默认情况下，DataFrame 对象的计算是单线程的。然而，Pandarallel 包通过多进程方式实现了无缝并行化。尽管这种方式并不完美（因为它要求复制数据），但对于 CPU 密集型计算来说，其加速效果仍然十分显著。
图 3.Make 监理的并行化方案
该模拟系统被设计为单线程运行。分组处理任务必须保持分组顺序，因此核心算法必须保持顺序执行。将工作负载扩展到众多 CPU 核心的唯一可行手段是利用工作流程本身的粗粒度并行性。该工作流程定义包含 500 多个独立任务。每个任务的运行时间从几分钟到一小时不等，内存消耗在 10 到 30 GB 之间（仅用于数据结构，因此基本上构成了一个不可交换的常驻集）。
幸运的是，Make 工具能够通过广为使用的选项“-j”来管理固定数量的并行任务。最具挑战性的是如何根据任务不断变化的内存需求来调整进程数量。据我所知，没有哪个构建系统会试图基于内存压力来限制任务数量，它们通常只考虑 CPU 负载。多亏了臭名昭著的 FreeBSD OOM killer 以及 Make 工具中积累的数十年 UNIX 智慧，这一问题最终比预期要容易解决。每当任务数量超过内存容量时，内存溢出 killer 就会终止占用内存最多的进程。虽然这会导致部分 CPU 时间的浪费，但却保证了整个系统的稳定和响应性。而且，被终止进程生成的中间文件会由 Make 清除，从而不会影响数据完整性。这种行为依赖于正确定义的任务，因为只有显式定义的 Make 目标才会被删除。
该系统的最终版本在操作员间歇性监控下连续运行了一个多星期。通过使用基于 ZFS 文件系统的固态硬盘驱动器，成功满足了对磁盘 I/O 带宽的高要求。平台整体的稳定性无可置疑。
关于 FreeBSD/ARM64 作为科学平台的最终结论可以归纳为以下几点：
该平台提供了出色的稳定性。系统开销低且发行版简洁，为 CPU 密集型或内存密集型任务提供了充足的资源。
只要后端存储使用固态设备，I/O 子系统就能满足最苛刻的工作负载。
只要开发者遵循编写可移植代码的最佳实践，将软件从 x86_64 移植到 ARM64 架构基本上只需要重新编译即可。如果是从同一架构的 Linux 移植，Linux 兼容层则提供了原生二进制文件所需的 Linux ABI。
对于系统包管理器不支持的复杂软件栈（且没有其他包管理器作为替代）的移植，可能会带来一些挑战。此时，采用基于 jail 的预构建环境等捷径是最佳选择。正如开源社区一贯的规律，软件只有达到一定的用户规模，才能引起开发者的足够关注。
这是 FreeBSD 又一个成功的案例，证明了众多开发者的努力，他们使 ARM64 移植工作稳定到足以让该系统的使用普及得与任何 x86 机器一样。
MACIEJ CZEKAJ 是 Semihalf 的首席软件工程师，专注于高速网络应用和驱动程序。他是 DPDK 项目的贡献者，并宣称自己开发了最早的 ARM64 以太网设备驱动程序之一（ThunderX ARM64 服务器上的 VNIC 驱动程序）。他在波兰克拉科夫 AGH 科技大学完成了关于高速网络加速的计算机科学博士课程。