临近年底，各大权威调研咨询机构报告将陆续出炉。刚刚，由工信部电子一所指导，计世资讯（CCW Research）发布了《2017-2018年度中国私有云市场现状与发展趋势研究报告》，成为今年首份中国私有云市场报告。

临近年底，各大权威调研咨询机构报告将陆续出炉。刚刚，由工信部电子一所指导，计世资讯（CCW Research）发布了《2017-2018年度中国私有云市场现状与发展趋势研究报告》，成为今年首份中国私有云市场报告。其中，不仅有大量一手调研数据，观点与预测，趋势与判断，以及中国私有云市场品牌竞争力分析象限，最抓人眼球的当属中国私有云企业TOP20榜单，这也是2018年首发的第一份专业的私有云企业排行榜。

一，私有云市场高速增长

根据计世资讯的研究调查结果，中国私有云市场将继续保持高速增长的趋势，预计2018年市场规模将达到512.4亿元，同比增长27.0%。且到2022年，预计中国私有云市场规模将达到近1000亿元。随着政务云、制造业、金融云等私有云市场（三大行业市场占据超过60%市场份额）的活跃，以及各地政府推动企业上云计划的实施，为中国私有云市场的发展提供了坚实的基础。

2017~2018年私有云市场规模及增长

计世资讯研究表明，预计2018年中国私有云市场中硬件市场份额为66.5%，硬件下降幅度有加速的趋势。软件和服务则呈现快速上升的趋势，预计2018年市场份额分别将达到21.2%和12.3%。硬件产品在私有云解决方案中的重要性持续下降，并且随着超融合的产品的快速落地，使得项目中硬件产品的采购规模大幅降低。另一方面，软件和服务产品的重要性越发凸显，已经成为了私有云解决方案中的核心，成为了决定私有云项目成功与否的关键。

二，私有云企业竞争力分析象限

中国私有云需求旺盛，因而成为各类企业竞争的重点。依照惯例，计世资讯发布了“2018年私有云市场品牌竞争力分析象限图”，其中，最值得关注的领导者象限包括：华为、新华三、VMware、华云、EasyStack（易捷行云）五家企业。

2017-2018年私有云市场各品牌竞争力分析象限

与去年竞争力分析象限中的领导者象限相比，有几点值得关注：

1、VMware是唯一一家国外企业，也是唯一进入领导者象限的非OpenStack企业。

VMware虚拟化可谓市场接受程度最高，那么中国用户对VMware产品应用是否还停留在虚拟化阶段呢？“VMware作为虚拟化巨头近年来在国内保持了良好的发展势头，服务器虚拟化产品市场份额远超其他对手。”计世资讯点评也印证了这一点：“但是在私有云方面，VMware的占有率似乎并不高。我们认为这主要源于用户管理需求的复杂化导致用户需要更开放更具有兼容性的产品，比如OpenStack+KVM的产品。”

同时，计世资讯也给出了VMware建议：“当然不可否认VMware在产品特性和功能方面依然有独到的地方，VMware仍然是私有云中的举足轻重领导者。但与国内用户使用特性的结合方面仍有待提升。对应用户的定制化需求往往是私有云方案赢得市场的关键，这方面VMware正在着手改善。”

2、EasyStack是唯一进入领导者象限的云创业型企业，专业私有云厂商。

EasyStack成立四年以来在中国私有云市场上声音不断，四年获得五轮融资，已到C++轮阶段。应该说，对于云创业型企业首要比拼的就是技术能力和产品能力，才能在强手林立的私有云市场迅速占据一席之地。“EasyStack一直受到资本市场青睐，也是为数不多的在Linux、OpenStack、Ceph、Kubernetes、Docker等开源云技术领域均有涉足的企业。”计世资讯对EasyStack的点评也强调了这一点，“EasyStack强调产品化能力，在稳定性、可靠性和性能上要求较高的金融行业，以及业务场景复杂、IoT等创新应用颇多的制造行业取得了不少标杆客户和较大市场份额。”

同时，计世资讯对EasyStack另一点评价也值得关注：“EasyStack也注重用户体验，在ECS企业云纯软件的基础上推出了云计算的软硬一体化交付产品ECS Stack超融合，扩大了市场受众。”

