BigData导论

发展历史

• 2004年，Google三驾马车，分布式文件系统GFS、大数据分布式计算框架MapReduce、NoSQL数据库系统BigTable
• 2006年，Doug Cutting（lucene的作者）根据论文原理初步实现了类似GFS和MapReduce的功能，开发出了Hadoop,包括分布式文件系统HDFS和大数据计算引擎MapReduce，Hadoop 1.0 大数据时代
• 2008年，Hadoop正式成为Apache的顶级项目，后来Doug Cutting本人也成为了Apache基金会的主席。自此，Hadoop作为软件开发领域的一颗明星冉冉升起,同年，专门运营Hadoop的商业公司Cloudera成立，Hadoop得到进一步的商业支持，发布CDH。
• 2012年，UC伯克利AMP实验室（Algorithms、Machine和People的缩写）开发的Spark开始崭露头角，同时YARN正式发布，Spark的商业化公司Databricks成立，Hadoop 2.0 计算和调度分离时代
• 2014年，由 3 所地处柏林的大学和欧洲的一些其他的大学共同进行的研究项目Stratosphere捐献给了 Apache 软件基金会，随后被更名为Flink，创始团队中的许多成员离开大学并创办了一个公司来实现 Flink 的商业化，他们为这个公司取名为 Data Artisans。2019 年阿里巴巴确认收购 德国初创企业 Data Artisan
• 2017年，Hadoop 3.0发布，基于CloudNative，向着容器化和AI方向演进，Hadoop 3.0 云原生时代，以获得统一运维、资源池化等方面的管理目的
• 2019年，Hudi、DeltaLake、Iceberg发布，标志大数据迈向湖仓一体的时代，做到数据中心化，分析多样化
• 2020年，Ozone发布，可以使用公有云对象存储，拥抱cloud和对象存储
• 2021年，Submarine， Ratis相继发布，人工智能和基于Raft的集群协议
  搜索和三大社交公司（Yahoop[Hadoop] FackeBook[Hive,Prestoe] Twitter[Storm] LinkIn[Kafka] ）支撑起大数据的发展

商业化

国外

1）Apache：运维麻烦，组件间兼容性需要自己调研。（一般大厂使用，技术实力雄厚，有专业的运维人员）
2）CDH：国内使用最多的版本，但 CM不开源，但其实对中、小公司使用来说没有影响（建议使用）
3）HDP：开源，可以进行二次开发，但是没有CDH稳定，国内使用较少

国内

1）TDH：星环科技发布的大数据版本，既有开源版本，也又商业化版本
2）FusionInsight：华为发布的大数据版本
3）等都是基于Hadoop体系，封装更多的开源组件，形成整体套件

组件简介

存储引擎

存储引擎包括文件存储系统，对象存储系统

• HDFS：（Hadoop Distribute File System）Hadoop体系基石，基于Google的GFS开发的分布式文件系统，Java语言，Yahoo主导。
• **Ozone：**基于HDFS的第二代文件存储系统，着力解决超大规模集群下，HDFS的GC和元数据风暴问题，Java语言，腾讯主导。
• **Min IO：**轻量级的对象存储服务，使用go语言开发。
• **Ceph：**Redhat提供的对象存储引擎

缓存引擎

• **Alluxio：**智能缓存加速系统，QueryEngine 与大数据集群的缓存中间件。通过暂时将数据存储在内存或其它接近计算服务所属介质中的方法, 起到加速访问并提供远程存储本地化提升性能的能力，实现数据冷热分离，Java语言，Alluxio主导。
• **JuiceFS：**待了解
• **Fluid：**将缓存层和K8S桥接起来，待了解

计算引擎

• 大数据离线计算：像MapReduce、Spark这类计算框架处理的业务场景都被称作批处理计算，因为它们通常针对以“天”为单位产生的数据进行一次计算， 这中间计算需要花费的时间大概是几十分钟甚至更长的时间。非在线得到的实时数据
• 大数据实时计算：对实时产生的大量数据进行即时计算，这类计算称为大数据流计算，相应地，有Storm、Flink、Spark-Streaming等流计算框架来满足此类大数据应用的场景。 流式计算要处理的数据是实时在线产生的数据。应用实时智能推荐，实时报表分析，实时监控场景

相关组件包括

