现在市面上的大数据产品太多了，但它们还远远没达到像 IaaS 层那样的标准化程度，每个产品之间的差别也并不是特别明确清晰。很多企业在做大数据平台或大数据方案的时候，常常不知道该选用哪些产品来满足自己的需求。一般的做法是做调研、学习、搭环境、测试、做各种产品的集成，但通常这个过程会很漫长，成本也很高。
我们希望这些事情都交给云平台来做，云上所有的产品都可以一键部署、一键伸缩，不论是加节点还是减节点都能够在 UI 界面上直接操作。对于一个企业来说，真正的核心是自己的业务，而不需要花太多的时间搞明白到底该用哪些工具搭建、部署、管理大数据。 大数据产品的运维和管理，应该交给更专注、具有更大规模效益的大数据服务厂商，用户只需聚焦于自己的业务 。本文来自青云QingCloud 大数据平台架构师李威(Jordan)在青云QingCloud 深圳站实践课堂上的分享， 全文 3158 字，阅读时长约为 13 分钟 。
QingCloud 基础架构云和技术平台云
QingCloud 提供了一个完整的基础架构云和技术平台云，这里面分了很多层，最下面一层是大家熟知的 IaaS 层，包括标准的计算、存储、网络。网络里还有路由器、负载均衡等，存储里面有块存储、共享存储、对象存储等各种面向不同场景的存储服务，计算中有主机、容器、映象等计算资源。
在这里我还是要推荐下我自己建的大数据学习交流群：532218147，群里都是学大数据开发的，如果你正在学习大数据 ，小编欢迎你加入，大家都是软件开发党，不定期分享干货（只有大数据开发相关的），包括我自己整理的一份2018最新的大数据进阶资料和高级开发教程，欢迎进阶中和进想深入大数据的小伙伴。
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、Spark Streaming、SAMZA、Flink 等，在选择它们时可以考虑的维度很多，比如说消息的传递机制保护(Guarantees)有 At-least-once(至少传输一次，它带来的结果是消息的重发)和Exactly-once(消息一定只处理一次，无论是在出错的情况还是其他的情况下)的区别;Latency(延迟)方面，如 Storm 是通过 Native 实现的流处理，延迟非常低。而 Spark Streaming 是通过 Micro-batching 实现的，它会把一段时间内的流组成小批量地处理，这样它的延迟就会高一些;吞吐量(Throughput)方面， Storm 的 Native 吞吐量没有那么高，SparkStreaming 的吞吐量就会很高。
一个企业的架构师或者方案的设计者在选型这些产品的时候，需要平衡自身流处理的业务到底在意什么维度，是在意吞吐量、性能，还是在意消息的处理机制。
存储 - HBase vs Cassandra
HBase 和 Cassandra 是两个非常接近的产品，很多人对它们可能不是很熟。它们都是列存储，都可以处理海量的数据，读写性能都非常好。但它们也有很多维度可以对比，首先是一致性，HBase 是基于行的强一致性，Cassandra 则是最终一致性，如果在中间的某个点写入数据的时候去读取，有可能不会读到最新数据;
稳定性方面，HBase 有自己的 HMaster、Namenode HA，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 的数据仓库项目—— Apache hook，在这个项目中他们贡献了一半以上的代码。所以，该团队在数据仓库的技术研发能力是很强的，与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，你可以管理很多大数据的组件。以前用户需要分散管理这些组件，当系统比较复杂的时候，易用性就会变得比较差。
大数据平台 + AppCenter 2.0
大数据技术发展太快了， QingCloud 面临一个困境：大数据产品是无穷无尽的，我们不可能把所有的产品提供出来，但是如果用户需要，我们怎么办?
第一，QingCloud 的大数据平台也会通过 QingCloud AppCenter 交付。如Hadoop、Spark、Elasticsearch 等产品都将是 AppCenter 中的一个 APP，当你需要一些非常典型的组合的时候，它也可以作为一个组合的 APP 出现在 AppCenter 上。对于用户来说，大数据产品的易用性会大大增强。 QingCloud AppCenter 不但提供 APP 的开发框架，它还提供 APP 运营的框架，你可以在 APP 上进行编排，将几个简单的 APP 拼装成一个大的 APP。
第二，大数据的场景太多了，如果 QingCloud 提供的没有你想用的怎么办?也很简单，如果你对这个产品非常熟，可以用 QingCloud AppCenter 框架将其做成一个云应用，提供给别人使用。这个概念非常接近于苹果的 Appstore 中的 APP 开发者， 如果你是一个企业用户或者在大数据领域中技能很强的个人开发者，就可以在 QingCloud 之上利用 AppCenter 框架在短期之内把你熟悉的大数据产品变成一个云服务，放在 QingCloud 的 AppCenter 上提供给所有人使用。
这样的事情在以前完全是不可想象的，即使做也需要花非常大的成本，QingCloud AppCenter 可以帮你在几天之内将已有的产品变成云服务。 同时，云服务的运营管理、生命周期框架都内置于 AppCenter 中。
作者：大数据学习05
链接：https://www.jianshu.com/p/5fdc9417d1c4
共同学习，写下你的评论
评论加载中...
作者其他优质文章