这符合计世资讯对于中国私有云市场的一个重要判断——现阶段按照License交付模式更多的是随着超融合等硬件设备一同交付，云软硬一体化交付正在成为私有云市场的新趋势。云软硬一体化交付模式将会大幅简化私有云的部署周期，有效减少厂商的定制化工作，推动私有云产品化落地，对市场起到强劲的推动作用。

此外，华为、新华三继续以传统IT企业身份占据领导者象限，且以国内为数不多的能够覆盖从硬件到软件再到解决方案，拥有全线云产品的特色，都在政务云方面表现突出。华云则以公有云企业身份新入领导者象限，计世资讯认为全云能力是华云最大的特点和优势。

三，OpenStack是中国私有云的事实标准

以OpenStack为代表的开源技术依然在私有云市场中占据主流。计世资讯认为，作为全球部署最广泛的开源云基础设施软件，OpenStack经过8年的发展，在国内已经形成了稳定的以OpenStack为核心的开源云生态体系。尽管OpenStack在近年来受到了容器等技术的冲击，但是在中国市场中越来越丰富、越来越成熟的用户实践案例表明，OpenStack开源云技术依然保持着足够的活力。现在OpenStack发展已经越发成熟，已逐渐摆脱了最初的版本混乱，后续运营维护、改造升级成本高昂等问题。

不仅5家领导者象限企业中就有4家（华为、新华三、华云、EasyStack）以OpenStack为基础，在排名TOP20的私有云企业当中开源与闭源技术应用比例也高达7:3。在企业用户调查中也反应了这一点，被调查的283家企业用户当中，私有云建设中开源软件和闭源软件的采用百分比分别为82.4%和17.6%。

2018年中国私有云TOP20厂商中开源和闭源技术应用比例

四，私有云企业TOP20大排名

计世资讯《2017-2018年度中国私有云市场现状与发展趋势研究报告》同时还发布了“2018中国私有云解决方案提供商TOP20”榜单：

中国私有云解决方案提供商TOP20

如果将竞争力象限中的企业进行排序，计世资讯给出的中国市场私有云TOP20榜单是这样的。你怎么看？

计世资讯报告中提到，按照类别来看，公有云厂商、传统IT厂商、电信运营商、系统集成商、云创业型公司五大类企业都已经深度参与到了私有云市场的竞争之中（具体代表企业如上）。可见，云计算经过超过10年的发展，重点已经从公有云市场转向行业企业市场挖潜，私有云已经成为云计算下半场的重要焦点。

付钱拉是一家做金融云服务的公司，目前对外提供有支付、资金管理、大数据征信、余额增值、理财超市等与金融相关的服务。付钱拉提供的这些金融服务非常简单好用，跟互联网上的大家看到的OAuth，评论等互联网接口类似，对接付钱拉的支付只需要7行代码。金融简单化，互联网化是我们企业的夙愿。但金融服务跟其他服务相比也有几个特点:

• 安全，稳定压到一切

• 数据要求强一致

• 重试成本高

• 调用链长，延时高

• 全程可回溯

• 用户操作谨慎

业务场景的这些特点会随着版本演进，逐渐渗透到付钱拉的整体架构设计里面，后面会慢慢展开。

目前付钱拉仍是一个创业公司，从2014年至今付钱拉经历了4次大的技术架构调整。目前仍在中小规模下运作，如果读者您目前的团队跟我们差不多，那我想会有更多共鸣。所以本文有几个适用范围:

处在技术债的积累期。

开发团队几十人。

硬件规模不过百。

服务调用千万级。

起步V1.0阶段

all in one 模式，所有服务都在一起，部署准双机，之所以叫准双机，是因为还略有不同。右边那个webapp里面还有定时任务，上面是网络分发层，下面是DB。是不是很熟悉的感觉?开发框架是Spring+MyBatis。网站前台，管理后台，定时任务，API接口都在一个war里面。所有操作直接打到数据库上，业务和通讯耦合和在一起， 批处理和实时接口也耦合和在一起。

大家看这个很low吧。业务刚起步的时候，逻辑简单，访问量也不高，其实还好。随着公司业务的迅猛发展，几个月后这套架构的不足就体现出来了。比如：

