UCan下午茶杭州站：大数据时代的“答疑解惑”，还需要 get 这些！

身处被广泛热议的大数据时代，人们普遍意识到，不但数据量迅速上升为“浩如烟海”，就连数据的功能，也早已突破“信息”的范畴，逐渐成为企业从中获得无限商业价值的战略资产。

如此背景下，如何更好地存储复杂海量的数据？如何从纷繁错综的数据中找到真正存在的价值？如何为企业数据架构安全的“保护网”？这些统统被称为困惑企业的数据难题！

这不，就在前不久刚刚结束的UCan下午茶杭州站活动中，多位技术大咖针对以上问题进行了深入探讨，涉及大数据技术的重点场景运用、企业级解决方案等诸多方向，干货满满。

现场开发者爆满

现场超百位开发者，热情参与了交流与互动，尤其对大数据技术在具体实践场景、以及云计算中所发挥的作用等十分关注。

此外，这些探讨也将为大数据相关领域的从业者们，提供借鉴与新思路，并十分值得广大开发者们，认真学习与总结！

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

（UCloud存储研发工程师 丁顺）

如今大数据分析挖掘，已经成为各个行业提升竞争力的全新支点，不但助力商业化进程明显加速，还就如何在各行各业场景中发挥价值产生了热议，数据使用权、数据安全、数据存储等问题亟待解决。

对此，UCloud存储研发工程师丁顺，就“高可用数据库的概念、架构解决方案以及自动化运维”等相关领域，展开了本沙龙的首个主题分享。

丁顺认为，随着技术的发展，如今的高可用数据库，其实好处很多，例如可以方便完成读写分离。

关于读写分离，通常情况下，数据库的诸多操作中，读操作请求次数远大于写操作，高可用数据库可以将写操作放到主库上，将读操作分担到多个从库上执行，通过这种读写分离的方式，提升数据库的整体运行效率。

 “高可用数据库还可以带来变更不停服的优点。简单来解释，高可用架构由多个数据库节点组成，要升级整个高可用数据库架构、或者做变更的话，会将备节点升级，再做主从切换。升级后的备节点变成主节点，之前的主节点变成备节点，随后整个系统升级完毕，这样的方式对用户影响非常小。”他补充道。

此外，高可用数据库的备份，不影响服务性能。

如果按照数据同步方式，将高可用数据库进行划分，可以归类为共享存储方案、操作系统实时数据块的复制、数据库级别的主从复制以及高可用数据库集群。其中“主从复制”方案，被认为是最经典的数据同步模式。

在分享过程中，丁顺还提及了容灾切换的问题。

他强调，一个比较重要的、与高可用架构方案，不太一样的地方，就是需要数据同步的过程，所以容灾切换时，一定要同步好数据之后提升为主库，把数据库请求流量导入新主库，才可以顺利提供服务。

另外，怎样准确判断是否需要容灾，也是值得探讨的事儿。

例如，经常出现的网络波动问题，可能有一段时间，被发现不能链接主库，但通常几秒钟之后，整个业务就突然恢复了，如果这个时候，着手进行数据库的容灾工作，代价相对较大。

由于容灾的实行，可能存在额外风险，所以要准确判断，是否需要容灾，要选择在最需要容灾的时候下手才好。

此外，需要额外关注的一点，在容灾切换时，可能主库和备库的数据，会出现不一致。假设容灾时，主备不容易切换，最后带来的问题，很可能就是数据丢失，这一点需要格外留心。

分享结束后，与会开发者还就UDB最大的优点、主从复制过程等方面，与丁顺展开了细致探讨。

行内人都知道，公有云2.0时代，云数据库新产品不断涌现，诸如AWS Aurora、阿里云PolarDB等。这对于长期专注分布式数据库的研发和运营的刘坚君来说，一个问题始终萦绕在他的脑海中希望得到解决：在利用最新软硬件和分布式技术改造传统数据库的工作中， 除了分布式数据库所要求的更大和更快之外，是否还有其他更重要的作用与价值呢？

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

（UCloud资深数据库研发工程师 刘坚君）

俗话说有新就有旧，关于新旧分布式数据库的区分，刘坚君表示，云数据库出现以来，比较重要的时间节点有几个，分别是2009年AWS正式发布、国内2012年阿里云推出RDS、UCloud在2013年推出UCloud UDB、2014年AWS推出AURORA以及2017年阿里云推出PolarDB。

在我们看来，其实过去的1.0版本，并非毫无用处，确实可以带来几方面的价值，其中重要的一方面，就是快速部署免运维的弹性。

随着云数据库使用量的增加，问题很难避免，所以云厂商必然会组建专业的DB团队，来“攻克” 7X24处理问题的模式，随之而来的就是“无死角”故障救援的推进，包括数据恢复、慢查询、参数调优等环节。

