22 从阿里内部产品看海量数据处理系统的设计（下）：架构与创新
上一期，Doris提出了目前阿里巴巴海量KV存储方面的问题，给出了Doris的业务价值、设计目标和技术指标。但是Doris项目组还必须证明自己有已经经过论证的架构技术方案，可以实现前面设定的目标，立项后可以迅速启动执行，不需要再去摸索尝试，风险可以把控。
因此，PPT后面的内容主要就是阐述Doris的架构方案和创新设计。
Doris是一种支持Key、Value数据结构的分布式存储系统，核心要解决的问题是分布式路由、分布式集群伸缩、分布式数据冗余与失效转移。所以Doris把分布式存储系统很重要的一块，也就是数据存储部分转移出去，使用第三方软件完成，当时选择Berkeley DB作为Doris的底层存储Store，Doris自己专注于分布式技术实现。
Doris的主要访问模型是，应用程序KV Client启动后，连接控制中心Administration，从控制中心获得整个Doris集群的服务器部署信息及路由算法，Client使用Key作为参数进行路由计算，计算得到集群中某些服务器作为当前Key、Value数据存储的服务器节点；然后KV Client使用自定义的通信协议将数据和命令传输给服务器上的Data Server组件，DataServer再调用本地的Berkeley DB将数据存储到本地磁盘。
Doris的核心技术就是这个架构模型上创新性地实现了自己独特的分区路由算法、失效转移策略、集群伸缩设计方案。并在项目开发过程中，将这个三个技术创新申请了技术专利。下面我们重点看下这三个技术创新。
分区路由算法
Doris采用一种基于虚拟节点的分区路由算法，Key使用余数Hash算法计算得到虚拟节点下标。
虚拟节点和物理服务器节点之间计算建立一个映射关系，通过映射关系查找实际要访问的物理服务器IP地址。
路由算法在初始化的时候就预先设立一个较大的数字，比如100000，当存储服务器集群需要伸缩的时候，要增加一个服务器，虚拟节点和下标计算算法不变，仅仅调整虚拟节点和物理服务器节点的映射关系就可以了，如PPT中图2所示。
这种基于虚拟节点的分区路由算法相对于传统的一致性Hash路由算法，可以获得更好的数据负载均衡，即数据在各个服务器上的存储分布更加均衡。在集群伸缩、增加服务器的时候可以做到更少迁移数据。在实践中，这种算法的一个更大优势是，如果将物理存储的文件系统和虚拟节点关联，即一个虚拟节点对应一个物理存储文件，那么当集群扩容，进行数据迁移的时候，就可以以文件为单位进行数据拷贝，这样迁移速度和运维成本都非常低。
这个基于虚拟节点的分区路由算法的关键难点是，如何计算虚拟节点与物理节点的映射关系，特别是在增加服务器的时候，如何重新计算这个映射关系，使新的映射关系依然处于负载均衡的状态，也就是每个物理节点映射的虚拟节点个数差不太多相同。
项目组抽象了一个数学公式完成映射关系的计算，你可以看上面PPT示例。
失效转移策略
在前面在技术指标上，曾经承诺Doris的可用性为99.997%，保证数据可用性的策略主要是数据存储冗余备份和数据访问失效转移。
我们先看下Doris如何实现冗余备份。
Doris将存储服务器集群分成多个group（默认情况下为2个group），数据写操作的时候，根据分区路由算法，在每个group里计算一个服务器地址，异步并发同时向多个group的服务器上写入数据，以此保证数据有多个备份。
当KV Client访问某台服务器失败的时候，Doris会启动失效转移策略。具体来说，Doris将失效分为三种情况：瞬时失效、临时失效、永久失效，不同情况采用不同的失效转移策略。
当第一次不能访问服务器的时候，Doris认为这是瞬时失效，会进行访问重试，如果三次重试后仍然失败，就会把失败信息提交给控制中心。控制中心检测该服务器心跳是否正常，并进行尝试访问，如果访问失败，就将该服务器标记为临时失效，并通知所有KV Client应用程序。
KV Client应用程序收到服务器失效通知的时候，启动临时失效策略，将原本需要写入到失效节点（图中的物理节点2）的数据写入临时日志节点（图中的物理节点X），而读操作则只访问正常的物理节点1。
当临时失效节点2恢复正常运行，系统会将失效期间写入临时日志节点X的数据合并恢复到物理节点2，这段时间物理节点2只提供写服务，不提供读服务。当所有数据恢复完毕，集群访问恢复正常。
而对于永久失效的节点，需要添加新的服务器以代替下线的服务器，基本策略就是将另一个group正常使用的服务器数据拷贝到新添加的服务器上即可。
需要说明的是，上述三种失效转移过程，除了服务器永久失效后，需要工程师手动添加服务器，并到控制中心添加新服务器配置、激活启用外，其他情况不需要任何人工干预，全部自动化完成。
集群伸缩设计
分布式系统的一个重要设计目标是集群弹性可伸缩，如果当前的服务器数目不能满足业务的负载压力要求，那么就添加更多的服务器去增强处理能力。对于分布式数据存储服务器的伸缩性扩容而言，必然伴随着数据的迁移，就是将原先服务器中的部分数据迁移到新的服务器上。
具体过程为：
1.向集群中一个分组group添加新的物理服务器，部署并启动Doris服务器进程。
2.将这个group的所有服务器设置为临时失效。
3.使用路由算法重新计算加入服务器后的虚拟节点分布，并把需要迁移的虚拟节点对应的物理文件拷贝到新服务器上。
4.设置group所有服务器临时失效恢复，将扩容期间的数据更新写回到这些服务器。
至此，PPT最前面提出的设计目标，经过一系列的关键技术设计分析，证明是技术是可行的，风险是可控的，可以启动开发了。
实际上当时项目组大概花了半年的时间开发Doris系统，部署上线以后，阿里巴巴多个业务产品接入Doris，并在极少运维的情况下，无故障运行了数年。后来服务器集群经过几次扩容，规模达到数百台服务器，实践证明当时的设计是经得起考验的。
最后，我想再说一下关于专利的事。公司一般都是希望能够申请更多的技术专利，这样在跟其他公司进行专利大战的时候才能做到“手中有枪，心中不慌”，特别是在遇到“专利流氓”的时候。所以大部分公司对工程师申请技术专利都比较支持。
大一点的公司法务部门通常会有专门的知识产权律师，他们会帮助工程师申请技术专利，工程师只要按照一般写技术文档的写法写一个技术交底书给公司律师，律师审核后会让专门的专利代理公司帮助编写专门的技术专利申请书，所以工程师申请专利的工作量并不大。
很多公司为了支持申请技术专利，会有很多奖励，比如申请成功一个专利会有几万的奖励，这对于工程师也是一笔不错的收入。做技术的同学可以关注下自己公司的专利奖励政策，如果还没有相关的专利奖励，正好你也可以借此机会说服公司管理层在这方面增加一些激励，这是一件利国家、利公司、利自己的好事。
小结
分布式数据存储系统是分布式系统中最有技术挑战的领域之一。其他的各种分布式系统，由于对数据的一致性和系统的可用性要求并没有那么高 ，所以技术难度和挑战相对没有分布式存储系统这么高。自己参与设计、开发这样的系统，会对分布式系统，乃至大数据系统有更深刻地理解，希望这两期专栏能引导你从开发者的视角，看待分布式大数据系统是如何设计开发出来的，从而对大数据技术有新的认识和领悟。
如果你在工作中遇到有技术挑战的项目，可以尽量找机会去参与，你能收获的不仅仅是最终开发出来的产品和公司的认可，还有自己技术的提升和更有想象力的职业前景。
思考题
今天的文中提到，Doris的分区路由算法在设计的时候，提出了一个数学模型计算虚拟节点和物理节点的映射关系。但是最后在开发过程中，项目组并没有使用这个数学模型进行计算，你能想到的实现算法还有什么呢？
你也可以在Doris的源代码中找到相关代码，分析Doris的最终实现算法和你的思考有什么异同。
欢迎你点击“请朋友读”，把今天的文章分享给好友。也欢迎你写下自己的思考或疑问，与我和其他同学一起讨论。
扩展阅读：
对专利感兴趣的同学可以进一步阅读Doris产品申请的三个技术专利：
http://www.soopat.com/Patent/201110325238
http://www.soopat.com/Patent/201110294092
http://www.soopat.com/Patent/201110285802
Doris源代码地址：
https://github.com/itisaid/Doris
- 玉剑冰锋 👍（9） 💬（1）
您好老师，请教几个问题1.架构设计中数据压缩比及数据存储时效策略是如何设计的？2.数据的完整性如何验证？3.后期运行过程中尤其是某个节点存储空间低于其他节点时，是否会发生数据倾斜的问题？
2018-12-18 - 钱 👍（2） 💬（2）
和redis的分片方式类似呀😄，你是虚拟节点，她是哈希槽。和一致性哈希也挺像的，只是虚拟节点和物理节点的映射更加的灵活可控。 老师牛逼，致敬！
2019-09-28 - weiruan85 👍（2） 💬（1）
老师，文章中还有几个重要的问题没有提交：1. 这种设计下，cap是如何抉择的。 在发生网络分区的时候，是选择C 还是A ？ 按照文章中的内容，感觉Doris没有采用逻辑日志复制的技术实现，而是采用了双写的实现思路，当时在设计时为什么这么考虑呢。 如果是双写，那么cap理论是不是就不太适用了，备份的数据和primary数据一定是一致的。 当网络发生分区后，执行故障转移，一直保证数据的一致性。
2019-08-02 - 观弈道人 👍（2） 💬（1）
老师你好，请问下，关于fail over部分，物理节点1，物理节点2是分别存储两片数据，当物理节点2挂掉的时候，文章中说物理节点1提供所有的read操作，我想问的是，节点1，2负责两片不同的数据，节点1如何承担原本访问节点2的读操作？谢谢。
2018-12-18 - William 👍（1） 💬（1）
还有一个疑问请帮忙解答一下： 在集群伸缩设计方案中，假如一开始只有两台物理机，有10000个虚拟节点，那么每台物理机各存储5000个虚拟节点的数据;现在增加一台物理机，那么最后的数据存储效果是物理机分别存储5000，2500，2500个虚拟节点的数据吗？这样算不算数据倾斜？
2018-12-19 - Jun 👍（0） 💬（2）
李老师，你好。感觉老师是山西人。如果是，那么老乡你好。这一章的数学公式是从物理节点映射的虚拟节点。实际请求到来时，应该是虚拟节点到物理节点，有公式吗？还是直接用一个映射表？另外使用一致性哈希加虚拟节点也是比较好的方案，不需要复杂的节点映射了。亚麻的dynamo就是这么做的。
2020-01-05 - vigo 👍（16） 💬（0）
智慧书，不仅说技术，还育人😄
2019-01-28 - 你为啥那么牛 👍（14） 💬（1）
遵循老师的5-20-2原则，5分钟没看进去，放弃，等待下一次偶遇
2021-03-06 - 吴小智 👍（12） 💬（0）
专栏真的是从 0 开始学大数据吗？看哭了，只能看懂一二两章
2019-07-17 - 大京京 👍（4） 💬（0）
有部分ppt内容是不准确的。新增一个物理节点，你前面说的算法是无法保证key1的路由节点pn1不移动的。只是数据迁移的时候，你是每个现有节点都各自迁移自己的一部分去新节点，现有节点之间不做迁移而已。
2019-01-23 - 纯洁的憎恶 👍（1） 💬（0）
感谢老师分享阿里巴巴的内部分布式数据库系统的立项过程。能了解行业头部的大公司，是如何作出如此重大决定，并快速落地支持、加速公司的成长。 我虽然是计算机专业毕业，但并没有计算机工业领域的工作经历，所以可能对其中的一些细节缺乏应有的感知力，这个慢慢来吧。 我目前在大型国企总部工作，在互联网+的大势下，公司立项了采购监督信息化课题，旨在借助大数据技术，实现采购管理全过程，事前、事中、事后的风险防控与预警体系。有效降低违法违规行为，提高效率。我正在参与这个课题，但是对项目中大数据技术的切入点，没有明确的思路，想听听老师建议。谢谢
2018-12-20 - 不加y 👍（0） 💬（0）
为什么不使用hbase了？
2023-06-03 - 高志权 👍（0） 💬（0）
评论一下
2022-03-23 - 张伟建 👍（0） 💬（0）
好难，努力学多点
2021-12-28 - garlic 👍（0） 💬（0）
把虚拟节点均分到物理节点上，每次新增物理节点，重新计算均值，把新增前物理节点上大于均值部分放到新增物理节点上。 算法实现上由于依赖前一次分配状态，需要从一个物理节点开始计算，虚拟节点和物理节点不会很多的话，这部分运算时间可以忽略不计。 数据分布还是需要调整虚拟节点个数达到均衡
2020-12-11