• **MapReduce：**Hadoop系统中第一代分布式计算框架，将分布式计算分为Map和Reduce两个阶段，自身实现Shuffle功能，Java语言，Yahoo主导，目前已基本处于淘汰状态。
• **Storm：**Storm 开发者无需再关注数据的流转、消息的处理和消费，只要编程开发好数据处理的逻辑bolt和数据源的逻辑spout，以及它们之间的拓扑逻辑关系toplogy，提交到Storm上运行就可以了。？
• **Spark：**MapReduce进行机器学习计算的时候性能非常差，因为机器学习算法通常需要进行很多次的迭代计算，而MapReduce每执行一次Map和Reduce计算都需要重新启动一次作业，带来大量的无谓消耗，而且Spark支持Yarn和HDFS，公司迁移到Spark上的成本很小，于是很快，越来越多的公司用Spark代替MapReduce。Scala语言，Databricks主导。
• **Flink：**可以同时支持流式计算和批处理计算。Java语言，阿里主导。

调度引擎

• Yarn：（Yet Another Resource Negotiator）将MapReduce执行引擎和资源调度分离开来，这就是Yarn，2012年，Yarn成为一个独立的项目开始运营，随后被各类大数据产品支持，成为大数据平台上最主流的资源调度系统。Yarn基于Container进行资源调度。Java语言，依赖开源。

• **Kubernetes：**俗称K8S，容器的编排引擎，云原生中编排引擎的事实标准，还有Docker公司开发Docker Swarm编排引擎。Go语言，Google主导。

分析引擎

大数据使用场景主要包括：数据分析和人工智能

• 数据分析：主要使用Hive、Spark SQL等SQL引擎完成

• 人工智能：数据挖掘与机器学习则有专门的机器学习框架TensorFlow（Google）、Caffe2（Facebook）、Pytorch（Facebook）、Mahout以及MLlib等，内置了主要的机器学习和数据挖掘算法。

分析主要通过SQL、AI框架已经NoSQL语言进行处理，包括OLTP（On-line Transaction processing 大数据中很少使用），OLAP（On-Line Analytical Processing），NoSQL（Not Only SQL）引擎，AI&BI（Artificial Intelligence/Business Inteligence）

OLAP引擎

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

• **MOLAP ：**基于多维数组的存储模型，也是OLAP最初的形态，特点是对数据进行预计算，以空间换效率，明细和聚合数据都保存在cube中。但生成cube需要大量时间和空间。可选Kylin、Druid等

• **ROLAP ：**完全基于关系模型进行存储数据，不需要预计算，按需即时查询。明细和汇总数据都保存在关系型数据库事实表中。可选Presto、impala等

• **HOLAP ：**混合模型，细节数据以ROLAP存放，聚合数据以MOLAP存放。这种方式相对灵活，且更加高效。可按企业业务场景和粒度进行取舍，没有最好，只有最适合

按照查询类型划分，OLAP一般分为即席查询和固化查询

• **即席查询：**通过手写sql完成一些临时的数据分析需求，这类sql形式多变、逻辑复杂，对查询时间没有严格要求
• **固化查询：**指的是一些固化下来的取数、看数需求，通过数据产品的形式提供给用户，从而提高数据分析和运营的效率。这类的sql固定模式，对响应时间有较高要求。

按照架构实现划分，主流的OLAP引擎主要有下面三点：

• **预计算系统：**在数据接入的时候根据指定的指标进行聚合运算，适合相对固定的业务报表类需求，进一步牺牲灵活性换取性能，以实现对超大数据集的秒级响应，只需要统计少量维度即可满足业务报表需求。（Druid、Kylin等）

• MPP架构系统：（Massively Parallel Processing）这种架构主要还是从查询引擎入手，使用分布式查询引擎，而不是使用hive+mapreduce架构，提高查询效率，基于Parquet列式存储的，基本是完全基于内存的并行计算。(Presto、Impala、SparkSQL、Greenplum、Drill等)。

• **搜索引擎架构的系统：**在入库时将数据转换为倒排索引，采用Scatter-Gather计算模型，牺牲了灵活性换取很好的性能，在搜索类查询上能做到亚秒级响应。但是对于扫描聚合为主的查询，随着处理数据量的增加，响应时间也会退化到分钟级。能够满足的的查询场景远多于传统的数据库存储，但对于日志、行为类时序数据，所有的搜索请求都也必须搜索所有的分片，另外，对于聚合分析场景的支持也是软肋。(es，solr等)

按照是否独立存储数据，划分为：

