360SDN.COM

首页/Java/列表

别让海量数据沉睡,大数据让每个字节数据都有意义

来源:青云QingCloud  2017-09-11 13:13:12    评论:0点击:

随着企业、互联网数据的飞速增长,我们拥有难以想象的海量数据,这些数据不仅支持着企业业务创新与决策优化,还是训练某一领域「人工智能」的基础条件。

本文为青云QingCloud 高级产品经理李威,在 QingCloud Insight 2017「大数据与人工智能」专场的演讲他于众人工智能的专家,围绕大数据与人工智能,从硬件架构、深度学习、自然语义分析等不同领域、不同方面展现大数据与人工智能的魅力。

青云QingCloud 高级产品经理李威

QingCloud 基础架构云和技术平台云



先简单介绍下青云本身的架构体系。最下面是青云提供的 IaaS 层,提供标准的网络、存储、计算的服务。计算里优包涵了主机,虚拟机,容器,还有物理机等,都是包涵在架构里面的一种资源,所以共用同一套调度系统。包含针对各种场景提供的存储功能,包含所有的软件定义网络,常用的网络硬件的功能,在青云的平台上基本上用软件形式实现。

基于 IaaS 层,青云提供 PaaS 服务,包括大数据平台和数据库平台。再往上就是一些管理服务,包括支撑的部署的架构。从这张图可以看出,青云大数据的平台,在青云整个架构中的位置。青云本身还是专注于做 IaaS 层和 PaaS 层,青云发布了 AppCenter,是基于企业里面应用的重用性,青云能够提供一个优质的平台框架,让信任青云的企业能基于这个平台框架来做各种 PaaS 和 SaaS 服务,青云本身还是会保持一贯的中立性原则,不会继续向上做各类垂直行业的业务。

QingCloud 完整的企业级大数据平台

根据青云对整个企业级大数据架构理解的深入,这个平台已经经过了几个版本的演进,这其实就是一个架构的模式。在平时的工作中,我们通过与各种规模,各种类型的企业进行交流和业务实现,来了解企业对于大数据的需求,比如图像的左侧是各类的数据元。中间的传输层可以用像 Kafka,如果是物联网,可以使用 EMQ,都可以做传输层。数据传输完成后,到最底下倒数第二层是大数据的存储层,常见的如 Mongo,HBase,或对象存储。对象存储我们可以理解为像 Amazon S3。在 Amazon 里面基本上绝大部分的用户,基本上都会用 S3 的服务。但是国内还没有认识到对象存储的巨大价值。其中的一个原因是 S3 这样对象存储的服务是需要编程的,使用的最好方式,是用 API,SDK 来做,2016 年移动互联网增长迅速的时候很多移动 APP 使用对象存储来做是比较合适的。使用对象存储不需要考虑给海量的数据扩容的问题,而且对象存储一般都会提供主流语言的 SDK。近几个月以来,我们发现对象存储的用量在增加,越来越多的企业用户可能在对象存储上使用场景会越来越多。

再往上属于计算层,一般分几个大类,包括实时处理,像 Storm,准实时处理,比较典型的是 Spark,批处理,例如 Hadoop MR&Hive,在这里会面临一个问题,就是开源的技术太多了,技术的特点其实差别不是那么明显,场景有很多也有覆盖的地方。很多企业客户,都会碰见这个问题,在这个大数据的时代,像 Apache 开源的产品种类非常多,更新非常快,企业根本不清楚,应该在何种场景下用那种产品,需要花大量时间跟企业来沟通的场景里面都有什么样的的特点,他的流程,他的数据规模,数据的来源,业务场景是怎样的,才能推荐一套大数据的框架过去,很难用一个产品满足他所有的需求。右侧单独把 ElasticSearch 提出来,因为 ES 最近发展迅猛,以前大家对 ES 的印象是用来做一个全文检索,现在 ES 的领域又扩充了,还可以做统计分析,所以 ES 的体验,易用性非常好,包括各类 ELK 套件的流行,所以用 ES 的用户越来越多。


再往上,我们有一个任务的调度,还有一个平台的管理层,他可以管理下面接的各种各样开源的产品。最上面那一层,离用户非常近,像青云上用的 Memcached,Redis,MySQL 我们都把它规定为这一层。


最下层的架构,意思就是说青云所有的架构,上层的架构,都是建在 IaaS 之上的。不管是虚拟机,物理机,还是容器。青云希望提供的是一个灵活的架构,最核心的地方是在于从下到上的层次,和从左到右的数据的生命周期。

在这个架构下每一块都可以替换,可以根据企业的不同场景来替换。

大数据产品如何选型?

