大话云上“分布式实践”，理解 B、A、C 并不难！

云计算，惊喜于可伸缩与算力集合；大数据、人工智能带给我们无可比拟的技术震撼；细探究竟，这三种技术都无法离开一个关键点，那就是经常被圈内人提及的“分布式”。

这不，就在刚刚结束不久的UCan下午茶北京站活动中，多位技术大咖针对云上的分布式实践展开了深入探讨，干货满满。

由于是年底的收官之作，本次UCan下午茶北京站活动采用了Keynote与开放式演讲相结合的形式，并伴随别样精彩的答题活动以及抽奖环节，无论是形式的新颖呈现以及内容的精彩程度统统往胜从前，现场人头攒动，开发者们关注无限！

现场人头攒动

据了解，现场几百名开发者热情参与了交流与互动，尤其对AI平台、分布式数据库、数据库高可用性容灾方案以及分布式存储等十分关注。此外，这些探讨也将为云计算、大数据以及AI领域的从业者们提供借鉴与新思路，并十分值得广大开发者们认真学习与总结！

《新一代公有云分布式数据库——UCloud Exodus》

——UCloud关系型存储研发部负责人 罗成对

众所周知，性能和容量一直是数据库关注的核心议题。尤其在公有云环境下更是挑战巨大，而UCloud云数据库团队一直在尝试如何优雅地解决这个难题。

在最先“揭面”的Keynote的演讲环节中， UCloud关系型存储研发部负责人罗成对在“新一代公有云分布式数据库——UCloud Exodus”的主题分享中表示，在“用户的需求就是我们下一个产品”的理念影响下，从2013年UCloud推出第一款云数据产品MySQL至今，云数据库产品上线将近6年且保持稳定运营，有数据显示共覆盖全球29个可用区，服务上万家企业用户，实例数几万个，数据量达到10PB+，单用户最多实例数超过6千个，单用户数据量1.8PB。

除了展现云数据库产品的成熟迭代之外，他还表明在实践过程中总结出的，目前云数据库面临的运营痛点，例如容量、性价比、性能、兼容性等，而解决这些痛点的高效方式，在于对云数据库的深刻理解，例如1.0阶段出现的云数据库就是云+数据库，大家都能意识到这个阶段的重点在于托管、零维护。

但2.0阶段如何实现云计算的共生，怎样实现矩阵式进化？本质上就是如何满足各种各样用户更高级别的追求，这是需要提升的核心所在，是要达到数据层和基础设施层的共生复用。

在产品层面，UCloud Exodus就是这样一款应时而生的云数据库。罗成对表示，Exodus支持最主流的开源数据库MySQL，协议完全兼容，通过融合最新软硬件技术，包括RDMA、Skylake、SPDK、用户态文件系统等来解锁新的能力。

从架构层面看，Exodus可以简单看分为两层，分别是上面的计算层，以及下面的存储层。  两层之间通过超高性能网络连接。

存储层是UCloud自研的新一代高性能分布式存储；而计算层则采用了原生的MySQL协议的DBServer，可能未来会发展支持PostgreSQL协议；二层之间走用户态文件系统UXFS。

可以看到，其中的典型架构与平时使用的主从架构是一样的，主从可以在不同的可用区甚至跨域，实现多级容灾部署。一主带多从，灵活而且整体性能强。通过共享存储来解决高可用的问题，而DB的核心问题之一就是高可用，在这种架构下，可解决很多1.0阶段无法搞定的难题。

总结来看，基于计算存储分离新型架构，UCloud采用了最新一代高性能分布式存储系统，计算层采用深度定制的MySQL InnoDB引擎，架构设计上支持一主多从。

“前端接入的是UXFS，提供的是用户态的IO栈，当DB接入到UXFS之后，直接通过RDMA到存储节点。存储层细分为两层，上面一层是Segment Server，下一层是ChunkServer。

通过增加SegmentServer，将DB需要的随机写IO转化为ChunkServer的顺序IO。整个IO路径并不完全强依赖MetaNode，将IO路径去除索引，减少一跳IO，从而提高IO性能。”他补充道。