相比2.0，尽管1.0依然存在用户价值，但出现的问题，也是不容忽视的。对此刘坚君明确认为，如今通过计算和存储分离的架构，可以让这些问题迎刃而解。   

首先，在容量与性能方面，分离架构可以帮助容量，达到100个TB，针对大部分业务的数据读库多写少的特点，增加只读实现读性能大幅度提升，同时MySQL可达100%兼容，硬件成本有效降低。   

另外，针对存储容量和计算能力按需扩容的问题，相对而言按需付费是最合理的，这表示在多个业务共同开发的过程中，分离架构可以帮助企业新业务达到逐步扩容，老业务也可以同步按照使用量扩容。   

一直以来，企业最关注运营成本。“资源成本计算机型和存储机型分开选型，成本可以大幅降低；MySQL100%兼容的情况，又让分库分表的方式成为过去。”他补充道。

谈到UCloud Exodus的具体实践，刘坚君强调，其技术理念则更进一步。计算和存储分离后，存储层将完全复用云平台的高性能分布式存储（如UCloud UDisk、阿里云盘古等），而会专注于构建一款数据库内核，去适配主流公有云和私有云厂商发布的高性能分布式存储产品，这种产品架构，称之为Shared-All-Disk架构。

Shared-All-Disk架构的优点明显。在提供云数据库2.0创新功能的同时，赋予了用户业务自由迁徙的能力，不被某个云平台绑架；同时能够连接上下游的软硬件厂商，共享云数据库2.0技术红利，共建生态。

更为重要的是Exodus最终开源， 会将核心系统的每一行源码开放，赋予用户深入了解和优化Exodus的能力。

当然，采用Shared-All-Disk这种开放式架构，有更多技术问题需要解决，其中的核心问题是IO路径问题。IO路径的优化，尽管有时候会押宝公有云产品的生产能力，但并不意味着在路径优化上毫无作为。

具体来说，主要是移除Binlog，主从同步后采用Redolog复制，随后下游系统数据同步，依据归档日志（由Redo log归档而来）反向生成Binlog然后同步，Binlog去除后，基于分布式存储的原子写能力有效去Double Write。需要说明的是，借鉴大部分2.0数据库，主从数据库同步采用了Redolog，主从之间同步Redolog Addr，从收到Addr之后再去底层数据中完成拉取。

分享过程中，在场开发者还提及数据的压缩性问题，指出所介绍的路径，是否考虑到数据量扩大的问题，毕竟每天产生的数据量，都要在10亿以上。

现场开发者积极互动

关于这个问题，刘坚君表示，该场景应用Aurora，目前来说，也解决不了过多的问题。如今云上场景，用来适配物联网还比较少，如果可以做到多点同时写入会更好。

精彩分享仍在继续，关于数据库的探讨，暂时告一段落后，网易资深数据库内核&大数据技术专家蒋鸿翔，又为与会开发者带来了主题为“基于Impala平台打造交互查询系统”的演讲。

基于Impala平台打造交互查询系统

（网易资深数据库内核&大数据技术专家 蒋鸿翔）

提到“交互查询”，蒋鸿翔先从交互查询的选型入手，他表示，项目熟悉程度、大厂背书情况以及熟悉了解其性能和优缺点指标都是考察选型的重要信息。既要拼性能，又要拼优缺点，要前期测试还要后期维护，本就不容易选择。

打比方来说，如果一个平台的性能很好，但整体架构部署上，却很复杂，模块多样且需要专人维护，这样计算下来运维成本显然很高，所以从性能以及运维成本出发，成本一旦较高，对性能的追求，也就只能以“基本满足”为标准了。

为了性能和成本的双举，他抛出了Impala平台，总结出该平台有几个鲜明的特点与优势，例如，元数据缓存，是其高性能表现的重要特点之一。

据悉，利用Impala平台查询之后，整个表单的数据，在哪个节点上都会一目了然，组织清晰。此外，平台还高效支持MPP并行计算，只是当集群规模变大时，就会变得相对棘手一些。

如今，代码生成，是比较流行的方式之一，很多自研数据库都会做代码生成，而Impala主要是用C11写成，此外还支持HDFS本地读。

尽管Impala平台优势多多，但依旧存在服务单点、Web信息不持久化、资源隔离不精准、底层存储不能区分用户以及负载均衡需要外部支持等缺陷。

对于此类问题的解决，蒋鸿翔一般情况下选择将Impala配合大数据平台综合使用。

他补充道，大数据服务中比较重要的选型就是ZK，如果基于ZK做成一个Load Balance，客户关联的时候，就可以主动选择，而不是被动接受，如果一台服务器出现问题，ZK的节点就会自动消掉，不会对全局产生影响。

