现在市面上的大数据产品太多了，但它们还远远没达到像IaaS层那样的标准化程度，每个产品之间的差别也并不是特别明确清晰。很多企业在做大数据平台或大数据方案的时候，常常不知道该选用哪些产品来满足自己的需求。一般的做法是做调研、学习、搭环境、测试、做各种产品的集成，但通常这个过程会很漫长，成本也很高。
我们希望这些事情都交给云平台来做，云上所有的产品都可以一键部署、一键伸缩，不论是加节点还是减节点都能够在UI界面上直接操作。对于一个企业来说，真正的核心是自己的业务，而不需要花太多的时间搞明白到底该用哪些工具搭建、部署、管理大数据。大数据产品的运维和管理，应该交给更专注、具有更大规模效益的大数据服务厂商，用户只需聚焦于自己的业务。
QingCloud基础架构云和技术平台云
QingCloud提供了一个完整的基础架构云和技术平台云，这里面分了很多层，最下面一层是大家熟知的IaaS层，包括标准的计算、存储、网络。网络里还有路由器、负载均衡等，存储里面有块存储、共享存储、对象存储等各种面向不同场景的存储服务，计算中有主机、容器、映象等计算资源。
IaaS层上面是PaaS，QingCloud在几年前就开始做PaaS平台，有一个原则贯穿始终——QingCloud的PaaS服务需要全部基于IaaS，这样做的好处是可以将QingCloudIaaS层所有的技术创新，如资源调度、SDN网络、性能优化，都透过IaaS层被PaaS享用，QingCloud的架构是一套统一的架构。
此外，QingCloud在PaaS层之上还提供了一些高级的管理服务，如编排、定时器、监控告警等以及客户部署的各种类型服务(如VPC、专属云、托管云)。
QingCloud完整的企业级大数据平台
QingCloud的大数据平台包含了完整的数据生命周期：负责数据传输的有Kafka;数据传进来之后可以存储在对象存储、HBase、MongoDB;负责从存储里拿出数据进行计算处理的有主流的实时处理工具Storm、准实时处理工具Spark、批处理工具hadoop、Hive等;还有一些在公有云上用量非常大的大数据组件：如Elasticsearch，性能和业务性很强，场景非常明确，只要做大数据、海量数据搜索都非常易用，以及Redis、Memcached、ZooKeeper等离用户比较近的大数据产品。
由于QingCloud是一家云服务商，所以提供的大数据平台是一个通用的服务，这与美团、小米、百度等互联网公司的大数据概念不太一样，它们的平台中会有很多与自己业务相关的东西。而QingCloud是在云上给所有的用户提供服务，所提供的这套大数据平台是一个通用的架构，每个组件之间的关系都非常灵活。QingCloud主要提供主流的大数据组件和组件之间关系的管理。
大数据产品如何选型?
很多用户在面对大数据时都会遇到一个相同的问题，应该选用什么产品?其实这个问题没有一个百分之百确定的答案，下面我们将会从各个维度来解析当前主流的大数据产品：
实时流处理引擎对比
实时流处理引擎主流的产品有Storm、StormTrident、SparkStreaming、SAMZA、Flink等，在选择它们时可以考虑的维度很多，比如说消息的传递机制保护(Guarantees)有At-least-once(至少传输一次，它带来的结果是消息的重发)和Exactly-once(消息一定只处理一次，无论是在出错的情况还是其他的情况下)的区别;Latency(延迟)方面，如Storm是通过Native实现的流处理，延迟非常低。而SparkStreaming是通过Micro-batching实现的，它会把一段时间内的流组成小批量地处理，这样它的延迟就会高一些;吞吐量(Throughput)方面，Storm的Native吞吐量没有那么高，SparkStreaming的吞吐量就会很高。
一个企业的架构师或者方案的设计者在选型这些产品的时候，需要平衡自身流处理的业务到底在意什么维度，是在意吞吐量、性能，还是在意消息的处理机制。
存储-HBasevsCassandra
HBase和Cassandra是两个非常接近的产品，很多人对它们可能不是很熟。它们都是列存储，都可以处理海量的数据，读写性能都非常好。但它们也有很多维度可以对比，首先是一致性，HBase是基于行的强一致性，Cassandra则是最终一致性，如果在中间的某个点写入数据的时候去读取，有可能不会读到最新数据;
稳定性方面，HBase有自己的HMaster、NamenodeHA，Cassandra是P2P的架构，去中心化，没有单点故障;分区策略方面，HBase是基于主键有序排列的范围分区，Cassandra是一致性Hash排列，可自定义策略;可用性，HBase是Down掉一台短暂不可读写，Cassandra是Down掉可继续读写。
从这些对比可以明显地看出来，HBase牺牲了可用性，注重强一致性，Cassandra有高可用性，没有强一致性。因此，在应用场景方面，HBase由于有强一致性，它可以做一些OLTP类型、交易类型的工作。Cassandra因为并发读写的量比较大，性能比较强，但是数据不要求强一致性，不要求数据时时刻刻精准和统一，可以做监控数据的存储。
常用Ad-hocOLAP查询分析产品对比
常用的数据仓库Ad-hoc和OLAP产品也非常多，在选择的时候可以从三个维度来衡量——数据量、灵活性和性能。
Hive：
基于MapReduce，可以处理海量数据，查询灵活，但性能较低;
Phoenix+HBase：
也可以处理海量数据，性能高，但查询只能通过Rowkey查询，灵活性较差;
Elasticsearch：
可以用来做数据分析和日志分析等应用场景，特点是查询灵活、性能高，但是它目前还支持不了海量数据，只能支撑TB级数据。这个原因主要是和它的架构有关系，Elasticsearch属于全链接的结构，所有节点之间都有通信，这应该是影响扩展性的一个原因;
Kylin：
百度、小米、美团等互联网企业都会用它来做数据仓库的分析，它可以处理海量数据，性能也很高，但是灵活性较低。由于Kylin采用的是预聚合查询，在数据仓库中需要把你要算的cube的维度和事实预先计算好，存到Hbase里面才能达到很高的性能，这导致它就丧失了灵活性;
Druid：
海量数据、性能、查询灵活都满足了，但是它也有一个限制，数据来源的每条记录里必须有一个Timestand，它是时序数据的处理，更多的被应用在实时处理的场景，比如广告分析;
HashData(GreenPlum)：
GreenPlum是一个传统的数据仓库，三个创始人依次是雅虎Hadoop团队的研发、全球Hadoop集群的运维和GreenPlum的核心研发工程师。他们在Apache上开源了一个基于Hadoop的数据仓库项目——Apachehook，在这个项目中他们贡献了一半以上的代码。所以，该团队在数据仓库的技术研发能力是很强的，与QingCloud一起实现HashData，这款产品查询灵活，性能高。但是它的局限是只能处理结构化的数据，不能处理非结构化数据。
计算与存储关系的思考
做大数据肯定会想到一个问题——大数据的数据到底放在什么地方?是放在硬盘里还是放在对象存储里?如果放在本地的话性能倒是可以满足，但是容量又不够。而放在对象存储里，容量可以无限扩展，但是性能肯定又没有本地硬盘快。例如Hadoop或者Spark，下面的数据如果放在本地机器或集群相关的存储上，它就拥有了大数据中数据本地性这个特性。但是这样做也会有问题，碰到海量小文件就不行了。这个问题谁能帮你解决?对象存储。对象存储针对小文件有专门的合并和优化，问题可以迎刃而解。
所以，QingCloud要做的就是让计算和数据不仅可以在一起，还可以分开。当数据量达到PB级以上的时候，数据存到IaaS和PaaS之上的分布式存储里成本也很高，这个时候就需要对象存储方案，将很久不用的历史数据和海量小文件都存在对象存储里。当你需要计算的时候，你有两个选择，如果不考虑实时性或者性能的话，你就可以直接在对象存储上面计算。如果需要高性能，可以将数据拉在HDFS上计算，这样就会变得很灵活。
那么，计算和存储的关系到底是什么呢?我们的理解是，当你想要性能的时候，就让它们在一起。当需要大批量计算处理的时候，就让它们分开。以前我们面对的是一个Hadoop集群或一个Spark集群，数据是到处分散的，而将数据都放在对象存储后，可以做到数据不动、计算随便动，计算引擎可以是Hadoop、Spark、Hive，它们都针对同一份数据进行计算。
大数据案例分析
QingCloud在线业务大数据分析流程图
QingCloud会用自己的大数据服务做业务、市场、销售的分析。我们会将一些线上数据库的数据进行解析、同步，包括典型的ETL处理，数据处理完存在HDFS里面，之后由Spark进行计算，最后把处理结果存到对于业务来说易于使用的产品，如PostgreSQL、Elasticsearch，通过API-server曝露给前端使用。这是一个比较典型的大数据分析流程，我们用它来验证QingCloud大数据平台提供的各种服务。
这是一个在QingCloud公有云上运行的大型的互联网社交平台，架构非常典型，它有一个数据的服务层，下面可以处理MySQL、缓存、Elasticsearch、MongoDB等数据存储，下面的数据层有ZooKeeper和Kafka，可以将应用级系统日志等信息输入到Spark平台上进行分析，如对于系统推荐的好有，用户是否添加了好友等。
某创新型综合金融公司
这是一个QingCloud的私有云案例，QingCloud可以将自己的整个软件全部部署到用户自己的环境当中去，架构主要有三大块：数据的抽取、数据处理、数据服务。数据源涵盖日志、关系型数据，还有一些ETL工具、日志处理框架、实时数据同步系统。中间有离线计算、实时计算。计算完之后会提供给离线服务，比如Hive、Spark，进行内部的数据分析。同时，还有一些在线服务，性能比较高、易用性比较好的服务。
这些案例的架构千奇百怪，但是仔细看其实都差不多，都分成数据的来源、收集、传输、计算、存储等架构，只不过具体用到的每个产品不一样，这和它的场景是相关的。对于QingCloud来说，无论用户是传统企业还是互联网企业，我们都能够提供一套非常灵活的大数据平台，满足任何一种应用场景的需求。
QingCloud大数据平台Rodmap
大数据平台管理架构
当大数据组件特别多的时候，需要有一个单独的平台来管理。QingCloud会提供一个界面执行一些Hive、SQL、Spark的脚本，在这个平台上你可以看到Storm和ZooKeeper数据的信息，存储可以直接从浏览器、HDFS、对象存储看到文件的结构，可以提交HBase实时的查询，可以看Kafka传输队列里现在的数据结构是什么样的。所以，它相当于一个管理的UI，你可以管理很多大数据的组件。以前用户需要分散管理这些组件，当系统比较复杂的时候，易用性就会变得比较差。
大数据平台+AppCenter2.0
大数据技术发展太快了，QingCloud面临一个困境：大数据产品是无穷无尽的，我们不可能把所有的产品提供出来，但是如果用户需要，我们怎么办?
第一，QingCloud的大数据平台也会通过QingCloudAppCenter交付。如Hadoop、Spark、Elasticsearch等产品都将是AppCenter中的一个APP，当你需要一些非常典型的组合的时候，它也可以作为一个组合的APP出现在AppCenter上。对于用户来说，大数据产品的易用性会大大增强。QingCloudAppCenter不但提供APP的开发框架，它还提供APP运营的框架，你可以在APP上进行编排，将几个简单的APP拼装成一个大的APP。
第二，大数据的场景太多了，如果QingCloud提供的没有你想用的怎么办?也很简单，如果你对这个产品非常熟，可以用QingCloudAppCenter框架将其做成一个云应用，提供给别人使用。这个概念非常接近于苹果的Appstore中的APP开发者，如果你是一个企业用户或者在大数据领域中技能很强的个人开发者，就可以在QingCloud之上利用AppCenter框架在短期之内把你熟悉的大数据产品变成一个云服务，放在QingCloud的AppCenter上提供给所有人使用。
这样的事情在以前完全是不可想象的，即使做也需要花非常大的成本，QingCloudAppCenter可以帮你在几天之内将已有的产品变成云服务。同时，云服务的运营管理、生命周期框架都内置于AppCenter中。
赞赏