下面会谈一些常见的块有哪些比较主流的东西,他们可能有哪些区别。这些在做大数据架构或者方案的时候可能会有一些参考的意义。先拿流计算来说,这个里面第一行第一个是 Storm,第二个是 Storm 的升级版 TRIDENT,后面 Spark Streaming,samza,右面是现在很火的 Flink,左边的第一列就是衡量的维度,表示说在这个维度上建立这个产品他的表现是什么。如果你某一些维度要求非常高的话,比如说,第三行的消息可靠性,或者传输的保障机制,像 Storm,它叫 At-least-once 就是至少一次。Spark Streaming 可以是处理正好一次,就是这个消息不管是出错还是正常的情况下,他可以保证正好处理一次。

比如说像倒数第三行的 Latency 延时,如果对延时要求非常高的话,那只能选取包含 low 的,像第一列的 Storm,或者像 Flink 这样流式的产品。如果对吞吐量有要求的话,可能像 Spark Streaming,包括 samza 和 Flink 都是可选的,这个是在实际的场景中需要去考虑的一些点。

在存储里面,其实存储里面很多,在这里来比较下很容易分不清楚的两个, HBase 和Cassandra。为什么说这两个很相近呢?因为两者都能提供高性能的海量数据的读取,也都是列式的,实际上 HBase 是列族的。两者很相近,而且场景也很相近,基本用他们做一些监控或者日志数据的存储,都是没问题的。但是其实两者之间还是有不同的。比如说在一致性上,HBase 是可以做到行的强一致,但是 Cassandra 叫最终一致,他是可调的,这也是国内大家对 Cassandra 有一个误解。稳定性方面,HBase 都有主从,不管他底层的 HDFS 高可用也好,Cassandra 它是无中心的,所以它没有单点故障。

分区策略上,像 HBase 它是组建有序的,Cassandra 是一致性 Hash,是没有顺序的关系的。但是它的策略也是可定义的。可用性方面, HBase 其实是牺牲了可用性,换取了第一行的一致性,他在 Down 掉一台的时候,因为他要迁移 HBase 上有一个叫做管理数据的一个模块迁到一台机器上,迁完之后才可以读写,所以是牺牲了可用性。Cassandra 属于 Down 掉一台没有关系,因为它有副本,他还可以继续写,这是需要考虑的场景,在做一些决策的时候,需要考虑的一些点。

第三个模块,OLAP 或者叫交互式查询这个模块,这里只是简单举了三个维度,数据量、灵活性和性能。其实这三个维度,熟悉研发的话,就会清楚,三者之间其实都是一个平衡的关系。Hive 虽然感觉比较过时了,但其实还有很多知名企业仍在使用 Hive,它是可以处理 P 级海量数据的,Hive 的查询也很灵活,虽然它是类 SQL 的,但是查询还算灵活,但是性能比较低。

  

像 Phoenix+HBase 这个组合可以处理海量的数据,性能也很高,但是查询不灵活,因为它是基于 RowKey 来做,所以它的查询都是基于 RowKey 那个设计来做的,所以它的查询不是很方便,比较适合于你的业务有点固定的场景。那 ElasticSearch 它的查询很灵活,性能也很高,但是它能承载的数据量很难到P级的,T 级的数据量 ElasticSearch 是 OK 的。这可能跟它的架构本身有关系,它是 P2P 的对等架构,全链接的架构,所以可能导致在本身的结点的扩展性上,不能扩展到非常多的结点。

Kylin 是国内的工程师主导的一个开源的项目,它的优势是里面有一个很精巧的概念,预计算,这一点在实际的应用当中落地性是非常强的。比如百度,小米,链家,很多知名的大型互联网公司都会用 Kylin 这样的工具,它相当于用空间换时间,在算法里一个很通用的想法,放到了 OLAP 的分析里面,能处理 P 级的数据量,性能也很高,延时很低,但是它的缺点是要按照他的维度,建立一个 Cube,那个 Cube 是相对固定的,替换是可以的,但是效率比较低,所以后续的 OLAP 的分析都是基于 Cube 的,导致查询没有那么灵活。


第三个 Druid,这个大家很少听过,比如大的视频网站,其商业模式和广告很相关的,可能用Druid 比较多,Druid 的特点是既可以做实时的 OLAP 分析,也可以做历史的,也可以处理海量数据,性能也很高,查询也很灵活。但是它是有一点时序数据,他的第一列必须得是时间戳。

接下来是 HashData,以前是 GreenPlum 的云上的一个版本,这个产品的特点是查询很灵活,是标准的 SQL 查询,性能也很高,可以支持 P 级的数据量,支持在云上横向的扩展结点。但是他是结构化的数据,必须得是关系型的数据。

