企业该如何做大数据的分析挖掘？这里有一份参考指南

现如今已经进入大数据时代，各种系统、应用、活动所产生的数据浩如烟海，数据不再仅仅是企业存储的信息，而是成为可以从中获取巨大商业价值的企业战略资产。这样背景下，如何存储海量复杂的数据、从纷繁错综的数据中找到真正有价值的数据，是大数据时代企业面临的难题。

8 月 18 日的“ UCan 下午茶”杭州站，来自 UCloud、网易、华为的五位技术专家，从数据库高可用容灾方案设计和实现、新一代公有云分布式数据库、基于 Impala 平台打造交互查询系统等不同维度出发，分享了他们在大数据查询、分析、存储开发过程中遇到的“困惑”与解决方案。

UCloud 丁顺：数据库高可用容灾方案设计和实现

高可用容灾是搭建数据库服务的一个重要考量特性，搭建高可用数据库服务需要解决诸多问题，保证最终的容灾效果。UCloud 云数据库产品 UDB 在研发演进过程中，根据用户的需要不断完善和演进，形成了一套完善的高可用架构体系。

UCloud 资深存储研发工程师丁顺从高可用数据库概述、典型的高可用架构分析以及高可用数据库自动化运维等角度，讲述了如何设计和运营一套完善的数据库高可用架构，保证在出现异常时能够及时恢复数据库服务。

业界典型的高可用架构可以划分为四种：第一种，共享存储方案；第二种，操作系统实时数据块复制；第三种，数据库级别的主从复制；第三，高可用数据库集群。每种数据同步方式可以衍生出不同的架构。

第一种，共享存储。共享存储是指若干 DB 服务使用同一份存储，一个主 DB，其他的为备用 DB，若主服务崩溃，则系统启动备用 DB，成为新的主 DB，继续提供服务。共享存储方案的优点是没有数据同步的问题，缺点是对网络性能要求比较高。 第二种，操作系统实时数据块复制。这种方案的典型场景是 DRBD。如下图所示，左边数据库写入数据以后立即同步到右边的存储设备当中。如果左边数据库崩溃，系统直接将右边的数据库存储设备激活，完成数据库的容灾切换。这个方案同样有一些问题，如系统只能有一个数据副本提供服务，无法实现读写分离；另外，系统崩溃后需要的容灾恢复时间较长。

第三种，数据库主从复制。这种方案是较经典的数据同步模式，系统采用一个主库和多个从库，主库同步数据库日志到各个从库，从库各自回放日志。它的好处是一个主库可以连接多个从库，能很方便地实现读写分离，同时，因为每个备库都在启动当中，所以备库当中的数据基本上都是热数据，容灾切换也非常快。 第四种，数据库高可用集群。前面三种是通过复制日志的模式实现高可用，第四种方案是基于一致性算法来做数据同步。数据库提供一种多节点的一致性同步机制，然后利用该机制构建多节点同步集群，这是业界近年来比较流行的高可用集群的方案。 UCloud 综合了原生 MySQL 兼容、不同版本、不同应用场景的覆盖等多种因素，最终选择采用基于数据库主从复制的方式实现高可用架构，并在原架构基础上，使用双主架构、半同步复制、采用 GTID 等措施进行系列优化，保证数据一致性的同时，实现日志的自动寻址。

自动化运维是高可用数据库当中的难点，UDB 在日常例行巡检之外，也会定期做容灾演练，查看在不同场景下数据是否丢失、是否保持一致性等，同时设置记录日志、告警系统等等，以便于第一时间发现问题，并追溯问题的根源，找出最佳解决方案。

UCloud 刘坚君：新一代公有云分布式数据库 UCloud Exodus

公有云 2.0 时代，云数据库新产品不断涌现。诸如 AWS Aurora、阿里云 PolarDB 等，UCloud 在采用最新软硬件和分布式技术改造传统数据库的工作中，也在思考除了分布式数据库所要求的更大和更快之外，是否还有其他更重要的用户价值？ UCloud 资深数据库研发工程师刘坚君，现场讲解了 UCloud 对于新一代公有云分布式数据库的思考与设计。