分布式存储一个核心点是数据分布，很关键一点就是告诉人们应该去哪里获取数据。怎么理解？就是内部通过一个算法实现，我们采用一个算法计算出数据到底在哪儿，这样的好处是可以减少IO的一跳，这对数据库提升非常明显。计算存储分离架构，带来的另外一个好处是，计算和存储单独计费、按量付费，存储层自带异步EC，进一步节省存储空间，整体体现出来则是Exodus性价比超高。通过这些设计，Exodus一举解决了云数据库容量、性能、性价比、兼容性等四大痛点。最后，罗成对介绍了Exodus（UXDB）的开发计划，并透露该产品会在2019年Q3进行公测。

《Kyligence：释放大数据生产力》

——Kyligence 云与生态合作部副总裁 刘一鸣

如今大数据分析技术层出不穷，技术栈日新月异，在带来海量数据处理能力的同时，数据分析的门槛依旧很高，在查询性能、数据建模易用性、语义模型表达能力、高并发响应等场景均存在最后一公里问题。而Apache Kylin + cloud，是针对数据分析生产力场景设计，将行业最佳数据分析实践沉淀为Apache顶级项目的成熟产品。

在题为《Kyligence：释放大数据生产力》的分享中，刘一鸣针对数据分析生产力场景设计，详细介绍了Kyligence在云端的业务实践。

他表示， Kyligence就是要把这套方法论沉淀成一个项目，从数据源出发，我们可以看到支持HIVE、Kafka，以及其他的数据作为数据源；其次中间有一个环节叫计算，麒麟核心思想是通过预计算算出索引，这样查询的时候才能快。

具体来说，麒麟内部有两个生命周期，第一是构建的过程，这个过程就是要把原始的数据读取出来，然后通过用户模型，把用户关心的事情通过一套可扩展计算框架算出一些中间结果；第二是查询，查询时候会查出一般的SQL语句，会直接根据中间结果获得最终结果，这个过程并不需要很大的集群，每个查询看起来都像RPC一样快，这就是以前查询HIVE等是以分钟为单位，现在可以变成以毫秒为单位的原因。

此外，据了解这两个过程的复杂程度并不一样。“第一个构建过程要处理海量数据，这部分麒麟利用了很多大数据技术，包括存储方面依赖HDFS，计算方面依赖的YARN来做调度，使用Map Reduce框架和Spark完成分布式计算，所以很有可能构建之初需要处理数据可能是100G，过段时间或者明天可能是100T，这完全是可扩展的。”刘一鸣进一步补充道。

关于“数仓是如何建设的”问题，他在演讲中也有详尽提及。过去，传统数仓的建设需要从很多系统中读取数据，例如OLTP、ERP、CRM系统等，其中会涉及到很长的流程，还需要保证数据的整合、清理、过滤、语义一致性以及保持模型层的完整，最后的环节才是导入一个数仓中，然后对接整个前端的应用需求。

相比而言，现在的做法可以简单概括为Kyligence=Kylin+Intelligence，就是加入了很多智能的元素在其中，所以麒麟通过数据结构的变化能够带来更好的性能、更好的语义层、更多的梳理并发，但这些事情还是会很依赖建模的准确度，模型设计师对需求场景的掌握、对业务的掌握以及对表的理解，这一点需要被明确。

据了解，Kyligence的客户类型分很多种，早期只是手机互联网应用的范畴，后来技术发展更多向金融、证券、保险、电信以及制造业转型，共通的一点，这些行业都有海量数据收集的场景，以及很强的互联网式精细化分析的需求。

现场，刘一鸣为开发者们列举了招商银行的应用案例加以说明。他总结道，招商银行的数仓建设大概有二十多年的历史了，所以不可避免遇到一个问题，那就是数据孤岛。