在这里特意把 OLTP 提出来,首先这是我们青云刚发布的一个新的产品,之所以把它归到大数据里面,是因为它也是可以处理海量数据的。大数据这个事情的产生,是因为传统的数据库处理不了海量的数据, MySQL 到了 T 级的数据量就无法继续。这个产品主要的场景就是能处理海量数据的 OLTP 的场景,它的做法也比较简单,在第二层有一个中间件的集群,下面的每一个结点叫做分片,每一个分片就是一个 MySQL 的集群,这样下面的分片是可以无限扩展的,在云上可以一键扩展,在这种架构下可以支持海量数据的。我们在架构层面,把像分库分表,像强一致,分布式事务能力,都添加进了分布式数据库里面,所以它是可以处理海量数据的 OLTP 的业务的。

计算与存储关系的思考

上面一些计算,分析相关的内容。那么对象存储,它为什么在大数据的场景中非常重要呢?大部分企业在用 AMAZON 的 EMR 或者其他的一些组件的时候,你会发现它好像很多的数据都存在 S3(对象存储)里面。为什么呢?原因很简单,S3 是一个可以无限扩展的一个存储,支持的文件的类型也是通用的,不管是非结构化的,比如日志数据还是视频,音频,图片都可以往里存。文件的大小也不限制,小到几 KB 大道几十 T 的文件都是可以存到里面去的。

青云提供的对象存储产品,有一个特点,就是支持 S3 接口。原因很简单,现在大数据开源的产品,基本上都支持 S3 协议,所以我们让一些主流的大数据的产品都能够直接使用 QingStor? 的对象存储,这样有什么好处呢?作为架构师,第一反映把数据都存再一个远端的地方可能性能有损失。是的,性能上是有损失。但是它的好处是,它的数据相当于有一个集中的存储的池子,企业里除了关系型的非结构化以外类型的数据,都可以存到对象存储里面,可以用不同的计算引擎针对同一份数据来做计算,相当于实现了数据不动的前提下,计算引擎可以随便切换,针对同一份数据,这边用 Spark 计算,这边用 Hadoop 计算都没问题。所以这是它的一个非常灵活的场景。

大数据案例分析

下面举几个青云实际的用户这套灵活的大数据平台的例子。图中这是个家电集团的案例,这家企业所做的是一个舆情分析,架构比较简单,他们会把爬到的大量数据存到对象存储里面,包括像倒数第二层的,像关系数据库的数据,备份的数据,都可以存到对象存储。在对象存储上,用 Spark 服务来做一些分析,分析后获得的结果,包括可以展示的文件可以通过 UI,因为 QingStor? 与 CDN 是可以直接集成的,相当于直接可以做一个加速的作用。这个客户最大的特点是什么呢?它的存储空间里的文件,因为是用爬虫所获取的网页文件,每个文件都比较小,但是存储空间里的文件的数量非常多。2016 年它的一个存储空间里面的文件有几十亿个,2017 年达到了百亿个,这样的海量的小文件,如果不使用对象存储的话,用 HDFS 这类是无法满足的。

第二个例子,青云的在线业务大数据分析的流程,因为青云本身也有很多的业务需要进行分析,其中分了几块,最上面会做一些离线的分析,把数据做个 ETL,传到 HDFS 里面,再用 Spark 的任务做一些分析计算,把结果拖到 PG、ES 里面,使得前段更容易处理,存取起来比较方便。另外青云会从各个物理机上把监控的数据,性能的数据通过 Kafka 往 ES 里面存。可以在前端做一些报警或者 Email 这些流程上的工作。

这是一个全球大型的互联网社交平台,其使用青云的方式很典型,用到的层次非常多,从最上层,使用青云的负载均衡集群进行接入,之后抽象了一个数据的服务层,下面就可以进行读写,像 MySQL,Redis,包括像 Mongo 这样一些常用的服务。再把收集上来的数据,通过 Kafka 传到 Spark 做一些计算分析,例如好友的推荐,包括用户的信息是否读取,包括是否添加了一些好友,来实现很多跟社交相关的一些场景。

这个是青云一个私有云的客户的案例,是一个综合类的金融公司,这个场景比较典型,最左边的就是各种的数据元,不管是以前的 MySQL,Oracle 还是日志这样的数据,通过中间你可以自己写一些 Python 的 ETL 工具,也可以使用在 Flume 自己带的一些日志处理的方式,把数据传到中间的黄色的两个层面,比如离线的计算,可以放到 HDFS 里面去进行,实时的计算,你可以用 Spark Streaming 或者 Storm。数据处理完之后,在蓝色的这部分是可以提供如数据存到,与业务比较贴近的,像 MySQL,Redis 或者像上面的可以做自助分析的 Hive,SparkSQL,最后提供给自己公司其他业务部门的报表,包括一些下游的供述或者查询,包括对外的数据服务。

他们使用整个的平台的场景是,比如说一些网站活动的监控,智能的报警,事件的营销,实时的推荐等等,用的比较重,业务的依赖性比较强。


