从0到1搭建大数据平台之数据存储

Posted 2022-12-07 大数据指北

大家好，我是脚丫先生 (o^^o)

近日参加了集团大数据平台之流批一体的建设。

流批一体，从调研直至研发。日日夜夜，泪流满面。

作业以：sql、jar、组件拖拽三种方式去提交实时任务，终究还是攻克。

今天想和小伙伴们，聊一聊大数据平台之数据存储，希望大家喜欢。

一、 前言

我们都知道，采集数据之后，得到数据是原始的和杂乱的，必须经过专门的清洗、 关联、规范化和精心的组织建模，而且要通过数据质量检测后才能进行后续的数据分析或用于提供数据服务，而这就是数据平台构建的关键环节–>数据存储处理

而我们今天要聊的是大数据平台是如何去存储海量数据呢 ？

在之前一期：从0到1搭建大数据平台之开篇

我们聊过，大数据的数据采集并存储的数据流程，如下图所示：

在整个大数据生态圈里，数据存储可以分为两大类：

1、是直接以文件形式存放在分布式文件系统上，处理工具可以直接读写 (Hive 和SparkSQL 都是这类)。

2、通过kafak存储实时数据，经过实时计算框架最后把指标数据利用NoSQL数据库来存储和管理数据(NOSQL数据库Hbase之类)。

二、数据存储的发展

2.1 传统数据存储

互联网时代各种存储框架层出不穷，眼花缭乱，比如传统的OLTP关系型数据库Oracle、mysql。

之前进行业务指标的统计分析都是基于传统的事务型数据库，传统的事务型数据库主要面对单一的业务系统，实现的是面向事务的增删改查。

随着业务的不断发展，产生的海量数据，面对复杂的数据分析指标，单一的事务性数据库已经不能满足数据分析的场景。

最根本的原因在于：数据分析通常需要访问大量的数据，单条数据的分析没有任何意义。 它不仅需要访问大量的数据，还要对其进行频繁的统计和查询。

1、大量访问数据，这些请求占用了大量数据库的资源，严重到影
响生产系统的性能。

2、大量的数据访问通常需要全表扫描，频繁而且通常又是并发地全表扫描会造成事务型数据库响应异常缓慢甚至宕机。

这促使数据仓库概念的出现。

2.2 数据仓库

在 1991 年出版的《Building the Data Warehouse》中，数据仓库之父比尔·恩门（Bill Inmon）首次给出了数据仓库的完整定义，他认为：

数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的，不可修改的数据集合。

1、所谓主题：要把不同业务系统的数据同步到一个统一的数据仓库中，然后按照主题域方式组织数据。主题可以把它理解为数据仓库的一个目录。

2、所谓集成：是指数据仓库中的信息不是从各个业务系统中简单抽取出来的，而是经过一系列加工、整理和汇总的过程，因此数据仓库中的信息是关于整个企业的一致的全局信息。

3、所谓随时间变化：是指数据仓库内的信息并不只是反映企业当前的状态，而是记录了从过去某一时点到当前各个阶段的信息。通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。

简而言之，它综合多个业务系统数据，主要用于历史性、综合性和深层次数据分析。

在了解数据仓库之后，不得不提下经典的两个数仓建模技术。

比尔·恩门（Bill Inmon）和 金博尔（Kimball）

恩门提出的建模方法自顶向下（这里的顶是指数据的来源，在传统数据仓库中，就是各个业务数据库），基于业务中各个实体以及实体之间的关系，构建数据仓库。

举个例子：

在一个最简单的买家购买商品的场景中，按照恩门建模的思维模式，首先你要理清这个业务过程中涉及哪些实体。买家、商品是一个实体，买家购买商品是一个关系。所以，模型设计应该有买家表，商品表，和买家商品交易表三个模型。

金博尔建模与恩门正好相反，是一种自底向上的模型设计方法，从数据分析的需求出发，拆分维度和事实。那么用户、商品就是维度，库存、用户账户余额是事实。

总结这两种数仓建模技术：

这两种方法各有优劣，恩门建模因为是从数据源开始构建，构建成本比较高，适用于应用场景比较固定的业务，比如金融领域，冗余数据少是它的优势。金博尔建模由于是从分析场景出发，适用于变化速度比较快的业务，比如互联网业务。由于现在的业务变化都比较快，所以我更推荐金博尔的建模设计方法。

2.3 数据湖

传统数据仓库，第一次明确了数据分析的应用场景应该用单独的解决方案去实现，不再依赖于业务的数据库。

