大数据整体架构概述

大数据5V特征

volume。数据体量大。
1. 采集数据量大。
2. 存储数据量大。
3. 计算数据量大。
4. TB、PB级别起步。
variety。种类、来源多样化。
1. 种类：结构化、半结构化、非结构化。
2. 来源：日志文本、图片、音频、视频。
value。低价值密度。
1. 信息海量但是价值密度低。
2. 深度复杂的挖掘分析需要机器学习参与。
velocity。速度快。
1. 数据增长速度快。
2. 获取数据速度快。
3. 数据处理速度块。
veracity。数据的质量。
1. 数据的准确性。
2. 数据的可信赖度。

企业数据分析方向

把隐藏在数据背后的信息集中和提炼出来，总结出所研究对象的内在规律，帮助管理者进行有效的判断和决策。

数据分析在企业日常经营分析中主要有三大方向：

现状分析：
1. 分析当下的数据。现阶段的整体情况，各个部分的构成占比、发展、变动。
2. 实时分析。面向当下，分析实时产生的数据。所谓的实时是指从数据产生到数据分析到数据应用的时间间隔很短，可细分秒级、毫秒级。
原因分析
1. 分析过去的数据。某一现状为什么发生，确定原因，做出调整优化。
2. 离线分析。面向过去，面向历史，分析已有数据。在实践维度明显成批次性变化。一周一分析（T+7），一天一分析（T+1)，所以也叫做批处理。
预测分析
1. 结合数据预测未来。结合已有数据预测未来发展趋势。
2. 机器学习。基于历史数据和当下产生的实时数据预测未来发生的事情。侧重于数学算法的运用，如分类、聚类、关联、预测。

数仓的主要特征

面向主题性

集成性

非易失性

时变性

大数据的特点

分布式存储。
分布式资源调度。
分布式计算。

分布式和集群的概念

分布式：多台机器。每台机器上部署不同组件。

集群：多台机器。每台机器上部署相同组件。

数据分析模型

星型模型

雪花模型

星座模型

就是星星模型的组合体

数据仓库分层

数据库与数据仓库区别

功能	数据库	数据仓库
数据范围	当前状态数据	存储历史、完整、反应历史变化数据
数据变化	支持频繁的增删改查操作	可增加、查询，无更新、删除操作
应用场景	面向业务交易流程	面向分析、支持侧重决策分析
处理数据量	频繁、小批次、高并发、低延迟	非频繁、大批量、高吞吐、有延迟
设计理论	遵循数据库三范式、避免冗余	违范式、适当冗余
建模方式	ER实体关系建模（范式建模）	范式建模+维度建模

OLTP、OLAP对比

	OLTP	OLAP
数据源	仅包含当前运行日常业务数据	整合来自多个来源的数据，包括OLTP和外部来源
目的	面向应用、面向业务、支撑事务	面向主题、面向分析、支撑分析决策
焦点	当下	主要面向过去、面向历史，实时数仓除外
任务	读写操作	大量读而很少写操作
响应时间	毫秒	秒、分钟、小时或者天取决于数据量和查询复杂性
数据量	小数据，MB/GB	大数据，TP/PB
主要应用	数据库	数据仓库

OLAP引擎分类

OLAP按存储器的数据存储格式分为MOLAP（Multi-dimensional OLAP）、ROLAP（Relational OLAP）和HOLAP（Hybrid OLAP）。

MOLAP。基于多维数组的存储模型，也是OLAP最初的形态，特点是对数据进行预计算，以空间换效率，明细和聚合数据都保存在cube中。但生成cube需要大量时间和空间。MOLAP可选Kylin、Druid等开源产品。
ROLAP。完全基于关系模型进行存储数据，不需要预计算，按需即时查询。明细和汇总数据都保存在关系型数据库事实表中。
HOLAP。混合模型，细节数据以ROLAP存放，聚合数据以MOLAP存放。这种方式相对灵活，且更加高效。

开源OLAP引擎	优点	缺点	技术融合成本	易用性	使用场景	运维成本	引擎类型
ClickHouse	1.列式存储<br />2.单机性能彪悍<br />3.保留明细数据<br />4.向量化引擎	1.分布式集群在线扩展支持不佳<br />2.运维成本极高	高	非标协议接口	全面	高	纯列存OLAP
Druid	1.实时数据摄入<br />2.列式存储和位图索引<br />3.多租户和高并发	1.OLAP性能分场景表现差异大<br />2.使用门槛高3.仅支持聚合查询	高	非标协议接口	局限	高	MOLAP
TiDB	1.HTAP混合数据库<br />2.同时支持明细和聚合查询<br />3.高度兼容MySQL	1.非列存储<br />2.OLAP能力不足	低	SQL标准	全面	低	纯列存OLAP
Kylin	1.预计算引擎，可以对数据一次聚合多次查询<br />2.支持数据规模超大<br />3.易用性强，支持标准sql<br />4.性能强，查询数据快（预聚合结果）	1.需要依赖Hadoop生态<br />2.仅支持聚合查询<br />3.不支持ad-hoc查询<br />4.不支持join以及对数据的更新	高	SQL标准	局限	高	MOLAP
Doris	1.GoogleMesa+ApacheImpa+ORCFlle/Parquet<br />2.主键更新<br />3.支持RollupTable<br />4.高并发和高吞吐的Ad-hoc查询<br />5.支持聚合+明细数据查询<br />6.无外部系统依赖	成熟度不足	低	兼容MySQL访问协议	全面	低	ROLAP

