项目背景燃气的安全使用直接关系人民群众的生命财产安全和社会的安全稳定，但目前燃气爆炸事故却屡见不鲜。据燃气爆炸公众平台统计，2014年-2016年的全国爆炸事故数据如下图所示，其中仅2016年燃气爆炸事故就有909起，共造成127人死亡、1096人受伤。

从燃气爆炸事故类型分析可以看出，瓶装液化石油气爆炸事故361起，高居爆炸事故数榜首。因此，对燃气泄漏进行监控，特别是小餐饮等企业的瓶装液化气泄漏亟需有效监控。但是，目前燃气监测的实际情况却面临瓶颈：

燃气报警方式单一，主要依靠前端设备的报警声光实施告警，当现场无人时无法了解燃气泄漏情况。 燃气报警未形成体系，仅仅了解单个报警信息，无法形成报警全局态势。 燃气报警管控方式简单，一次报警未及时处理可能就会导致严重后果，亟需构建燃气报警管理机制。　　对此，针对燃气泄漏的监控和燃气工作环境的治理需求，打造了具备燃气泄漏数据上传、数据分析和通知功能，应用现场报警、手机短信、自动拨打电话、手机APP推送等多种保障的“燃气报警云平台”。

燃气报警云平台通过燃气报警传感器结合云技术监测系统，构建前端燃气报警器和中心端大数据云计算支撑平台，建立燃气报警管理体制，为居民区、餐饮企业、地下商场、储藏室等应用场所提供丰富的应用服务、技术支撑、预测预警、辅助决策等功能，帮助减少燃气爆炸事故。

平台架构逻辑架构设计 　“燃气报警云平台”采用“互联网+安全”的思路，着眼于燃气报警大数据相关领域，包括燃气报警大数据的采集、存储、处理、挖掘、展示等，解决方案总体架构如下图所示：

整个架构由四层组成，从下往上依次为：　　数据源：本层是燃气报警数据的采集，包含从前端燃气报警终端上传的报警数据，上报数据通信方式采用NB-IoT。　　云平台层：本层包含解决海量燃气数据存储问题的分布式云存储平台和万物云平台，以及实现IaaS、PaaS甚至SaaS功能的云计算平台等。可以将省、市、区县各级的燃气报警系统部署在统一的云计算平台上，实现业务系统的快速部署上线，实现资源弹性供给，有效降低总体拥有成本。　　大数据层：本层实现了基于数据立方技术的大数据库，基于分布式技术的大数据的挖掘、分析，该层主要对各类数据进行处理分析，为业务应用层提供服务。　　应用层：应用层包括燃气报警系统的门户网站、移动业务、App等。应用层提供了不同角色人员获取燃气报警信息的窗口。　　物理拓扑设计　　整个“燃气报警云平台”是基于云计算分布式架构，利用大数据技术而设计规划，主要包括前端数据采集设备、燃气报警监控云平台和客户端等相关模块，具体架构如下图所示：

“燃气报警云平台”为统一监测平台，平台的数据量会随着时间和平台的不断拓展而逐渐增多，所以要求底层大数据库和存储系统采用云计算分布式架构，以具有优异的横向平滑扩展性;“燃气报警云平台”具有良好的用户体验，支持PC客户端、手机客户端等多终端用户的访问使用。前端设备　　燃气报警云平台前端数据采集采用通过国家强制性产品认证的燃气报警设备——GTII型独立式可燃气体探测器，每当报警灯发出声、光报警，即提示燃气浓度超标。

在燃气报警器的安装过程中，应根据气源性质，选择合适的探测器安装位置对接固定。　　1.天然气、煤气(比空气轻)：建议安装在低于天花板0.3-0.9米，距气源半径1.5米以内。　　2.液化石油气(比空气重)：建议安装在离地面0.3-0.9米，距气源半径1.5米以内。

预警平台燃气报警云平台主要分为PC端和移动端，主要应用功能包括实时监控、设备管理、报警管理、数据统计。　1.实时预警平台支持地图展示功能，标注了平台内所有燃气报警监控点位信息，以不同颜色区分设备的不同状态，蓝色代表设备在线、灰色代表设备离线、红色代表设备报警，并进行日常管理。

当燃气浓度超过阈值时，红色点跳动并发出报警鸣叫，点击报警设备点即可查看该报警设备的基本信息、报警次数、报警时间。同时，业主、街道安全员与运维人员也将收到以短信或电话语音形式发送的通知，第一时间知晓燃气泄露情况。

2.设备管理，管理员通过PC端和移动端，可完成设备的添加、修改和删除等，选择某一具体设备点，将展示该设备的详细信息(设备名、联系方式、设备号、地址)和报警记录。

3.预警管理，管理员可查看所有设备列表信息、报警记录以及报警处理进度，通过平台展示的报警日志信息，可进一步查看报警设备的名称、报警值、时间、手机号、地址等，便于选择报警择处理方式。

4.数据统计与分析，管理员可通过数据统计功能查看当前区域的实时天气状况、常驻户数、商户饭店数、当前区域的报警统计展示，包括区域报警折线图、街道的常驻户数、商户饭店数量、燃气报警次数。选择具体街道，可查看当前街道所有报警记录信息，包括设备名称、阈值、时间、手机号、地址。

运维管理每当前端监控的燃气设备出现异常情况，云平台及时发出告警，第一时间发送短信给业主和街道安全员，发送短信和电话语音通知给公司第一运维人员，第一运维人员收到通知后打开手机APP,查看告警日志，并跟踪此次事件进行处理。

如果在五分钟后，第一运维人员没有接收到此次告警处理信息，也就是未打开APP查看日志，平台会第二次发送短信，电话语音通知给业主、第一运维人员，第二运维人员;任意运维人员接收告警信息并处理此次告警，则告警流程结束。　　若在5分钟内无任何运维人员处理，则平台按照重复以上告警流程，继续在五分钟一次间隔提醒对应人员，直到此次告警有人处理。　　在预警过程中，燃气预警云平台全国运维管理中心将综合统筹各地报警信息，如果某地运维人员没有及时处理，管理中心将同步收到提示，进而督促相关负责人及时处理。　　至此，建立了以前端设备采集实时数据，通过燃气报警云平台及时通知，并由业主、安全员、运维人员共同保障的全局燃气报警管理机制，保障燃气泄露在第一时间得以处理。成功案例　　目前，南京市秦淮区燃气报警器项目一期主要应用于全区12个街道和3个管委会共15个部门管辖内的所有小餐饮场所。该系统包括前端燃气报警器、后端云报警平台、云报警APP等，已经通过秦淮区各级领导以及各街道负责人的视察，同时，经相关部门现场测试，产品的软硬件各项功能均达到项目预期效果。　　当监测到燃气浓度达到或超过报警器预先设定的阈值上限时，报警器会发出报警的蜂鸣声，同时触发后台短信平台发送报警短信通知预先设定的业主、对应社区的安全员、运维人员的手机上，如果以上人员未及时处理，平台也会给相应人员自动拨打语音电话，以确保相关人员及时得知报警信息，尽快妥善处理，解除安全隐患以保障业主的生命财产安全。　　所有设备的安装注册情况、运行情况、燃气报警情况全部写入后端大数据平台，并在PC端、iOS端、安卓端进行安全态势展示。

预期效益经济效益：减少人民群众、商家财产损失　　(1)调整产业结构，促进产业升级　　(2)形成产业集聚效应、催生新型服务产业链　　社会效益：保护生命、社会稳定　　(1)打造安全预警信息云平台，满足人民群众对环境数据的需求　　(2)加速城市信息化基础建设，为智慧城市夯实基础

【IT168资讯】一年一度的中国系统架构师大会震撼来袭了! SACC2017于10月19日-21日在北京新云南皇冠假日酒店盛大召开。今年，大会以“云智未来”为主题，云集国内外顶级专家，诚邀百余名演讲嘉宾，围绕云计算、人工智能、大数据、移动互联网、产业应用等热点领域展开技术探讨与交流。

20日下午，大数据平台架构技术实践(下)专场由爱奇艺云平台技术总监刘俊晖主持，百度外卖大数据首席架构师梁福坤、饿了么资深研发工程师王海华、蘑菇街技术经理刘旭晖(天火)、荣之联架构师王苹、爱奇艺高级技术经理张超和唯品会高级架构师钟翔为大家奉上了一场大数据平台架构技术实践的饕餮盛宴。

基于Druid的大数据采集即计算实践

▲百度外卖大数据首席架构师梁福坤

