大厂内部技术立项：阿里Doris

阿里内部海量数据处理系统的设计：Doris立项。阿里内部产品。2010前后各种NoSQL系统爆发，各种开源NoSQL在这个时期发布出来，阿里也开发自己NoSQL系统Doris，目标支持海量KV数据存储，访问速度和可靠性高于主流NoSQL，系统要易维护和伸缩。

1 大公司如何看待内部技术产品

互联网主靠互联网产品盈利，如阿里主靠淘宝、天猫、阿里巴巴B2B网站，而公司工程师主要也是开发这些产品，但这些产品通常都要处理海量用户请求和大规模数据存储，所以在系统底层通常用到很多基础技术产品，如分布式缓存、分布式消息队列、分布式服务框架、分布式数据库等。

这些基础技术产品可选择开源技术，也可自研。自研优点是可针对业务场景定制开发，同时培养提高自己工程师技术实力；缺点投入大、风险高。公司到了规模，都会自研基础技术产品，提升产品研发能力，又提高业界地位，吸引人才并提高竞争门槛，形成竞争壁垒。

但公司资源有限，主要资源肯定还在业务产品开发，那剩下资源到底应该投哪？需形成公司内部一套竞争策略，以使优秀项目能够得到资源。

对工程师而言，业务产品的开发技术难度相对较低，若想更快提高技术，去开发基础技术产品更能得到提升和锻炼，所以优秀工程师更愿意去开发有难度有挑战的创新性基础技术产品，而不是去开发业务产品。

因此，在工程师和公司间就形成博弈：工程师想开发基础技术产品，但得得到管理层支持；管理层资源有限，只愿意支持开发那些对业务有价值、技术有创新、风险较低的基础技术产品。

所以工程师就需说服管理层，想要做的就是对业务有价值、技术有创新、风险比较低的基础技术产品；而管理层则要从这些竞争者中选出最优秀项目。

通过这种博弈，公司的资源会凝聚到最有价值的技术产品上，优秀的工程师也会被吸引到这些项目上，最后实现了公司价值和员工价值的统一和双赢。

2 立项启动会

Doris项目的立项启动会，你是老板，看看你最关注一个项目的哪些技术指标；又或者你是Doris工程师，可以想想哪些指标是老板关注的，并且从技术上是可以实现的。

当前现状

• 网站关键业务有许多海量KV数据存储和访问需求
• 国际站UDAS使用
  • 存在问题：扩容困难、写性能较低、实时性低等
• 网站有多套KV方案,接口不统一,运维成本高
  • 国际站UDAS-BDB
  • 中文站 :TT
• 飞天KV Engine(Aspara)问题
  • 使用复杂
  • 性能较低

开篇当前现状，当时阿里巴巴没有统一大数据NoSQL解决方案，有的产品是自己在业务代码中实现数据分区逻辑，从而实现海量KV数据的存储访问。这样做主要问题：

• 开发困难

  程序员在开发时要知道自己存储的数据在哪台服务器

• 运维困难

  增加服务器的时候，需要开发配合，故障的时候也很难排查问题

现状需要解决。有无现成解决方案？有，但现成方案也有问题，所以必须自己开发一套系统解决。这样，后面想做的一切才能顺理成章。

当你想做一个新东西，它必须要能解决当前的问题，这是人类社会的基本运行规律。重要的是你要能发现问题。就像你做的东西将来也一定会有问题，因为现在的产品在将来一定会落伍，但那不再是你的问题。

技术只是手段，技术不落在正确的问题，就一点用也没有。什么是正确问题，需要去思考和发现。

产品定位

产品定位：海量分布式透明化KV存储引擎

业务价值：

• 替换UDAS：解决扩容迁移复杂,维护困难的问题
• 国际站海量KV数据存储
• 国际交易站
• 中文站

前一页说完当前问题，引出必须要开发一个海量数据处理系统，这页就要说明：

• 产品定位：海量分布式透明KV存储引擎
• 业务价值就是能够支撑阿里巴巴未来各个主要产品的海量数据存储访问需求

这两页是整个PPT的灵魂，管理层如果对第一页提出的问题不认可，又对第二页产品要实现的价值不以为然，那基本上这个项目也就凉了。

到这里没问题，得到认可，下步就要突出项目创新和特点。

产品目标

功能目标

• KV存储Engine
• 逻辑管理：Namespace
• 二级索引

非功能目标

海量存储：透明集群管理，存储可替换

伸缩性：线性伸缩，平滑扩容

高可用：自动容错和故障转移

高性能：低响应时间，高并发

扩展性：灵活扩展新功能 低运维成本：

• 易管理

• 可监控

约束

一致性：最终一致性

产品的功能目标和非功能目标要清晰、要有亮点，和业界主流产品比要有竞争优势（用红色字体标出），要更贴合公司的业务场景。Doris的主要功能目标是提供KV存储，非功能目标包括在运维上要实现集群易于管理，具有自我监控和自动化运维功能，不需要专业运维人员维护；要支持集群线性伸缩，平滑扩容；具有自动容错和故障转移的高可用性；高并发情况下快速响应的高性能性；支持未来功能持续升级的可扩展性。

