数极客首页

为什么选择这样的大数据平台架构?

大数据平台架构的层次划分没啥规范

,以前笔者曾经做过大数据应用规划,也是十分

纠结,由于
应用的分类也是横纵交错

,后来还是觉得表现
一个“能用”准绳
,明晰
且容易了解

,能指导树立

,这里将大数据平台划分为“五横一纵”。当前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大搭数据技术组件,能够

完成
对各类技术组件的透明访问才干

,同时经过
该平台完成
从数据设计、开发到数据销毁的全生命周期管理,并把规范

、质量规则战争

战略
固化在平台上,完成
从事前管理、事中控制和事后稽核、审计的全方位质量管理战争

管理。其它诸如调度管理、元数据管理、质量管理应
然不在话下,由于
管住了开发的源头,数据管理的复杂度会大幅降低。从系统管理的角度看,公司将大数据平台归入
统一的云管理平台管理(私有云),云管理平台包括支持一键部署、增量部署的可视化运维工具、面向多租户的计算资源管控体系(多租户管理、安全

管理、资源管理、负载管理、配额管理以及计量管理)和完善的用户权限管理体系,提供企业级的大数据平台运维管理才干

支撑,当然这么庞大
的目的
要完成
也非一日之功。总结下大数据平台的一些反动
性价值。大数据时期
,大多数企业的架构必然向着散布

式、可扩展及多元化展开

,所谓合久必分,不再有一种技术能包打天下了, 这冲击着传统企业集中化的技术外包方式

,应战
是庞大

的。

大数据及云计算时期
,面多这么多技术组件,要采用一项新的技术,机遇微风
险共存:关于
大数据平台的商业版本,企业面对的是协作
同伴
的效劳
跟不上,由于
展开

太快,关于
开源版本,企业面临的是自身

运维才干

和技术才干

的应战
,关于
自主才干

理论

央求

更高。当前BAT、华为、新型互联网等企业在狼吞虎咽

般的席卷人才, 关于
诸如运营商等大型企业的人才应战
是庞大

的,但同时也包含
着机遇

, 事实上,关于
努力
于搞大数据的人来讲,来运营商等企业搞也是不错的选择,由于
一方面企业在转型,另一方面数据量够大,技术主导的机遇

更多。关于
众多中小型企业来说,缺乏大数据人才,无法开发内部的大数据系统,这时能够

应用一些第三方的大数据软件公司提供的大数据系统,如国内新兴的大数据厂商:数极客就提供了包括用户行为剖析

商业智能剖析

在内的全面的大数据剖析

产品线。

发表评论

评论已关闭。

相关文章