大数据的时代已经来临，到底什么是大数据，大数据技术如何和企业运营结合起来？读完本文，你会有新的答案。
本文为青云qingcloud 大数据平台研发工程师迟连义在 青云qingcloud 实践课堂·南京站中的演讲总结而来，他以《大数据平台的应用化、场景化及服务化实践》为议题，分享了青云qingcloud 大数据平台的整体架构及每个组件的应用场景，大数据产品云化的过程中的经验、青云 appcenter 2.0 的整体结构和功能特性以及青云qingcloud 大数据平台未来的发展规划。全文5320字，建议阅读时间13分钟.
青云qingcloud 大数据平台架构
上图详细介绍了青云qingcloud 大数据平台目前的整体架构。分层来看：输入端的数据源，可以是企业的用户浏览记录数据、电商平台的交易数据、视频用户的浏览记录、播放时长记录等数据。这些数据会接入到存储或者计算单元进行分析。
在整个过程中需要有一个缓冲区去缓冲数据。青云qingcloud 提供了主流的 kafka 分布式消息队列服务来满足这一需求，它的优点是：以订阅和发布模式有效地解耦了输入端与输出端，可以实现即使只有一次输入，输出端也可以多次消费，彼此之间不会发生影响。
在存储层，青云qingcloud 提供 mongodb 非关系型数据库。mongodb 是最接近关系型数据库的非关系型数据库，它可以提供类 sql 的访问模式，并且提供 hbase，一个可以承载海量数据存储的分布式数据库。hbase 有一个特点，只能通过 rowkey 进行检索，但它能够保证每行很好的一致性访问，同时具备很好的读写性能，如果不想把数据存在数据库里面，青云qingcloud 还提供了 hdfs 和对象存储服务。hdfs 本身是针对于大文件进行设计的，在处理小文件的时候它会有一些问题。小文件同样会在 hdfs namenode 里面占一块内存，如果小文件过多就会导致 namenode 的内存性能受到一定影响。同时，在后续做数据分析的时候，小文件过多会导致 mapruduce 中的 map 数量过多，整体分析过程会很慢。相比之下，对象存储则会对小文件做一些优化，所以如果需要处理大量小文件，存储到对象存储里面是更好的选择。
从数据本地化的角度来看，如果经常要进行计算，还是采用本地化的存储计算会更快，因为从对象存储取数据会通过公网。从成本角度来说，存在 hdfs 内会比存在对象存储上成本稍高。青云qingcloud 是对数据进行分层分类，如果需要处理的是一些历史数据，不需要经常进行查询和分析，可以放在对象存储上，而对于一年内经常进行分析和查询可以放在 hdfs 上。
在数据计算层，青云qingcloud 提供了实时数据处理 storm 和准实时处理的 spark (包括spark streaming)。同时提供了 hadoop mapreduce 及 hive 等离线批处理工具。在服务协调方面，提供 zookeeper 服务，zookeeper 是一个非常通用的功能，很多大数据组件，如 hbase、kafka 等都依赖于 zookeeper，很多企业用户也会基于 zookeeper 开发自己的服务协调。
elasticsearch，常用于企业内部的日志查询及分析。除了 elasticsearch 集群，青云qingcloud 还提供一个 elk 套件，囊括了从日志收集、日志检索到分析结果最终展现的全过程的功能套件，青云qingcloud 还提供了 redis 和 memcached 两个非常通用的缓存工具。
大数据管理平台
上图列出了比较主流的大数据工具，但有一个问题，这些大数据工具彼此之间都是独立的。比如：storm 有自己的一套监控 ui，监控拓扑的执行情况以及是否存在延迟等。在 hadoop 中，hdfs 也有一套自己的 ui，可以监控每一个 namenode 节点的状况和文件的情况。那么，如果一个企业用了很多大数据组件，一定需要一个统一的平台把所有大数据组件管理起来，青云qingcloud 提供了这样一个大数据管理平台，可以把该平台理解成一个 ui，把所有大数据组件囊括其中。
该平台根据开源 hue 做的二次开发，支持直接 hive 查询，结果可以通过图表展现出来，也可以提交 spark sql、spark shell 等。还可以将关系型数据库，如 mysql，放进来统一管理。在 job 方面，可以直接用 oozie 进行调度，也能直接看到 mapreduce job 目前的运行情况，包括刚才提到的 storm 拓扑的管理，以及 zookeeper 节点信息展现。
在储管层面，对 hdfs 及 qingstor 对象存储，都提供了数据路径的监控及展示页面，hbase 可以在管理平台上面直接做 shell 查询，也可以看到表的信息等等。kafka, 可以清楚展示 topic 的信息，和每个 kafka group 对某个 topic 的消费情况。
大数据产品云化瓶颈
在对这些应用进行运化开发的过程中，青云qingcloud 也遇到了一些问题，会影响到以后大数据平台的扩展。主要这三个方面：
第一个是大数据发展太快，各个领域存在很多竞品。比如在列式数据库方面，青云qingcloud 提供了 hbase，但还有 canssandra。在离线计算方面，还有比 hive 快很多倍的 impala 这些工具目前青云qingcloud 还没有放到云平台上。另外，在一些特有领域，如 ai，区块链，机器学习，深度学习方面，如容器应用领域，这些应用都还没有集成到青云qingcloud 的大数据平台上。这些领域的产品非常多，但青云qingcloud 的精力有限，这是遇到的第一个挑战。
第二个挑战是云化周期长。以青云qingcloud 的经验要云化一个大数据产品，把大数据产品真正放到 qingcloud 上，作为一个云原生应用大约需要两到三个月的时间。首先要搭建一个整体开发测试环境，要把大数据应用的一些自带的东西放在开发设计环境里面去，同时开发人员要对青云的 api，包括生命周期管理体系都要有一定的了解。在开发过程中，撰写针对云平台生命周期管理的代码，之后还要开发应用监控、报警等功能，最后经过测试，需对接云平台内的计费、工单等等这些系统，最终做成一个独立的应用。
第三个是挑战产品间的组合非常复杂。比如，目前青云qingcloud 的 hadoop 和 hbase 是独立提供的。 如果一个用户要想一键部署一个 hadoop + hbase 的集群，青云qingcloud 就需要按第二点提到的开发流程重新做一个新的产品发布出来。这样子导致组件间的组合特别复杂。
同时，青云qingcloud 还需要一种服务之间的自动发现能力。比如：kafka 是依赖于 zookeeper 的，如果在一个部署的 zookeeper 集群中添加或删除一个节点，kafka 集群需要手动修改与 zookeeper 的链接地址。青云qingcloud 希望这一过程是自动的，自动感知变化并作出修改 。
面对这三个挑战，最终青云qingcloud 找到了比较好的解决方案，就是青云qingcloud 的 appcenter 2.0。首先产品特别多，而青云qingcloud 自身精力有限。但是青云qingcloud 可以联合一些技术能力很强的开发伙伴，让他们可以基于青云qingcloud 去便捷地开发云化一些大数据产品。做到这点的关键是需要提供一套很方便开发的手段,降低开发难度。
appcenter 2.0 提供了一套模版化的开发流程，大幅降低开发难度。同时，appcenter 2.0 也把主要的功能，如应用生命周期管理，监控告警，工单系统，计费等等全部抽象出来，以标准化的形式交付出来，最终把整个应用的开发周期从几个月降低到了几周，这也解决了第二个开发周期长的挑战。
青云qingcloud appcenter 2.0 简介
青云qingcloud appcenter 2.0 是什么样的平台？
首先，appcenter 2.0 是一个经过高度抽象，可以部署各种分布式应用的平台。青云qingcloud 知道分布式应用整体架构多种多样的，比如: zookeeper 是 peer to peer 架构; hadoop 是主从架构； redis cluster 是分片式的。appcenter 2.0 会对这些不同的架构做高度的抽象，把应用整个生命周期抽象出来，然后开发者只需用类似自然语言的方式在模版中进行修改，表明应用需要在生命周期的不同阶段，做哪些动作从而完成整个开发流程。这种高度抽象使云上的应用开发和交付变的异常的简便和标准化，它是以模版的形式提供给开发者。
其次，appcenter 2.0 是全新的云操作系统，贯穿资源与应用平台。青云qingcloud 可以把 iaas 理解成对物理资源的虚拟化，可以类比成现在用的 pc 机。实际上最终用户在使用 pc 机时用到的是上层的软件应用，在 pc 机和软件之间还有一定的距离，需要一个东西去调动 pc 机中的各种资源，这个东西就是操作系统。
appcenter 2.0 实质上就是架构在 iaas (云平台) 层上的操作系统，操作系统会提供很多接口，让开发者在青云qingcloud 操作系统上开发各种各样的应用，最终提供给最终用户去使用。
appcenter 2.0 架构图
上图为 appcenter 2.0 的整体架构图，主要分三块：开发者控制台、用户控制台以及调度系统（中间部分）。首先，开发者控制台：开发者可以通过这里创建一个应用及不同的版本，然后基于每个版本，分别创建配置文件，其中会描述需要被定义的信息，如环境变量、集群节点的可选个数、每一个节点角色需要的 cpu 和内存配置等。
同时还要在模版文件中完整定义整个应用的生命周期。之后将配置文件打成一个压缩包并在开发者控制台提交，之后青云qingcloud 人员会进行审核，对应用进行详细的测试，看它的监控报警是否有完善等等。当青云qingcloud 觉得该应用符合标准，会批准开发者进行发布。应用发布之后，在用户控制台，最终用户便可以看到它的应用。如果用户对该应用感兴趣，就可以进行安装和部署。
用户部署以后会真正的进入调度系统的处理范围。青云qingcloud 调度系统首先会在用户需要中创建一个元数据管理服务，基于一个 3 节点的集群，对最终用户是免费开放。然后会根据最终用户的选择，创建相应数量的节点，cpu 核数，内存容量及存储空间等资源。
在appcenter 中， 这些资源是支持 kvm、docker、及 lxc 三种架构。创建好资源后，这些资源的元数据信息会被注册到元数据管理集群。之后在资源管理层面会启动一个 confd，它相当于一个 agent，会时刻监控元数据管理服务中注册进去的元数据。如果这些元数据发生变化，那么会触发由开发者定义好的要执行命令，后者更新配置文件等各类操作。
接下来，调度系统会负责整个应用的生命周期管理，包括创建、扩容、关闭或启动等等这些操作。同时调度系统还会周期性地调用由开发者定义的一系列管理操作，如监控、健康检查等等。
接下来青云qingcloud 详细看一下 appcenter 2.0 的功能和技术特性。上图显示的是开发者需要提供的一些模板文件，比较重要是这几个第一个 config.json，主要用来配置应用的 ui，其中定义了最终用户在前端需要看到的一些信息，如该应用可以选择多少核的 cpu，多少容量的内存，每一类节点橘色可以创建多少个节点。
因为很多应用对节点数量是由限制的：hadoop 集群，salve 节点的数量最少需要 3 个；像 zookeeper 集群，节点数量一般都是奇数个的。对于这样的限制，都可以在在模版文件中具体的进行配置。
json 文件最终的效果会是，青云qingcloud 通过预置好的统一的 ui 界面，把 json 文件中的各项配置在前端提供给最终用户。然后是 cluster.json.mustache，该文件实际上定义了整个应用的基础架构。
基础架构包括定义应用中需要哪些类型或角色的节点，如 hadoop 集群中会分三种不同角色的节点，而针对每一个节点的角色，开发者需要定义其完整的生命周期管理以及监控报警。生命周期管理刚才有提到，包括如横向扩容和纵向扩容等等操作。
开发者要通过 cluster.json.mustache 模版文件，告诉调度系统需要执行哪些操作，需要执行主机里面哪些脚本，那么调度系统在生命周期到来的时候，会触发这些脚本的执行。
接下来是监控报警功能，这一点在青云qingcloud 审核过程中，会强制要求每一个应用必须存在。因为作为一个云应用，监控和报警很重要，在客户业务出现问题的时候，他需要了解到底是业务出现问题还是产品出现问题。
最后一个是多语言翻译功能，青云qingcloud 提供的是英文，最终用户其实想看到一些中文展示，开发者需要定义一个多语言翻译的文件，告诉青云qingcloud 它的行业变量和角色对应的中文是什么样的名字，青云qingcloud 会最终展示在界面上。
以上这张图就是一个上传配置文件的界面，开发者在创建应用和版本以后，并完成以上的两个配置文件的撰写后，就在该位置提交，并发布版本。之后会现在后台通过青云qingcloud 的审核。青云qingcloud 现在的审核比较严格，因为青云qingcloud 要对最终用户负责，开发者对应链接到控制台测试，测试一下配置文件写的是否合理，测试生命周期管理，并测试监控报警是否合理。
以上介绍的是 appcenter 2.0 的一些基本功能，可以帮助开发者通过模板文件的方式很便捷地在运平台上开发一个自己的应用。还有一个比较高级的功能，就是应用编排。通过元数据管理集群以及 confd 这两者之间的交互，可以实现应用之间的自主感知。举例来说，kafka 需要依赖 zookeeper，那么如果 zookeeper 集群发生了增加或删减节点的变化，kafka 集群是可以感知到该变化，并自动执行配置文件更新和重启集群等操作。
另外一个例子是上文提到的大数据平台管理 ui 系统。该 ui 在启动的时候通过应用间自主感知能力，可以感知到用户的 vpc 下面已经使用了哪些大数据产品，之后可以自动将大数据产品添加到管理 ui 里面去，而且后续如果在同一个 vpc 下，�...