云计算，赋予IT资源可伸缩的力量，从而可以整合算力，为各种新技术提供表演的舞台，同时也为社会积蓄了丰富的资源，为大数据、人工智能提供底层技术的支撑。大数据技术则将通过对数据的存储、加工、处理、分析，在为人们发掘数据价值的同时，也为人工智能提供了丰富优质的数据资源。而人工智能技术，则是人类社会智能化的关键，它将是除了互联网以外，对人类产生深远影响的另一项技术，其释放的力量将再次彻底改变我们的生活。
不过，这三项技术都离不开一个关键点，那就是分布式，如果不能深刻理解分布式，实际上也就无法真正理解云计算、大数据以及人工智能。2018年UCan下午茶收官战，以“回归云核心，服务大数据和AI的分布式实践”为主题，来自UCloud、奥思数据、Kyligence的技术专家，就大数据和AI平台的分布式设计实践进行了深入的探讨和分享。
UCloud上线商用至今，已稳定运营6年，覆盖全球29个可用区，服务上万家企业用户。目前，UCloud云数据库的实例数达几万，整个系统的数据量超数据量10PB+，单用户实例数达到6k+，单用户数据量1.8PB。在这样急剧扩张的数据规模之下，无疑给云数据库的容量上限、性价比、性能以及兼容性带来了前所未有的挑战。UCloud关系型存储研发部负责人”罗成对认为，想要解决这些挑战，需要改变传统的云+数据库思维，实现数据层和基础设施层的共生复用。
传统的分布式数据库下，数据库可以简单抽象两层，第一层是SQL层，第二层是Storage，SQL层的典型实现是基于分布式存储，这种方案可以兼容各种协议，无限扩容，不存在分布式事务和分布式Join问题，但其缺点也很明显，SQL层存在多节点缓存一致性和分布式锁的问题；Storage层最典型的实现是基于Sharding架构，该架构下也可以进行无限扩容，但协议无法100%兼容，存在分布式事务和分布式Join难题。
总体来说基于传统的分布式存储方案可以实现无线扩容问题，但它的缺点是协议无法兼容，且存在分布式事务和分布式Join难题。在这样的背景之下，UCloud基于高性能分布式存储架构，通过融合最新软硬件技术，着手研发新一代公有云分布式数据库Exodus。
Exodus支持主流的开源数据库MySQL，完全兼容各种协议，包括RDMA、Skylake、SPDK、用户态文件系统等，计算层采用深度定制的MySQL InnoDB引擎，架构设计上支持一主多从，通过这些设计，Exodus一举解决云数据库容量、性能、性价比、兼容性四大痛点。
系统基于用户态的协议栈，更能适应新的硬件红利，单核理论能到百万IOPS的能力，减少传统内核中断，上下文切换的开销。网络的时延开销在传统分布式存储中本来就是大头，基于融合以太网的 RDMA 协议 (RoCE) 网络实质上是一种允许通过以太网使用远程直接内存访问的网络协议，可以实现Zero Copy。
而底层采用了AppendOnly的模式，相较于传统的原地更新方式 ，在EC数据安全性以及实现Snapshot等方面更加友好，对于静默错误等磁盘异常也有更好的检测手段。IO路径上，则采用CRUSH算法来计算所有分片的placement，不需要缓存或者查询索引。LSMT Log-structure merge tree 通过LSMT来支持随机读写。
传统分布式存储一般采用的是三副本的方式来保证数据可靠性（10-11个9），Exodus在采用底层为追加写的方式来实现后，可以采用EC和压缩的方式，在不影响可靠性的前提下将数据副本成本从3降到1左右。计算层采用深度定制的MySQL+InnoDB，可以直接复用公有云分布式存储产品（如UCloud 块存储产品 UDisk ）。
基于这样的架构设计，罗成对判断，未来云平台的底层的分布式存储产品，在IO路径上将实现极致优化，主流云平台底层分布式存储将实现微秒级延迟，百万级IOPS，足以支持高性能业务（如数据库）。
如何有效降低成本，加快AI方案的试错，是每个想把AI算法产品化的企业都需要考虑的问题。UCloud LabU深度学习开发工程师范融结合UCloud AI PaaS平台的技术实践，讲述了UCloud如何为公有云用户提供一套开箱即用的AI开发、测试、部署一体化环境。
在AI PaaS平台落地之前，大部分企业面临的第一个挑战就是基础环境构建的复杂性：AI框架的多样化选择，环境的诸多变量、硬件的诸多变量以及底层数据存储的诸多变量。以上这些交叉组合之后直接导致了一个情况：如果需要构建完整的一套软硬件组合的系统，而每一条业务线都有不同需求时，多环境维护就会变得异常痛苦。其次，需要在AI系统建设时考量算法的兼容性、平台需要具备扩展性、弹性伸缩的能力、容灾能力等以应对平台的横向和纵向扩展。因此，一个完善的AI PaaS 平台需要具备如下特点：
算法兼容性：更好地兼容各类AI框架和算法；
横向扩展能力：支持CPU、GPU，支持S3、NFS、HDFS等多种存储；
纵向扩展能力：平台具备横向扩展能力，支持业务规模的不断扩大；
高可用：具备弹性伸缩的能力以及容灾能力；
环境迁移：可迁移公有云能力到私有云环境中。
基于以上五大要素，UCloud构建了自有的AI基础平台，里面包含AI Train和AI Inference两大核心服务。如下图所示，最上层最侧是训练日志、服务状态、TensorBoard框架和Jupyter，下面接着就是图形化界面，这里面主要是完成一些基本的部署操作，右侧是Python SDK接口，接入层下面即为平台核心的AI Train和AI Service，最底层封装了所有的计算节点和存储接入。
AI Train方面，为了实现横向扩展能力，UCloud不仅提供单机训练，同时还提供了分布式训练能力。也就是说除了提供单节点的程序，只要用户满足开发框架要求，平台还可自动部署分布式框架，海量训练服务下，可极大缩减训练时间，提高效率。另外，平台也提供交互式训练方式，用户可以和云上空间进行实时互动，并获取云上实时训练结果。
此外，在AI Training和AI Inference平台算力方面，UCloud设计了两大资源池，如果用户的算力要求比较低，希望实现很好的弹性扩容能力，可以采用CPU资源池。如果对算力要求比较高，可以采用GPU资源池，这样，就可以根据不同的用户计算力需求提供最优的支持。
业界有多种数据库高可用方案，每种方案都有自己的特点和不足，来自UCloud的资深存储研发工程师丁顺，就这些方案的技术实现及优劣进行了详细的讲解，并分享了UCloud云数据库产品UDB在高可用容灾方案上面的设计和实现，以及UDB产品大规模高可用数据库运维中的一些经验和心得。
据丁顺介绍，业界典型的高可用架构可划分为四种： 第一种，共享存储方案；第二种，操作系统实时数据块复制；第三种，数据库级别的主从复制；第三，高可用数据库集群。每种数据同步方式可以衍生出不同的架构。
第一种，共享存储。共享存储是指若干DB服务使用同一份存储，一个主DB，其他的为备用DB，若主服务崩溃，则系统启动备用DB，成为新的主DB，继续提供服务。一般共享存储采用比较多的是SAN/NAS方案，这种方案的优点是没有数据同步的问题，缺点是对网络性能要求比较高。
第二种，操作系统实时数据块复制。 这种方案的典型场景是DRBD。如下图所示，左边数据库写入数据以后立即同步到右边的存储设备当中。如果左边数据库崩溃，系统直接将右边的数据库存储设备激活，完成数据库的容灾切换。这个方案同样有一些问题，如系统只能有一个数据副本提供服务，无法实现读写分离；另外，系统崩溃后需要的容灾恢复时间较长。
第三种，数据库主从复制。 这种方案是较经典的数据同步模式，系统采用一个主库和多个从库，主库同步数据库日志到各个从库，从库各自回放日志。它的好处是一个主库可以连接多个从库，能很方便地实现读写分离，同时，因为每个备库都在启动当中，所以备库当中的数据基本上都是热数据，容灾切换也非常快。
第四种，数据库高可用集群。前面三种是通过复制日志的模式实现高可用，第四种方案是基于一致性算法来做数据同步。数据库提供一种多节点的一致性同步机制，然后利用该机制构建多节点同步集群，这是业界近年来比较流行的高可用集群的方案。
UCloud综合了原生MySQL兼容，不同版本、不同应用场的覆盖等多种因素，最终选择采用基于数据库主从复制的方式实现高可用架构，并在原架构基础上，使用双主架构、半同步复制、采用GTID等措施进行系列优化，保证数据一致性的同时，实现日志的自动寻址。
自动化运维是高可用数据库当中的难点，UDB在日常例行巡检之外，也会定期做容灾演练，查看在不同场景下数据是否丢失、是否保持一致性等，同时设置记录日志、告警系统等等，以便于第一时间发现问题，并追溯问题的根源，找出最佳解决方案。
数据分布算法是分布式存储的核心技术之一，不仅仅要考虑到数据分布的均匀性、寻址的效率，还要考虑扩充和减少容量时数据迁移的开销，兼顾副本的一致性和可用性。奥思数据创始人兼CTO 李明宇现场分析了几种典型的数据分布算法的优缺点，并分享了具体实现中会遇到的一些问题。
一致性哈希算法因其不需要查表或通信过程即可定位数据，计算复杂度不随数据量增长而改变，且效率高、均匀性好、增加/减少节点时数据迁移量小等特性受到开发者喜爱。但具体到实际应用中，这种算法也因其自身局限性遇到了诸多挑战，如在“存储区块链”场景下，几乎不可能获取全局视图，甚至没有一刻是稳定的；企业级IT场景下，存在多副本可靠存储问题，数据迁移开销巨大。
所谓存储区块链，可以理解为分布式存储（p2p存储） + 区块链，它通过token激励，鼓励大家贡献存储资源，参与构建一个全世界范围的分布式存储系统。因为需要激励大量用户自发参与，因此会涉及上亿甚至几十亿节点的寻址和路由问题，目前业界主要的解决方案主要有Chord、Kademlia等。不过，Chord算法效率较低，会产生较高延迟，可以采用Finger table，除了记录当前节点以及下一节点位置，同时还记录当前节点2^i+1的位置，降低计算复杂度，最终降低延迟。
企业级IT场景下，数据分布算法包括Dynamo、Ceph的CRUSH、Gluster的Elastic Hashing以及Swift的Ring等。这些算法都有相似的特点，首先它们都是基于/借鉴一致性哈希，增加/减少节点时数据迁移量小。其次，引入对数据中心物理拓扑的建模（Cluster Map），数据多副本 / EC分片跨故障域 / 可用区分布。另外，这些算法还可以对节点划分权重，数据分布和容量/性能匹配，辅助扩容。
总体来说，这两类方案均是基于一致性哈希算法实现，只是因为需求不同，才有了不同的改进方向。企业级更注重副本故障域的分布；而对于P2P存储，则更注重在节点随时退出随时加入的情况下，保证数据能够在有效时间内寻址。
大数据分析场景在丰富的技术产品栈面前，依旧面临着技术门槛高、人才短缺、项目开发周期长等问题。IT部门如何从被动的业务实现者转变为业务的赋能者，业务部门如何通过优秀的工具更好地理解数据、挖掘数据的价值，是每一个数据团队、IT 团队需要思考的问题。来自Kyligence云与生态合作部副总裁刘一鸣基于上述问题，讲述了Apache Kylin技术的设计思考和最佳实践。
Apache Kylin是一个开源的分布式分析引擎 ，提供Hadoop之上的SQL查询接口及多维分析（OLAP）能力（可以把Kylin定义为 OLAP on Hadoop ）。据介绍，它是首个完全由中国人贡献到国际顶级开源社区的开源项目，也是首个来自中国的Apache顶级开源项目。
Apache Kylin作为OLAP引擎包含了从数据源（Hive／Kafka等）获取源数据，基于MapReduce 构建多维立方体(Cube) ，并充分利用 HBase 的列式特性来分布式的 存储立方体数据 ，提供标准SQL解析与查询优化，以及ODBC／JDBC驱动及REST API等多个模块。
如下图所示，Kylin基于HBase的列式存储，计算结果集保存在HBase中，原有的基于行的关系模型被转换成基于键值对的列式存储，维度组合作为Rowkey，查询访问不再需要昂贵的表扫描，维度值通过编码算法（字典、定长、时间戳等）高度压缩，指标通过Column存储，可以灵活、无限制的增加指标数量，此外，预先计算的结果也为高速高并发分析带来了可能。
大多数的Hadoop分析工具和SQL是友好的，所以Apache Kylin拥有SQL接口这一点就显得尤为重要。Kylin用的SQL解析器是开源的Apache Calcite，支持几乎所有的SQL标准。Hive用的也是Calcite。
与其它SQL ON Hadoop不同，Kylin主要采用预计算（离线计算）的实现方式 。用户在使用之前先选择一个Hive Table的集合，然后在这个基础上做一个离线的Cube构建，Cube构建完了之后就可以做SQL查询了。用离线计算来代替在线计算，在离线过程当中把复杂的、计算量很大的工作做完，在线计算量就会变小，就可以更快的返回查询结果。通过这种方式，Kylin可以用更少的计算，获取更高的吞吐量。
由于篇幅限制，本文仅整理了现场部分精彩演讲内容，感兴趣的读者可以点击 阅读原文 下载讲师PPT进行深入了解！雷锋网雷锋网雷锋网
正在生成分享图...
nebula