从选型到实现——企业级云端大数据平台最佳实践

内容来源：2017 年 7 月 29 日，青云资深产品经理李威在“大数据与人工智能大会”进行《云端大数据平台最佳实践》演讲分享。IT 大咖说（微信id：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。

阅读字数：3289 | 9分钟阅读

嘉宾演讲视频及PPT回顾：suo.im/4A4Y7h

青云提供了完整的基础架构云和技术平台云，图中最下方的IaaS层提供标准的网络存储和计算服务，我们认为主机、虚拟机、容器、物理机等在架构中都是资源，共用同一套调度器。上层PaaS服务中的大数据平台以及数据库和缓存都是基于IaaS的，调用的是IaaS的API接口。再往上就是管理服务，它包含自身的一些部署架构。

一般的大数据平台架构首先面对的就是各种数据源，接着就是数据的传输，这里的传输层推荐使用Kafka。数据传输完成后就来到了大数据存储层，这里最常使用的有MongoDB、HBase、对象存储等。再往上的计算层一般分几类，实时处理主流使用Storm、准实时处理推荐使用Spark，批处理则使用Hadoop、Hive等。另外还需要任务的调度和平台管理层来管理接入的各种开源产品。我们将Redis、Memcached、MySQL归类到最上层，但是这层并不是UI层，而是因为离用户比较近，使用率较高。

以上所有的架构都是建立在IaaS之上的，不管是虚拟机、物理机还是容器。整个架构的核心地方在于从下到上的层次和从左到右的生命周期中的每个模块都可以根据企业的场景替换。

实时流处理引擎主流的产品有 Storm、Storm Trident、Spark Streaming、SAMZA、Flink 等，在选择它们时可以考虑的维度很多，比如说消息的传递机制保护（Guarantees）有 At-least-once（至少传输一次，它带来的结果是消息的重发）和 Exactly-once（消息一定只处理 一次，无论是在出错的情况还是其他的情况下）的区别；Latency（延迟）方面，如 Storm 是通过 Native 实现的流处理，延迟非常低。而 Spark Streaming 是通过 Micro-batching 实现的，它会把一段时间内的流组成小批量地处理，这样它的延迟就会高一些；吞吐量（Throughput）方面， Storm 的 Native 吞吐量没有那么高，Spark Streaming 的吞吐量就会很高。

HBase和Cassandra是非常相近的两个产品，都能提供高性能的海量数据读取，也都是列存储，读写性能都非常好。而且应用场景也很相似，都会用来做监控或者日志数据的存储。

但是它们也有很多不同的，首先一致性上HBase是行的强一致，Cassandra是最终一致；稳定方面HBase有多Hmaster，Namenode HA，Cassandra则去中心化，没有单点故障；分区策略方面，HBase 是基于主键有序排列的范围分区，Cassandra 是一致性 Hash 排列，可自定义策略；可用性方面，HBase是牺牲了可用性换取了一致性， Down 掉一台后短暂不可读写,Cassandra 是 Down 掉可继续读写。

交互式查询这方面考虑的维度有很多，这里选取数据量、灵活性、性能这三个维度来衡量。

可以处理海量处理，查询灵活，但是性能比较低。

这两个组合也可以查询海量数据，同时性能也比较高，但是查询是基于Rowkey的，非常不灵活，比较适合业务固定的场景。

ElasticSearch的查询灵活，性能也很高，不过承载的数据量很难达到p级别，只能支撑TB级别数据。这个主要是和它的架构有关系，因为它是属于全链接的结构，所有可能导致节点的扩展性有问题。

可以处理海量数据，性能也很高，但是灵活性较低。由于 Kylin 采用的是预聚合查询，在数据仓库中需要把你要算的 cube 的维度和事实预先计算好，存到 HBase 里面才能达到很高的性能，这导致就它丧失了灵活性。

海量数据、性能、查询灵活都满足了，但是它是时序数据，数据来源的每条记录里必须有一个 Timestamp。

采用标准的SQL查询，所以查询很灵活。而且性能也很高，支持PB级别数据，能在云上横向扩展节点。但是它的限制在于只能处理结构化的数据。

上图是我们用来处理海量数据的产品，它有一个中间件的集群，下方的每一个节点都是一个分片，每个分片又是一个MySQL的集群。这些分片在云上是可以无限扩展的，所以这种架构可以支持还海量数据。

在架构层面我们还将自动分库分表、数据强一致、分布式事务能力都做到了分布式数据库中。

对象存储在大数据的处理中非常重要，一般我们使用的都是S3对象存储，它可以无限扩展，并且支持的文件类型是通用的，不管是非结构化的数据、日志、视频、音频、图片都能存储，对文件的存在也没有限制。

青云提供的对象存储就支持S3接口，这样一些主流的大数据产品就可以直接使用QingStor的对象存储。虽然这种形式在性能上有所损失，但是数据的集中存储方便了计算引擎的切换，同一份数据可以使用不同的计算引擎计算。

整个架构中首先会将爬取的数据以及关系型数据库的备份数据都存储在对象存储中，然后经由Spark进行数据分析。分析完成的结果中的展示文件可以通过UI展示。

青云自身的也有很多的业务需要分析，我们会将一些线上数据库的数据进行解析、同步，包括典型的 ETL 处理，数据处理完存在 HDFS 里面，之后由 Spark 进行计算，最后把处理结果存到对于业务来说易于使用的产品，如 PostgreSQL、Elasticsearch，通过 API-server 曝露给前端使用。这是一个比较典型的大数据分析流程，我们用它来验证 QingCloud 大数据平台提供的各种服务。

这是一个在 QingCloud 公有云上运行的大型的互联网社交平台，架构非常典型。最上层用自身的Web Server接入负载均衡，下方有一个数据的服务层，可以处理 MySQL、缓存、Elasticsearch、MongoDB 等数据存储，再往下的数据传输层Kafka，可以将应用级系统日志等信息输入到 Spark 平台上进行分析，如对于系统推荐的好有，用户是否添加了好友等。

青云不仅提供大数据的相关组件，还提供了管理这些组件的平台。我们的大数据管理平台可以通过UI界面直接执行Hive、SQL、Spark的脚本，还可以直接看到 Storm 和 ZooKeeper 数据的信息，存储可以从浏览器、HDFS、对象存储看到文件的结构，可以提交 HBase 实时的查询，可以看 Kafka 传输队列里现在的数据结构是什么样的。这些是在大数据的组件之上的平台管理层。

大数据技术的变化太过迅速，我们无法提供所有的相关产品，所以需要在大数据平台下提供一个框架层，这样就可以将各种产品转化为服务集成到平台中。

青云的AppCenter就是这样的一个框架，我们的PaaS以及大数据服务全部都是基于这个框架交互。这样就能保证上层有统一的平台管理，下层有插件式的框架集成各种产品。