技术指标

技术指标也要亮眼，至少不能明显低于当前主流同类产品的指标。当时Doris根据阿里巴巴的内部使用需求场景，支持所有的B2B业务的KV存储，因此设计目标是未来部署一个100～10000台服务器的集群规模，并不支持无限伸缩。如果前面说过别的产品的缺点，这里也要对应说明自己强在哪里。

设计指标的设定，既不能低，如果比目前主流同类产品的指标还要差，自己再开发这样的产品就没有意义；也不能太高，如果设定太高，过度承诺，让老板、用户对你未来交付的产品抱有太高的期望，将来稍有不慎，无法达到期望，不但对产品的发展造成不良影响，甚至大家对你的人品都会产生怀疑。做好对别人的期望管理，让大家对你既充满期待，又不至不切实际，不但对你的职业发展大有帮助，应用到生活中也会获益良多。

至此，问题说了、方向有了、设计指标定了，到底能否开发出期望的产品，就看PPT把核心架构和关键设计讲清楚，要证明自己真的能做到。

Doris提出目前阿里海量KV存储问题，给出Doris业务价值、设计目标和技术指标。但Doris项目组还须证明有已经论证的架构技术方案，可实现前面设定目标，立项后可迅速启动执行，无需再摸索尝试，风险可控。因此，PPT后面阐述Doris架构方案和创新设计。

3 整体架构

• 二层架构：Client，DataServer + Store
• 四个核心组件：Client，RataSerer，Store，Administration

Doris是支持KV分布式存储系统，核心解决问题：

• 分布式路由
• 分布式集群伸缩
• 分布式数据冗余
• 失效转移

所以Doris把分布式存储系统的数据存储部分转移出去，使用三方软件完成，当时选择Berkeley DB作Doris底层存储Store，Doris自身专注分布式技术实现。

4 主要访问模型

• 应用程序KV Client启动后，连接控制中心Administration，获得整个Doris集群服务器部署信息及路由算法
• Client使用Key作为参数进行路由计算，计算得到集群中某些服务器作为当前KV数据存储的服务器节点
• 然后KV Client使用自定义通信协议将数据和命令传输给服务器上的Data Server组件，DataServer再调用本地的Berkeley DB将数据存储到本地磁盘

Doris核心技术就是该架构模型上创新性实现独特分区路由算法、失效转移策略、集群伸缩设计方案。

5 分区路由算法

基于虚拟节点的分区算法：

• 均衡性：数据分布均衡
• 波动性：X/(M+X)，优于一致性Hash的 X/M

5.1 实例

两个物理存诸节点的情况：

三个物理存诸节点的情况：

Doris采用一种基于虚拟节点的分区路由算法，Key使用余数Hash算法计算得到虚拟节点下标。

虚拟节点下标 = hash(md5(key)) mod 虚拟节点个数

虚拟节点和物理服务器节点之间计算建立一个映射关系，通过映射关系查找实际要访问的物理服务器IP地址。

路由算法在初始化的时预设一个较大数字，如100000，当存储服务器集群需伸缩时，要增加一个服务器，虚拟节点和下标计算算法不变，仅调整虚拟节点和物理服务器节点的映射关系。

相比传统一致性Hash路由算法，可获得更好数据负载均衡。在集群伸缩、增加服务器时可做到更少迁移数据。

更大优势是，若将物理存储的文件系统和虚拟节点关联，即一个虚拟节点对应一个物理存储文件，则当集群扩容，进行数据迁移时，即可以文件为单位进行数据拷贝，迁移速度和运维成本都极低。

这基于虚拟节点的分区路由算法的关键难点：咋计算虚拟节点与物理节点的映射关系，尤是增加服务器时，咋重算这映射关系，使新映射关系依然处负载均衡态，即每个物理节点映射的虚拟节点个数差不太多相同。

物理节点由2个扩充到3个，映射关系变化。

每个虚拟节点对应两个对等物理节点：

Primary节点公式

Secondary节点：S = N+1-P

• z：虚拟节点下标
• N：虚拟节点总数
• x：物理节点下标(一维下标)
• y：物理节点对应虚拟节点下标(二维下标)

项目组抽象了一个数学公式完成映射关系的计算，你可以看上面PPT示例。

6 失效转移策略

技术指标曾承诺Doris可用性99.997%，保证数据可用性的策略主要是数据存储冗余备份和数据访问失效转移。

6.1 Doris冗余备份

基本访问架构

1. 对等Node访问
2. 双写保证可用性(W=2，R=1)
3. 基于分区算法查找两个Node
   • Copy 1 Node
   • Copy 2 Node
4. 数据恢复和数据同步
   • Redo Log
   • Update Log

Doris将存储服务器集群分成多个group（默认情况下为2个group），数据写操作时，根据分区路由算法，在每个group里计算一个服务器地址，异步并发同时向多个group的服务器上写入数据，以此保证数据有多个备份。