• **物化视图：**将数据复制到引擎当中，按照预定的策略进行组织和存储，一般预计算系统都是通过物化视图，按照自定义的索引或者维度来组织数据，提高查询速度。硬连接
• **普通视图：**使用原始数据，一般MPP架构系统，都采用非物化视图，使用分布引擎来提高查询效率。软连接

相关组件：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9c0MqJBT-1653055570650)(D:\WorkSapce\Document\Markdown\BigData.assets\image-20220109173400340.png)]

• **Pig：**Yahoo的一些人觉得用MapReduce进行大数据编程太麻烦了，于是便开发了Pig。Pig是一种脚本语言，使用类SQL的语法，开发者可以用Pig脚本描述要对大数据集上进行的操作，Pig经过编译后会生成MapReduce程序，然后在Hadoop上运行，已经完全淘汰。
• **Hive：**编写Pig脚本虽然比直接MapReduce编程容易，但是依然需要学习新的脚本语法。于是Facebook又发布了Hive。Hive支持使用SQL语法来进行大数据计算，比如说你可以写个Select语句进行数据查询，然后Hive会把SQL语句转化成MapReduce的计算程序。Java语言，Facebook主导，基本处于淘汰边缘，
• **Impala：**Cloudera开发了Impala，这是一种运行在HDFS上的MPP架构的SQL引擎。和MapReduce启动Map和Reduce两种执行进程，将计算过程分成两个阶段进行计算不同，Impala在所有DataNode服务器上部署相同的Impalad进程，多个Impalad进程相互协作，共同完成SQL计算。在一些统计场景中，Impala可以做到毫秒级的计算速度。Java+C++语言，Cloudera主导。
• **Presto：**Hive使用MapReduce作为底层计算框架，Facebook称Presto的性能比Hive要好上10倍多。2013年Facebook正式宣布开源Presto，所有处理都在内存中完成，Java+C++语言，Facebook主导。
• **ClickHouse：**列式存储OALP数据库，采用多种库、表引擎和函数，在内存中运行，充分利用CPU能力。 C++语言，Yandex主导
• **Kylin：**Apache kylin是一个开源分布式分析引擎、提供Hadoop、Spark之上的SQL查询接口及多维分析（OLAP）能力，可以在亚秒内查询巨大的Hive表（还可以与BI工具集成ODBC、JDBC、RestAPI、还有自带的Zepplin插件，来访问Kylin服务）kylin是一种OLAP数据引擎，支持大数据生态圈的数据分析业务，主要是通过预计算的方式将用户设定的多维度数据立方体(cube)缓存起来，达到快速查询的目的。应用场景应该是针对复杂sql join后的数据缓存。核心是Cube，Cube是一种预计算计数，预先对数据做多维索引，查询时候通过扫描索引，提高速度。Kylin主导
• **Druid：**通常是基于时序的事实事件，事实发生后进入Druid，外部系统就可以对该事实进行查询。Druid是一个用于大数据实时查询和分析的高容错、高性能开源分布式系统，用于解决如何在大规模数据集下进行快速的、交互式的查询和分析。
• **Kudu：**关系型数据库

NoSQL引擎

KV存储

KV引擎（Key-value Stores）兼容Redis核心数据结构与API；支持数据的持久化；支持弹性扩展。KeyByte帮助用户快速开发热点数据缓存、高并发数据存储、实时或限时业务支持等应用。

• Redis:

• HBase:

• Cassandra：

搜索引擎

搜索引擎（Search Engines）提供全文搜索，灵活查询方式，毫秒级快速响应，支持多种数据格式

• Elastic Search：
• Solar：

时空数据库

时空数据库（Geo-Spatial DBMS）支持空间地理、时空轨迹、遥感影像等海量数据的存储、查询、分析和挖掘服务，内置了时空索引、空间拓扑几何、遥感影像处理等高效算法。Spacture帮助用户快速开发时空查询分析、时空模式挖掘、时空轨迹聚类等应用，广泛应用于位置服务、城市管理、交通物流、疫情防控等场景。提供海量时间序列数据的高效压缩存储和高性能分析服务,快速开发各类业务与设备的实时监控、实时预警、实时故障诊断等应用。

• **GeoMesa：**时空数据库

图数据库

图数据库（Graph DBMS）原生图存储，百亿点、万亿边、PB级大规模图数据存储；具备10+层的深度链路分析能力，提供丰富的图分析算法和深度图算法；支持标准图查询语言并兼容OpenCypher，并具备海量数据3D图展示能力。StellarDB帮助用户快速开发欺诈检测、推荐引擎、社交网络分析、知识图谱等应用。