刘坚君首先从 1.0 时代存在的问题入手，他认为 1.0 时代云数据库带来了三方面价值：弹性、故障救援、知识复用。但它同样面临三大难以解决的问题：容量和性能、租用成本、运营成本。

到 2.0 时代，解决上述三个问题的思路是计算和读写分离。通过计算和读写分离，将传统数据库的计算层和存储层拆开，各自独立扩展和演进。这样做的好处是：1.提供更大的容量和读写性能； 2.按需扩容和付费； 3.优化运营成本并降低运营风险。业界已推出的 2.0 云数据库（如 Aurora、PolarDB 等），均采用计算和存储分离的架构。

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

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

更为重要的是，Exodus 将最终将开源，UCloud 会将核心系统的每一行源码开放，赋予用户深入了解和优化 Exodus 的能力。并建设开源社区，吸收全行业的优化成果，共同改进和完善 Exodus。

网易蒋鸿翔：基于 Impala 平台打造交互查询系统

在数据分析当中，因为数据基数庞大、关系模型复杂、响应时间要求高等特性，数据之间的交互查询就显得尤为重要。来自网易的大数据技术专家蒋鸿翔现场从交互式查询特点着手，深入浅出讲解了 Impala 架构、原理，以及网易对 Impala 的改进思路和使用场景。

Impala 是 Cloudera 公司主导开发的新型查询系统，它提供 SQL 语义，能查询存储在 Hadoop 的 HDFS 和 HBase 中的 PB 级大数据。已有的 Hive 系统虽然也提供了 SQL 语义，但由于 Hive 底层执行使用的是 MapReduce 引擎，仍然是一个批处理过程，难以满足查询的交互性。相比之下，Impala 能够很快速的实现数据查询。下图是一个 Impala 的架构图。

Impala 拥有元数据缓存、MPP 并行计算、支持 LLVM 与 JIT 以及支持 HDFS 本地读、算子下推等特性。但它也有一些缺陷，如服务单点、Web 信息无法持久化、资源隔离并不精确、负载均衡需要外部支持等。

网易针对上述不足之处，在原有的 Impala 查询系统下，进行了系列改进优化：

基于 ZK 的 Loadbalance。原始的 Impala 负载均衡需要外部支持，为此网易基于 ZK 做了一个 Loadbalance 方案； 管理服务器。主要为了解决当某一个节点挂掉时数据丢失的问题，管理服务器会将所有的状态信息搜集进来，后续如果做分析都可以通过关联的服务器查询； 细粒度权限和代理； Json 格式； 兼容 Ranger 权限管理； 批量元数据刷新； 元数据同步； 元数据过滤； 对接 ElasticSearch 查询。 据蒋鸿翔介绍，改造后的交互查询系统，已经成功应用于网易数据科学中心的一站式大数据平台自助查询系统上。同时，数据分析中心的一站式报表系统底层，也搭载在 Impala 上。相信未来，基于 Impala 的查询系统将会应用于更多不同的场景。

UCloud 王仆：UCloud 分布式 KV 存储系统

分布式 KV 存储系统在互联网公司中扮演着重要角色，各类上层业务对于 KV 存储系统的高可用性、可扩展性和数据一致性都有着很高的要求。UCloud 存储部门在迭代升级分布式 Redis 架构的同时，也一直致力于研发基于硬盘存储的大容量分布式 KV 系统。来自 UCloud 的技术专家王仆，着重介绍了 UCloud 在大容量分布式 KV 系统设计方面的经验，以及应对线上业务高性能、高容量要求的系统架构设计思路。

下图为 UCloud 分布式 KV 存储系统架构，底层为多个 Storage，每一个 Storage 有三个节点，这三个节点需要放在不同的物理机上，防止一台机器宕机后系统不可用；标红框的属于 Master 节点，Master 节点通过日志同步的方式，同步到层节点，整个数据的请求从 Proxy 进入。