在模型设计上，提出了数据仓库模型设计的方法论，为后来数据分析的大规模应用奠定了基础。

但是进入互联网时代后，最为重要的两个变化：

1、数据规模前所未有，传统的数据仓库难于扩展，根本无法承担如此规模的海量数据。
2、数据类型变得异构化，不仅有结构化数据，还有半结构化，非结构数据。而传统的数据仓库对数据模型有严格的要求，在数据导入到数据仓库前，数据模型就必须事先定义好，数据必须按照模型设计存储。

因总总的限制，导致传统数据仓库无法支撑互联网时代的数据挖掘。

随着大数据技术普及，数据湖概念被提出。

数据湖（Data Lake）是一个以原始格式存储数据的存储库或系统。

其构建组件基于Hadoop进行存储。

简而言之，数据湖原始数据统一存放在HDFS系统上，引擎以Hadoop和Spark,Flink开源生态为主，存储和计算一体。

通俗总结：数据仓库和数据湖

数据仓库存储结构化数据(先处理后存储)。

数据湖存储原始数据(先存储后处理)。

这里可以用一个做菜的场景做一个类比。以前数据仓库的时候，好比把原材料都加工好了，比如土豆清洗，去皮，切片，这样炒土豆片的时候直接炒就可以了。数据湖的时候呢，直接把土豆存储进来，这样以后想炒土豆片就切片，想炒土豆丝就切丝。增加了灵活性的同时，省去了前期头都处理的费用。

三、 批处理的数据存储

3.1 HDFS分布式文件系统

Hadoop Distributed File System，简称HDFS，是一个分布式文件系统。它是谷歌的Google File System ( GFS）提出之后， Doug Cutting 受Google 启发而开发的一种类GFS 文件系统。

它有一定高度的容错性，而且提供了高吞吐量的数据访问，非常适合大规模数据
集上的应用。

HDFS提供了一个高容错性和高吞吐量的海量数据存储解决方案。

在Hadoop 的整个架构中， HDFS在MapReduce 任务处理过程中提供了对文件操作和存储等的支持， MapReduce 在HDFS基础上实现了任务的分发、跟踪和执行等工作，并收集结果，两者相互作用，共同完成了Hadoop 分布式集群的主要任务。

HDFS分布式文件架构如下所示：

离线数据一般基于HDFS分布式文件系统作为数据仓库。

四、实时处理的数据存储

实时处理的数据为无界流数据，因此分为原数据存储和数据处理后的存储。

4.1 原数据存储

实时数据处理通常还会有从某历史时间点重启以及多个实时任务都要使用同一源头数据的需求，因此通常还会引人消息中间件Kafka来作为缓冲，从而达到实时数据采集和处理的适配。

Kafka是最初由Linkedin公司开发，是一个分布式、可分区、多副本，基于zookeeper协调的分布式消息系统。

场景：在实时数仓中，以 Kafka 为支撑，将所有需要实时处理的相关数据放到 Kafka队列中来实现贴源数据层(ODS)。

4.2 实时处理之后的数据存储

1、HBase的NOSQL数据库

HBase 是一种构建在HDFS 之上的分布式、面向列族的存储系统。 在需要实时读写并随机访问超大规模数据集等场景下， HBase 目前是市场上主流的技术选择。
HBase 技术来源于Google 论文《Bigtable ：一个结构化数据的分布式存储系统》。

如同Bigtable 利用了Google File System 提供的分布式数据存储方式一样， HBase 在HDFS 之上提供了类似于Bigtable 的能力。

HBase解决了传统数据库的单点性能极限。

实际上，传统的数据库解决方案，尤其是关系型数据库也可以通过复制和分区的方法来提高单点性能极限，但这些都是后知后觉的，安装和维护都非常复杂。 而HBase从另一个角度处理伸缩性问题， 即通过线性方式从下到上增加节点来进行扩展。

场景： 对于数据在线服务（即数据使用方传入某个业务ID，然后获取到所有此ID 的相关字段），通常放在HBase内。

2、关系型数据库

实时数据经过实时计算引擎Flink、Spark处理后，可以存储于Mysql或者Oracle等关系型数据库。

场景：对于实时数据大屏，通常放在某种关系数据库（如MySQL）内。

3、 缓存数据库

经过实时计算引擎Flink、Spark处理后的数据，同时也可以存储在Redis里，作为缓存数据。

场景：为了提高性能并减轻对底层数据库的压力，还会使用缓存数据库（如Redis）等。

好了，今天就聊到这里，祝各位终有所成，收获满满！

我是脚丫先生，我们下期见~