• Neo4j：
• Nebula Graph：

事件数据库

事件数据库 （Event Stores）数据从指定时间点重放，保证数据顺序性；具备弹性扩展和容错能力。Event Store帮助用户快速开发日志收集、应用监控、流式数据处理、在线分析等应用。（我理解这就是Kafka呀）

文档数据库

文档数据库（ Document Stores）

• MongoDB：

时序性数据库

时序性数据库（Time Series DBMS）

• **InfluxDB：**时序计算引擎

AI/BI引擎

• Pytorch：
• TenserFlow：

数据湖组件

数据湖技术是计算引擎和底层存储格式之间的一种数据组织格式，用来定义数据、元数据的组织方式

• **Hudi：**Uber开源项目
• **Iceberg：**Netfix开源项目
• Delta Lake： Databricks开源项目

Hive MetaStore做元数据管理存储的问题

1、上云挑战：

支撑多种存储对象，文件存储，对象存储

统一的Table语义，ACID

兼容Spark,Flink,Presto计算框架

2、近实时数仓：

按照时间分区生成文件的，如果分区太小，小文件，源数据数据库数据膨胀，文件级全局统计信息

3、变更：

Schmea变更

分区变更

数据变更

任务引擎

• Azkaban： Azkaban是由Linkedin开源的一个批量工作流任务调度器。用于在一个工作流内以一个特定的顺序运行一组工作和流程。Azkaban定义了一种KV文件格式来建立任务之间的依赖关系，并提供一个易于使用的web用户界面维护和跟踪你的工作流。
• Oozie： Oozie由Cloudera公司贡献给Apache的基于工作流引擎的开源框架,是用于Hadoop平台的开源的工作流调度引擎,是用来管理Hadoop作业,属于web应用程序，由Oozie client和Oozie Server两个组件构成,Oozie Server运行于Java Servlet容器（Tomcat）中的web程序。
• Ariflow： Airflow 是一个使用 Python 语言编写的 Data Pipeline 调度和监控工作流的平台。Airflow 是通过 DAG（Directed acyclic graph 有向无环图）来管理任务流程的任务调度工具，不需要知道业务数据的具体内容，设置任务的依赖关系即可实现任务调度。这个平台拥有和 Hive、Presto、MySQL、HDFS、Postgres 等数据源之间交互的能力，并且提供了钩子（hook）使其拥有很好地扩展性。除了使用命令行，该工具还提供了一个 WebUI 可以可视化的查看依赖关系、监控进度、触发任务等。
• XXL-JOB： XXL-JOB是一个分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已
  开放源代码并接入多家公司线上产品线，开箱即用。
• DolphinScheduler： Apache DolphinScheduler(Incubator,原Easy Scheduler)是一个分布式数据工作流任务调度系统，主要解决数据研发ETL错综复杂的依赖关系，而不能直观监控任务健康状态等问题。Easy Scheduler以DAG流式的方式将Task组装起来，可实时监控任务的运行状态，同时支持重试、从指定节点恢复失败、暂停及Kill任务等操作。作为强大的带有有向无环图（DAG）可视化界面的分布式大数据工作流调度平台，DolphinScheduler解决了复杂的任务依赖关系和简化了数据任务编排的工作。它以开箱即用的、易于扩展的方式将众多大数据生态组件连接到可处理 100,000 级别的数据任务调度系统中来。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4I14kwxb-1653055570651)(D:\WorkSapce\Document\Markdown\BigData.assets\format,png.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JwUiswNH-1653055570651)(D:\WorkSapce\Document\Markdown\BigData.assets\format,png-16417960433184.png)]

元数据管理

• **MetaStore：**Hive中Metastore组件提供统一的元数据管理，提供大数据层面的元数据管理，HDFS的NN提供存储在HDFS中的（大数据的片段文件）的文件的元数据
• **Catalog：**DRF，Glue
• Atlas：

数据治理

数据的全生命周期管理

其他工具