各种模块耦合严重，不能局部扩容。

直接打数据库，IO和CPU都过载。

历史数据沉淀拖慢数据库性能。

发展V2.0阶段

解决V1.0的问题，最简单的方式就是拆应用，加机器，加内存，换SSD。把前台、后台、定时、接口拆成4个应用，独立部署。为了解决数据库性能问题，增加多级缓存。JVM里面的localCache，分布式Redis的上线，大大降低了数据库IO。如果业务稳定了，其实这个架构我们会一直沿用下去。

付钱拉遇到的真实情况是随着业务的迅猛发展，平台的功能模块开始了爆炸式增长。各种需求层出不穷，人手也比较紧张，本着先发展后治理的思路。经过3个月的努力，终于把项目写成了一个大泥球，运行速度越来越慢，新增修改需求也越来越慢，Bug越来越不容易捉，最主要性能也扛不住了。这个时候，不改也不行了。

思考
泥球一定不好吗？如何拆解大泥球？新业务线如何避免写成大泥球？我们总结了一下，有以下几点:

增强业务的理解和抽象

增强团队协作和知识储备

学会挑重点，合理安排优先级

其实如果业务逻辑不是特别复杂，系统对于性能、稳定性要求不是特别高。这套简单实用的架构挺适用于小公司的快速发展的。回头有机会我们把V2.0的架构开源出来，让大家评判一下。

V1.0和V2.0 架构其实没有大多变化，主旋律是拆分解耦和加机器加缓存。这也是目前业界普遍采用的做法。那有没有更好的设计理念？

可以灵活的提高性能；

可以简单的做单元测试；

可以无缝升级新版本；

可以稳步提高开发效率；

我们先看两个非常简单的问题：

假设付钱拉只提供两个API，一个是做加法，客户端给参数a和b，服务端返回a+b。一个是做++1，客户端get，服务端获取最新值+1后返回。

1+1 是一种CPU密集型操作，API主要做计算操作，而且不需要保存状态，这种服务我们叫无状态化的计算型服务。因为没有状态，无线程安全问题，完全可以并发操作。如果顶不住了可以随时加机器解决。

而++1这种呢，需要获取当前的最新值，才可以做+1操作，是一种有状态的服务。这种服务我们叫有状态的IO密集型服务。

++1 还有一个特殊情况，服务线程还需要考虑并发的问题。再考虑上分布式环境下，状态不能单机保存，还需要考虑集中存储的问题。

以上两个例子，是目前付钱拉API的两个典型的场景。

借这个场景来说明有状态无状态，IO密集，计算密集等API设计时的通用问题。那么怎么解决呢？

我们先从程序的结构上说起，API也是一个程序，按照各位大佬书上说的：程序=数据结构+算法。

算法就是1+1的问题，加法就是一个最简单的算法。++1 更多的是一个数据结构的问题，比如使用Redis的Incrby来做累加，因为Redis的单线程模型，分布式存储和线程同步的问题一并解决了。所以比较好的设计思路是把算法和数据结构完全分离。

如果程序不能完全隔离状态，那就把状态（数据结构）托管到专门的状态存储中间件。比如Redis、MySQL等，逻辑和状态从设计和部署上解耦，即所有的服务都是『无状态化的服务』。

基于金融服务要求完全可回溯，再考虑到数据库的并发锁性能问题。更新操作可以理解为先删除再增加，更新操作首先是一个随机IO，定位数据行需要时间。

另外操作也比较复杂，先删后加，更新还会丢失历史版本，比如更新1->2->3，我们只能看到最终结果3，看不到过程1和2了，所以建议用新增替代更新。

所以 把状态理解成版本，版本只能新增累加，如 git svn 等版本控制工具。

新增操作是顺序IO，一直在表的末尾追加，性能优于更新而且新增不会有并发的问题，更新要考虑并发。另外新增可以保存所有的历史版本，例如新增1，2，3，都在表里面。

思考了这么多…..那么新的架构要满足那些条件呢？

服务化V3.0

综上所述，新版的架构应该具备目前比较流行的”微服务”的特质:

模块化

服务化

异步化

简单可调试

全流程跟踪

原生云支持，弹性部署

3.0这个版本 从webapp切换成了微服务架构：

给大家看看我们的事件处理机制：

V3.0是一个基于MQ消息的异步驱动的流程组织引擎，整体的业务流程都是消息驱动，上游处理完毕后，把消息扔给下游就不管了。哪个模块出了异常都可以随时终止流程返回给调用方，如果程序正常执行完毕，最末端的模块负责给调用方响应。

那模块如何响应调用方？调用方在发消息的时候，在报文里面放一个UUID的队列名称。调用方发出消息后，就开始阻塞监听这个UUID的返回队列，各个处理模块都可以给这个UUID队列放消息，调用方收到消息后流程就结束了。我们内部叫”用两个异步的消息，完成一次同步的通讯”。

V3.0 上线后极大的提高了我们的处理性能，弹性局部扩容，异步化等特性也都具备了，终于可以喘一口气了。

差点忘了说了，V3.0重构时我们顺便解决了数据的分库分表问题。

数据库集群分了三个大区:

“在线库”主要做实时交易用，日表操作，只保留最新的7天数据。

“离线库”主要做查重和实时交易统计，数据秒级同步，周表操作，保存半年。

“历史库”主要做BI和数据分析，月表操作，永久保存。

V3.0 稳定了半年多吧，也发现了一些问题，也在逐步的完善。有一些基础的设计理念，针对日益复杂的需求变更，还是有点慢。目前我们的核心业务有一部分还跑在3.0这个架构上。其他大部分业务我们都在V4.0这个框架上了。V3.0和V4.0其实是有不同的适用场景的，不是一个完全的新版本替代关系。

服务化V4.0

V4.0 相对于 V3.0来说，有几个显著的改变：

大家可以对比一些 V3.0的架构图。

增加了控制器队列，主要负责消息的编排，各个具体功能模块执行完毕后。

不需要决定把消息给那个下游模块了，而是直接返回给控制器模块，控制器来决定下一个模块是谁。

控制器模块其实也是一个普通队列可以多点部署防止单点故障。

控制器模块的编排是根据配置文件来做的.配置文件里面定义了一个业务的调用链。

配置文件支持简单的顺序，选择，循环和tryCatch等分支流程。

下面是一个例子：

单看性能参数，3.0的性能大概是4.0 的2.5倍左右，4.0主要用在业务逻辑多变，性能要求不是特别高的场景下。

下面说一下付钱拉的批处理和调度：

我们仿照Hadoop搞了一套调度与批处理，用nas mount网络存储 来替代HDFS实现分布式文件存储。用数据库MySQL来存放调度等meta数据，替代jobtracker。大体一个拉模型，各个任务节点都要主动去MySQL里面轮询任务。

有没有我的任务？

不停的去MySQL里面查…

业务和运维人员可以用sql和我们的工具界面。

操作数据库的记录实现任务的分配 执行 结果反馈.. 重提 .. 可以自动跑批，也可以人工干预。成本不高 但是很简单实用。

这个批处理架构有兴趣的，我们可以单聊，今天就说个架子，不详细展开了。

上面这个PPT说的是数据库的一些设计的基本原则。时间关系也不展开讲了。

原文地址 原文链接

• 整体架构
• 数据采集
• 数据存储与分析
• 数据共享
• 数据应用
• 实时计算
• 任务调度与监控
• 元数据管理
• 总结

一直想整理一下这块内容，既然是漫谈，就想起什么说什么吧。我一直是在互联网行业，就以互联网行业来说。
先大概列一下互联网行业数据仓库、数据平台的用途：

1. 整合公司所有业务数据，建立统一的数据中心；
2. 提供各种报表，有给高层的，有给各个业务的；
3. 为网站运营提供运营上的数据支持，就是通过数据，让运营及时了解网站和产品的运营效果；
4. 为各个业务提供线上或线下的数据支持，成为公司统一的数据交换与提供平台；
5. 分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果；比如广告定向精准投放、用户个性化推荐等；
6. 开发数据产品，直接或间接为公司盈利；
7. 建设开放数据平台，开放公司数据；