“不同的部门，例如信用卡部门、数仓部门、风控部门，数据不一致，主要是因为存在不同的平台上。如果通通放在一起就会发现，都放入Teradata中有点儿小贵，放在GreenPlum中并发度又不够，如果向Hadoop平台做迁移，作为全公司统一的数仓平台，分析的语义层模型能不能统一也是个问题。所以用麒麟做成一个统一的数据服务层，上面对接传统招行中使用的BI工具，包括Cognos、MSTR、Superset等，如此就形成了整个招商银行内部，80多个不同的部门使用的统一场景架构。”

《AI PaaS平台实践》

——UCloud LabU深度学习开发工程师 范融

在UCan 下午茶深圳站曾进行精彩分享的UCloud LabU深度学习开发工程师范融也准时来到收官现场，作为开放式演讲环节中唯一的女技术工程师，带来主题为“AI PaaS平台实践”的分享。

首先，范融说明了AI场景下做PaaS面临的挑战。在研发AI的整个周期中，用户面临诸如AI选型、AI开发周期、应用迭代、训练及推理环境部署等痛点。无论是普通开发者还是企业用户都希望有一种解决方案，它可以兼容更多深度学习算法以及框架，并保证存储、网络性能优势。最后，她将AI PaaS平台的需求总结为算法兼容性、纵向扩展、横向扩展、高可用、环境迁移。

接着，她详细介绍了UCloud关于基础平台架构的很多技术干货。在整个AI 平台架构中，中间层是训练平台和在线服务平台两个基础平台，他们都拥有错误处理、负载均衡等功能；底层部分通过计算节点接入层兼容了各种异构的计算节点，如GPU、CPU; 在存储方面通过统一的接入层，让各种类型的存储介质接入平台后，面向开发者们访问方式都会像本地访问一样简单快捷。由于不同的用户有不同的使用习惯，例如有的用户可能习惯图形化的接入，因为直白，所见即所得；而有的用户需要与自己的内部系统做连接，所以迫切要求SDK做全自动化的脚本介入等。在架构上层有一个API的接入层，做到兼容各类用户访问需求。图形化界面方面，支持训练日志、服务状态、TensorBoard图表，Jupyter Notebook等实时交互方式。SDK方面，兼容主流深度学习框架，例如TensorFlow、Keras、Caffe、MXNet。

然后，范融针对这套架构如何在满足之前提出的五项用户需求，进行了详细的讲解。

通过Docker技术实现运行环境的逐层分离：统一基础镜像层，负责存储操作系统、驱动、依赖库；分类基础镜像层，负责针对不同深度学习框架进行打包存储；用户定义镜像层，开放给用户编写自己的AI代码。通过这样的分层管理，镜像可以做到很好的预装、定制、重用、兼容的特性，以此满足第一个需求挑战“算法兼容性”。

通过中间接入层实现纵向扩展：以存储类型的纵向扩展为例，通过中间层向下适配各类存储类型，如对象存储，NFS等，对使用存储的上层服务器提供统一的访问接口，并且在这个层次上实现带宽控制、权限控制、完整性检查等。这样就可以对用户无影响的情况下，满足数据类型“纵向扩展性”的要求。类似的，计算节点接入层完成了算力节点类型的“纵向扩展性”的要求。

此外，为了支持“横向扩展性”和“高可用”的需求，需要将原来单个的训练任务分布式化，使其拆分成若干个同构的小任务让不同的服务器来运行。对于AI训练服务，支持对于标准Tensorflow和MXNet自动分布式任务拆分；对于AI在线服务，由于是WebService形式，天然支持分布式部署。随后，动态监控计算节点运行压力，凭借UCloud云上海量的计算资源，动态弹性的扩容，以此满足“横向扩展性”。同时，UCloud计算集群分地域部署，随时灾备切换，以此保证“高可用”需求。

在讲解完公有云系统架构后，范融转而介绍私有云实施经验。凭借公有云上良好的分层模块的架构设计，API接入层、计算节点接入层、数据存储接入层将UCloud AI PaaS平台的核心组件全方位包围，使其能够方便的接入各类账号、资源、权限、数据管理组件，以此达到快速将公有云AI PaaS平台特性迁移部署到私有云的“环境迁移”需求。