今天下午的第一位主题演讲嘉宾是梁福坤，百度外卖大数据首席架构师。2014年加入百度，先后带团队建设为百度地图6大Place场景做数据分析，后专注于百度外卖大数据生态从0开始孵化并最终完善。自主研发涉及到数据采集3大平台、开放式ETL4件套、OLAP分析平台、Adhoc、大数据分布式调度、数据集市、数据仓库等，另外技术驱动数十个辅助业务分析角色的分析挖掘平台。为大数据研发打造离线、实时数据整套解决方案，同时构建并推广AI学习平台系统。

今天，他带来了《基于Druid的大数据采集即计算实践》的主题分享，不仅介绍了百度外卖大数据架构，还特别强调了对Druid选型是基于三点考虑：一、是化简为繁采集即计算;二、性能，可扩展，支持高性能，高并发，高吞吐;三、丰富的查询接口。

而冲击波(ShockWave)则作为在Druid基础之上构建的采集即计算的开源项目，主要目的能够实现百度外卖业务场景下预设数据需求规则，可以实现数据的持续、实时的交付。 冲击波除了支持Druid原生态查询API之外，可以通过定义数据源选择、数据分组、数据过滤计算规则下数据指标的聚合运算，同时不同时间频次周期下的入库规则，交付数据支持自定义目的库和数据推送，是一套完整的从数据源接入、计算最终交付的整体解决方案。

饿了么离线大数据平台实践

▲饿了么资深研发工程师王海华

第二位主题演讲嘉宾是王海华，饿了么资深研发工程师。目前在饿了么大数据平台负责大规模Hadoop集群和相关生态系统的维护和研发工作，对常见分布式系统有丰富的实践经验和深入理解，曾经在滴滴负责数千节点规模Hadoop集群的平台研发工作，Apache Hive/Spark/Alluxio代码贡献者。

今天，他带来了《饿了么离线大数据平台实践》的主题分享，他认为饿了么团队的高效工作有益于他们的工作口号——“Everything in 30min”。随着公司业务规模的飞速增长，饿了么离线大数据平台也面临巨大的挑战。在主题演讲中，他主要介绍饿了么离线大数据平台的架构演进、全流程数据化平台运维监控的新思路和平台化服务治理方面面临的问题和一些实践经验。

王海华指出，离线平台治理有3大挑战：如何在分布式环境里快速发现和定位问题？如何把握平台大盘趋势？如何做到用户自助错误/性能分析？而解决办法就是数据化运维。

演讲的最后，他还介绍了团队对数据化治理未来的规划。

大数据平台调度系统架构理论和实践

▲蘑菇街技术经理刘旭晖(天火)

第三位主题演讲嘉宾是刘旭晖(天火)，蘑菇街数据平台资深架构师，负责蘑菇街大数据服务平台整体产品规划和架构设计工作。此前多年供职于Intel开源技术中心，Spark/Hadoop/HBase/Phoenix等开源项目贡献者。在久远历史中，还曾在内核驱动，操作系统中间件，输入法，浏览器等方向有多年开发和开源贡献经验。

他今天带来了《大数据平台调度系统架构理论和实践》的主题分享，他特别强调：“调度系统是大数据系统中非常核心的一块，调度系统有2大类，一个是资源调度系统，一个是作业调度系统，并花费较大的篇幅重点讨论工作流调度系统为什么要这样做，而不是Show我们具体是怎么做。因为怎么做，取决于你的目标。”

在此背景下，他结合蘑菇街自研Jarvis调度系统两年多的思考和实践经验，和大家一起探讨了一个以易用性和可维护性为导向的作业调度系统应该如何规划产品功能定位。

最后，他还指出开源既不是单向输出，也不要奢望别人无偿奉献。要做到这一点，维护者得花费大量的精力去维护社区的氛围。

荣之联大数据平台的应用实践

▲荣之联架构师王苹

第四位主题演讲嘉宾是王苹，荣之联架构师。曾就职于IBM大数据团队，具有多年大数据平台研发经验。目前专注于大数据企业级应用的方案设计及技术选型，同时带领团队研发荣之联大数据产品。

今天带来了《荣之联大数据平台的应用实践》的主题分享，她指出，大数据在ToB和ToC市场的玩法是非常不同的，To B市场必须要有产品去帮助客户，DataZoo被荣之联定位为新一代大数据平台产品,它是基于Hadoop但不仅仅只是Hadoop。并介绍了DataZoo的功能特性及相关案例。

▲DataZoo架构

从DataZoo公布的架构图可以看出，DataZoo将hadoop生态层作为平台的基础层，并集成了开源社区Hadoop、Hive、HBase、 Spark、Zookeeper、Kafka、Flume、 Sqoop等核心项目。

爱奇艺广告大数据实践

▲爱奇艺高级技术经理张超

第五位主题演讲嘉宾是张超，爱奇艺高级技术经理。带领广告前端及数据团队，负责从SDK埋点，数据处理，到查询，可视化，分析应用等整个端到端广告数据体系。

今天带来了《爱奇艺广告大数据实践》的主题分享，爱奇艺广告数据系统需要支持海量数据处理和高维ad hoc分析，同时要保证查询高性能，低延迟以及准确性。本次分享针对以上广告业务数据的挑战，介绍爱奇艺广告数据平台的整体设计及一些实践中的经验。

爱奇艺广告数据应用场景，主要有3个方面：一是查询，能自助查询广告收入分成，订单投放效果，库存使用。二是分析，可视化分析包含（UV转化漏斗，Post-buy人群，N+Reach）；三是发现，主要是异常检测，数据挖掘。

目前，爱奇艺广告数据规模，日均新增百亿级日志，10T+，存储量达PB级别，单表最高40+个维度，3000亿行数据，时间跨度长：需要保存至少2年以上。

唯品会机器学习平台架构实践

▲唯品会高级架构师钟翔

第六位主题演讲嘉宾是钟翔，唯品会高级架构师。曾在Databricks，Intel工作，现主要负责大数据部门机器学习平台的建设工作。

今天带来了《唯品会机器学习平台架构实践》的主题分享，此次演讲介绍了唯品会架构机器学习平台的建设实践。钟翔从问题、思路和方案三个方向为大家讲解了以下五个问题：

建设机器学习平台的动机和想解决的问题;如何基于Notebook架构交互式的快速迭代的开发环境;如何基于容器构建弹性的机器学习集群;如何用Tensorflow和其他技术支持分布式的深度学习;如何架构数据，满足算法共享，数据共享，模型共享的需求。

最后，钟翔指出，唯品会机器学习平台的最高目标是提高生产力和支撑前沿探索系统需求。

▲更多信息尽在IT168现场报道专题 http://sacc.it168/topic2017/

大数据平台架构的层次划分没啥标准，以前笔者曾经做过大数据应用规划，也是非常纠结，因为应用的分类也是横纵交错，后来还是觉得体现一个“能用”原则，清晰且容易理解，能指导建设，这里将大数据平台划分为“五横一纵”。

当前BAT基本公开了其大数据平台架构，从网上也能查询到一些资料，关于大数据平台的各类技术介绍也不少，但在那个机制、那个环境、那个人才、那个薪酬体系下，对于传统企业，可借鉴的东西也是有限的。

技术最终为业务服务，没必要一定要追求先进性，各个企业应根据自己的实际情况去选择自己的技术路径。

与传统的更多从技术的角度来看待大数据平台架构的方式不同，笔者这次，更多的从业务的视角来谈谈关于大数据架构的理解，即更多的会问为什么要采用这个架构，到底能给业务带来多大价值，实践的最终结果是什么。

它不一定具有通用性，但从一定程度讲，这个架构可能比BAT的架构更适应大多数企业的情况，毕竟，大多数企业，数据没到那个份上，也不可能完全自研，商业和开源的结合可能更好一点，权当抛砖引玉。

大数据平台架构的层次划分没啥标准，以前笔者曾经做过大数据应用规划，也是非常纠结，因为应用的分类也是横纵交错，后来还是觉得体现一个“能用”原则，清晰且容易理解，能指导建设，这里将大数据平台划分为“五横一纵”。

具体见下图示例，这张图是比较经典的，也是妥协的结果，跟当前网上很多的大数据架构图都可以作一定的映射。

何谓五横，基本还是根据数据的流向自底向上划分五层，跟传统的数据仓库其实很类似，数据类的系统，概念上还是相通的，分别为数据采集层、数据处理层、数据分析层、数据访问层及应用层。

同时，大数据平台架构跟传统数据仓库有一个不同，就是同一层次，为了满足不同的场景，会采用更多的技术组件，体现百花齐放的特点，这是一个难点。

数据采集层：既包括传统的ETL离线采集、也有实时采集、互联网爬虫解析等等。

数据处理层：根据数据处理场景要求不同，可以划分为HADOOP、MPP、流处理等等。

