分布式是大数据处置处罚的万能药？

使用分布式集群来处置处罚大数据是当前的主流，将一个大任务拆分成多个子任务分布到多个节点进行处置处罚通常能获得显著的性能提升。因此，只要发现处置处罚能力不足就可以通过增长节点的方式进行扩容，这也是许多拥趸者最质朴的想法。以至于当我们打仗一项新的大数据处置处罚技术往往首先问的就是支不支持分布式以及能支持多大规模的集群，可见“分布式思维”已经根深蒂固。
那么分布式真是处置处罚大数据的万能药吗？
“万能”固然不大概。没有包治百病的灵药，任何技术都有其适用场景，分布式也一样。
能否使用分布式技术解决处置处罚能力题目，要联合任务的特点来看。假如这个任务很轻易拆分，就可以使用分布式；否则假如任务比较复杂，拆分后还要相互耦合引用乃至发生大量跨节点数据传输等环境就不一定恰当使用分布式了，假如强利用用结果反而更差。
详细来说，大多数生意业务型（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具备极高的盘算性能可以有效利用硬件资源，因此在实际应用中这个集群规模已经足够用了，许多场景使用单机最多几台就都搞定了。固然，假如遇到极少数必要更大集群的应用场景就必要选用其他技术了。
总结一下，应用分布式的条件是任务易“拆”，更关键的是，先要充分发挥单机性能之后再分布式。
SPL资料

• SPL下载
  
• SPL源代码
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。