当下时代，数据为王，很多人伙伴每天都在使用数据，处理数据。其中相当一步人甚至在维护数据集，要出来大数据相关的任务。那么在维护一个巨型数据集时候需要注意什么，会遇到什么问题呢，如何解决这些问题？这可能是很多人会问的一系列问题。本文我们就来学习一个老哥总结的处理TB级数据集时的一些经验教训和通用方法。

处理一个数据相对很容易，但是随着数据的不断增加，这个任务就会变得越来越不寻常。当数据集规模一步步扩大时，可能就会面临一系列的问题需要解决，其中牵涉到工具方面的扩展也涉及到架构方面的优化和更新。这个文章主要介绍在单机环境和多级集群情况下两种数据扩展之旅，涉及横向和纵向扩展，最大程度利用可用的资源实现任务目标。

需要注意的是任何优化或扩展都无法弥补有缺陷的算法。在扩大规模之前，首先评估算法至关重要，一个劣质算法可能会让你走很多弯道，甚至会掉坑里。

计算是扩展时首先可能遇到的瓶颈。扩展计算可以通过几种不同的实用方法来完成。数据科学家或机器学习工程师可能都熟悉Joblib，这是一个用于并行运行代码的库，一些常见计算库中都用到过，例如scikit-learn或XGBoost。

使用Joblib并行化某些内容的过程很简单，如下所示：

>>> from joblib import Parallel, delayed

>>> from math import sqrt

>>> parallel_mapper = Parallel(n_jobs=-1)

>>> delayed_func = delayed(sqrt)

>>> jobs = [

delayed_func(x**2)

for x in range(10)

]

>>> parallel_mapper(jobs)

[0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0]

Joblib 是扩展并行工作负载的好方法。 它用于 scikit-learn 和其他工具，证明对于许多工作负载都是可靠的。 这甚至没有考虑其有关记忆或快速压缩持久性的其他出色功能。 Joblib 对于使函数在所有 CPU 核心上可并行化很有帮助。

GNU Parallel是著名的Linux命令行CLI工具，可以用于并行任务。广泛用于大量数据预处理或提取数据的数据准备任务重。与Joblib不同，GNU Parallel可以在脚本之外使用并且用途广泛。甚至可以并行运行其他shell脚本或者Python脚本等。比如要解压一个一个目录中大量的压缩包，如果手动或者其他方法处理比较繁琐，但是使用GNU Parallel则可以手到擒来：

ls | parallel --eta --bar "unzip -q {} -d output/"

对于Linux老手，这就是一个非常简单的单行任务。实际中在数据处理工作中，善用单行脚本命令可以极大简化我们的任务。

对于任何任务，一旦将bash命令设置为在单个文件上运行，就可以通过稍微修改命令来并行化它。 默认情况下，并行使用所有可用的CPU核心，并且可以使用ssh在多台计算机上执行命令，然后paralle将这些机器临时征为一个计算集群并行处理。

如果对于更复杂的任务，则可以使用Ansible和Ansible Playbook来处理。

何时需要切换到使用多台机器（例如Spark或Dask等集群）的一个关键标志是计算对于用例来说花费的时间太长。可以用实验、数据处理或其他一些任务来评估。一般来说一个让仍不能容忍边界是把单机配置增加到最大，比如AWS的 u-24tb1.112xlarge的VPS（448 CPU，24T内存），某些工作也需要数月或一年才能完成计算，那必须要采用集群方案了。

通过切换到多台较小的计算机，可以比更突出的实例获得多种性能优势。根据您的扩展解决方案，水平扩展允许跨CPU、内存和网络与使用的实例数量进行几乎线性的扩展。

除非有些特殊需求，一般建议可以采用公有云VPS组集群方案来进行任务，一方面可以节省一次性硬件费用，二是可以灵活扩展升缩集群规模，临时改变架构。

大多数相当大的云VPS实例提供高达10 GBit的互联网速度，这可以帮助缓解IO瓶颈，特别是当快速将数据传入或传出时。如果工作负载需要高速IO传入数据是，可以使用云厂商的IO优化VPS实例，可以在通过短时间的实例费用获取你需要的带宽要求（如果对于自建集群则需要花费成本太过高昂）。