数据分析层：主要包含了分析引擎，比如数据挖掘、机器学习、 深度学习等。

数据访问层：主要是实现读写分离，将偏向应用的查询等能力与计算能力剥离，包括实时查询、多维查询、常规查询等应用场景。

数据应用层：根据企业的特点不同划分不同类别的应用，比如针对运营商，对内有精准营销、客服投诉、基站分析等，对外有基于位置的客流、基于标签的广告应用等等。

数据管理层：这是一纵，主要是实现数据的管理和运维，它横跨多层，实现统一管理。

1、数据采集层，这是基础。

离线批量采集，采用的是HADOOP，这个已经成为当前流线采集的主流引擎了，基于这个平台，需要部署数据采集应用或工具。

诸如BAT都是自己研发的产品，一般企业，可以采用商用版本，现在这类选择很多，比如华为BDI等等，很多企业技术实力有，但起步的时候往往对于应用场景的理解比较弱，细节做工很差，导致做出来的产品难以达到要求，比如缺乏统计功能等，跟BAT差距很大，传统企业去采购这类产品，要谨慎小心。

一个建议是，当采购产品的时候，除了技术先进性和指标外，更多的应该问问是版本啥时候上线的，是否在哪里成功部署，是否有足够多的客户，如果能做个测试就更好，否则，你就是小白鼠哦，这个坑踩了不少。

能做和做成产品是两个境界的事情，小的互联网企业当然也能做出对于自己好用的采集工具，但它很难抽象并打造出一个真正的产品，BAT自研其实形成了巨大的优势。

实时采集现在也成了大数据平台的标配，估计主流就是FLUME+KAFKA，然后结合流处理+内存数据库吧，这个技术肯定靠谱，但这类开源的东西好是好，但一旦出现问题往往解决周期往往比较长。

除了用FLUME，针对ORACLE数据库的表为了实现实时采集，也可以采用OGG/DSG等技术实现实时的日志采集，可以解决传统数据仓库抽全量表的负荷问题。

爬虫当前也逐渐成为很多企业的采集标配，因为互联网新增数据主要靠它，可以通过网页的解析获取大量的上网信息，什么舆情分析、网站排名啥的，建议每个企业都应该建立企业级的爬虫中心，如果它未在你的大数据平台规划内，可以考虑一下，能拿的数据都不拿，就没什么好说了。

企业级的爬虫中心的建设难度蛮大，因为不仅仅是需要爬虫，还需要建立网址和应用知识库，需要基于网页文本进行中文分词，倒排序及文本挖掘等，这一套下来，挑战很大，当前已经有不少开源组件了，比如solr、lucent、Nutch、ES等等，但要用好它，路漫漫其修远兮。

还有一个就是，如果有可能，笔者建议将数据采集平台升级为数据交换平台，因为其实企业内有大量的数据流动，不仅仅是单向的数据采集，而且有很多数据交换，比如需要从ORACLE倒数据到GBASE，从HBASE倒数据到ASTER等等，对于应用来讲，这个价值很大。

既然数据采集和数据交换有很多功能非常类似，为什么不做整合呢?也便于统一管理，感觉企业的数据交换大量都是应用驱动，接口管理乱七八糟，这也是我的一个建议。

总得来讲，建设大数据采集平台非常不易，从客户的角度讲，至少要达到以下三个要求：

多样化数据采集能力：支持对表、文件、消息等多种数据的实时增量数据采集(使用flume、消息队列、OGG等技术)和批量数据分布式采集等能力(SQOOP、FTP VOER HDFS)，比基于传统ETL性能有量级上的提升，这是根本。

可视化快速配置能力：提供图形化的开发和维护界面，支持图形化拖拽式开发，免代码编写，降低采集难度，每配置一个数据接口耗时很短，以降低人工成本。

统一调度管控能力：实现采集任务的统一调度，可支持Hadoop的多种技术组件(如 MapReduce、Spark 、HIVE)、关系型数据库存储过程、 shell脚本等，支持多种调度策略(时间/接口通知/手工)。

2、数据处理层，现在有个词叫混搭，的确是这样。

Hadoop的HIVE是传统数据仓库的一种分布式替代。应用在传统ETL中的数据的清洗、过滤、转化及直接汇总等场景很适合，数据量越大，它的性价比越高。但目前为止看，其支撑的数据分析场景也是有限的， 简单的离线的海量分析计算是它所擅长的，相对应的，复杂的关联交叉运算其速度很慢。

一定程度讲，比如企业客户统一视图宽表用HIVE做比较低效，因为涉及到多方数据的整合，但不是不可以做，最多慢点嘛，还是要讲究个平衡。

hadoop到了X000台集群的规模也撑不住了,当前很多企业的数据量应该会超过这个数量，除了像阿里等自身有研发能力的企业(比如ODPS)，是否也要走向按照业务拆分Hadoop集群的道路?诸如浙江移动已经拆分了固网、移网、创新等多个hadoop集群。

Hadoop的SPARK的很适合机器学习的迭代，但能否大规模的应用于数据关联分析，能否一定程度替代MPP，还需要实践来验证。

MPP应该来说，是采用分布式架构对于传统数据仓库最好的替代，毕竟其实际上是变了种的关系型数据库，对于SQL提供完整支持，在HIVE做了转化分析后，数据仓库的融合建模用它来做性能绰绰有余，其性价比较传统DB2更好一点，比如经过实用，Gbase30-40台集群就能超过2台顶配的IBM 780。

MPP现在产品很多，很难做优劣判断，但一些实践结果可以说下，GBASE不错，公司很多系统已经在上面跑了，主要还是国产的，技术服务保障相对靠谱，ASTER还有待观望，自带一些算法库是有其一些优势，GreenPlum、Vertica没用过，不好说。

现在有个说法是MPP最终也要被Hadoop那套框架替代，毕竟诸如SPARK啥的都在逐步稳定和成熟，但在短期内，我觉得还是很靠谱的，如果数据仓库要采用渐进的演化方式，MPP的确是很好的选择。

现在诸如中国移动，eBAY等大量公司都在采用这类混搭结构，以适应不同的应用场景，显然是一种自然的选择。

大数据平台的三驾马车，少不了流处理。

对于很多企业来讲，其显然是核武器般的存在，大量的应用场景需要它，因此务必要进行建设，比如在IOE时代不可想象的实时、准实时数据仓库场景，在流处理那里就变得很简单了，以前统计个实时指标，也是很痛苦的事情，当前比如反欺诈实时系统，一天系统就申请部署好了。

只尝试过STORM和IBM STREAM，推荐IBM STREAM，虽然是商业版本，但其处理能力超过STORM不是一点半点，据说STORM也基本不更新了，但其实数据量不大，用啥都可以，从应用的角度讲，诸如IBM这种商业版本，是不错的选择，支撑各类实时应用场景绰绰有余。

流处理集群以流处理技术结合内存数据库，用以实时及准实时数据处理，基于IBM Streams流处理集群承载公司的实时业务：

3、数据分析层，与时俱进吧。

先谈谈语言，R和Python是当前数据挖掘开源领域的一对基友，如果要说取舍，笔者真说不出来，感觉Python更偏向工程一点，比如有对分词啥的直接支撑，R的绘图能力异常强大。但他们原来都以样本统计为主，因此大规模数据的支撑有限。

笔者还是更关注分布式挖掘环境，SPARK是一种选择，建议可以采用SPARK+scala，毕竟SPARK是用scala写的，对很多原生的特性能够快速支持。

TD的MPP数据库ASTER也内嵌了很多算法，应该基于并行架构做了很多优化，似乎也是一种选择，以前做过几度交往圈，速度的确很快，但使用资料屈指可数，还需要老外的支持。

传统的数据挖掘工具也不甘人后，SPSS现在有IBM SPSS Analytic Server，加强了对于大数据hadoop的支撑，业务人员使用反馈还是不错的。

也许未来机器学习也会形成高低搭配，高端用户用spark，低端用户用SPSS，也是要适应不同的应用场景。

深度学习现在渐成潮流，TensorFlow是个选择，公司当前也部署了一套，希望有机会使用，往人工智能方向演进是大势所趋。

无论如何，工具仅仅是工具，最终靠的还是建模工程师驾驭能力。

4、数据开放层，也处在一个战国时代。

有些工程师直接将HIVE作为查询输出，虽然不合理，也体现出计算和查询对于技术能力要求完全不同，即使是查询领域，也需要根据不同的场景，选择不同的技术。