• **Sqoop：**专门将关系数据库中的数据导入导出到Hadoop平台的Sqoop，Sqoop适合关系数据库数据的批量导入、导出。
• **Canal：**如果想实时导入关系数据库的数据，可以选择Canal，CDC增量导入。
• **Flume：**针对大规模日志进行分布式收集、聚合和传输的Flume。Flume最早由Cloudera开发，后来捐赠给Apache基金会作为开源项目运营
• **DistCp：**DistCp（分布式拷贝）是用于大规模集群内部和集群之间拷贝的工具。 它使用Map/Reduce实现文件分发，错误处理和恢复，以及报告生成。 它把文件和目录的列表作为map任务的输入，每个任务会完成源列表中部分文件的拷贝。 由于使用了Map/Reduce方法，这个工具在语义和执行上都会有特殊的地方。 这篇文档会为常用DistCp操作提供指南并阐述它的工作模型。
• **Kyuubi：**将Hive迁移到Spark Beeline Hue Superset（图形化）连接 HiveServer Kyuubi 支持HiveServer协议，使用Spark引擎
• **MQ：**Message Queue作为消息中间件，接收消息，进行数据的流转，主要使用的Kafka（Erlang开发，LinkIn主导）Pulsar（Java开发，Yahoo主导）

相关概念

观念分析

• 将程序分发到数据所在的地方进行计算，也就是所谓的移动计算比移动数据更划算。
• 这就是现在互联网企业广泛使用的负载均衡、分布式缓存、分布式数据库、分布式服务等种种分布式系统。

数据来源

• 业务数据，一般为存储在关系型数据库或者KV数据库中的业务流程中产生的数据，多维结构化数据
• 日志数据，一般为应用运行过程打印的日志相关数据，多维半结构化数据，多用于监控、告警、审计等使用
• 爬虫数据，爬虫从公开的环境中爬取的数据，搜索引擎多使用的场景
• 公开数据，一般是实验性的数据，多用于实验验证，基准测试等功能，多为厂商或实验组织提供

构建方式

• 自研：基于开源代码，自己开发，（相当于自建工厂，使用自己的原材料，自己生产产品）

• 解决方案提供商：解决方案提供商 （找专业的施工队建工厂，使用自己的原材料，自己生产产品）其中包括 Cloudera、 HortonWorks CDH 、星环科技 TDH、华为 FunsionInsight

• 大数据云计算服务商：（找代工厂，使用自己的原材料，在代工厂自己生产产品） 阿里云 MaxCompute 、华为云 MRS

• 大数据SaaS服务商：（找代工厂，使用自己的原材料，让在代工厂生产产品） 友盟、神策、百度统计

• 大数据开放平台：商品提供商 （直接买产品） 征信，气象局

基准测试

基准测试（BenchMark）

软件性能指标：

• 响应时间：完成一次任务（请求）花费的时间。
• 并发数：同时处理的任务数（请求数）。
• 吞吐量：单位时间完成的任务数（请求数、事务数、查询数……）。
• 性能计数器：System Load，线程数，进程数，CPU、内存、磁盘、网络使用率等

资源：处理器，内存，网络，磁盘（CPU、Memory、Disk、Net）
优化三板斧：时空互换，批量提交，同步异步

数据存储格式

列式存储，行式存储，混合存储

• Patquet：
• ORC：
• Avro：

商业运营

商业化运营中的相关指标

• 新增用户数
• 用户留存率 （用户留存率 = 留存用户数 / 当期新增用户数） 3日留存，还有5日留存、7日留存等
• 用户流失率 = 1 - 用户留存率
• 活跃用户数（日活跃用户数、月活跃用户数等）。提升活跃是网站运营的重要目标
• PV 打开产品就算活跃，打开以后是否频繁操作，就用PV这个指标衡量，用户每次点击，每个页面跳转，被称为一个PV（Page View）
• GMV即成交总金额（Gross Merchandise Volume），是电商网站统计营业额（流水）、反映网站营收能力的重要指标
• 转化率 （转化率 = 有购买行为的用户数 / 总访问用户数）

展示方式 ECharts

• 折线图 能够很好的展现趋势
• 散点图 发现数据分布上的规律与趋势，可谓肉眼聚类算法。
• 热力图 热力图用以分析网站页面被用户访问的热点区域，以更好进行页面布局和视觉展示。
• 漏斗图 漏斗图可谓是网站数据分析中最重要的图表，表示在用户的整个访问路径中每一步的转化率
  未来20年最有发展潜力的三项技术分别是：区块链、人工智能、物联网

其他

SQL定义

SQL Structured Query Language

• DDL data define language
• DQL data query language
• DCL data manipulation language (insert,delete,update)

数据分层

OneData OneService、OneID、OneModel

应用层