整个系统是有中心节点的系统，路由管理由 Master 来管理，Master 通过每个机器上的 Host 管理 Storage 节点，由 Zookeeper 确定谁是主谁是从，因此，一些管理方面的请求都是直接连接到 Master 上的，包括创建、删除和控制台方面的功能等。

在测试过程中也发现了一些性能方面的问题，如采用的部分 Raft 协议是单 Raft，设计之初并没有实现并行 Raft 功能，因此数据同步较慢；其次，请求是通过代理的方式实现，代理的延迟会比直接访问的延迟更高，后期，会考虑提供一些客户端的 SDK，让请求可以跳过代理，减少一次网络交互。

在 KV 系统的后续优化上，王仆介绍到，为了能够将存储系统应用于更多不同的业务场景，未来会考虑更高的通用性，适配多种的存储引擎；另外，因为 Redis 比较流行，系统设计之初主要是支持 Redis，但是业界还有一些其他协议，这时候需要特殊的转化流程，未来希望做成一个支持各种协议的通用结构化存储系统，适配其他不同协议。

华为时金魁：实时流计算技术及其应用

随着 Flink/Spark Streaming 的大受欢迎，实时流计算开始为人熟知，进入大众视野。流计算在物联网行业、车联网、智慧城市等行业快速落地，亦创造出越来越多的价值。来自华为的架构师时金魁，现场分享了实时流计算的一些技术方案和落地应用。

在传统的数据处理流程中，总是先收集数据，然后将数据放到 DB 中。当人们需要的时候通过 DB 对数据做 query，得到答案或进行相关的处理。这个流程看起来虽然合理，但是结果却非常的紧凑，尤其是对于一些实时搜索应用环境中的某些具体问题，类似于 MapReduce 方式的离线处理并不能很好地解决问题。这就引出了一种新的数据计算结构—流计算方式。它可以很好地对大规模流动数据在不断变化的运动过程中实时地进行分析，捕捉到可能有用的信息，并把结果发送到下一计算节点。

目前，业界开源的流计算框架很多，最早有 Storm、Heron，后来还有 Akka，Beam，以及现在的 Kafka 等等。在诸多的开源框架中，时金魁认为，Flink 是最恰当的流计算框架，Spark Streaming 则是最有潜力的流计算框架，但这两个框架在落地应用中都有各自的优缺点。

华为根据 Flink 与 Spark 框架各自的特点，摒弃其劣势，设计开发出一款全新的实时流计算服务 Cloud Stream Service （简称 CS ）。CS 采用 Apache Flink 的 Dataflow 模型，实现完全的实时计算，同时，采用在线 SQL 编辑平台编写 Stream SQL，定义数据流入、数据处理、数据流出，用户无需关心计算集群, 无需学习编程技能，降低流数据分析门槛。下图为华为的实时流计算服务概览图。

据介绍，CS 聚焦于互联网和物联网场景，适用于实时性要求高、吞吐量大的业务场景。主要应用在互联网行业中小企业、物联网、车联网、金融反欺诈等多种行业应用场景，如互联网汽车、日志在线分析、在线机器学习、在线图计算、在线推荐算法应用等。

总结

虽然说开源软件因为其强大的成本优势而拥有极其强大的力量，数据库、云计算厂商仍会尝试推出性能、稳定性、维护服务等指标上更加强大的产品与之进行差异化竞争，并同时参与开源社区，借力开源软件来丰富自己的产品线、提升自己的竞争力，并通过更多的高附加值服务来满足部分消费者需求。

总的来看，未来的大数据分析技术、存储将会变得越来越成熟、越来越便宜、越来越易用，相应的，用户将会更容易、更方便地从自己的大数据中挖掘出有价值的商业信息。

想要获取更多技术和活动资讯，可关注“ UCloud 技术公告牌”微信公众号；或搜索微信 ID：ucloud_tech 进行关注。