HBASE很好用，基于列存储，查询速度毫秒级，对于一般的百亿级的记录查询那也是能力杠杠的，具有一定的高可用性，我们生产上的详单查询、指标库查询都是很好的应用场景。但读取数据方面只支持通过key或者key范围读取，因此要设计好rowkey。

Redis是K-V数据库，读写速度比HBASE更快，大多时候，HBASE能做的，Redis也能做，但Redis是基于内存的，主要用在key-value 的内存缓存，有丢失数据的可能，当前标签实时查询会用到它，合作过的互联网或广告公司大多采用该技术，但如果数据越来越大，那么，HBASE估计就是唯一的选择了?

另外已经基于IMPALA提供互联网日志的实时在线查询应用，也在尝试在营销平台采用SQLFire和GemFire实现分布式的基于内存的SQL关联分析，虽然速度可以，但也是BUG多多，引入和改造的代价较大。

Kylin当前算是基于hadoop/SPARK的多维分析的杀手级工具，应用的场景非常多，希望有机会使用。

5、数据应用层，百花齐放吧。

每个企业应根据自己的实际规划自己的应用，其实搞应用蓝图很难，大数据架构越上层越不稳定，因为变化太快，以下是运营商对外变现当前阶段还算通用的一张应用规划图，供参考：

6、数据管理层，路漫漫其修远兮

大数据平台的管理有应用管理和系统管理之分，从应用的角度讲，比如我们建立了DACP的可视化管理平台，其能适配11大搭数据技术组件，可以实现对各类技术组件的透明访问能力，同时通过该平台实现从数据设计、开发到数据销毁的全生命周期管理，并把标准、质量规则和安全策略固化在平台上，实现从事前管理、事中控制和事后稽核、审计的全方位质量管理和安全管理。

其它诸如调度管理、元数据管理、质量管理当然不在话下，因为管住了开发的源头，数据管理的复杂度会大幅降低。

从系统管理的角度看，公司将大数据平台纳入统一的云管理平台管理(私有云)，云管理平台包括支持一键部署、增量部署的可视化运维工具、面向多租户的计算资源管控体系(多租户管理、安全管理、资源管理、负载管理、配额管理以及计量管理)和完善的用户权限管理体系，提供企业级的大数据平台运维管理能力支撑，当然这么宏大的目标要实现也非一日之功。

总结下大数据平台的一些革命性价值。

大数据时代，大多数企业的架构必然向着分布式、可扩展及多元化发展，所谓合久必分，不再有一种技术能包打天下了， 这冲击着传统企业集中化的技术外包模式，挑战是巨大的。

大数据及云计算时代，面多这么多技术组件，要采用一项新的技术，机遇和风险共存：

对于大数据平台的商业版本，企业面对的是合作伙伴的服务跟不上，因为发展太快，对于开源版本，企业面临的是自身运维能力和技术能力的挑战，对于自主能力实际要�...

　　在云计算走向成熟之前，我们更应该关注系统云计算架构的细节，从传统的架构到云上大数据，实现了很多的转变。传统的大数据平台计算和数据一般都在一起，到云上之后计算后可能为虚拟机、或容器，存储和计算是分离的。任何计算节点访问存储时都是通过高速互联网络把数据迁移到本地来，实现的优势也就是大数据的服务化，灵活配置。因此，借助强大的计算性能，结合云计算平台的优势，从传统架构的大数据平台向云上数据的转变，将给用户提供更高的灵活性和管理，并能够为用户节省大量的成本。

　　传统IT架构

　　传统的IT环境构建是比较复杂的过程。从安装硬件，配置网络，安装软件，应用，配置存储等，许多环节都需要一定的技术力量储备。当环境发生改变时，整个过程需要重复进行。我们都知道，不同的人安装配置的环境会又很大差异。放在复杂的企业环境来考虑，即使有说明，仍然无法保证环境的一致性。

　　云上架构

　　众所周知，传统服务器包含处理器、存储、网络、电源、风扇等模块设备。与传统服务器相比，云服务器关注的是高性能吞吐量计算能力，关注的是在某段时间内的工作量总和。因此，云服务器在架构上和传统的服务器有着很大的区别。

　　一般来说，企业的云架构搭建主要从6个方面来看，混合云构建、企业级云服务、合规性、安全性、创新性、业务的连续性。以下是阿里云的3个云上经典架构组成供参考：

　　一、云上网络基础架构

　　·自定义私有网络：子网划分，路由规划

　　·网络逻辑隔离：网络虚拟化，VPC之间完全隔离

　　·公网访问：弹性IP接入、SNAT/DNAT网关

　　·混合云构建：物理专线/VPN网关实现云上与数据中心互联

　　·访问控制：安全组实现不同安全域网络隔离

　　二、云上安全基础架构

　　·DDos防护

　　·WEB应用防护

　　·授权与访问控制

　　·审计日志记录威胁检测系统

　　·安全评测和托管服务

　　三、云上同城异地容灾架构

　　同城高可用：自动切换、同城容灾、无需额外成本

　　异地容灾：多地域分布、应用和数据级别容灾

　　优势

　　云服务器体系架构包含云处理器模块、网络处理模块、存储处理模块与系统模块等。这种架构的优势使得云服务器可以大幅提高利用率。采用多个云处理器完成系统设计，引入低功耗管理方案完成对系统的集中冗余管理，同时优化系统设计，去除重复硬件。经过高效的资源整合，提高利用率，从而使得性价比得以提升，引起网站服务器租用价格的降低。

　　云服务器凭借其合理的网站服务器租用价格，为各类企业节省大量的业务成本，从而赢得不少企业的青睐。

　　但是传统IT架构向云上架构过渡时仍免不了面临许许多多的挑战，IT系统的复杂性、总体拥有的成本问题、业务的连续性、现有应用如何改造、遗留系统与资产等等，都是企业要考虑的问题，值此之际，阿里云河南服务中心面向客户举办阿里云中原行·分享沙龙（郑州站）第二期，邀请阿里云资深技术工程师现场答疑，解构阿里云上技术架构解决方案，帮助企业平滑迁云，业务优化。

【IT168评论】随着IT架构的不断演进，云计算必定会成为未来所有IT应用的基石，而大数据作为数据应用分析的基础技术未来将会变的越来越重要，大数据为人工智能提供基础物料，为企业决策者提供数据支撑，但是另一方面大数据的高成本和高门槛也让普通企业望而生畏。

但即便如此，依然无法阻挡不少企业对大数据的追求，但大数据平台选型是一个复杂的过程，因此，知名企业的大数据平台架构图就有着重要的参考作用。

10月19日，一年一度的中国系统架构师大会(SACC)再度盛装来袭。SACC 2017云集了百余位国内外的顶级专家，围绕云计算、人工智能、大数据、移动互联网、产业应用等热点领域进行思维碰撞和技术交流。

就在19日下午的《大数据平台架构技术实践(上)》专场中，来自滴滴大数据平台负责人罗李，知乎大数据平台负责人王雨舟，腾讯云托管hadoop服务平台技术负责人陈龙分别分享了各自所在企业的大数据平台架构图。

▲滴滴大数据体系架构图

▲知乎大数据平台架构图

▲腾讯云大数据平台架构图(EMR)

▲更多信息尽请关注IT168专题报道

自从像AWS这样的公共云产品开辟了大数据分析功能以来，小企业通过挖掘大量的数据做到只有大企业才能做到的事情，至今大约有10年时间。这些事情其中包括网络日志、客户购买记录等，并通过按使需付费的方式提供低成本的商品集群。在这十年中，这些产品蓬勃发展，涵盖了从实时(亚秒级延迟)流媒体式分析到用于分析批量模式工作的企业数据仓库，而企业数据仓库则可能需要数天或数周才能完成。

以下将介绍用于大数据堆栈的五个最有用的架构，以及每个架构的优点，以便更好地理解和权衡。此外，还对成本(按$ - $$$$$的规模)、何时使用、热门产品，以及每种架构的提示和技巧进行了阐述。

五个大数据架构

在此并没有什么特别的顺序，用户在AWS公共云旅程中可能遇到的五个顶级大数据架构是：

流媒体- 允许摄取(并可能分析)任务关键型实时数据，这些数据可能会以爆发的形式出现在用户面前。通用(或特定)的批处理集群—在可扩展、经济高效的集群中提供通用存储和计算功能，可以执行其他四种架构的任何和所有功能。NoSQL引擎 - 使架构师能够处理“3V” —高速度、高容量，以及底层数据的多样性/可变性。企业数据仓库(EDW) - 允许组织为多年的历史数据维护一个单独的数据库，并对该数据运行各种长期运行的分析。就地分析 - 允许用户将数据“就地”保存在低成本存储引擎中，并针对该数据运行高性能的即席查询，而无需创建单独的、昂贵的“集群”。

