04 移动计算比移动数据更划算
大数据技术和传统的软件开发技术在架构思路上有很大不同，大数据技术更为关注数据，所以相关的架构设计也围绕数据展开，如何存储、计算、传输大规模的数据是要考虑的核心要素。
传统的软件计算处理模型，都是“输入 -> 计算 -> 输出”模型。也就是说，一个程序给它传入一些数据也好，它自己从某个地方读取一些数据也好，总是先有一些输入数据，然后对这些数据进行计算处理，最后得到输出结果。
但是在互联网大数据时代，需要计算处理的数据量急速膨胀。一来是因为互联网用户数远远超过传统企业的用户，相应产生了更大量的数据；二来很多以往被忽视的数据重新被发掘利用，比如用户在一个页面的停留时长、鼠标在屏幕移动的轨迹都会被记录下来进行分析。在稍微大一点的互联网企业，需要计算处理的数据量常常以PB计（1015 Byte）。
正因为如此，传统的计算处理模型不能适用于大数据时代的计算要求。你能想象一个程序读取PB级的数据进行计算是怎样一个场景吗？一个程序所能调度的网络带宽（通常数百MB）、内存容量（通常几十GB ）、磁盘大小（通常数TB）、CPU运算速度是不可能满足这种计算要求的。
那么如何解决PB级数据进行计算的问题呢？
这个问题的解决思路其实跟大型网站的分布式架构思路是一样的，采用分布式集群的解决方案，用数千台甚至上万台计算机构建一个大数据计算处理集群，利用更多的网络带宽、内存空间、磁盘容量、CPU核心数去进行计算处理。关于分布式架构，你可以参考我写的《大型网站技术架构：核心原理与案例分析》这本书，但是大数据计算处理的场景跟网站的实时请求处理场景又有很大不同。
网站实时处理通常针对单个用户的请求操作，虽然大型网站面临大量的高并发请求，比如天猫的“双十一”活动。但是每个用户之间的请求是独立的，只要网站的分布式系统能将不同用户的不同业务请求分配到不同的服务器上，只要这些分布式的服务器之间耦合关系足够小，就可以通过添加更多的服务器去处理更多的用户请求及由此产生的用户数据。这也正是网站系统架构的核心原理。
我们再回过头来看大数据。大数据计算处理通常针对的是网站的存量数据，也就是刚才我提到的全部用户在一段时间内请求产生的数据，这些数据之间是有大量关联的，比如购买同一个商品用户之间的关系，这是使用协同过滤进行商品推荐；比如同一件商品的历史销量走势，这是对历史数据进行统计分析。网站大数据系统要做的就是将这些统计规律和关联关系计算出来，并由此进一步改善网站的用户体验和运营决策。
为了解决这种计算场景的问题，技术专家们设计了一套相应的技术架构方案。最早的时候由Google实现并通过论文的方式发表出来，随后根据这些论文，开源社区开发出对应的开源产品，并得到业界的普遍支持和应用。这段历史我们在前面的“预习”中已经讨论过了。
这套方案的核心思路是，既然数据是庞大的，而程序要比数据小得多，将数据输入给程序是不划算的，那么就反其道而行之，将程序分发到数据所在的地方进行计算，也就是所谓的移动计算比移动数据更划算。
有一句古老的谚语，说的是“当一匹马拉不动车的时候，用两匹马拉”。听起来是如此简单的道理，但是在计算机这个最年轻的科技领域，在很长一段时间里却并没有这样做。当一台计算机的处理能力不能满足计算要求的时候，我们并没有想办法用两台计算机去处理，而是换更强大的计算机。
商业级的服务器不够用，就升级小型机；小型机不够用，就升级中型机；还不够，升级大型机，升级超级计算机。
在互联网时代之前，这种不断升级计算机硬件的办法还是行得通的，凭借摩尔定律，计算机硬件的处理能力每18个月增强一倍，越来越强大的计算机被制造出来。传统企业虽然对计算机的处理需求越来越高，但是工程师和科学家总能制造出满足需求的计算机。
但是这种思路并不适合互联网的技术要求。Google、Facebook、阿里巴巴这些网站每天需要处理数十亿次的用户请求、产生上百PB的数据，不可能有一台计算机能够支撑起这么大的计算需求。
于是互联网公司不得不换一种思路解决问题，当一台计算机的计算能力不能满足需求的时候，就增加一台计算机，还不够的话，就再增加一台。就这样，由一台计算机起家的小网站，逐渐成长为百万台服务器的巨无霸。Google、Facebook、阿里巴巴这些公司的成长过程都是如此。
但是买一台新计算机和一台老计算机放在一起，就能自己开始工作了吗？两台计算机要想合作构成一个系统，必须要在技术上重新架构。这就是现在互联网企业广泛使用的负载均衡、分布式缓存、分布式数据库、分布式服务等种种分布式系统。
当这些分布式技术满足互联网的日常业务需求时，对离线数据和存量数据的处理就被提了出来，当时这些分布式技术并不能满足要求，于是大数据技术就出现了。
现在我们来看，移动计算程序到数据所在位置进行计算是如何实现的呢？
1.将待处理的大规模数据存储在服务器集群的所有服务器上，主要使用HDFS分布式文件存储系统，将文件分成很多块（Block），以块为单位存储在集群的服务器上。
2.大数据引擎根据集群里不同服务器的计算能力，在每台服务器上启动若干分布式任务执行进程，这些进程会等待给它们分配执行任务。
3.使用大数据计算框架支持的编程模型进行编程，比如Hadoop的MapReduce编程模型，或者Spark的RDD编程模型。应用程序编写好以后，将其打包，MapReduce和Spark都是在JVM环境中运行，所以打包出来的是一个Java的JAR包。
4.用Hadoop或者Spark的启动命令执行这个应用程序的JAR包，首先执行引擎会解析程序要处理的数据输入路径，根据输入数据量的大小，将数据分成若干片（Split），每一个数据片都分配给一个任务执行进程去处理。
5.任务执行进程收到分配的任务后，检查自己是否有任务对应的程序包，如果没有就去下载程序包，下载以后通过反射的方式加载程序。走到这里，最重要的一步，也就是移动计算就完成了。
6.加载程序后，任务执行进程根据分配的数据片的文件地址和数据在文件内的偏移量读取数据，并把数据输入给应用程序相应的方法去执行，从而实现在分布式服务器集群中移动计算程序，对大规模数据进行并行处理的计算目标。
这只是大数据计算实现过程的简单描述，具体过程我们会在讲到HDFS、MapReduce和Spark的时候详细讨论。
小结
移动程序到数据所在的地方去执行，这种技术方案其实我们并不陌生。从事Java开发的同学可能有过用反射的方式热加载代码执行的经验，如果这个代码是从网络其他地方传输过来的，那就是在移动计算。杀毒软件从服务器更新病毒库，然后在Windows内查杀病毒，也是一种移动计算（病毒库）比移动数据（Windows可能感染病毒的程序）更划算的例子。
大数据技术将移动计算这一编程技巧上升到编程模型的高度，并开发了相应的编程框架，使得开发人员只需要关注大数据的算法实现，而不必关注如何将这个算法在分布式的环境中执行，这极大地简化了大数据的开发难度，并统一了大数据的开发方式，从而使大数据从原来的高高在上，变成了今天的人人参与。
思考题
互联网应用系统架构中有一种重要架构原则是尽量使用无状态的服务，不同服务实例之间不共享状态，也就是不持有数据，用户请求交给任何一个服务实例计算，处理的结果都是一样的，为什么要这样设计？这种架构有什么好处？
欢迎你写下自己的思考或疑问，与我和其他同学一起讨论。
- 面试官问 👍（153） 💬（1）
无状态服务的主要好处是服务间无需同步状态或者数据，便于扩缩容。
2018-11-06 - 不求 👍（58） 💬（3）
针对于思考题的一些思考： 分布式架构的原则：尽量使用无状态的服务，不同服务实例之间不共享状态，也就是不持有数据。。。 这个问题我是这样考虑的，什么是无状态的服务？为什么需要它？它是在怎样的情况下出现的？ 这个应该是分布式架构的设计者在考虑架构的可扩展行（伸缩性）的时候设计出来的这样一个针对于服务的一个要求或者是标准（也就是原则）； 所以我想说，这个问题太“应试”了，就像您的课程一样，之前都是顺着从无到有的一个顺序给我们讲解，我听的很爽，真的是爽，突然来了一个这样的反逻辑的“应试”问题，我有点懵。 再多说一点，好像国内的教育太“应试”的原因也有是过于拆解概念，然后对概念进行逻辑行考核验证；所以我们上学时都挺会考试的，都在应付这个逻辑，而忽略了真正的学识，一个从无到有的东西，它是如何被创造出来的，它为什么会被创造出来，它还有没有改善的余地。也是“应试”环境下的学生创造力越来越差的原因吧，更多的花费在了逻辑推理上。 老师，若有冒昧，还请批评指正，感谢🙏
2018-11-07 - 陈柏林 👍（22） 💬（1）
每台服务器原本都不带有程序，但是调度服务器为处理服务器分发任务之后，处理服务器就执行任务并检查是否有该程序，没有就下载，下载之后从指定路径中读取数据进行处理，处理好之后统一存放处理结果，大概的执行流程是这样吗？
2018-11-07 - cellardoor 👍（10） 💬（1）
无状态的好处： 1，伸缩性更好，应用之间无需同步状态，方便伸缩。 2，幂等，应用服务器之间都是对等的，请求落在哪里都可以得到相同的响应。 3，可用性更好，有状态，意味着有数据丢失的可能，在某些情况下，状态不一致容易造成可怕的结果。 4，性能好，应用服务器之间无需同步，减少对资源的浪费；
2018-11-06 - 五岳寻仙 👍（9） 💬（1）
刚接触这个领域，认知还比较浅显。我觉得成千上万的机器之间通信会很耗费时间，无状态能保证减少机器之间的耦合，提高效率。
2018-11-06 - 小橘子🍊 👍（6） 💬（1）
小白问？老师能不能举一个例子说明一下什么是有状态什么是无状态？
2018-12-09 - 没有枫树的枫林 👍（6） 💬（2）
有点抽象，能举例子说明一下什么是无状态的什么是有状态的吗？移动计算不就是那个节点都进行相同的计算吗？是说计算过程需要依赖其他节点的数据叫有状态？
2018-11-07 - 老男孩 👍（4） 💬（1）
期待后面的文章。无状态的服务是内聚的低耦合的，同一个用户的请求可以被分发到不同服务节点上进行处理。伸缩自如。
2018-11-06 - 公号-技术夜未眠 👍（4） 💬（1）
无状态服务有利于提升分布式系统的可伸缩性。
2018-11-06 - 贝特 👍（3） 💬（1）
无状态，主要是为了可靠性和扩缩容。 可靠性体现在如果集群中单个节点故障后，其他节点能无缝接管比此节点的数据，而不需要实时做同步。 扩缩容和可靠性类似，单节点坏掉就是缩容的一个特殊场景，扩容体现在增加节点后也不需要做状态和数据同步。
2018-11-11 - John Lau 👍（3） 💬（1）
無狀態服務可以免除需要同步狀態的情況，系統可以跟據情況把計算自由分發到不同的機器上，而不用考慮同步問題。實現起來也會簡單很多。 但我有個問題:現實場景就是有很多時候需要有狀態，有沒有系統的思考方法，把需要狀態的工作方式，改寫成不需要狀態的工作方式？
2018-11-06 - 达子不一般 👍（2） 💬（1）
分发任务到执行进程执行，执行进程还是要从hdfs数据节点远程拉数据是不？所以是否还是不能算移动计算？
2019-10-10 - 不似旧日 👍（2） 💬（1）
什么叫做无状态服务 ?
2019-01-17 - 丶请叫我七七丿。 👍（2） 💬（1）
大数据引擎根据集群里不同服务器的计算能力，在每台服务器上启动若干分布式任务执行进程，这些进程会等待给它们分配执行任务.... 请问：分布式任务执行程序是指什么？
2019-01-08 - 杰之7 👍（1） 💬（1）
通过这一节的复习，针对每日PB级数据量，一台计算机的内存，磁盘，带宽没法满足需求时，产生了移动计算比移动数据更划算的思路。 在大数据技术之前，老师讲述了大型网站的分布式架构思路，由于大型网站的用户请求数量庞大，用更多的服务器来满足不同用户的需求。在次基础之上，产生了大量的已存数据，我们需要对这些数据进行统计算计和关联关系，来给用户更好的体验，于是就产生了大数据技术。 大数据技术同样也是分布式架构，HDFS存储数据，将数据分成很多Block，数据引擎根据不同服务器的计算能力，启动若干个分布式任务执行进程。MR或者Spark编程，打包成JAR包。Hadoop等执行引擎解析程序处理的数据输入路径，根据数据量大小，分成Split。任务执行进程通过放射加载程序，这一步就是移动计算，即完成了程序的传输。最后执行进程读取数据给程序去执行。 回到老师的问题架构中无状态服务或者不共享数据，我想是这样服务器之间的耦合更低，便于增加更多的服务器，来满足更多用户的请求。 之后每一篇的复习都会回答文章老师的问题，也是自己思考的一个过程和学习，会有思考的不足，请老师给出修正。
2019-01-19