青云的架构有一个演进,青云并不是只提供一些大数据的开源的组件,青云还做了两件很重要的事情,第一,这么多的组件需要上面有一个管理的平台,能管理各种各样的大数据的产品,比如需要有 UI,下面可以直接去使用 Hive,Spark,SQL 这样的计算引擎,也可以去支持Oozie,Yarn 这样的任务调度,可以直接察看,像 HDFS,QingStor? 对象存储里面的文件,也可以直接使用 HBase 的查询,或者可以直接察看 Kafka 里面的消息,或者主题创建的情况,这是在大数据组建平台之上的平台管理层。

再往下,青云提供了 AppCenter 的框架,这个框架的作用,是为了迎合大数据产品的变化速度。比如说青云的许多合作伙伴,或企业用户,其自身有一个大数据的产品,有足够研发实力,或者说他所需要的大数据的产品,青云目前的组件里正好没有,这个时候我 AppCenter 这个框架,让他可以把各类大数据的产品,变成一个服务,相当于集成到这个平台里面来。


目前青云的 PaaS 服务,包括大数据服务,全部是基于 AppCenter 这个框架来交付的,刚才提到的 Hadoop,ES,Kafka 都是如此。包括青云的 Kubernetes 容器的平台的服务都是基于这套框架来做的。这样就能保证在上层有一个统一的平台管理层,来管理各类组件。

下面有一个相当于一个插件式的框架,可以集成各类大数据的产品进来,从而变成一个云服务,这样的话对于各行业的企业用户来说,使用整个大数据平台的灵活性就非常强了。因为生命周期基本上是相似的,层次从底到上基本上是一个模型。但是中间的各种组件,是可以自由切换的。这个平台下面提供了框架平台,还提供了一个能力,就是在两个组建之间是可以管理他的依赖关系的,这里举一个简单的例子。

比如说 ZooKeeper 和 Kafka 之间,kafka 是要依赖于 ZooKeeper 的。但是在一个情况中,比如 ZooKeeper 这个集群本身扩容了,加了几个节点或者改了一些配置,Kafka 这个集群,因为依赖于 ZooKeeper 是需要做相应改变的,之前是需要手动来做这个改变,现在在框架层把依赖关系做了一层管理,这样可以在 ZooKeeper 这个集群变化的时候,Kafka 集群相应的配置参数都会自动去变化。这样的话,当的组件的依赖非常多的时候,或者当产品之间的关系非常多的时候,有一个被依赖的组件变化,其他的产品的变化不需要手动进行改变,这在运维上是非常提升效率的。


青云做的底层接入的框架,可以支持 LXC,Docker,KVM。青云最开始提出要把各种大数据的产品放到云上实现的时候,很多企业都说,正常都是用物理机来做,用云的方式来做的话,势必会有性能损耗。2016 年,青云做了两件事情。

第一,性能的瓶颈其实就是硬盘和网络吗?青云推出了 SDS 2.0,推出了 container machine,其实就是 Docker 底层的一项技术,但是没有Docker那个生态,基本没有虚拟化的损耗,跟物理机的性能是接近的,SDS 2.0 是支持 container machine 的。

第二,是 SDN 2.0 的突破,比如说物理网卡是 10G 的情况下,SDN 2.0 在没有配置它的限速的情况下是可以达到 8G 的,这样在虚拟的网络的性能和物理网络性能,其实差别已经非常小了,如果你再加上软件定义网络的灵活性和可扩展性的话,就可以满足很多客户的需求了。

这样基本解决了企业客户对于把大数据的东西放到虚拟化的平台上,性能损耗的问题,在实践过程中,运转的也比较流畅,并没有碰见性能问题。今天青云发布了 BM 产品之后,之后大数据的产品放在云上使用,不存在使用的难度,更大的理由是青云支持物理机的调度,可以像使用虚拟机一样,使用物理机。在 10 分钟之内,在 UI 上建设所需要的性能的物理机,直接登录进去就可以使用,与使用虚拟的场景是一模一样的。这个时候把大数据平台布置上去之后,跟虚拟化便没有关系了,只与云有关系,它是可以弹性的,把云的能力体现了出来,又没有虚拟化的损耗。所以青云 2017 年会依托于底层的 AppCenter 的框架,会很快的推出 Kylin、Flink,包括跟人工智能相关的 TensorFlow、Caffe,还有各种各样我们觉得企业用户需要的大数据的产品,把它变成服务集成到我们的大数据平台里面。

Insight 大会资料下载

为扫描下方二维码或点击「阅读原文」,获取本次大会资料。

QingCloud Insight|科技,洞见未来

- FIN -

阅读原文

为您推荐

友情链接 |九搜汽车网 |手机ok生活信息网|ok生活信息网|ok微生活
 Powered by www.360SDN.COM   京ICP备11022651号-4 © 2012-2016 版权