前言：分布式是大数据处理的万能药？今天叶秋学长跟大家一起探讨这个问题~
使用分布式集群来处理大数据是当前的主流，将一个大任务拆分成多个子任务分布到多个节点进行处理通常能获得显著的性能提升。因此，只要发现处理能力不足就可以通过增加节点的方式进行扩容，这也是很多拥趸者最朴素的想法。以至于当我们接触一项新的大数据处理技术往往首先问的就是支不支持分布式以及能支持多大规模的集群，可见“分布式思维”已经根深蒂固。
那么分布式真是处理大数据的万能药吗？
“万能”当然不可能。没有包治百病的灵药，任何技术都有其适用场景，分布式也一样。
能否使用分布式技术解决处理能力问题，要结合任务的特点来看。如果这个任务很容易拆分，就可以使用分布式；否则如果任务比较复杂，拆分后还要相互耦合引用甚至发生大量跨节点数据传输等情况就不一定适合使用分布式了，如果强行使用效果反而更差。
具体来说，大多数交易型（OLTP）场景都较为合适，单任务涉及数据量很小但并发很多，任务很容易拆分，适合使用分布式技术提升性能（虽然会面临少量分布式事务，但目前已有成熟技术处理）。
对于分析型（OLAP）任务则要复杂一些。有些简单查询也适合分布式，比如帐户明细查询（中国近期流行的健康码查询就是此类）。这类查询的总数据量巨大，但每个帐户的数据量很少，而每个查询任务也只要本帐户的数据，并不涉及复杂计算，很类似上述OLTP场景中单任务涉及数据量小且相互无关的特点，因此很容易拆分，这时增加分布式节点就可以有效提升查询效率。在这类场景下分布式也可以称得上是灵药了。
但对于复杂一些的计算场景就未必了。比如我们常见的关联运算，在分布式环境下关联运算会有Shuffle的动作，要在节点之间交换数据，当节点数较多时数据交换造成的网络延迟就会抵消多机分摊计算带来的性能提升，再增加节点性能不仅不会提升反而可能下降。很多分布式数据库都会有节点数上限的指标，就是因为这个原因，而且这个上限还很低，通常也就几十最多上百就达到了。
更重要的是，分布式集群算力也并不能线性扩展。集群由多个物理机组成，多机通过网络进行通信。当集群中发生本机内存不足需要访问其它节点的内存时就需要通过网络，而网络只适合批量访问，但内存的使用常常是小量随机式的。通过网络进行跨节点内存访问就会导致性能下降十分明显，通常是一两个数量级的。这就需要动用数倍甚至数十倍的硬件资源才能弥补性能的缺失。使用集群虽然能提升算力，但并不能线性地扩展，在有限的节点限制下能够发挥的作用也十分有限。这时对于想要分布式发挥“无限算力”的小伙伴，分布式技术也只能遗憾了
我们实际业务中还有很多更复杂的计算场景，比如常见的跑批任务，就是每天空闲（如夜间）时间将业务数据加工成待用的结果，这类运算复杂度极高，不仅计算规则复杂并且有先后顺序，多步骤运算要按照顺序逐次完成。处理时还会涉及大量历史数据，可能要反复读取并关联，这会导致分布式技术应用困难。即使计算任务能够拆分，在数据加工的过程中经常还会生成中间结果落地以便下一步继续使用，这些临时产生的中间结果由于无法及时分布到其他节点上（临时产生的中间数据无法事先冗余），其他节点要计算就要借助网络交换数据又会大幅降低性能。在这类复杂计算场景下，别说分布式节点限制，就是想利用分布式技术都不容易，灵药就更谈不上了。所以这类复杂业务常常还是使用大型单体数据库实施，不仅成本高，容量随着任务的增多也很容易达到上限。
那么，这种场景的计算性能碰到瓶颈，如果分布式不能解决，那又能怎么办呢？
要解决问题，要先分析这类运算有什么特点，运算慢的原因到底在哪里。
其实，深入研究一下这类场景的特点就会发现，很多 “慢”运算涉及的数据量并不是很大。这类计算通常是基于以业务数据为核心的结构化数据进行的，数据总量虽然很大，但单次任务涉及的并不大，通常也就几十到几百GB，很少上TB的。比如一个典型的银行跑批场景，假设有2000万账户，每个账户每月一条汇总记录，跑批通常会使用过去一年的历史数据计算，总体算下来也不到3亿行。假设每条记录有100个统计值，每行按1K估算，物理大小也就300G左右，使用一些简单技术也能压缩到100G以内。这种数据规模单机通常就可以容纳了。
数据量并不大，那为什么会跑这么慢呢？跑批要数小时的情况比比皆是。
主要原因有两个。
一是计算复杂。数据量虽然不大，但计算过程中会反复关联，计算量上来以后性能当然就变差了。我们举个极端一点的例子，国家天文台的天体聚类计算场景就是数据量不大但计算复杂度高导致性能低下的情况。该场景共有11 张照片（数据），每张有 500 万天体，数据量总共不超过10G。现在要将位置（天文距离）邻近的天体聚合成一个再计算属性。这个任务的数据量虽然不大，但计算量非常大，和规模的平方成正比，天文距离的计算次数大约是500万 *500万 *10张=250万亿次，这真是个天文数字。这个任务用某分布式数据库动用 100 个 CPU，仅处理 50 万天体也需要 3.8 小时，处理 500 万目标规模则需要 15 天（用户期望是在数小时内处理完）。
二是单机计算性能没有被充分发挥，换句话说就是硬件资源利用率低，这跟应用的数据处理技术密切相关。我们目前处理结构化数据还主要使用SQL（数据库），这是无法发挥单机计算性能的重要原因。SQL由于缺乏一些关键的数据类型（如记录类型）和基本运算（如有序计算）导致很多高性能算法都无法描述，结果只能使用慢算法。虽然现在很多数据库在工程上有所优化，但也只能针对简单的场景，情况复杂之后数据库的优化器就会失效，解决不了根本问题。这也解释了上面天文台的例子使用SQL即使借助100CPU的集群计算时间仍然无法满足需要的原因。
事实上，如果数据处理技术能够根据实际计算场景因地制宜地使用适合的算法，就可以降低计算复杂度提升计算性能。这里的关键是，高性能算法不仅要能想出来，还要能写出来。SQL就很难实现这个目标，即使能想出来也实现不了，最后只能干瞪眼。
除了SQL，像Spark这样的新兴计算技术也同样存在性能差（资源利用率低）的问题。Spark中的 RDD 采用了immutable机制，在每个计算步骤后都会复制出新的 RDD，造成内存和 CPU 的大量占用和浪费，资源利用率很低，想要达到性能要求就需要依靠大集群大内存。
因此，想要充分利用硬件资源提升计算效率就要再选用其他技术，这就要提到SPL了。
与SQL类似，SPL也是专门面向结构化数据的计算引擎。不同的是，SPL采用了更加开放的计算体系，内部提供了很多高性能算法实现机制（以及对应的高性能存储），可以达到高效算法不仅能想出来还能实现的目标，甚至还很容易实现。这样就可以将硬件资源发挥到极致，本来要用集群的运算也可以不用集群，大集群可以改用小集群。
还是拿上面天文台的例子来说，如果一样老老实实地对比250万亿次，SPL也没法做到更快。但可以想办法优化算法，具体到这个问题时，可以利用天体距离的单调性和有序性进行粗筛，用二分法迅速把可能匹配的天体定位到很小的范围内，排除了绝大多数的比对计算；计算复杂度就可以减小到原来的1/500，再结合并行计算就可以有效提升计算效率。
前面我们说了，高性能算法不仅要能想出来，还要能实现。SPL实现这个优化后的算法要多少代码呢？一共50行！效果怎么样呢？500万规模的全量数据使用16CPU可以在4小时内完成，整体相对SQL方案可以提速几千倍。（具体案例细节可以参考： SPL 提速天体聚类任务 2000 倍）
细心的小伙伴可能发现了，在这个案例中要达到用户要求的性能指标SPL使用的硬件资源很少，单机就可以满足，并不需要分布式。这就是我们主张的：先把单机性能发挥到极致，不够用再分布式。
SPL还实施过很多这样单机*群的案例，比如在某商业银行的手机银行多并发账户查询场景中，SPL使用单台服务器就达到了原来6台ElasticSearch集群的查询效率，同时解决了实时关联的问题（案例详情： 开源 SPL 将银行手机账户查询的预先关联变成实时关联）。还有在电商漏斗计算场景中，SPL使用8CPU可以跑出29秒的结果，而同样的计算在Snowflake 的 Medium 级服务器（4节点集群）上三分钟未跑出结果（细节参考： SQL 提速：漏斗转化分析）。
除了实现单机*群的效果外，对于原本在单体数据库上跑得慢的任务，使用SPL充分发挥单机性能后也能提速很多倍，这样就不必再求助于分布式了。比如，在某银行的对公贷款业务计算中，原本使用AIX+DB2要计算1.5小时，改用SPL后不到10分钟就可以完成，性能提升10倍（案例详情： 开源 SPL 提速银行贷款协议跑批 10+ 倍）。还有某大型保险公司的车险跑批场景中，使用SPL替代数据库将跑批时间从原来的2个小时提升到17分钟，提速7倍（案例详情： 开源 SPL 优化保险公司跑批优从 2 小时到 17 分钟）。类似的案例还有很多，对SPL高性能计算案例及原理感兴趣的小伙伴可以参考： 快出数量级的性能是怎样炼成的。
当然，这里并不是要反对分布式，而是希望不要“无脑”分布式，把单机性能充分发挥完不够用再使用分布式才是解锁大数据计算的正确姿势。
SPL也提供了完善的分布式计算功能，有相应的负载均衡和容错机制，针对不同的需求和计算场景可以使用不同的容错方案（如冗余式容错和备胎式容错）。值得一提的是，SPL集群的定位是中小规模，集群节点最好不要超过32个。由于SPL具备极高的计算性能可以有效利用硬件资源，因此在实际应用中这个集群规模已经足够用了，很多场景使用单机最多几台就都搞定了。当然，如果遇到极少数需要更大集群的应用场景就需要选用其他技术了。
总结一下，应用分布式的前提是任务易“拆”，更关键的是，先要充分发挥单机性能之后再分布式。