• ADS（Application Data Service）数据应用层，该层主要是提供给数据产品和数据分析使用的数据，一般会存放在ES、Redis、PostgreSql等系统中供线上系统使用；也可能存放在hive或者Druid中，供数据分析和数据挖掘使用，比如常用的数据报表就是存在这里的。

数仓层

• DWS（Data Warehouse Service）数据服务层，该层是基于DWM上的基础数据，整合汇总成分析某一个主题域的数据服务层，一般是宽表，用于提供后续的业务查询，OLAP分析，数据分发等。一般来说，该层的数据表会相对较少；一张表会涵盖比较多的业务内容，由于其字段较多，因此一般也会称该层的表为宽表。
• DWM（Data Warehouse Middle）数据中间层，该层是在DWD层的数据基础上，对数据做一些轻微的聚合操作，生成一些列的中间结果表，提升公共指标的复用性，减少重复加工的工作。
• DWD（Data Warehouse Details）数据细节层，该层是业务层和数据仓库的隔离层，保持和ODS层一样的数据颗粒度；主要是对ODS数据层做一些数据的清洗和规范化的操作，比如去除空数据、脏数据、离群值等。
• DIM（Dimension）公共一致性维度层：维度是维度建模的基础和灵魂，维度属性是查询约束条件、分组和报表标签生成的基本来源，是数据易用性的关键。

原始层

• ODS（Operation Data Store）数据运营层：数据准备区，也称为贴源层。为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可，为上层数据工作做好准备工作

表的分类

• 事实表（Fact Table)，事实表是指存储有事实记录的表，比如系统日志、销售记录等。事实表的记录在不断地增长，比如电商的商品订单表，就是类似的情况，所以事实表的体积通常是远大于其他表。
• 维度表（Dimension Table）或维表，有时也称查找表（Lookup Table），分析基于多个维度去分析，多维度关联生成事实表，是与事实表相对应的一种表；它保存了维度的属性值，可以跟事实表做关联，相当于将事实表上经常重复出现的属性抽取、规范出来用一张表进行管理。维度表主要是包含两个部分：
  • 高基数维度数据：一般是用户资料表、商品资料表类似的资料表，数据量可能是千万级或者上亿级别
  • 低基数维度数据：一般是配置表，比如枚举字段对应的中文含义，或者日期维表等；数据量可能就是个位数或者几千几万。

存储组件

HDFS

HDFS

Ozone

Ozone: HDFS NN 规模超过5亿时[GC,块汇报风暴] 元数据+文件块，HDFS使用联邦模式来完成，将元数据存贮在RocksDB数据库，管理块组，本省就是一个存储结构
对象存储：KV存储
文件系统：书结构，list,rename,deleteDir
优化方向：
1、文件系统管理+文件块管理分离，大量文件块管理时异步进行 – 性能更好
2、DB中将Dir和File分开，2个表来存储，异步删除 – 扩展性更好
对于锁的处理：
1、固定层级锁
2、细粒度路径锁[锁太多]
3、lockPool,路径锁， 产生死锁[路径顺序加锁]

HDFS降成本：EC,分层存储

MinIO

待详细学习

调度组件

MapReduce

MapReduce编程模型
针对输入数据，将计算过程分为两个阶段，一个Map阶段，一个Reduce阶段，可以理解成是面向过程的大数据计算

• Map模型，本地输入{k,v} 输出{k,v}到本地
• shuffle， 将不同的map输出的结果{k,v1},{k,v2},{k,v3}合并将合并为{k,[v1，v2，v3]}，发送给reduce，这里有Partitioner来实现MapReduce框架默认的Partitioner用Key的哈希值对Reduce任务数量取模shuffle也是整个MapReduce过程中最难、最消耗性能的地方
• reduce模型，输入{k,[v1，v2，v3]},输出{k,sum}
  MapReduce计算框架
  如何为每个数据块分配一个Map计算任务，也就是代码是如何发送到数据块所在服务器的，发送后是如何启动的，启动以后如何知道自己需要计算的数据在文件什么位置（BlockID是什么）。
  处于不同服务器的map输出的 ，如何把相同的Key聚合在一起发送给Reduce任务进行处理。
• JobClient 客户端，提交作业
• JobTracker 主服务，命令下面提到的TaskTracker进程启动相应数量的Map和Reduce进程任务，并管理整个作业生命周期的任务调度和监控
• TaskTracker 从服务，和DataNode进程启动在同一个服务器，管理Map进程和Reduce进程，同时上报Job的状态