大数据架构演变

传统离线大数据架构

Lambda架构

Lambda架构缺点：

同样需求需要开发两套一样的代码。
集群资源使用增多。
离线结果和实时结果不一致。
批量计算T+1可能计算不完。
服务器存储大。

Kappa架构

Kappa架构缺点：

Kafka无法支撑海量数据存储。
Kafka无法支持高效的OLAP。
无法复用数据血缘管理体系。
Kafka不支持update/upsert。

湖仓一体实时数仓架构

湖仓一体解决问题：

存储统一。
Kafka存储量小问题。
任意分层都可以OLAP数据分析。
复用同一套相同的血缘关系。
实时数据更新。

公司架构选择

对比项	传统离线大数据架构	Lambda架构	Kappa架构
实时性	离线（无法处理实时业务）	离线+实时	实时（批流一体）
计算资源	只有批处理	批和流同时运行，资源消耗大	只有流处理，资源开销小
重新计算时吞吐量	批处理全量处理，吞吐量大	批处理全量处理，吞吐量大	流式全量处理，吞吐较批处理全量要低一些
开发、测试难度	批处理一套代码，开发、测试、上线难度小	批处理和流处理相同逻辑两条代码，开发、测试、上线难度大	只需实现一套代码，开发、测试、上线难度相对较小
运维成本	维护一套引擎，运维成本小	维护两套引擎，运维成本大	维护一套引擎，运维成本小

这里对3、4情况选择架构存疑，待以后更了解之后补充

网易实时数仓实践

顺丰实时数仓实践

腾讯实时数仓实践

滴滴实时数仓实践

数据计算模型

批式模型（Batch)

批式模型就是使用MapReduce、Hive、Spark等典型的批计算引擎，以小时任务或者天任务的形式来做数据计算。

延迟：小时级延迟或者天级别延迟。这里的延迟不单单指的是定时任务的时间，在数据架构里，这里的延迟时间通常是定时任务间隔时间+一系列以来任务的计算时间+数据平台最终可以展示结果的时间。数据量大、逻辑复杂的情况下，小时任务计算的数据通常真正延迟时间是2~3小时。
数据完成度：数据较为完整。以处理时间为例，小时级别的任务，通常计算的原始数据已包含了小时内的所有数据，所以得到的数据相对较完整。但如果业务需求是事件事件，这里涉及到终端的一些延迟上报机制，在这里，批式计算任务就很难派上用场。
成本：成本很低。只有在做任务计算时，才会占用资源，如果不做任务计算，可以将这部分批式计算资源出让给在线业务使用。从另一个角度来说成本是挺高的，如原始数据做了一些增删改查，数据晚到的情况，那么批式任务是要全量重新计算。

流式模型（Stream）

流式模型，典型的就是使用Flink来进行实时的数据计算。

延迟：很短，甚至是实时。
数据完整度：较差。因为流式引擎不会等到所有数据到齐之后再开始计算，所以有一个watermark的概念，当数据的事件小于watermark时，就会被丢弃，这样是无法对数据完整度有一个绝对的保障。在互联网场景中，流式模型主要用于活动时的数据大盘展示，对数据的完整度要求并不算很高。在大部分场景中，用户需要开发两个程序，一是流式数据生产流式结果，二是批式计算任务，用于次日修复实时结果。
成本：很高。因为流式任务是常驻的，并且对于多流join的场景，通常要借助内存或者数据库来做state的存储，不管是序列化开销，还是和外部组件交互产生的额外IO，在大数据下都是不容忽视的。

增量模型（Incremental）

增量模型，简单来讲，是以mini batch的形式来跑准实时任务。Hudi在增量模型追踪支持了两个最重要的特性：

Upsert：这个主要是解决批式模型中，数据不能插入、更新的问题，有了这个特性，可以往Hive中写入增量数据，而不是每次进行完全的覆盖。（Hudi自身维护了key->file的映射，所以当upsert时很容易找到key对应的文件）
Incremental Query：增量查询，减少计算的原始数据量。以Uber中司机和乘客的数据流Join为例，每次抓取两条数据流中的增量数据进行批式的Join即可，相比流式数据而言，成本要降低几个数量级。