“ 来一起认识下大数据的技术框架有哪些，它们分别用于解决哪些问题？它们的内在逻辑和适用场景有哪些？OK，一起去探索下。”     01 —   生态架构   首先，看一下大数据技术体系的整体架构图。根据数据流转的方向，从下而上进行介绍。 在前面，我们了解到，大数据的数据存储是分布式的，而且能够接受任务调度，与传统的数据存储存在差异。所以离线方式处理的数据，需要通过ETL模块，导入到大数据的数据存储系统进行存储；其中Sqoop是常见的抽取结构化数据工具；而Flume和Logstach是用于抽取非结构化、半结构化数据工具。 大数据的数据存储系统，最常见的就是分布式文件系统HDFS；如果需要使用NoSQL数据库功能，HBase是基于HDFS实现的一个分布式NoSQL数据库。   存储起来的数据，使用大数据的通用计算引擎MapReduce或Spark进行计算，这些计算任务会由资源管理框架——Yarn进行调度。将任务分发到数据的存储位置——HDFS中。 但使用通用计算引擎MapReduce或Spark编写处理任务，需要使用特定的语法；这样一来，原有的特定领域的传统业务，进行迁移时就会带来很多问题。比如原有的数据仓库，使用SQL进行数据处理任务，但迁移到大数据平台之后，原来的SQL业务需要全部转换为MapReduce、Spark语法，迁移成本太大。其次，图计算、机器学习等其他领域，在MapReduce、Spark语法基础上，实现起来非常困难，且易用性很差。 于是在通用计算引擎之上，针对不同的领域，诞生了很多提升易用性的产品；以使得对存储在大数据平台上的数据进行数据分析，变得更加容易。 比如在Hadoop生态圈的Hive，它的作用就是将SQL转化成MapReduce任务，减少了数据仓库迁移成本，虽然它的SQL支持率只有60%左右，而且有特定的语法HQL（Hive SQL），但已经极大的简化了结构化数据的处理过程。当然它现在也支持底层计算引擎转换为Spark，以便提升处理性能。 Hadoop生态圈的Pig的功能和Hive类似，但它是将MapReduce封装为自己的API，使用起来比原生的MapReduce更易用一些；在早期，使用的公司较多，现在基本已很少被使用。 Hadoop生态圈的Malhot是机器学习的一个框架，可以完成机器学习的任务，底层将任务转换为MapReduce，从而实现分布式运算。 除了Hadoop生态圈，Spark引擎也有自己的生态圈，其中Spark SQL和Hive功能类似，将SQL转换为Spark任务，提升结构化数据处理的易用性。MLlib提供机器学习的功能，GraphX完成图计算功能，Spark Streaming完成流计算任务。 在架构图中的数据分析层中，有一个产品比较特殊——ElasticSearch，它是用于大数据下的搜索与检索场景的产品。但它是独立运行的，将数据存储于本地磁盘，不依赖于HDFS；有自己的计算引擎，不依赖于MapReduce、Spark。所以，除了在大数据领域，其它很多场景中也能见到它的身影。     02 —   大数据实时流处理 在大数据实时运算这里，半结构化、非结构化数据先通过实时ETL工具，如Flume、Logstash进行数据的实时采集；结构化数据，一般会采用监控数据库预写日志的方式，通过CDC或者OGG等工具进行实时抽取。 实时抽取的数据，首先会进入到消息队列中，完成削弱峰值和解耦合的功能，之后便交于流处理引擎进行处理。常见的流处理引擎有Spark Streaming、Flink。 其中Spark Streaming是将实时处理任务转换为Spark这种离线批处理任务进行处理，它的原理就是将一定时间间隔内的数据，转换为离线批处理任务，只要时间间隔足够短，它就可以近似于实时处理。所以Spark Streaming的处理方式也被称为微批处理模式。 而Flink，它有自己的运算引擎，所以是真正意义上的实时计算，而不需要转换为批处理任务。 数据经过处理之后，最终的结果会被存储到数据库集群中，企业常用的选型是HBase，因为它有一个较好的特性：高并发读，可以满足前端系统结果的实时查询。当然，Druid、Clickhouse也是常用的选型产品。    03 —   分布式协调 大数据的产品，都是分布式架构，以集群的形式部署和运算。于是，分布式集群的管理便成了一个问题，比如节点间的发现、主从的切换等。而Zookeeper，就是为了解决这些问题而存在的，它提供分布式协调服务。 Zookeeper本质上是一个特殊的文件系统，加上消息通知机制，来完成分布式协调。 比如节点间的发现，当某个集群在第一次启动时，假设为Kafka，它会在Zookeeper上的文件系统中创建自己的目录——Kafka。 其中Kafka每个节点启动成功后，假设为Node01，会在Zookeeper上的Kafka目录中注册，即创建自己的节点文件——Node01，Zookeeper检测到Kafka目录创建了Node01，便会通知Kafka中的所有节点，Node01加入到集群中了。 而Node01超过一定时间没有向Zookeeper进行通信，Kafka目录下的Node01文件便会被删除，于是Zookeeper便又会通知所有Kafka节点，Node01节点被移除了。 在很多大数据产品中，都会依赖Zookeeper集群，用于实现分布式协调服务。   04 —   分布式任务调度 大数据分析任务，一般都会有多个产品协同完成，并且存在严格的先后顺序。比如，要完成对当天数据的处理，首先需要通过ETL组件，将数据抽取到HDFS中进行存储，之后再由Hive或Spark SQL将数据接入进行处理，处理完成之后，为了保证前端的查询效率，可能再通过ETL组件将结果表存储到其它数据库中。 其次，大数据任务的执行，如离线数据仓库，一般会选择定时执行；如凌晨零点，对昨天的数据统一进行抽取，并处理计算。 大数据的分布式任务调度组件Azkaban、Oozie就是来完成这些任务的，它们可以完成控制任务的执行顺序、定时执行等功能。 而Azkaban相对Oozie来说，它的功能相对丰富，Web界面也较为美观，在企业选型中比较常见。 看到这里，关于大数据技术体系，你懂了吗？记得关注，下期见！ 编辑于 2021-9-17 15:54