Yarn

Yarn

Kubernetes

待详细学习

计算组件

Spark

Spark

Flink

Flink

AI(ML,DL,GraphX)

待详细学习

Kafk

待详细学习

Pulsar

待详细学习

2012年Yahoo开发，2016年捐献给Apache,2018年成为顶级项目
存储和计算分离的架构，支撑多层级存储，Function机制，Function Mesh(基于k8s提供函数编排)

OLAP组件

ClickHouse

ClickHouse

Doris

Doris

Druid

Druid

Kylin

Kylin

NoSQL组件

HBase

• HMaster集群，保存HRegion的metadata【HRegionServer地址，端口号，以及key和HRegin的对应信息】【HMaster是主备通过ZK选主，保证高可用】

• HRegion保存数据【存储key值】，如果单HRegion保存过多，就会分裂成两个HRegion,并将HRegion在整个集群中进行迁移，以使HRegionServer的负载均衡。

• HRegion会把数据存储在若干个HFile格式的文件中，这些文件使用HDFS分布式文件系统存储，在整个集群内分布并高可用

• 数据结构：LSM（Log Structed Merge Tree）树，数据写入的时候以Log方式连续写入，然后异步对磁盘上的多个LSM树进行合并，没有太搞懂

• 于是Saleforce推出了Phoenix，一个执行在HBase上的SQL引擎。

AI/BI组件

• AI：指广义的人工智能，包括机器学习、数据挖掘以及其他从数据中获取以前未知知识的技术

• BI：则更多地使用统计方法将大量数据汇总成更简单的报告，方便人们理解

大数据架构

Lambda

Lambda 架构（Lambda Architecture）是由 Twitter 工程师南森·马茨（Nathan Marz）提出的大数据处理架构。这一架构的提出基于马茨在 BackType 和 Twitter 上的分布式数据处理系统的经验。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-i5uZ9Tqa-1653055570652)(D:\WorkSapce\Document\Markdown\BigData.assets\852983-20190923115012470-1830630474.jpg)]

Lambda 架构总共由三层系统组成：批处理层（Batch Layer），速度处理层（Speed Layer），以及用于响应查询的服务层（Serving Layer）。

批处理层存储管理主数据集（不可变的数据集）和预先批处理计算好的视图。

批处理层使用可处理大量数据的分布式处理系统预先计算结果。它通过处理所有的已有历史数据来实现数据的准确性。这意味着它是基于完整的数据集来重新计算的，能够修复任何错误，然后更新现有的数据视图。输出通常存储在只读数据库中，更新则完全取代现有的预先计算好的视图。

速度处理层会实时处理新来的大数据。速度层通过提供最新数据的实时视图来最小化延迟。速度层所生成的数据视图可能不如批处理层最终生成的视图那样准确或完整，但它们几乎在收到数据后立即可用。而当同样的数据在批处理层处理完成后，在速度层的数据就可以被替代掉了。

Lambda 架构的不足

虽然 Lambda 架构使用起来十分灵活，并且可以适用于很多的应用场景，但在实际应用的时候，Lambda 架构也存在着一些不足，主要表现在它的维护很复杂。

使用 Lambda 架构时，架构师需要维护两个复杂的分布式系统，并且保证他们逻辑上产生相同的结果输出到服务层中。

我们都知道，在分布式框架中进行编程其实是十分复杂的，尤其是我们还会针对不同的框架进行专门的优化。所以几乎每一个架构师都认同，Lambda 架构在实战中维护起来具有一定的复杂性。

Kappa

Kappa 架构是由 LinkedIn 的前首席工程师杰伊·克雷普斯（Jay Kreps）提出的一种架构思想。克雷普斯是几个著名开源项目（包括 Apache Kafka 和 Apache Samza 这样的流处理系统）的作者之一，也是现在 Confluent 大数据公司的 CEO。

Kappa架构改进 Lambda 架构中速度层的系统性能，使得它也可以处理好数据的完整性和准确性问题，改进 Lambda 架构中的速度层，使它既能够进行实时数据处理，同时也有能力在业务逻辑更新的情况下重新处理以前处理过的历史数据

像 Apache Kafka 这样的流处理平台是具有永久保存数据日志的功能的，通过平台的这一特性，我们可以重新处理部署于速度层架构中的历史数据。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-s5RMMlCL-1653055570652)(D:\WorkSapce\Document\Markdown\BigData.assets\852983-20190923115103982-2134800686.png)]