1. 流媒体

流媒体解决方案由以下多个因素定义：

关键任务数据—即使丢失一笔交易也会给用户带来灾难性的后果。负载中的爆发尖峰——物联网的基础设施可能会从完全无声的状态转变为同时与其通话设备中的一个。实时响应 - 高延迟响应对用户来说可能是灾难性的。

这里有很多现实世界的例子，从特斯拉公司的电动汽车(基本上是移动的4G设备)不断将汽车的位置发送到数据中心，通知司机下一个充电站在哪里。此外，人们喜欢的日本一家高度自动化的寿司专营店：Sushiro。Sushiro所做的是将RFID传感器放在每个寿司盘底，然后，寿司传送带上的传感器跟踪每个盘子的动态，将数据点发送到AWS Kinesis，其后端响应仪表板的更新，通知寿司厨师，例如“丢掉即将过期变质的食物，或者制作更多的鸡蛋寿司，或者解冻更多的金枪鱼”，通过使用流媒体技术，该连锁店不仅有上述的实时效率推荐，而且还可以获得每家餐厅的历史信息，并且可以了解顾客购买的趋势。

Sushiro是一个很好的例子，因为它符合流媒体的所有三个要求。其仪表板现在对业务运营至关重要。

成本：$$ - $$$$$(通常为RAM密集型)适用性：任务关键型数据，负载爆发尖峰，实时响应。用户需要构建KPI的实时仪表板。注意事项：独立的流媒体解决方案的构建和维护成本很高。扩展可能具有挑战性，特别是如果在EC2上构建。失败对企业来说可能是灾难性的，但大多数产品都提供故障保护，例如复制优化、备份和灾难恢复，以避免这种情况。受欢迎的产品：Kinesis(托管服务)，Kafka(基于EC2)，Spark Streaming(作为托管服务和基于EC2)和Storm。提示和技巧：使用Kinesis作为初学者(易于使用、体积小、成本低)。许多组织转向基于EC2的Kafka(如果他们只需要流媒体)或Spark Streaming，以获得更好的控制，并降低大批量成本。这是AWS中为数不多的几次托管任务，像Kinesis这样的托管服务最终会比基于EC2的Kafka解决方案花费更多的费用。

2. 通用(或特定)的批处理集群

使用Hadoop/Spark这些系统，用户可以获得高度可扩展、低成本(商用硬件和开源软件)存储和计算，这些存储和计算可能会遇到大量问题，从而以尽可能低的成本对数据进行批量分析。

Hadoop技术非常成熟，提供了一个非常丰富的软件生态系统，可以利用这些通用计算和存储资源提供从数据仓库到流媒体，甚至NoSQL的所有内容。

在Hadoop之上，现在可以运行Spark，它带有自己的可扩展框架，以低延迟(高内存)方式提供上述所有功能，甚至适用于流媒体和NoSQL。

成本：$ - $$$$(高度依赖于内存需求)适用性：最低成本、最大灵活性。如果希望采用一个集群完成所有任务，并从Hadoop或Spark内部部署转移，那么这是一个不错的选择，非常适合机器学习。注意事项：一个全能的系统很少把每件事都做好，但这可以通过使用Spark和为每个工作量身定制的集群来大大减轻工作负荷。热门产品：EMR(托管服务，也将运行Spark)，Cloudera(基于EC2)，Hortonworks(通过EMR作为托管服务，基于EC2)。提示和技巧：在S3存储桶中长期存储源数据，构建集群，并根据需要将数据加载到集群中，然后在分析任务完成后立即关闭所有数据。这实际上正是默认情况下EMR的工作原理，但即使使用的是Cloudera或Hortonworks(现在功能几乎相同)，也可以轻松编写上述所有内容。利用EC2现场实例可以节省80%-90%的成本，并检查自己的分析，以便可以向上或向下旋转集群。以利用成本最低的spot窗口。

3. NoSQL引擎

Velocity(并发事务)在这里特别重要，这些引擎被设计为处理任意数量的并发读写。虽然其他系统通常不能用于最终用户(需要低延迟响应)和员工分析团队(可能会使用长时间运行的查询锁定多个表)，同时，NoSQL引擎可以扩展以适应一个系统的两个主服务器。一些开发允许以低延迟方式实时加入和查询该数据。

成本：$$ - $$$(通常为内存密集型)适用性：“3V”问题。简单和/或快速变化的数据模型。需要构建KPI的实时仪表板。警告：必须放弃交易和丰富多样的SQL。由于它不使用SQL，因此无法使用Tableau和Microstrategy等可视化工具直接查询数据。扩展(尤其是添加新节点和重新平衡)可能很困难，并且会影响用户延迟和系统可用性。受欢迎的产品：DynamoDB(托管服务)，Neptune(托管服务，目前仍处于测试阶段)，Cassandra(基于EC2)，CouchDB(基于EC2)和HBase(通过EMR作为托管服务，基于EC2)。提示和技巧：努力采用AWS管理的服务DynamoDB，而不是配置EC2并加载第三方系统。定期修剪最终用户DynamoDB表，并在这些历史表上创建每周或每月的表。使用Dynamic DynamoDB“自动调整”配置的容量，使其始终满足消耗。使用DynamoDB Streams可以对客户服务取消等关键事件进行实时响应，或者在第二个区域提供备份。

4. 企业数据仓库(EDW)

企业数据仓库(EDW)与此处提到的其他系统截然不同。它提供了人们称之为“OLAP”(在线分析处理，可以支持来自内部用户的一些长时间运行的查询)与“OLTP”(在线事务处理，可以支持来自最终用户的大量读取和写入)功能，如Oracle的RDBMS或MySQL。当然，可以使用OLTP系统作为企业数据仓库(EDW)，但是大多数人都将OLTP数据库集中在最近用户的低延迟，最近事件(如“跟踪上周的订单”)需求和定期(通常是每天)窗口更旧数据输出到OLAP系统，业务用户可以在数月或数年的数据中运行长时间的查询。

这些OLAP系统使用诸如列式存储、数据非规范化(创建具有几乎无限维度的“数据立方体”)等策略，并提供RDBMS级ANSI 92 SQL依从性，这意味着可以完全访问SQL功能，并且可以定制Tableau等可视化工具直接与他们合作。

成本：$$ - $$$$$(通常需要大量节点来存储和处理大量数据)。适用性：如果希望专门针对业务价值分析数据或构建KPI的实时仪表板。警告：确保团队了解OLAP和OLTP之间的区别，并确保他们以正确的方式使用每个OLAP和OLTP。提示和技巧：与EMR/Hadoop一样，只在需要时启动集群，将源数据保存在S3存储桶中(这实际上是Redshift默认工作的方式)。标记集群，以便用能够以自动方式快速识别和关闭未使用的容量。考虑保留以控制成本。真正了解可用的不同节点类型(高存储、高吞吐量)以便利用每个节点类型。采用本机加密，因为它可以将性能降低多达20%-25%。通过O'Reilly课程深入了解Redshift，或考虑通过出色的“数据仓库”课程进行面对面培训，该课程几乎完全涵盖Redshift。

5. 就地分析

几年前，Presto通过提供高性能的数据分析改变了游戏规则，而无需将数据从原生的、低成本的长期存储中移出。其最终结果是，可以简单地运行查询，而不是必须为昂贵的EMR或Redshift集群支付全部费用。而是只按使用的内容收费。

此外，人们需要很多时间来尝试选择(然后管理)EMR或Redshift集群的正确节点和节点数。采用Presto，人们不再知道也不关心这种差别，而这一切都在用户需要的时候起到作用。

最后，Presto支持RDBMS级别的ANSI-92 SQL兼容性，这意味着所有可视化工具都可以直接使用它，具有的SQL背景可以在ad-hoc查询中全面使用。

费用：$ - $$适用性：成本极低。没有任何管理。可以作为低成本、中等性能的企业数据仓库(EDW)。它不需要将数据复制到第二个系统。大型连接和复杂分析效果很好。警告：需要最低延迟。为了获得不错的性能，可能会使用序列化格式Parquet、压缩、重新分区等重新格式化存储的数据。可能需要多轮查询调整和/或重新格式化才能获得正确的结果。目前不支持UDF或事务。热门产品：AWS Athena(用于查询S3数据的托管服务)，EMR(托管服务-可以自动安装Presto)，自我管理的Presto(基于EC2–用户永远不想在AWS中执行此操作)。提示和技巧：只需使用Athena。利用AWS Glue构建ETL管道，以获取原始数据，并将其重新格式化为S3或Athena可以更有效地使用的内容。使用S3生命周期策略将原有的数据移动到低成本的归档存储(如Glacier)。