以AWS云方案为例子一台u-24tb1.112xlarge的成本可以足够换成135个 m7i.8xlarge VPS。这可以得到4320 CPU（单机的10倍）、17.28TB RAM和1687.5 Gigabit互联网速度（单机的17倍）！虽然RAM相比较高性能单机要少点，如果要让内存更高点，可以选用内存优化的配置，则可以让内存达到34.56 TB。使用多台机器的还可以带来更大意义上优势，比如系统冗余（防止单点故障）、对实例大小的更精细控制等，可以按照需求随时间可以临时增加和减少配置和VPS主机数量等。此外，通过正确的后端，可以扩展到用例、编排工具或计费实现允许的任意数量的实例。这种级别的可扩展性是一项至关重要的优势，使能够满足工作负载的需求，而不受单个实例功能的限制。

与所有事情一样，不同的方法各有好处。评估每个解决方案的优缺点，并确定最适合用例的方案。在最大化性能的同时最小化成本最终的目标。

与其他类型的工作负载相比，令人尴尬的并行工作负载通常是最容易扩展的。前面讨论了如何使用Joblib或Parallel扩展计算，但是扩展到多台机器呢？有很多工具可以扩展计算。建议使用工具（比如AWS的Batch或Lambda）来处理一次性的极其并行的工作负载。批处理是可扩展的，并且，可以以使用按需实例的一小部分成本来完成大部分任务，而所需的时间只是在单台计算机上并行运行它们所需的时间的一小部分。

值得一提的一个警告是，作业的总体吞吐量将更多地受到读取和写入速度的限制，而不是计算速度。 如果正在读取/写入数据库，那么数据库可能会成为瓶颈（甚至崩溃）。S3是一个可行的读写选项，因为它的设计目的是更好地扩展，但它仍然有其局限性。每个分区前缀每秒3500次写入和5500次读取。S3被设计为在扩展到用户时不可见，因此可能无法控制它如何适应增加的吞吐量。一旦数据位于S3（或您使用的任何服务）中，就可以将其传输到任何需要的地方。

这种设置相当乏味，但对于一次性任务来说可以很好地扩展。通过几次迭代，可以将设置时间减少到几分钟，具体取决于流程自动化程度和团队的需求。一般来说，设置时间对于节省的计算和工程时间来说是值得的。

分析负载

分析工作负载的扩展更具挑战性。通常需要对单个数据集并尝试对该数据集执行大量操作。可能还具有交互性元素，例如在Jupyter Notebook中运行的内容。用于扩展分析工作负载的首选工具是Dask，另一种选择是Spark。

Dask和Spark 都是开源工具，可让工作负载扩展到多台机器，各有优缺点。这两个工具也可以在本地使用，并且它们的DataFrame（Dask DataFrame和Spark Dataframe）实现可用于扩展现有工作负载。

Dask的设置和安装要容易得多。可以使用一个命令在几分钟内让Dask在本地运行（pip install "dask[complete]"顺便一提）。另一方面，Spark需要更多的设置，而且在本地计算机上运行更具挑战性。Dask的另一个好处是，任何使用Pandas或Numpy的数据科学家都可以很快习惯它，而Spark则，需要一套完全不同的技能。Dask还与多个PyData工具更好地集成，这样就可立即让他们协同跑起来。

相比之下，Spark和Spark生态系统要成熟得多，并且团队可能已经投入了时间来启动和运行Spark集群。我在使用Dask时偶尔会遇到错误或性能问题，而Spark由于其成熟度而更加稳定。Dask也不适合长时间运行的计算。

鉴于此，一般建议是：

如果是一个小团队或初创公司，没有大数据或分布式计算的基础设施。在这种情况下，建议至少尝试使用Dask，无论团队在 Spark方面的经验如何。在在本地运行Spark时，可以使用Dask验证您的用例，并且团队将能够利用PyData空间中的其他工具。

如果已经使用过Spark 或将其作为重要数据基础设施的大型组织的一部分。在这种情况下，坚持下去是有意义的，但是如果你没有用过Dask，如果可以尝试一下，两者可以共用。

总之，管理和扩展多 TB 数据集需要深入了解您的数据和您可以使用的工具。 通过利用 Joblib 和 GNU Parallel 进行单机扩展，您可以最大限度地提高计算资源的效率。 当需要扩展到单台机器之外时，AWS Batch、Dask 和 Spark 为各种工作负载（从令人尴尬的并行任务到复杂的分析操作）提供强大的解决方案。

关键要点是在扩展之前首先优化算法，确保您不仅仅是放大低效率。 积极探索和采用新工具可以显着提高您的绩效和成本效益。 成功的扩展不仅取决于原始计算能力，还取决于战略规划和资源管理。 拥抱学习曲线； 您将有足够的能力自信而熟练地处理最大的数据集。