“如果加入一个管理服务器的组件，就可以更好解决服务器节点出现故障所导致的历史数据丢失问题，而且还排除了后期排查的种种局限。管理服务器会将所有的状态信息搜集进来，后续做相关分析时再也不会费力不讨好。”蒋鸿翔说。

目前，分布式KV存储系统，在互联网公司中，扮演着重要的角色，各类上层业务，对于KV存储系统的高可用性, 可扩展性和数据一致性都有着近乎苛刻的要求。

支持大部分Redis主要数据结构的协议……

在实际使用中比Key-Value命令更普遍……

还可将纯内存的Redis，转变为硬盘存储，提高容量，降低成本……

最重要的一点，可以满足对多副本间的数据强一的要求，在性能优先的情况下，可以将同步方式降级成为最终一致……

一直以来，为了满足这些，UCloud存储部门，在迭代升级分布式Redis架构的同时，也一直致力于研发，基于硬盘存储的大容量分布式KV系统。

“我们发现，目前在线的服务Redis是比较流行的协议，支持较多的数据结构，包括Hash等，所以希望这套KV存储，能够用协议转化的方式支持大部分Redis协议，可以做到将一个纯内存的存储变成硬盘存储，达到成本降低、容量提升的效果，最高应该可以支持到PD级别。”UCloud技术专家王仆提出。

UCloud分布式KV存储系统

（UCloud技术专家 王仆）

 

在长期的实践探索中，王仆发现，在测试中还是会出现一些性能方面的问题。例如一些Raft协议，可以认为是单Raft，并没有实现并行Raft功能，同步并不快等。

鉴于此，他表示后期会考虑更高的通用性的尝试，例如适配多种的存储引擎，另外一点，就是希望做成一个支持各种协议的通用结构化存储协议。

关于恰当利用Redis的案例分析，据了解，其实大型社交App的客户比较适用，此外一个重要的应用，就是关注以及状态消息发布的场景。

例如，几百万用户的社交群体，要求响应会比较高，用户一般会使用Redis的数据结构来缓存数据，达成较快的响应。

王仆着重强调，其实KV存储最大的应用，还是互联网广告的DSP。

DSP中，一般会在缓存中，存储一些用户定向的标签，例如健身或者购物。

“之前把这些标签和要投放的广告ID联系起来，比较快的加速定向标签对应的广告投放，通过观察投放效果来修正广告投放的估算值，这些信息一般来说会用一个独立的缓存。这种情况下，一般比较大的公司都会自己做缓存服务，如果是一个相对简单的系统或者平台，多数用户还是选择使用Redis来实现。”王仆说。

作为沙龙最后一位登台分享的嘉宾，华为云技术专家时金魁表示，其实开源流计算很多，最早是STORM，还有HERON，后来还涉及到Akka等。

实时流计算技术及其应用

（华为云技术专家 时金魁）

在“实时流计算技术及其应用”的分享中，时金魁表示，流计算不能避免Dataflow模型。

原因在于，首先流数据没有便捷结束的说法，数据作业开始之后就永远都不会停止；此外，很多操作都是基于一个数据集，数据集是有限的，例如查SQL语句，有开始和结束，但是流式结束查询的时候，数据结构是持续增加的，流量并没有结束。

实时云计算适用场景比较多，例如广告、监控大盘、打车软件、金融风控、异常检测、交通、物流、外卖等，而且金融风控，交通、物流、外卖等很多场景都可以看到实时大数据。

谈及流计算的技术层面，时金魁认为，Flink做计算还是比较合适的。除了有一个TABLE，还能做一些SQL以及时空数据，主要用在物联网方向，例如电子围栏、车辆超速、地理位置，以及智能学习的模型、实时推理等。

“Flink用的最多的就是SQL。现在云上很多用户，一般直接写SQL，还有就是API。 Flink的特性，最基本的就是，具备消息事件，有Event Tine、ingest Time和Process Time等。”他补充道。

Flink虽然看似“超能”，但也会有一些潜在的问题存在。例如，Flink数据倾斜有一个问题。因为实时数据，每一个时间点的数据量不一样，随着时间点突然增加，这个数据量变大后，要计算资源，还要动态调配，这可以算是一个业界难题了。

大数据，从技术角度看，涉及计算、存储、网络等范围甚广、学习难度大，但却可以发挥重要作用。大数据，从产业角度看，可以显著提升传统企业的运营效率，助力数字化升级；引领全新的商业模式，为新兴企业赢得快速发展机遇……

UCan下午茶关于数据的探讨，虽然暂时告一段落，但企业针对数据的深入探索，似乎才刚刚开始！