把它们放在一起

通过了解将在公共云中运行的五个顶级大数据架构，用户现在可以获得有关最佳应用位置的可操作信息，以及潜伏的位置。

一旦用户开始在AWS公共云中构建大数据架构，将很快了解到更多的架构，并且在很多情况下，企业可能会最终同时使用上述所有内容，可能使用Kinesis将客户数据流媒体传输到DynamoDB和S3。用户可能偶尔会在该源数据上启动EMR(进行某些机器学习)或Redshift(分析KPI)集群，或者可以选择以可以通过AWS Athena就地访问的方式格式化数据，让它像企业数据仓库(EDW)一样发挥作用。

具有执行TMTOWTDI的能力是一件好事，AWS公司努力提供最适合用户需求的服务。如果用户从头开始，在AWS认证的全球知识培训课程中花费三天时间将可以提供满足其需求的服务，并让用户尽快开始运营，并且顺利实施。

作者：Rich Morrow

马总说过这是一个DT的时代，一个从IT到DT转变的时代。确实这几年到处都能听到诸如“云计算”、“大数据”、“上云”的谈论，确实随着云计算的兴起，依托于相对低成本、高稳定性的云设施构建平台的成本越来越低，越来越多的公司都在推数据相关的平台、产品。如阿里、京东、百度、腾讯，以及一些打着大数据旗号的创业公司都有出自己的数据平台和产品，用户依托于平台确实大大降低了数据处理、使用的难度，降低了从数据挖掘价值的时间成本。于此同时，平台架构的变迁也成为备受关注的问题。今天我们就来看看有哪些大数据的平台架构你不知道。

489034603

一、首先是数据方面（大数据时代以数据为主导）：如何进行模型分层？一般模型分层计算程序，以哪种语言为主？

从数据仓库 或 大数据平台 的角度来讲，数据的分层，大体有两种思路：

a) 基础数据层：主要避免后续数据应用层的大变更。一般面向各业务系统或数据源集，利用业界较为先进的数据模型（如FS-LDM），按数据的特性（即数据驱动）进行数据的整合,以形成相对稳定的基础数据模型层。

b) 应用数据层：一般是面向各应用需求 或 业务用户，利用业界较为合理的数据模型理念（如星型\维度模型），按需求的要求（即需求驱动）进行数据的分布，以形成统计方便、展示友好、满足需求的应用数据模型层。

在数据流向 或 数据处理的过程中，所使用到的语言或方式可能更多的是以下两大类：

a) 基于传统数据库：大多采用ETL的方式，进行数据的抽取、清洗、整合；这中间，可能会利用到类似DataStage，Kettle等工具，用得最多的，可能就是各数据库提供的SQL语言了，SQL语言使用简单、方便、学习门槛较低，且易于掌握。

b) 基于大数据平台：大多采用的开源的工具 或 语言，如Hive, Hbase , Spark,Python等。这里面，可能使用更多的是Hive 与 Python， 这两个工具学习简单，易于掌握，并且，进行数据处理时，也更直观、方便。

二、架构方面：在架构过程中，一般以7点展开，如：

a. 存储和计算都基于HIVE；

b. GREENPLUM作为HIVE的“cache”存在，供用户做一些小数据的快查询，报表存储；

c. 调度：和canaan框架进行整合，支持用户快速新增任务，并自动导入任务依赖；

d. 主数据：保存了数据仓库元数据信息，供用户查询和系统内部各个模块交互；

e. ACL：构建了数据仓库数据访问权限控制，包括用户权限申请、审批者审批、数据赋权等；

f. 传输；

g.监控：由于任务数量增长较快（2000+），运维已经是个问题此外，需花了较大精力做了可视化的工作：

有些朋友不认为Hive是一个数据库，认为Hive是一个类似传统数据库的SQL引擎的工具，虽然Hive有自带的元数据存储库，但这个库里面，也只是存放了Hive工具为完成用户提交的请求而必须要的Hadoop的元数据信息 及两者的映射关系数据；并没有存放用户的任何数据，用户的数据还是存放在Hadoop或Hbase等文件系统或数据库中。

在以上这7点中，最难的就是：数据治理 与 系统监控 这两块

三、数据应用：数据一般以哪种形式，呈现给用户？技术上是通过哪些策略实现？

数据应用主要分成两大类：

a) 面向业务人员：一般是自行研发一个界面美观的WEB应用，调用业界成熟的工具（如MSTR,COGNOS)的API，实现数据展示给终端用户进行查看。

b) 面向IT专业人员：一般是直接从数据库/文件系统中，借助SQL或其它的开源工具，直接查询、统计、分析、挖掘；这样会更直接、更方便。

以上这些可供大家测试一下，有哪些知识是自己还不熟练的，可以再学习，个人观点不喜勿喷，谢谢大家。

另外，如果小伙伴想学习大数据技术，可以加下图片下面的交流群，群里有很多学习视频都可以下载，而且每天大数据架构师马士兵老师都会在群里分享大数据的技术。。

大数据的时代已经来临，到底什么是大数据，大数据技术如何和企业运营结合起来？读完本文，你会有新的答案。

本文为青云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 下，�...

随着大数据越来越被重视，数据采集的挑战变的尤为突出。今天为大家介绍几款数据采集平台：

Apache Flume Fluentd Logstash Chukwa Scribe Splunk Forwarder

大数据平台与数据采集

任何完整的大数据平台，一般包括以下的几个过程：

数据采集–>数据存储–>数据处理–>数据展现(可视化，报表和监控)

其中，数据采集是所有数据系统必不可少的，随着大数据越来越被重视，数据采集的挑战也变的尤为突出。这其中包括：

我们今天就来看看当前可用的六款数据采集的产品，重点关注它们是如何做到高可靠，高性能和高扩展。

1、Apache Flume

Flume 是Apache旗下的一款开源、高可靠、高扩展、容易管理、支持客户扩展的数据采集系统。 Flume使用JRuby来构建，所以依赖Java运行环境。

Flume最初是由Cloudera的工程师设计用于合并日志数据的系统，后来逐渐发展用于处理流数据事件。

Flume设计成一个分布式的管道架构，可以看作在数据源和目的地之间有一个Agent的网络，支持数据路由。

每一个agent都由Source，Channel和Sink组成。

Source

Source负责接收输入数据，并将数据写入管道。Flume的Source支持HTTP，JMS，RPC，NetCat，Exec，Spooling Directory。其中Spooling支持监视一个目录或者文件，解析其中新生成的事件。

Channel

Channel 存储，缓存从source到Sink的中间数据。可使用不同的配置来做Channel，例如内存，文件，JDBC等。使用内存性能高但不持久，有可能丢数据。使用文件更可靠，但性能不如内存。

Sink

Sink负责从管道中读出数据并发给下一个Agent或者最终的目的地。Sink支持的不同目的地种类包括：HDFS，HBASE，Solr，ElasticSearch，File，Logger或者其它的Flume Agent。

Flume在source和sink端都使用了transaction机制保证在数据传输中没有数据丢失。

Source上的数据可以复制到不同的通道上。每一个Channel也可以连接不同数量的Sink。这样连接不同配置的Agent就可以组成一个复杂的数据收集网络。通过对agent的配置，可以组成一个路由复杂的数据传输网络。

配置如上图所示的agent结构，Flume支持设置sink的Failover和Load Balance，这样就可以保证即使有一个agent失效的情况下，整个系统仍能正常收集数据。

Flume中传输的内容定义为事件(Event)，事件由Headers(包含元数据，Meta Data)和Payload组成。

Flume提供SDK，可以支持用户定制开发：

Flume客户端负责在事件产生的源头把事件发送给Flume的Agent。客户端通常和产生数据源的应用在同一个进程空间。常见的Flume 客户端有Avro，log4J，syslog和HTTP Post。另外ExecSource支持指定一个本地进程的输出作为Flume的输入。当然很有可能，以上的这些客户端都不能满足需求，用户可以定制的客户端，和已有的FLume的Source进行通信，或者定制实现一种新的Source类型。

同时，用户可以使用Flume的SDK定制Source和Sink。似乎不支持定制的Channel。

2、Fluentd

Fluentd是另一个开源的数据收集框架。Fluentd使用C/Ruby开发，使用JSON文件来统一日志数据。它的可插拔架构，支持各种不同种类和格式的数据源和数据输出。最后它也同时提供了高可靠和很好的扩展性。Treasure Data, Inc 对该产品提供支持和维护。

Fluentd的部署和Flume非常相似：

Fluentd的架构设计和Flume如出一辙：

Fluentd的Input/Buffer/Output非常类似于Flume的Source/Channel/Sink。

