前言
现在市面上的大数据产品太多了，但它们还远远没达到像iaas层那样的标准化程度，每个产品之间的差别也并不是特别明确清晰。很多企业在做大数据平台或大数据方案的时候，常常不知道该选用哪些产品来满足自己的需求。一般的做法是做调研、学习、搭环境、测试、做各种产品的集成，但通常这个过程会很漫长，成本也很高。
我们希望这些事情都交给云平台来做，云上所有的产品都可以一键部署、一键伸缩，不论是加节点还是减节点都能够在ui界面上直接操作。对于一个企业来说，真正的核心是自己的业务，而不需要花太多的时间搞明白到底该用哪些工具搭建、部署、管理大数据。大数据产品的运维和管理，应该交给更专注、具有更大规模效益的大数据服务厂商，用户只需聚焦于自己的业务。本文来自青云qingcloud大数据平台架构师李威（jordan）在青云qingcloud深圳站实践课堂上的分享，全文3158字，阅读时长约为13分钟。
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-hoc&olap查询分析产品对比
常用的数据仓库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中。
『充电时间』实践课堂第三季已经开始了，本次课程内容仍以技术实践为主，以用户场景为切入带你，主要围绕qingcloud的技术理念、功能特性和使用技巧展开，话题将涵盖如何高效构建原生云应用，云端容器部署，微服务架构，应用感知，自动化运维等业内热点话题。