上面列出的内容看上去和传统行业数据仓库用途差不多，并且都要求数据仓库/数据平台有很好的稳定性、可靠性；但在互联网行业，除了数据量大之外，越来越多的业务要求时效性，甚至很多是要求实时的 ，另外，互联网行业的业务变化非常快，不可能像传统行业一样，可以使用自顶向下的方法建立数据仓库，一劳永逸，它要求新的业务很快能融入数据仓库中来，老的下线的业务，能很方便的从现有的数据仓库中下线；

其实，互联网行业的数据仓库就是所谓的敏捷数据仓库，不但要求能快速的响应数据，也要求能快速的响应业务；

建设敏捷数据仓库，除了对架构技术上的要求之外，还有一个很重要的方面，就是数据建模，如果一上来就想着建立一套能兼容所有数据和业务的数据模型，那就又回到传统数据仓库的建设上了，很难满足对业务变化的快速响应。应对这种情况，一般是先将核心的持久化的业务进行深度建模（比如：基于网站日志建立的网站统计分析模型和用户浏览轨迹模型；基于公司核心用户数据建立的用户模型），其它的业务一般都采用维度+宽表的方式来建立数据模型。这块是后话。

整体架构

下面的图是我们目前使用的数据平台架构图，其实大多公司应该都差不多：

逻辑上，一般都有数据采集层、数据存储与分析层、数据共享层、数据应用层。可能叫法有所不同，本质上的角色都大同小异。
我们从下往上看：

数据采集

数据采集层的任务就是把数据从各种数据源中采集和存储到数据存储上，期间有可能会做一些简单的清洗。
数据源的种类比较多：

• 网站日志：

作为互联网行业，网站日志占的份额最大，网站日志存储在多台网站日志服务器上，
一般是在每台网站日志服务器上部署flume agent，实时的收集网站日志并存储到HDFS上；

• 业务数据库：

业务数据库的种类也是多种多样，有Mysql、Oracle、SqlServer等，这时候，我们迫切的需要一种能从各种数据库中将数据同步到HDFS上的工具，Sqoop是一种，但是Sqoop太过繁重，而且不管数据量大小，都需要启动MapReduce来执行，而且需要Hadoop集群的每台机器都能访问业务数据库；

应对此场景，淘宝开源的DataX，是一个很好的解决方案（可参考文章 《异构数据源海量数据交换工具-Taobao DataX 下载和使用》），有资源的话，可以基于DataX之上做二次开发，就能非常好的解决，我们目前使用的DataHub也是。当然，Flume通过配置与开发，也可以实时的从数据库中同步数据到HDFS。

• 来自于Ftp/Http的数据源：

有可能一些合作伙伴提供的数据，需要通过Ftp/Http等定时获取，DataX也可以满足该需求；

• 其他数据源：

比如一些手工录入的数据，只需要提供一个接口或小程序，即可完成；

数据存储与分析

毋庸置疑，HDFS是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。

离线数据分析与计算，也就是对实时性要求不高的部分，在我看来，Hive还是首当其冲的选择，丰富的数据类型、内置函数；压缩比非常高的ORC文件存储格式；非常方便的SQL支持，使得Hive在基于结构化数据上的统计分析远远比MapReduce要高效的多，一句SQL可以完成的需求，开发MR可能需要上百行代码；

当然，使用Hadoop框架自然而然也提供了MapReduce接口，如果真的很乐意开发Java，或者对SQL不熟，那么也可以使用MapReduce来做分析与计算；

Spark是这两年非常火的，经过实践，它的性能的确比MapReduce要好很多，而且和Hive、Yarn结合的越来越好，因此，必须支持使用Spark和SparkSQL来做分析和计算。因为已经有Hadoop Yarn，使用Spark其实是非常容易的，不用单独部署Spark集群，关于Spark On Yarn的相关文章，可参考：《Spark On Yarn系列文章》
实时计算部分，后面单独说。

数据共享

这里的数据共享，其实指的是前面数据分析与计算后的结果存放的地方，其实就是关系型数据库和NOSQL数据库；