第一步，部署 Apache Kafka，并设置数据日志的保留期（Retention Period）。这里的保留期指的是你希望能够重新处理的历史数据的时间区间。

例如，如果你希望重新处理最多一年的历史数据，那就可以把 Apache Kafka 中的保留期设置为 365 天。如果你希望能够处理所有的历史数据，那就可以把 Apache Kafka 中的保留期设置为“永久（Forever）”。

第二步，如果我们需要改进现有的逻辑算法，那就表示我们需要对历史数据进行重新处理。

我们需要做的就是重新启动一个 Apache Kafka 作业实例（Instance）。这个作业实例将从头开始，重新计算保留好的历史数据，并将结果输出到一个新的数据视图中。我们知道 Apache Kafka 的底层是使用 Log Offset 来判断现在已经处理到哪个数据块了，所以只需要将 Log Offset 设置为 0，新的作业实例就会从头开始处理历史数据。

第三步，当这个新的数据视图处理过的数据进度赶上了旧的数据视图时，我们的应用便可以切换到从新的数据视图中读取。

第四步，停止旧版本的作业实例，并删除旧的数据视图。

与 Lambda 架构不同的是，Kappa 架构去掉了批处理层这一体系结构，而只保留了速度层。你只需要在业务逻辑改变又或者是代码更改的时候进行数据的重新处理。

公有云解决方案

AWS(MR)

AWS 有较为成熟完善的数据湖方案，组件间耦合度很低，一个组件专干一个事情，很好的保证了灵活性和性能

• **S3 （对象存储）**做统一数据湖存储
• Lake Formation（元数据） 元数据管理和权限控制
• Glue 做数据 ETL
• Redshift OLAP分析引擎
• Athena 做数据计算和分析

ALI(E-MR)

• OSS 对象存储，JindoFS 做统一存储
• DLF

HW(MRS)

• OBS 对象存储，Memarts 做缓存加速
• MRS 提供基于Hadoop体系整套方案

数据中台

程序 = 数据 + 算法

• 传统的程序 = 规范化的数据 + 预定好的算法

• 数据驱动程序 = 动态的、持续变化的，多用户输入的数据 + 智能的、个性化的、实时的、自适应的算法

所有大数据领域的应用包括但是不限于：推荐，搜索，指数，个性化，画像，内容情感分析，内容自动标签，趋势预测，产品性能报告，发欺诈，风控

OneData理念

提供统一的数据规范，数据统一存放和管理，提供全局抽象、共享和复用能力，以此指导数字化运营

• 全局商业洞见（Total Insight) 个性化服务[用户画像，产品画像，匹配服务，反馈服务] 实时数据表报
• 业务信息化 OLTP （SOR system of record) 存储关系型数据
• 数据仓库 OLAP (SOI system of insight) 存储面向分析主体的关系型数据
• 大数据 DataLake (SOE system of engagement) 解除scheme的限制，更多的数据源和更丰富维度的聚合分析，并能够实现更高维度的数据分析。 计算引擎（spark,flink），分析引擎(Presto,kylin),文档数据库、对象数据库、图数据库,时空数据库等
  数据中台 共享，复用，抽象

建设步骤

1、大数据平台建设阶段
OPS工具：Ansible. Puppet、Chef、Fabric ？ 监控、告警、备份、恢复
工作流量管理工具：0ozie、Azkaban、Airflow等工作流系统，依赖关系管理 tgt
数据治理工具：
数据安全+权限：
2、数据管理及应用阶段
业务流程管理：
顶层业务架构的梳理，业务域和数据域的划分;
数据规范的确定；
业务流程的梳理及面向业务流程的数据建模；
数据导入、数据清洗、数据治理、数据转换；
主题的分析及实现，数据集市的建立。
数据管理：
数据流程监控，程序的运行时间预定义的ETA （预期完成时间），
数据血缘关系
元数据管理
数据安全：
Kerberos认证，数据审计，多租户，端到端安全，单点登录
3、数据能力中台化阶段
全局的数据治理、数据能力的复用和共享以及云原生架构的支撑
DataOps:提高数据分析的质量并缩短数据分析的周期

架构+方法论
在方法论中，最重要的思想是业务驱动，数据赋能，快速落地，小步快跑，
在体系架构上，核心是采用云原生的架构统一管理，抽象底层复杂的数据基础能力层，全局管理数据开发流程