针对私有云方案的应用，范融列举了一个私有云接入层的具体案例，被称为一体机方案。如果用户有一个完整一体机，完全可以搭建自己的AI算法库，将算法库通过API调入到私有云中进行训练，训练出来的模型自动部署到在线服务平台上，然后与自己业务系统的微服务对接，这样一来用户生态私有云的布置就能快速部署完成。

最后，范融分享了几个实际的客户案例：

案例1：使用UCloud AI平台部署多场景的图片特征标签在线服务，灰度发布、各场景资源隔离、弹性扩容的特性，为客户大大节省了客户系统的运行维护成本。

案例2：使用UCloud AI平台对大量样本文件的OCR图片识别场景进行自动化分布式训练。将用户原本在单机运行训练算法，自动分布式到8台4卡P40物理机运行，大大提升了用户的训练时间，加快了算法迭代开发的周期

案例3：使用UCloud AI平台支撑AI Chanllenger全国挑战赛。弹性扩容的特性，很好的为大赛高峰使用需求提供稳定支撑。按需收费的特性，极大节省了大赛组委会的赛事运营成本。

《数据库高可用容灾方案设计和实现》

——UCloud资深存储研发工程师 丁顺

开放式的精彩分享仍在继续，在有关“数据库高可用容灾方案设计和实现”的分享中，UCloud云数据库的资深研发工程师丁顺，对传统数据库服务与高可用数据库进行了对比。

传统的数据库服务是一个数据库，一旦发生宕机的情况，整个数据的读写全部不可用，就会对服务造成很大的影响，为了解决这个问题就要想办法提高整个数据库服务的可能性。所以为解决数据库宕机导致数据无法读写，确保对运维、提供服务带来更多便利要求的前提下，高可用数据库应运而生。

高可用数据库既然带来那么多好处，如何设计一个高可用数据库系统？需要着重关注哪些问题呢？首先，各个数据库节点之间的数据是如何做到同步的？丁顺表示，这就需要保证数据库在发生一个切换之后，同时需要最新的数据的要求下，数据同步是很重要的，否则如果切换之后发现数据不一致，这个问题比较严重，所以要保证各个节点的数据及时同步。同步过程中势必会对整个系统带来一些影响，也需要关注。

容灾是怎么进行。不同架构的容灾切换的复杂度是不一样的，在设计高可用数据库当中要尽可能去简化容灾的步骤，因为只有步骤做到简化，容灾时间才可以缩短，对用户的影响会更小。

“此外，我们需要关注的是运维效率问题。有可能一个数据库设计出来之后确实具备高可用能力，但一些容灾和运维操作十分繁琐，也不利于数据库的长期维护。”他补充道。

面对高可用数据库带来的好处，丁顺还详细分析了业界典型高可用数据库架构，并按照数据同步的方式进行了划分，其中包括共享存储、操作系统实时数据块复制、基于主从的复制、基于一致性协议的复制四种数据同步的方式。

除此以外，他还提出了UCloud云数据库产品UDB。据了解，UDB采用经典的主从模式设计，为了提高数据一致性，采用了半同步的模式，用来保证可靠性。

具体来说，首先要考虑原生的MySQL的兼容；另外架构可以尽可能涵盖不同的版本，有一些比较老的版本也可以去兼容高可用架构，享受高可用的红利；整个架构可以涵盖不同的应用场景，也就是说，假设有很多不同的存储引擎，都可以进行涵盖。

基于这样的设计思路，所以UCloud高可用数据库产品采用比较经典的主从模式来进行设计，即Master DB和Standby DB双主架构；为了提高数据一致性采用了半同步的模式，提高它的可靠性；同时由于高可用架构下可能还会挂载其他的备库，所以使用了GTID，保证做切换的时候可以让下面的备库进行无缝感知等。

关于高可用数据库运维经验，其中日常要进行例行巡检是非常重要的。在巡检中发现有时候高可用数据库延时过大是导致高可用数据库无法切换的重要原因之一，所以在日巡检当中需要把主从延时这个指标作为一个非常重要的时间指标加以关注。

