加入收藏 | 设为首页 | 会员中心 | 我要投稿 湘西站长网 (https://www.0743zz.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 大数据 > 正文

阿里的数据分析技术有多强?从优酷的大数据架构中,我学到了这些

发布时间:2022-11-02 16:00:44 所属栏目:大数据 来源:未知
导读: 这些年,互联网热词有很多。大数据绝对排进前三。
就像5G一样,都在说,但都不知道怎么用。大数据也一样。有些数据库从业人员,自己的库1T数据都不到,但在外面说起来,满嘴都是大数据,说

这些年,互联网热词有很多。大数据绝对排进前三。

就像5G一样,都在说,但都不知道怎么用。大数据也一样。有些数据库从业人员,自己的库1T数据都不到,但在外面说起来,满嘴都是大数据,说的自己就跟专家一样。问他,什么是大数据,除了回答,大还是大之外,蹦不出其他词儿。

用概念解释概念,只会越来越模糊。了解大数据最佳途径之一,就是去拆解每个使用它的团队,做成了什么事。不说找100个案例来分析,只要看懂10个,就应该知晓大数据在整个数据团队之中的作用。

我已经拆解了5个,今天拆第6个。优酷的OLAP大数据引擎。前面拆解的美团,搜狐,菜鸟,医院,还有制造业大数据应用,围绕着ETL比较多,而今天的优酷OLAP,更多是在数据分析领域。

据个别自媒体发文,都引用马云的话,说,未来数据分析师会失业,但是我却不这么看。未来人人都必须是数据分析师。

言归正传,优酷这样的视频网站,数据分析类工作,必定是数据团队的重器所在。会员的CRM管理服务,视频播放的性能保障以及广告投放的策略分析,都需要数据分析提供决策依据。

所有的数据团队建设,基本都是业务先行,分层,定标准,定指标体系,数据架构跟上,定主题,定事实指标组合,定流量策略。所以,建设数据仓库的第一要事,就是对业务进行摸底和画像。

大数据 系统 架构_大数据架构_大数据网络安全架构

利用传统的数据仓库技术,为什么不能解决优酷现在遇到的问题?

仅仅从数据量大的角度来分析,原本百万行级数据,进行聚合,比如说要19分钟,通过分库分表或者读写分离,暂时能缓解一部分数据分析压力,但在下一次流量洪峰到来之时,这些架构,就不能100%说可以抵抗住计算需求。

因此大数据架构,优酷需要更优质的方法,来一劳永逸的解决流量暴涨。与其他团队一样,他们需要借鉴其他公司的做法。

其实,国人做技术的,应该反思,为什么 这类解决方法都只能借鉴社区,而不是自研。大数据的发起者,毫无疑问,是谷歌。为什么谷歌会有这样强大的创新力,是值得深思的事。

大数据网络安全架构_大数据 系统 架构_大数据架构

大数据 系统 架构_大数据架构_大数据网络安全架构

优酷借鉴的是 GreenPlum, 一个 MPP 架构的分布式数据库引擎。底层以多个 PostgreSQL 组成。GreenPlum 最大的缺陷,是缺乏对硬件级别的容错。

所有节点都需要参与计算,万一有个别节点故障,本次计算就失败。但优势也很明显,所有节点参与计算,对于即时计算处理,非常有利。

大数据网络安全架构_大数据 系统 架构_大数据架构

大数据网络安全架构_大数据架构_大数据 系统 架构

第二个考察的对象是批处理架构,Map Reduce 和 Spark. 并发是加大了,并不需要所有界都参与计算,将任务节点和计算节点解耦,且任务节点会依据策略,分配不同数据的计算几点。

但Map 与 Reduce 先后的计算顺序,会增加节点之间的通信成本,始终阻碍处理速度的提升。而MR与Spark, 都有个共性的优势,故障容错非常好,且性能可以线性提高。遇到业务高峰,通过增加机器,就能解决。

大数据架构_大数据网络安全架构_大数据 系统 架构

既然,MPP与批处理各自的优势都明显,就融合到一起,对冲各自的劣势。MPP用来即时计算,即分析和实时报表,而批处理架构用来做离线清洗数据。

当然,既然两者架构结合的那么恰到好处,为什么 Greenplum 就不能把底层的 PostgreSQL 换成 HDFS 呢,这样两者就真正的融合,发挥的效能可以达到最高。其实业界也正在做了,MPP On Hadoop.

到了互联网领域,数据量超过一定级别后,多维度计算引擎就会失效。维度建模层面,多维度计算引擎使用的是预计算与存储的方法,就是以空间去换时间。一旦维度模型变了,一切就要重来。这也就是这些多维度计算引擎不灵活的终极原因。

既然不灵活,那么就要考虑替代方法。互联网领域开始了预计算处理的探索,市面上热议的预计算处理引擎有两个:Kylin 和 Druid.

大数据网络安全架构_大数据架构_大数据 系统 架构

Kylin 的功能,是在指定的多维度数据,进行预计算之后,将结果存储到HBase, 比如计算维度A的某个指标M,得到结果后,以KV的形式存储到 HBase. 但分析一项业务,并不仅仅使用维度A,还要兼顾维度B,C,D,这样的维度组合,对Kylin来说,是不堪重负的。

因此 Druid 自带有上卷功能的预计算就比Kylin要先进很多。老读者肯定都知道,之前我克服报表耗时15分钟的技巧,就是简单的SQL重写,使用 Group By Cube 的语法。这里的 Druid就好比 Group By Cube, 对维度进行灵活的交叉聚合,方便业务分析时,因为临时增加维度,而不能有效使用 Kylin。

大数据架构_大数据 系统 架构_大数据网络安全架构

市面上,所有的OLAP技术,基于两套方案实现:

1) MPP 和批处理

2) 预计算

MPP和批处理,会有很多组合,比如之前美团使用的就是Doris, 属于MPP一种。而批处理,Spark, MapR, 都是。预计算,传统的Cube和Kylin就是。

大数据网络安全架构_大数据架构_大数据 系统 架构

事情到这里,还没完。互联网业务之所以复杂,更在于实时性数据处理需求更旺盛。优酷在实时数据分析领域也遇到很多技术瓶颈。以上谈论的方法,应付离线的,准实时的BI报表,数据分析,还绰绰有余,但对于实时的报表就无能为力了。

因此,优酷在实时数据分析上,采用了自研的方法。自研并不是自己研发语言,框架之类的,而是采用开源工具,搭建自己的预计算系统。

当然,实时报表,用商业工具如FineReport也是可以做到的。

(编辑:湘西站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!