6.2 可用性关键场景

• 瞬时失效
• 临时失效
  • 服务端升级或者网络暂时不可用
  • 失效机器在短时内可恢复(例如:2小时内)
  • 恢复后数据和失效前一致
• 永久失效
  • 机器下线

当KV Client访问某台服务器失败的时候，Doris会启动失效转移策略。Doris将失效三种：

• 瞬时失效
• 临时失效
• 永久失效

不同情况采用不同的失效转移策略。

6.3 集群管理-健康检査和配置抓取

Cluster Management - Health Check and Failover：

• 检查1：ConfigServer对DataServer心跳检查
• 检查2：Client 访问时Fail报告
• 其他Client定时配置抓取

当第一次不能访问服务器的时候，Doris认为这是瞬时失效，会进行访问重试，如果三次重试后仍然失败，就会把失败信息提交给控制中心。控制中心检测该服务器心跳是否正常，并进行尝试访问，如果访问失败，就将该服务器标记为临时失效，并通知所有KV Client应用程序。

临时失效的fail over

物理节点2临时失效期间数据处理：

物理节点2恢复期间数据处理：

• 物理节点2临时失效，并在可接受时间内恢复
• 物理节点x：备用节点，临时存放失效的物理节点2的数据，物理节点2恢复后迁移回物理节点2
• 物理节点2临时失效及恢复期间物理节点1承担所有read操作

KV Client应用程序收到服务器失效通知的时候，启动临时失效策略，将原本需要写入到失效节点（图中的物理节点2）的数据写入临时日志节点（图中的物理节点X），而读操作则只访问正常的物理节点1。

当临时失效节点2恢复正常运行，系统会将失效期间写入临时日志节点X的数据合并恢复到物理节点2，这段时间物理节点2只提供写服务，不提供读服务。当所有数据恢复完毕，集群访问恢复正常。

永久失效 Failover

每份 Data 写两份保证高可用:Copy1，Copy2

一致性处理：version(timestamp) Conflict Check & Merge

而对于永久失效的节点，需要添加新的服务器以代替下线的服务器，基本策略就是将另一个group正常使用的服务器数据拷贝到新添加的服务器上即可。

需要说明的是，上述三种失效转移过程，除了服务器永久失效后，需要工程师手动添加服务器，并到控制中心添加新服务器配置、激活启用外，其他情况不需要任何人工干预，全部自动化完成。

7 集群伸缩设计

分布式系统的一个重要设计目标是集群弹性可伸缩，如果当前的服务器数目不能满足业务的负载压力要求，那么就添加更多的服务器去增强处理能力。对于分布式数据存储服务器的伸缩性扩容而言，必然伴随着数据的迁移，就是将原先服务器中的部分数据迁移到新的服务器。

7.1 扩容数据迁移

机器扩容数据迁移处理：

• 集群扩容，新增Node X
• 旧路由算法：Route1( key1)={pn1, pn2 }
• 新路由算法：Route2( key1)={pn1, pnx}
• 新日算法有个Node相同，因此只需要迁移一个Node

Pn2 数据迁移到px，client 不再对pn2数据操作：

• R操作只在pn1上
• W/R 操作指向{pn1，pnx}

Client对等节点中的一个pn1不变(路由算法保证)

7.2 具体过程

1.向集群中一个分组group添加新的物理服务器，部署并启动Doris服务器进程。

2.将这个group的所有服务器设置为临时失效。

3.使用路由算法重新计算加入服务器后的虚拟节点分布，并把需要迁移的虚拟节点对应的物理文件拷贝到新服务器上。

4.设置group所有服务器临时失效恢复，将扩容期间的数据更新写回到这些服务器。

至此，PPT最前设计目标，经过一系列的关键技术设计分析，证明是技术是可行的，风险是可控的，可启动开发。

实际上当时项目组大概花半年时间开发Doris系统，部署上线后，阿里多个业务产品接入Doris，并在极少运维时，无故障运行数年。后来服务器集群经过几次扩容，规模达到数百台服务器，实践证明当时的设计是经得起考验的。

8 专利

公司一般都是希望能够申请更多的技术专利，这样在跟其他公司进行专利大战的时候才能做到“手中有枪，心中不慌”，特别是在遇到“专利流氓”的时候。所以大部分公司对工程师申请技术专利都比较支持。

大一点的公司法务部门通常会有专门的知识产权律师，他们会帮助工程师申请技术专利，工程师只要按照一般写技术文档的写法写一个技术交底书给公司律师，律师审核后会让专门的专利代理公司帮助编写专门的技术专利申请书，所以工程师申请专利的工作量并不大。

很多公司为支持申请技术专利，会有很多奖励，比如申请成功一个专利会有几万。

9 总结

其他的各种分布式系统，由于对数据的一致性和系统的可用性要求并没有那么高 ，所以技术难度和挑战相对没有分布式存储系统这么高。

工作中遇到技术挑战项目，尽量参与，收获不仅是最终开发出来的产品和公司的认可，还有自己技术的提升和更有想象力职业前景。