大数据 从为什么开始
问题
- Java Web中日志数据存储在哪里?
- 如何统计歌曲实时热度和歌手实时热度?
- 点播日志中没有歌手信息怎么办?
- 使用vue开发web平台实时展示结果?
- 实时点播数展示一直轮询数据库?数据量、大效率低怎么办?
场景(Java Web为什么需要大数据?)
场景一:数据存储有瓶颈
抖音平台:点赞,评论、私信、广告、浏览记录、商品数据、交易记录…
场景二:数据计算有瓶颈
电影网站:榜单
场景三:实时场景计算瓶颈
实时交易数据,实时人数统计
场景四:数据挖掘瓶颈
京东、淘宝、当当商品推荐如何解决?
如何构建大数据平台?
每个大数据公司构建大数据平台是最重要的一环
*构建数据仓库平台*
范式建模与ER实体关系模型
三范式
- 第一范式:原子性,字段不可再分
- 第二范式:唯一性,有主键,非主键字段依赖于主键
- 第三范式:非主键字段不能相互依赖
ER:Entity-Relationship实体关系模式
数据库设计的理论基础
实体 属性 关系
为什么要构建数据仓库?
构建数据仓库仅仅是因为数据量大,MySQL存储不下吗?
- 数据存储在互不兼容的系统中
数据孤岛(各个系统数据库 可能不同) - 关系型数据库一般不存储日志数据
漏斗分析(如何更好地服务用户) - 决策者需要从商业角度观察数据,关系型数据库不适合
数据仓库 Data Warehouse -DW
数据仓库是面向主题的、集成的(非简单的数据堆积)、相对稳定的、反映历史变化的数据集合,数仓中得数据是有组织有结构的存储数据集合,用于对管理决策过程的支持
数据仓库发展历史
-
萌芽阶段(1978-1988年)
将业务处理系统和分析系统分开 -
探索阶段(1988年)
DEC公司提出TA2规范,定义分析系统四个部分:
数据获取、数据访问、目录和用户服务 -
雏形阶段(1988年)
IBM,信息仓库,数据抽取、转正、有效性验证、加载、Cube开发, -
确立阶段(1991年)
- 比尔·恩门,范式建模 “数据仓库之父”
自上而下
- 拉尔夫·金博尔,维度建模(解决范式建模,分析效率高)
自下而上
- 比尔·恩门,范式建模 “数据仓库之父”
-
争吵与混乱(1996-1997年)
-
合并(1998-2001年)
比尔·恩门 提出CIF架构:数据分层,不同层采用不同建模方式
维度建模
拉尔夫·金博尔派 提出拉维度建模,维度建模主要面向分析场景
维度表:对维度列的解释说明
维度列:一些外键列(有对应维度表)
事实表: 维度列和度量列(一些数据列)
(1)星型模型
缺点:维度表中可能存在字段冗余
优点:通过一次关联查出数据,效率高
(2)雪花模型
缺点: 需要多次连表,效率低
优点:更符合三范式
雪花模型与星型模型对比:
星型模型违反三范式,雪花模型范式建模
星型模型数据分析效率比雪花模型高
企业级数仓构建使用星型模型和星座模型(在星型模型的维度表中再关联事实表)居多
优先选择星型模型
企业级数据仓库分层设计
CIF架构
分层好处
案例
大数据技术栈
-
架构底层核心技能
JVM
多线程&高并发
网络通信IO -
数据采集体系技术
- 离线
SQOOP
DataX
Kettle - 实时
Flume
Maxwell
Canal
Nifi
- 离线
-
中间件技术
分布式协调服务zookeeper
分布式缓存 Redis
分布式消息系统Kafka
分布式消息系统Pulsar
数据分析ELK Stack -
分布式存储技术
分布式文件系统HDFS
分布式数据库HBase
分布式数据仓库Hive
数据湖技术Hudi
数据湖技术Delta lack
数据湖技术 Iceberg -
数据处理技术
分布式计算框架MapReduce
分布式计算框架Spark
分布式计算框架Flink -
OLAP生态体系
OLAP-Kylin
OLAP-Presto
OLAP-Druid
OLAP-Impala
OLAP-ClickHouse
OLAP-Phoenix
OLAP-Kudu
OLAP-Doris -
稳健架构设计
离线数仓构建方法论
实时数仓构建方法论
数据治理-数据质量管理
数据治理-元数据管理
数据治理-数据安全管理
kerberos
数据中台构建方法论
可视化:TCV,Superset -
集群调度
分布式集群调度框架Yarn
任务流调度oozie
Azkaban
Airflow
集群管理平台 clodera Manager
Ambari -
数据挖掘体系相关
python
多元线性回归
贝叶斯算法
KNN算法
KMeans算法
TF—IDF
逻辑回归
决策树
随机森林 -
岗位
三大岗位:数仓开发、数据挖掘、平台开发大数据ETL开发
大数据离线数仓开发
大数据实时数仓开发
大数据接口开发
大数据业务分析开发
数据库与数据仓库的区别
数据库OLTP & 数据仓库OLAP
大数据架构演变之路
- 离线大数据架构
- Lambda架构(离线处理+实时链路)-传统实时开发
- Lambda架构(离线数仓+实时数仓)
Lambda架构缺点:
- 同样需求需要开发两套一样的代码
- 集群资源使用增多
- 离线结果和实时结果不一致
- 批量计算T+1可能计算不完
- 服务器存储大
- Kappa架构
Kappa架构缺点:
- Kafka无法支撑海量数据存储
- Kafka无法支持高效的OLAP
- 无法复用数据血缘管理体系(链路)
- Kafka不支持update/upsert
架构选择
- 公司刚上大数据或者公司业务没有实时场景
传统离线大数据架构 - 公司离线业务多,实时业务少
- 离线数仓+实时链路的Lambda架构
- 公司离线业务和实时业务多比较多
离线数仓+实时数仓的Lambda架构 - 公司实时业务多,离线相对较少
Kappa纯实时数仓架构
绝大多数公司采用Lambda架构
互联网公司实时业务多混合架构
绝大多数实时业务采用Kappa架构,关键核心业务使用离线全量计算方式(Lambda)
批流一体
- 架构角度
- 计算框架处理角度
- SQL支持角度
- 存储层面 —> 数据湖
湖仓一体实时数仓架构
优点:
- 存储统一
- Kafka存储量小问题
- 任意分层都可以OLAP数据分析
- 复用同一套相同的血缘关系
- 实时数据更新
实践