前面使用Hive、MR、Spark、SparkSQL分析和计算的结果，还是在HDFS上，但大多业务和应用不可能直接从HDFS上获取数据，那么就需要一个数据共享的地方，使得各业务和产品能方便的获取数据；

和数据采集层到HDFS刚好相反，这里需要一个从HDFS将数据同步至其他目标数据源的工具，同样，DataX也可以满足。

另外，一些实时计算的结果数据可能由实时计算模块直接写入数据共享。

数据应用

• 业务产品

业务产品所使用的数据，已经存在于数据共享层，他们直接从数据共享层访问即可；

• 报表

同业务产品，报表所使用的数据，一般也是已经统计汇总好的，存放于数据共享层；

• 即席查询

即席查询的用户有很多，有可能是数据开发人员、网站和产品运营人员、数据分析人员、甚至是部门老大，他们都有即席查询数据的需求；

这种即席查询通常是现有的报表和数据共享层的数据并不能满足他们的需求，需要从数据存储层直接查询。

即席查询一般是通过SQL完成，最大的难度在于响应速度上，使用Hive有点慢，目前我的解决方案是SparkSQL，它的响应速度较Hive快很多，而且能很好的与Hive兼容。

当然，你也可以使用Impala，如果不在乎平台中再多一个框架的话。

• OLAP

目前，很多的OLAP工具不能很好的支持从HDFS上直接获取数据，都是通过将需要的数据同步到关系型数据库中做OLAP，但如果数据量巨大的话，关系型数据库显然不行；

这时候，需要做相应的开发，从HDFS或者HBase中获取数据，完成OLAP的功能；

比如：根据用户在界面上选择的不定的维度和指标，通过开发接口，从HBase中获取数据来展示。

• 其它数据接口

这种接口有通用的，有定制的。比如：一个从Redis中获取用户属性的接口是通用的，所有的业务都可以调用这个接口来获取用户属性。

实时计算

现在业务对数据仓库实时性的需求越来越多，比如：实时的了解网站的整体流量；实时的获取一个广告的曝光和点击；

在海量数据下，依靠传统数据库和传统实现方法基本完成不了，需要的是一种分布式的、高吞吐量的、延时低的、高可靠的实时计算框架；

Storm在这块是比较成熟了，但我选择Spark Streaming，原因很简单，不想多引入一个框架到平台中，另外，Spark Streaming比Storm延时性高那么一点点，那对于我们的需要可以忽略。

我们目前使用Spark Streaming实现了实时的网站流量统计、实时的广告效果统计两块功能。

做法也很简单，由Flume在前端日志服务器上收集网站日志和广告日志，实时的发送给Spark Streaming，由Spark Streaming完成统计，将数据存储至Redis，业务通过访问Redis实时获取。

任务调度与监控

在数据仓库/数据平台中，有各种各样非常多的程序和任务，比如：数据采集任务、数据同步任务、数据分析任务等；

这些任务除了定时调度，还存在非常复杂的任务依赖关系，比如：数据分析任务必须等相应的数据采集任务完成后才能开始；数据同步任务需要等数据分析任务完成后才能开始；

这就需要一个非常完善的任务调度与监控系统，它作为数据仓库/数据平台的中枢，负责调度和监控所有任务的分配与运行。

前面有写过文章，《大数据平台中的任务调度与监控》,这里不再累赘。

元数据管理

这块想要做好，非常复杂，我觉得是且价值小于成本，因此我们暂不考虑这块。目前只有每天任务运行的元数据。

总结

在我看来，架构，并不是技术越多越新越好，而是在可以满足需求的情况下，越简单越稳定越好。目前在我们的数据平台中，开发更多的是关注业务，而不是技术，他们把业务和需求搞清楚了，基本上只需要做简单的SQL开发，然后配置到调度系统就可以了，如果任务异常，会收到告警。这样，可以使更多的资源专注于业务之上。

相关阅读：
大数据平台任务调度与监控系统
Spark On Yarn系列文章
异构数据源海量数据交换工具-Taobao DataX 下载和使用

好了，就这些吧，后面想到了再漫谈吧。码字很累的，希望多多支持我的博客。
转载请注明：lxw的大数据田地 » 大数据环境下互联网行业数据仓库/数据平台的架构之漫谈