大数据技术和传统的软件开发技术在架构思路上有很大不同，大数据技术更为关注数据，所以相关的架构设计也围绕数据展开，如何存储、计算、传输大规模的数据是要考虑的核心要素。
传统的软件计算处理模型，都是“输入 -> 计算 -> 输出”模型。也就是说，一个程序给它传入一些数据也好，它自己从某个地方读取一些数据也好，总是先有一些输入数据，然后对这些数据进行计算处理，最后得到输出结果。
但是在互联网大数据时代，需要计算处理的数据量急速膨胀。一来是因为互联网用户数远远超过传统企业的用户，相应产生了更大量的数据；二来很多以往被忽视的数据重新被发掘利用，比如用户在一个页面的停留时长、鼠标在屏幕移动的轨迹都会被记录下来进行分析。在稍微大一点的互联网企业，需要计算处理的数据量常常以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可能感染病毒的程序）更划算的例子。
大数据技术将移动计算这一编程技巧上升到编程模型的高度，并开发了相应的编程框架，使得开发人员只需要关注大数据的算法实现，而不必关注如何将这个算法在分布式的环境中执行，这极大地简化了大数据的开发难度，并统一了大数据的开发方式，从而使大数据从原来的高高在上，变成了今天的人人参与。
思考题
互联网应用系统架构中有一种重要架构原则是尽量使用无状态的服务，不同服务实例之间不共享状态，也就是不持有数据，用户请求交给任何一个服务实例计算，处理的结果都是一样的，为什么要这样设计？这种架构有什么好处？
欢迎你写下自己的思考或疑问，与我和其他同学一起讨论。
精选留言
2018-11-06 07:35:14
2018-11-07 16:20:29
分布式架构的原则：尽量使用无状态的服务，不同服务实例之间不共享状态，也就是不持有数据。。。
这个问题我是这样考虑的，什么是无状态的服务？为什么需要它？它是在怎样的情况下出现的？
这个应该是分布式架构的设计者在考虑架构的可扩展行（伸缩性）的时候设计出来的这样一个针对于服务的一个要求或者是标准（也就是原则）；
所以我想说，这个问题太“应试”了，就像您的课程一样，之前都是顺着从无到有的一个顺序给我们讲解，我听的很爽，真的是爽，突然来了一个这样的反逻辑的“应试”问题，我有点懵。
再多说一点，好像国内的教育太“应试”的原因也有是过于拆解概念，然后对概念进行逻辑行考核验证；所以我们上学时都挺会考试的，都在应付这个逻辑，而忽略了真正的学识，一个从无到有的东西，它是如何被创造出来的，它为什么会被创造出来，它还有没有改善的余地。也是“应试”环境下的学生创造力越来越差的原因吧，更多的花费在了逻辑推理上。
老师，若有冒昧，还请批评指正，感谢🙏
2019-09-26 06:47:14
移动计算比移动数据更核算
2、课后思考及问题
2-1：啥是大数据？
数据很好理解，就是计算机处理的基本材料，文本、音频、视频都是数据，大怎么理解？多大算大？我的理解这是一个相对的概念，比如：数据量大到世界上最牛逼的计算机都存不下，都计算好几个小时，如果用单位表示，大到PB就算大数据啦！
2-2：为啥出现大数据？
因为有了互联网，网上的计算机数以亿计，有些公司想把数以亿计的计算机的操作人、操作人的信息、操作人的操作轨迹、操作历史等等数据都想记录下。这个量可能使用PB都不好表示，比如：Google、Facebook、亚马逊、阿里、腾讯、百度、京东、美团等等。
2-3：处理大数据的老思路是啥？
提高单机的存储和性能，普通PC——服务器——小型机——大型机——超型机——超大型机。
2-4：处理大数据的新思路是啥？
分而治之，用普通PC通过互联网联系起来，就像产生大数据一样的根本原因一样，不断的通过增加机器来提高存储空间和计算能力。
2-5：老思路为啥走不通了？
单机再牛逼也有上限，好比关羽是武圣，但也抵挡不了千军万马。
2-6：新思路为啥走的通？
她的解决思路和产生问题的根源是类似的，数以亿计的电脑能同时记录下操作人的信息、能知道数以亿计的人在操作什么，另外，这些数以亿计的电脑，无论是搜索、购物、社交、娱乐，他们基本都是在同时做，但互联网公司中这些都同为巨头的确没有，此时已经分而治之过一次了，所以，理论上增加机器确实能够存储下那么多数据其且不用数以亿计上万台就行。
2-7：新思路带来了那些新问题？
上万台机器怎么分工协作，数据怎么快速存储？数据又怎么快速获取？数据怎么聚合？怎么从海量的数据中发现珍珠？怎么保证数据高可用？
2-8：这些新问题的解决思路是啥？
怎么快速存取？怎么聚合？怎么发现价值？三者是相关联的，其中怎么快速存取又是矛盾的，大部分数据是读多写少，所以，选择了怎么快速的取数，取数要想快，好像没啥好点子，就是三板斧，一是尽量在内存中操作；二是用哈希分片；三是用有序存储结构来存储实际的数据，比如：B+树，取的快就能聚合的快，聚合后就能发现数据的规律，发现规律就能预测未来，预测未来就能占领先机，占领先机那赚钱就是翻手之事啦。
数据高可用，好像就一手，副本，一个不够两个，两个还不够三个，当然，副本间最好离的远远的。
集群间无状态的好处，很自然，比如：公司想辞你，随便组内某个成员都能接手你的活，或者随便招一个人都能接手你的活，那对领导而言你和小组间就是无状态的，你的有无，宕机与否并不太重要。假如你做了许多核心项目，代码只能你看得懂，那公司领导就不管随意辞你，即使你要走，也要交接许久，否则后面会很难过的，其实每个领导也都想达到这个效果，只是人不是机器，数据说同步就同步啦！所以，对于某些员工客客气气，对于其他的则粗声大气。
2018-11-07 08:05:27
2018-11-15 12:44:43
对于大数据，如果不是无状态服务，那弹出一个服务，还要调它依赖的服务，那么这个处理过程，会有非常多非必要的开销，也有非常多的隐患。譬如，被调用的服务怎么保证面对大量请求时的处理性能和可用性？所以，大数据的计算或存储，必须用一个无状态服务。
对于它的处理逻辑：就是先把计算模型先设计好，之后，在先抓数据源，并分片后处理成任务。任务调用计算模型，生成计算结果。这样，任务分片后，被放入了一个分布式环境中执行，就实现了分布式计算。
2018-11-06 07:31:36
无状态的原因是程序包可以负载均衡的分发到任何最优的节点进行计算，计算时宕机了也可以在另一台创新计算，各个节点都是一样的环境
2018-11-06 15:36:44
1，伸缩性更好，应用之间无需同步状态，方便伸缩。
2，幂等，应用服务器之间都是对等的，请求落在哪里都可以得到相同的响应。
3，可用性更好，有状态，意味着有数据丢失的可能，在某些情况下，状态不一致容易造成可怕的结果。
4，性能好，应用服务器之间无需同步，减少对资源的浪费；
2018-11-06 11:59:50
2018-12-09 23:06:21
2018-11-07 08:55:46
2018-11-06 12:00:21
2018-11-06 08:17:05
2018-11-13 10:17:22
2018-11-11 14:51:33
可靠性体现在如果集群中单个节点故障后，其他节点能无缝接管比此节点的数据，而不需要实时做同步。
扩缩容和可靠性类似，单节点坏掉就是缩容的一个特殊场景，扩容体现在增加节点后也不需要做状态和数据同步。
2018-11-06 06:50:53
但我有個問題:現實場景就是有很多時候需要有狀態，有沒有系統的思考方法，把需要狀態的工作方式，改寫成不需要狀態的工作方式？
2019-10-10 08:05:53
2019-01-17 11:02:06
?
2019-01-08 16:59:15
请问：分布式任务执行程序是指什么？
2020-03-22 15:05:31
2020-01-06 17:14:04