另外，定期容灾演练很有必要。丁顺说：“因为有时候我们会改变容灾逻辑，就需要自己进行一个容灾演练才能发现一些问题，尤其需要去满足演变之后数据切换是不是一致，因为非常害怕数据切换以后不一致的情况。”

最后，在运维过程中对高可用容灾记录要进行全方位记录，并且切换失败时要进行及时的告警，这样才能帮助做以后的一些日志复盘分析，同时发现不能容灾情况下能够第一时间人工介入，这点也非常重要。

《技术内幕：分布式存储中的数据分布算法》

——奥思数据 创始人&CTO 李明宇

不论是云存储服务、企业级存储系统，还是区块链存储，分布式存储已经成为了数据存储的主流方案，传统的集中式存储设备正在淡出IT舞台。数据分布算法是分布式存储最核心的技术之一，不仅仅要考虑到数据分布的均匀性、寻址的效率，还要考虑扩充和减少容量时数据迁移的开销，兼顾副本的一致性和可用性。

具体到企业级存储和区块链存储的不同场景，对数据分布的需求又有很大不同，一个算法并不能解决所有的问题，奥思数据创始人&CTO李明宇在分享中，将比较几种典型的数据分布算法，分析其优缺点并讨论在具体应用中会遇到的诸多问题。

编程的时候如果有N个小的空间，我们要把数据均匀分布下去怎么做？最简单用哈希表来做，一致性哈希算法首先计算复杂度非常低，只要算一次哈希匹配就可以了，均匀性比较好，但扩容的时候呢？

所以真正应用的时候都是改进型哈希算法，直接应用肯定会遇到一些挑战。究其原因，他认为，首先数据的分布是随机的，如果用到企业级存储往往有哪些要求？其中需要提及的多副本可靠存储，即一个文件存多个副本，保证任何一个文件发生故障都不会丢失。有人说，怕数据丢失可以存十份，一个硬件存储的价格、硬件成本，目前做得好的也在50万左右。存10份，意味着多出来450万的成本，一个PB，不可接受。

成本接受的前提下数据还不能丢，怎么办？即便存了三份数据，五份数据，因为算哈希是随机的，所以怎么保证五个副本不放在一个盘上，或者这个区间或者那个区间？其实这是有一定概率的。

另外很重要的一点，一致性哈希算法是最基础的，它构成了现在分布式存储数据分布的基础算法，数据怎么找到它的存储位置？算哈希匹配，这样能够极大的提高效率。换句话说如果采用查表的方式，Objecto的数量太多了，查表的负担非常大，存储开销非常大，一致性哈希算法不用查表。

企业级存储与区块链存储考虑的问题又不一样，企业级存储主要考虑全局可控，故障域和权重的因素，实际上在扩容的时候并不是扩哈希到设备的映射，而是扩PG到设备的映射，会发现PG可能并没有增多，但是OSD数量增多了，随之PG到OSD的映射也就改变了。

除了精彩的主题分享之外，本次2018 UCan下午茶年终收官还准备了精彩纷呈的展区互动和抽奖环节，不仅增强了现场参会者的互动交流，更为本次沙龙增添光彩。

云计算，为各种新技术提供表演的舞台；大数据技术为人工智能提供了丰富优质的数据资源；而人工智能技术，则被认为是对人类产生深远影响的另一项关键技术，但如果不能深入理解“分布式”，这些至关重要的前沿科技也就不能被更好地了解和运用。UCan下午茶北京站关于云上“分布式”的探讨虽然暂时告一段落，但企业们对其关注并深入挖掘的历程似乎才刚刚开始！

-End-

---

print_r('点个好看吧！');
var_dump('点个好看吧！');
NSLog(@"点个好看吧！");
System.out.println("点个好看吧！");
console.log("点个好看吧！");
print("点个好看吧！");
printf("点个好看吧！\n");
cout << "点个好看吧！" << endl;
Console.WriteLine("点个好看吧！");
fmt.Println("点个好看吧！");
Response.Write("点个好看吧！");
alert("点个好看吧！")
echo "点个好看吧！"

喜欢就点击“好看”吧！