10年大数据平台经验,总结出这份数据建设干货(内含多张架构图)
在业务增长过程中,每个企业不知不觉积累积累了一些数据。无论数据是多是少,企业都希望让“数据说话”,通过对数据的采集、存储、分析、计算最终提供对业务有价值信息。
由此,大数据平台、数据中台等新鲜的概念就真的落地了,其实数据类的概念都是相同的:报表、BI、数据仓库…少了一个都玩不转,只有每一个都做到极致,企业的数据价值才能得到提高。
先来说说背景吧,搭建大数据平台离不开BI。在大数据之前,BI就已经存在很久了,简单把大数据等同于BI,明显是不恰当的。但两者又是紧密关联的,相辅相成的。
BI是达成业务管理的应用工具,没有BI,大数据就没有了价值转化的工具,就无法把数据的价值呈现给用户,也就无法有效地支撑企业经营管理决策;大数据则是基础,没有大数据,BI就失去了存在的基础,没有办法快速、实时、高效地处理数据,支撑应用。
所以,数据的价值发挥,大数据平台的建设,必然是囊括了大数据处理与BI应用分析建设的。
淘宝的大数据平台
滴滴的大数据平台
你可以看到,这些知名大厂的大数据平台真的是大同小异,他们根据各自场景和技术栈的不同,虽然在大数据产品选型和架构细节上略有调整,但整体思路基本上都是一样的。
再来说说数据中台吧,厚平台,大中台,小前台,没有基础厚实笨重的大数据平台,是不可能构建数据能力强大、功能强大的数据中台的。没有大数据中台,要迅速搭建小快灵的小前台也只是理想化的。
数据平台你可以把它看成是数据集,那么数据中台呢他就是数据集API,那么它们之间就差在API这三个字母上,API我想应该不需要过多解释呢,大家都知道,比如学JAVA的时候有了JAVA API你才知道怎么使用,那么数据中台相当于在数据平台的基础上告诉你这些数据怎么使用。
有数据中台之前,我们根本就不清楚表的来源和链路,尤其是一些复杂报表的结果表,来源非常复杂可能涉及到多个系统,涉及十几个源表。等到上游业务表要做变更、都不知道会影响哪些报表,线上已经运行上千个报表了啊!要去揪出这些来实在是麻烦!有了数据中台之后,10秒钟就能解决这个问题。
如果是公司需要进行大数据分析,那么还要研究以下几个问题:
为什么需要搭建大数据分析平台?要解决什么业务问题?需要什么样的分析?数据量有多少?是否有实时分析的需求?是否有BI报表的需求?
这里举一个典型的场景:
公司之前采用Oracle或MySQL搭建的业务数据库,而且有简单的数据分析,或者可能采购了BI系统,就是直接用业务系统数据库进行支持的,现在随着数据量越来越大,那么就需要采用大数据技术进行扩容。
搞清楚需求之后,按照以下的步骤进行:
1、整体方案设计
- 数据量有多少:几百GB?几十TB?数据存储在哪里:存储在MySQL中?Oracle中?
- 分析主题是什么:只有几个简单指标?还是说有很多统计指标,需要专门的人员?
- 是否需要搭建整体数仓?
- 是否需要BI报表:业务人员有无操作BI的能力,或团队组成比较简单,不需要前后端人员投入,使用BI比较方便;
- 是否需要实时计算?
2、组件选型
架构设计完成后就需要组件选型了,这时候最好是比较资深的架构师参与设计,选型包括:
- 离线计算引擎:Hadoop、Spark
- 实时计算引擎:Storm、Flink
- BI软件:FineBI
3、安装部署
选型完成后,就可以进行安装部署了,这部分其实是最简单的,直接按照每个组件的部署要求安装即可。
后文是对数据仓库、大数据平台、数据中台的一些总结性的架构材料,也是对自己这些年来的一些汇总和思考吧,看懂了前面的文字,后面的各种架构图也就无需赘述了。
1、数据仓库硬件架构
2、数据仓库功能架构
3、数据仓库技术架构
4、第一个Hadoop平台硬件架构
主要是为了解决海量离线数据的计算和存储,在Hadoop集群中实现明细数据、汇总数据存储,在mysql中实现报表数据存储。
5、第一个流式处理平台硬件架构
主要是为了解决海量实时数据的流式采集和计算,在Hadoop集群中实现明细数据、汇总数据存储,在mysql中实现报表数据存储;并通过实时事件处理集群实现流式事件的匹配。
6、大数据平台系统规划
对于大数据平台各种软硬件各种组件的规划
7、大数据平台系统定位
8、大数据平台逻辑部署架构
9、大数据平台功能视图
10、大数据平台数据流向
11、大数据平台整体硬件架构
12、数据中台整体架构