Input

Input负责接收数据或者主动抓取数据。支持syslog，http，file tail等。

Buffer

Buffer负责数据获取的性能和可靠性，也有文件或内存等不同类型的Buffer可以配置。

Output

Output负责输出数据到目的地例如文件，AWS S3或者其它的Fluentd。

Fluentd的配置非常方便，如下图：

Fluentd的技术栈如下图：

FLuentd和其插件都是由Ruby开发，MessgaePack提供了JSON的序列化和异步的并行通信RPC机制。

Cool.io是基于libev的事件驱动框架。

FLuentd的扩展性非常好，客户可以自己定制(Ruby)Input/Buffer/Output。

Fluentd从各方面看都很像Flume，区别是使用Ruby开发，Footprint会小一些，但是也带来了跨平台的问题，并不能支持Windows平台。另外采用JSON统一数据/日志格式是它的另一个特点。相对去Flumed，配置也相对简单一些。

3、Logstash

Logstash是著名的开源数据栈ELK (ElasticSearch, Logstash, Kibana)中的那个L。

Logstash用JRuby开发，所有运行时依赖JVM。

Logstash的部署架构如下图，当然这只是一种部署的选项。

一个典型的Logstash的配置如下，包括了Input，filter的Output的设置。

几乎在大部分的情况下ELK作为一个栈是被同时使用的。所有当你的数据系统使用ElasticSearch的情况下，logstash是首选。

4、Chukwa

官网：https://chukwa.apache.org/

Apache Chukwa是apache旗下另一个开源的数据收集平台，它远没有其他几个有名。Chukwa基于Hadoop的HDFS和Map Reduce来构建(显而易见，他用Java来实现)，提供扩展性和可靠性。Chukwa同时提供对数据的展示，分析和监视。很奇怪的是它的上一次 github的更新事7年前。可见该项目应该已经不活跃了。

Chukwa的部署架构如下：

Chukwa的主要单元有：Agent，Collector，DataSink，ArchiveBuilder，Demux等等，看上去相当复杂。由于该项目已经不活跃，我们就不细看了。

5、Scribe

代码托管：https://github/facebookarchive/scribe

Scribe是Facebook开发的数据(日志)收集系统。已经多年不维护，同样的，就不多说了。

6、Splunk Forwarder

以上的所有系统都是开源的。在商业化的大数据平台产品中，Splunk提供完整的数据采金，数据存储，数据分析和处理，以及数据展现的能力。

Splunk是一个分布式的机器数据平台，主要有三个角色：

Search Head负责数据的搜索和处理，提供搜索时的信息抽取。

Indexer负责数据的存储和索引 Forwarder，负责数据的收集，清洗，变形，并发送给Indexer

Splunk内置了对Syslog，TCP/UDP，Spooling的支持，同时，用户可以通过开发 Input和Modular Input的方式来获取特定的数据。在Splunk提供的软件仓库里有很多成熟的数据采集应用，例如AWS，数据库(DBConnect)等等，可以方便的从云或者是数据库中获取数据进入Splunk的数据平台做分析。

这里要注意的是，Search Head和Indexer都支持Cluster的配置，也就是高可用，高扩展的，但是Splunk现在还没有针对Farwarder的Cluster的功能。也就是说如果有一台Farwarder的机器出了故障，数据收集也会随之中断，并不能把正在运行的数据采集任务Failover到其它的 Farwarder上。

总结

我们简单讨论了几种流行的数据收集平台，它们大都提供高可靠和高扩展的数据收集。大多平台都抽象出了输入，输出和中间的缓冲的架构。利用分布式的网络连接，大多数平台都能实现一定程度的扩展性和高可靠性。

其中Flume，Fluentd是两个被使用较多的产品。如果你用ElasticSearch，Logstash也许是首选，因为ELK栈提供了很好的集成。Chukwa和Scribe由于项目的不活跃，不推荐使用。

Splunk作为一个优秀的商业产品，它的数据采集还存在一定的限制，相信Splunk很快会开发出更好的数据收集的解决方案。

【IT168 技术】摘要：通过对数据处理阶段性发展的解析，分析大数据、人工智能技术的发展趋势。结合实际生产需求，验证了基于容器云架构的新一代大数据与人工智能平台在数据分析、处理、挖掘等方面的强大优势。

关键词：大数据 人工智能 云计算 Docker 基础能力 多租户

Abstract：Through analyzing the staged development of data processing, this paper analyzes the development trend of big data and AI technology. According to the requirement of customers, the new generation of big data and AI platform based on Docker Cloud verify the powerful advantages in data analysis, processing, mining and so on.

Key Words：Big data; AI; cloud computing; Docker;basic abilities; Multi-tenant

引言

人工智能、大数据与云计算三者有着密不可分的联系。人工智能从1956年开始发展，在大数据技术出现之前已经发展了数十年，几起几落，但当遇到了大数据与分布式技术的发展，解决了计算力和训练数据量的问题，开始产生巨大的生产价值;同时，大数据技术通过将传统机器学习算法分布式实现，向人工智能领域延伸;此外，随着数据不断汇聚在一个平台，企业大数据基础平台服务各个部门以及分支机构的需求越来越迫切。通过容器技术，在容器云平台上构建大数据与人工智能基础公共能力，结合多租户技术赋能业务部门的方式将人工智能、大数据与云计算进行融合。

数据处理的发展阶段

随着信息技术的蓬勃发展，特别是近十年，移动互联技术的普及，运营商、泛金融、政府、大型央企、大型国企、能源等领域数据量更是呈现几何级数的增长趋势。数据量的膨胀除了带来了数据处理性能的压力外，数据种类的多样性也为数据处理手段提出了新的要求，大量新系统的建设同时产生了众多数据孤岛，给企业的数据运营维护与价值发掘带来了重大的挑战。随着大数据技术的不断发展，企业的数据处理技术转型也经历了几个阶段，如图1所示。

▲图1 企业数据处理转型的阶段变化

在第一阶段，大数据技术发展的早期，为了打破数据孤岛，将各类数据向大数据平台汇集，形成数据湖的概念，作为多源、异构的数据的数据归集，在此基础上进行数据标准化，建立企业数据的汇聚中心。在这个阶段，对非结构化数据处理以存储检索为主，对结构化数据处理提供各类API和少量SQL支持，使海量的以SQL实现为主的业务难以迁移到大数据平台，新业务开发使用门槛高，大数据技术的推广受到阻碍。

在第二阶段，企业客户的需求集中表现为，如何更好地处理结构化数据以及将老的IT架构迁移到分布式架构中。各大数据平台厂商开始在SQL on Hadoop领域进行研发和竞争，不断提高SQL标准的兼容程度。在这个过程中，Spark诞生并逐渐取代了过于笨重且TB量级计算性能存在缺陷的MapReduce架构，Hadoop技术开始向结构化数据处理分析更深度的应用领域进发。随着SQL on Hadoop技术的不断发展与星环科技解决了Hadoop分布式事务的难题，越来越多的客户在Hadoop上构建新一代数据仓库，将Hadoop技术应用于越来越多的业务生产场景，技术门槛的降低，使越来越多的客户可以利用强大的分布式计算能力轻松分析处理海量数据。在这个阶段后期，随着企业客户对实时数据分析研判需求的不断提高，流处理技术得以蓬勃发展。

在第三阶段，一部分企业已经完成了由基于关系型数据库为核心的数据处理体系向基于大数据技术为核心的数据处理体系的转变。在本阶段早期，很多企业客户不满足于通过SQL基于统计对数据的分析和挖掘，促使传统的机器学习算法开始实现分布化，但主要还是针对结构化数据的学习挖掘。随着深度学习技术和分布式技术的碰撞，演化出了新一代的计算框架，如TensorFlow等，计算能力的提升，并结合大量训练数据，使机器学习人工智能技术在结构化与非结构化数据领域产生巨大威力，开始应用于人脸识别、车辆识别、智能客服、无人驾驶等领域;同时，对传统机器学习算法产生了巨大冲击，一定程度上减少了对特征工程与业务领域知识的依赖，降低了机器学习的进入门槛，使人工智能技术得以普及。另一方面，可视化的拖拽页面、丰富的行业模板、高效率的交互式体验，极大地降低了数据分析人员的使用门槛，让人工智能技术进一步走入企业的生产应用。

大数据、人工智能与云技术的融合

随着企业内部对于数据资源的应用不再仅仅局限于IT部门，越来越多的内部项目组与分支机构加入大数据平台的使用中，加之数据处理技术的不断发展，如何解决基础平台的资源隔离问题、管理分配问题、编排调度问题;如何将企业业务应用需要的基础服务能力做更好地抽象，降低应用所需的基础服务的环境搭建、开发、测试部署周期，提升IT支撑效能;如何更好地管理众多的基于大数据与人工智能开发的应用等等成为企业急需解决的问题。