数据仓库诞生的原因有很多，但无非是从两个方面衍生出来的。即数据分析和数据积存。   1、数据分析：企业为了满足数据分析的需要，并且为了避免各个部门自己建立独立的数据抽取系统，导致不同部门在不同时间里从业务数据库中抽取的数据不一致，致使决策失误等问题，从而建立的统一的数据仓库来存放数据，为各个部门提供统一的数据，便于企业做数据分析、辅助决策。     2、数据积存：随着企业业务数据增多，业务数据库累积了大量数据，但时间较为久远的历史数据使用频率很低，且堆积在业务库中导致数据库性能下降。于是希望建立统一的数据仓库，用来积存业务库中的历史数据，减轻业务库的负担。     所以数据仓库的目的是为了用于历史数据的存储和分析计算。     因为这两个原因建立的企业数据仓库，在实现上一般会划分为贴源层、ODS层、数据明细层、数据汇总层、主题模型层5个层级。当然不同企业的架构会有不同的删减。     业务数据库定期通过ETL抽取到数据仓库中，会进入到贴源层，这一层的数据与业务库的数据保持一致，目的是存放业务库的历史数据。一般而言，一天会进行一次数据抽取，存放到贴源层中。贴源层的数据不允许修改，是只读的。但允许数据在ETL的时候（进入贴源层之前）加入一些字段，如更新时间、来源系统、更新类型等。（在保证数据一致的情况下，可以适当增加数据，便于管理）   这里说一下数据更新这个新加入的字段，数据在进入到贴源层时，更新类型这一个字段的值统一为INSERT，表明进入数据是直接新增进来的。如果数据更新后，这一这段的值会变为UPDATE，标志数据是更新后的。   但既然贴源层的数据不允许修改，那何来更新这一说呢？   之前说到，数据仓库的目的之一是为了存储业务数据库的历史数据，帮助业务库减负。既然是减负，那么数据在进入到数仓后，业务库一定会删除相应的历史数据。     历史数据虽然访问的频率不高，但业务中肯定会有查询甚至修改的操作，那这些操作在业务库找不到对应的数据，就会落到数据仓库的贴源层中。   但贴源层数据是只读的，不允许进行数据修改，于是ODS层就出现了，数据仓库中的ODS层的作用就是从贴源层中读取数据，然后进行处理，处理后看情况再放回到贴源层中。     ODS层不用来存储数据，它只是业务与数据仓库的一个接口，用来查询和操作数据仓库的数据。   那么业务中对于历史数据的查询，就可以直接落到ODS中，ODS查询后将结果返回，那业务如果对历史数据的修改也是在ODS中完成的，ODS从贴源层拿到数据，修改后再追加到贴源层中，那么之前数据的更新标志位INSERT，在ODS中将数据修改后，再追加到贴源层中，标志位就会变成UPDATE。   贴源层和ODS层完成了历史数据的存储，减少了业务数据库的数据积存。那还有一个问题待解决-----数据分析。     贴源层中的数据来自不同的业务库，而且可能每个省份都有一个业务数据库。那么这些数据抽取到贴源层之后可能是多张表（一个省份一张），于是需要对数据进行轻度汇总，将多张表进行汇总，然后存储到数据明细层中，完成对数据的初步整理。   数据明细层的数据是不能直接用来分析计算的，因为明细层的数据还是满足三范式的，所以在数据分析的时候性能会比较差，会涉及到大量表的join合并。需要根据分析计算的主题，对明细层的数据进行合并，处理成大宽表后存储到数据汇总层中，为数据分析做准备。   数据汇总层中的数据已经脱离了三范式，完全满足分析计算的需要。于是数据分析任务会落到数据汇总层中进行计算，计算得到的结果会保存到主题模型层中。     主题模型层其实就是我们所说的数据集市。因为数据仓库是为了数据分析而生的，数据存储在数据仓库中直接暴露给前端进行OLTP的查询、处理会对性能造成很大的影响。而且数据仓库本身并不能满足业务的多种需求（并发查询、搜索检索）。   所以数据集市负责对处理后的数据进行存放，满足业务的不同需求，如果是要进行并发查询，那一般会进行预处理计算，并做成CUBE模型，然后存储到HBase中。如果要满足搜索检索业务，那会将结果数据存储到ES中。   数据集市是为业务而生的，提高了业务的查询效率，并满足业务的多种要求，且减轻了数仓的压力。   关于数仓的建设，不同企业有不同的方案，层次的划分也略有不同。在实现上，也会采用多种不同数据库来共同完成数仓搭建。但数仓需要解决的问题和原理是相同的。   对数仓感兴趣的小伙伴，可以看我的免费课程《【入门精讲】数据仓库原理与实战》详细了解！