在大数据技术发展的早期，仅仅是在计算框架MapReduce中提供简单的作业调度算法，随着资源管理的需求，在Hadoop 2.0时代，Yarn作为单独组件负责分布式计算框架的资源管理。但是，一方面，Yarn仅仅能够管理调度计算框架的资源;另一方面，资源的管理粒度较为粗放，不能做到有效的资源隔离，越来越不能满足企业客户的需求。

云计算技术作为资源隔离封装虚拟化，以及管理调度的技术，本应应用于解决上述问题。但是，在Docker容器技术被广泛接受之前，云计算虚拟化技术主要基于虚拟机封装资源，并在其之上加载操作系统，资源利用率低，早期有厂商尝试将大数据平台构建在基于虚拟机技术的云化方案上，由于资源利用和稳定性问题，在私有云上的尝试鲜有成功案例。在公有云方面，借助公有云较为强大的基础平台硬件与运维支持能力，有一些非核心业务的应用尝试。

随着Docker、Kubernetes等容器技术的发展，与微服务等技术概念的形成，大数据与人工智能基础平台开始基于容器云构建底层资源管理与调度平台。容器云就像一个分布式的操作系统，将集群中的各类硬件资源进行封装、管理以及调度，将封装的资源作为容器承载大数据的相关组件进程，再将这些容器进行编排，组成一个个的大数据和人工智能的基础服务，如分布式文件系统HDFS、NoSQL数据库Hbase、分布式分析型数据库Inceptor、分布式流处理平台Slipstream、分布式机器学习组件Sophon等。由这些基础服务编排构建公共能力服务层，提供如数据仓库、数据集市、图数据库、全文搜索数据库、流处理服务、NoSQL数据库、机器学习平台服务、定制图像识别服务等，为企业打造全新的数据处理核心系统。基于这一核心系统服务于各类企业的不同部门。通过资源隔离技术，通过对每个租户的资源分配和权限管理，满足业务分析人员的个性化分析需求，专注于业务逻辑的开发和数据的分析挖掘。

技术融合的应用

中国邮政大数据平台建设以Transwarp Data Hub(以下简称TDH)与Transwarp Operating System(以下简称TOS)作为基础架构系统，搭建的新一代逻辑数据仓库和数据集市，完全取代了Teradata和Oracle。

总体架构与实现

中国邮政大数据平台服务于量收、邮务、名址等系统，同时运用容器云TOS实现创新多租户的数据分析挖掘环境。建立从业务层到管理层到决策层的智能分析体系，模拟量化风险和收益，实现对邮政各种业务数据进行分类、管理、统计和分析等功能，给各级管理人员提供各类准确的统计分析预测数据，使其能够及时掌握全面的经营状况，为宏观决策提供支持;为省分公司基层业务人员提供详尽的数据，供其对各自的工作目标、当前和历史状况进行准确的把握，对业务活动进行有效支撑，满足邮政经营分析管理及决策支持。

中国邮政大数据平台以五大基础服务集群域为基础，分别是数据湖集群域、企业数据仓库集群域、省分服务集群域、机器学习实验室集群域、开发/测试/培训集群域。

(1)数据湖集群域：基于TDH平台搭建的数据湖，主要承担多源异构的数据归集，数据湖内包括：原始数据池、清洗加工数据池、整合加工数据池等。

(2)企业数仓集群域：基于TDH搭架的数据仓库集群，基于大数据创新搭架逻辑数据仓库，用于迁移改造原有基于Teradata搭架的数据仓库，数据集市和基于Oracle搭建的报刊集市的邮政量收管理系统。

(3)省分服务集群域：基于TOS搭建容器化多租户数据分析平台云。为省、市分公司开发人员和业务人员提供省分多租户的平台环境，集团分发数据与自有数据存储计算，自有应用的开发与管理，独立租户使用运行。

(4)机器学习实验室集群域：基于TOS搭建的容器化多租户大数据机器学习平台，为集团数据中心分析师提供多租户的开发实验环境平台，进行数据探查、业务建模、算法研究、应用开发、成果推广等。

(5)开发/测试/培训集群域：为应用开发人员、系统测试人员、培训师、学员提供多租户的大数据与机器学习平台，为开发商及内部单位提供开发测试培训服务。

以此为基础，达到了数据管理、服务管理、运维管控、安全管控四个维度的统一。在风险管控、决策支持、服务支撑、流程优化、品牌创新、交叉营销六大应用领域展开应用。实现了租户管理、数据治理、数据加工、数据挖掘、数据探索、数据展现六大平台功能。

数据湖和数据仓库基于TDH构建，将包括业务系统数据、实时流数据、合作单位数据、互联网数据等不同数据源，通过ESB接入、ETL工具、Kafka、Sqoop、文本上传、人工接入等方式，统一汇聚进入数据湖。加工后获得的数据资产发布到数据资产目录，通过数据资产目录的构建TDH与TOS用户间数据交互体系。便于用户快速检索数据，通过数据资产目录实现对数据的集成、融合、安全、共享。数据资产目录包括：元数据、主数据、数据安全、数据标准、数据质量、数据轮廓、数据生命周期等。此外，企业用户通过大数据门户按需申请租户存储计算资源、数据资源、审批流程通过后，集群资源管理员按需快速部署集群，自动化将数据从数据湖加载入数据分析集群或省分集群对应的租户空间，供数据开发人员使用。数据开发人员会将数据应用成果固化到数据湖内，对外提供数据服务。

数据仓库与数据集市的完整迁移

中国邮政大数据平台是全球首个采用Hadoop(TDH)技术完全取代Teradata和Oracle的混合架构搭建新一代逻辑数据仓库和数据集市的系统。

原量收系统使用Teradata的数据仓库和Oracle的数据库，数据使用空间目前已接近30TB，现有使用用户约5万人，提供近约900张报表的灵活查询，单日报表查询频次最高能达到40万次，月初高峰查询需支持约2000计算查询并发。

通过项目前期大量调研准备工作，制定了切实可行的项目实施方案。量收管理系统的总体架构、ESB、BI工具、ETL工具、调度工具、门户等都保持不变，仅将原量收系统的数据仓库和数据集市，使用大数据平台进行完全替换，降低了整个迁移风险。

整个迁移过程中，包括环境部署、模型迁移改造、接口迁移改造、数据迁移、ETL迁移改造、报表迁移改造、数据核对、性能优化、业务应用迁移、风险控制，系统测试等。例如模型迁移改造，不改变原有业务逻辑，只需对接口层模型，基础层模型、汇总层模型进行轻度改造。对于模型改造来说，系统基础层模型结构相对复杂，关联度相对较高，原系统使用Teradata数据库。TDH全面兼容Teradata的数据类型与SQL方言，降低了迁移成本。同时迁移完成后，性能大幅提升，见图2。

▲图2 迁移前后数据集市业务场景500并发测试性能对比

基于容器云的大数据与机器学习平台的全面应用

基于TOS实现的多租户新模式，将大数据与机器学习平台组件完全容器化实现，并在TOS提供能力服务。集团统一部署企业内部云平台，对邮政各个租户(集团、省分、市局等)动态分配存储、计算、网络等资源，并实现完整的资源隔离，使得各个租户数据分析人员和业务人员获得相对独立的资源环境，赋能业务创新，同时可动态调配资源，实现资源的共享优势。

集团、省分、市局各级人员通过多租户平台，实现资源发布、申请，使用及应用开发、成果推广。通过项目立项申请审批后，省分项目组人员在租户空间内，接入访问数据资源，使用平台服务资源，大数据分析工具及机器学习挖掘工具展开数据分析挖掘工作，具体开展数据处理、模型开发、算法应用、应用发布等，在审批验收之后，将成果推广到数据湖上部署对全集团提供数据应用服务。

通过TOS+TDH搭架厚平台、薄应用的微服务架构，实现租户之间的异构性、独立测试与部署、资源按需伸缩、高性能计算能力、租户间错误问题隔离、团队全功能化。实现数据资产化管理。面对集团数据多样、海量、跨板块、跨专业的需求，集团对数据进行了全面梳理，创新集成各版块、专业数据，创建数据资产目录便于快速检索获取资产，管控治理资产，让数据即资产从理论阶段上升到实现阶段。

结语

随着企业数据处理与服务需求的不断发展，由大数据的汇聚，分布式技术释放计算能力开始，技术不断延伸发展，大数据、人工智能与云计算的边界越来越模糊，�...