zoukankan      html  css  js  c++  java
  • 大数据平台基础架构和常用处理工具-copy

    https://blog.csdn.net/qq_27384769/article/details/80159953

    一、概述
    数据在线分析处理和常用工具
    大数据离线处理和常用工具
    OLAP 和 OLTP 处理和常用处理工具
    二、数据在线分析处理和常用工具
    1、Flume 介绍
    Flume 专注于大数据的收集和传输,用来解决在线分析处理特点,数据源源不断的到来的问题。类似的大数据开源系统有 Logstash 和 Fluentd 。

    三者区别如下:

    Logstash 主要 和 Elasticsearch 、 Kibana 结合使用,俗称 ELK 框架; Logstash 主要负责将数据源的数据转换成 Elasticsearch 认识的索引结构供 Kibana 查询
    Fluentd 当前的使用者已经很少,逐渐被功能更强大的 Flume 代替了
    Flume 能够支持多种数据源并且输出到多种输出源,并且支持多种格式的数据


    架构图中 Source 用来连接输出源,Sink 用来连接输出源,Channel 是 Flume 内部数据传输通道(主要包括 Memory Channel 和 File Channel)。

    其中 Source 连接的输入源可以但不限于:

    Avro
    Thrift 
    Exec(unix command  output)
    JMS (Java Message Service)
    Kafka
    NetCat (可以使用 nc –lk port 测试)
    Syslog
    Custom 
    其中 Sink 连接的输出源可以但不限于:

    Hdfs
    Hive 
    Avro
    Thrift 
    File Roll
    Hbase
    ElasticSearch (提供的功能和 Logstash 一样,但是不如Logstash 丰富,大多数时候需要自己构造 ElasticSearch 文档和索引)
    Kafka
    Custom
    Flume 也能多个 Agent 相连形成 Agent 链

    2、Spark 和 Storm 介绍
    Spark (Spark Streaming) 和 Storm 专注于将数据按照时间窗口进行聚合和处理。用来解决在线分析处理特点,数据需要尽快的得到处理的问题。所以经常被称作流式处理框架。

    两者的区别如下:

    Storm 提供比 Spark 更加实时的流式处理;
    Spark 提供比Storm更加多的服务,Spark 逐渐已经形成类似 Hadoop 的生态圈了。
    目前Spark 生态圈包含的生态系统如下(而且还正在逐渐的壮大中):

    目前 Spark 有三种集群管理模式:

    Standalone:一种简单的集群管理,其包括一个很容易搭建集群的Spark;
    Apache Mesos :一种通用的集群管理,可以运行Hadoop MapReduce和服务应用的模式;
    Hadoop YARN : Hadoop2.0中的资源管理模式。
    其中第二种和第三种都是使用 Spark 做任务管理和调度,Mesos 和 Yarn 做资源管理和调度

    Spark 工作组件

    Strom 结构图

    Storm 的工作组件:

    topology:一个拓扑是一个个计算节点组成的图,每个节点包换处理的逻辑,节点之间的连线表示数据流动的方向;
    spout:表示一个流的源头,产生tuple;
    bolt: 处理输入流并产生多个输出流,可以做简单的数据转换计算,复杂的流处理一般需要经过多个bolt进行处理。
    Strom 拓扑topology的组成

    3、HBase 介绍
    HBase 专注于大数据存储和提供查询,用来解决在线分析处理特点,数据经过处理后数据量依然巨大的存储和展现问题。类似的大数据开源系统有 Cassandra 。

    两者区别如下:

    Cassandra 满足可用性和分区容忍性,允许数据的不一致(不同客户端可能看到不一样的情况)、 Cassandra 提供了类似 SQL 的 CQL 查询语言,查询方便;
    HBase 满足一致性和分区容忍性,拥有强大的记录集一致性。HBase不支持 SQL 需要使用者部署第三方服务来支持 SQL (如 Apache Phoenix);


    组成部件说明:

    Client:使用HBase RPC机制与HMaster和HRegionServer进行通信;

    Zookeeper: 存储hbase:meta 表等元数据信息;HRegionServer把自己以Emphedral方式注册到Zookeeper中,HMaster随时感知各个HRegionServer的健康状况;Zookeeper避免HMaster单点问题;

    HMaster: 主要负责Table和Region的管理工作:

    管理用户对表的增删改查操作
    管理HRegionServer的负载均衡,调整Region分布
    Region Split后,负责新Region的分布
    在HRegionServer停机后,负责失效HRegionServer上Region迁移
    HRegionServer:HBase中最核心的模块,主要负责响应用户I/O请求,向HDFS文件系统中读写数据:

    HRegionServer管理一些列HRegion对象;
    每个HRegion对应Table中一个Region,HRegion由多个HStore组成;
    每个HStore对应Table中一个Column Family的存储;


    Region的 Split 和 StoreFile 的 Compact:

    Client写入 -> 存入MemStore,一直到MemStore满 -> Flush成一个StoreFile,直至增长到一定阈值 -> 触发Compact合并操作 -> 多个StoreFile合并成一个StoreFile,同时进行版本合并和数据删除 -> 当StoreFiles Compact后,逐步形成越来越大的StoreFile -> 单个StoreFile大小超过一定阈值后,触发Split操作,把当前Region Split成2个Region,Region会下线,新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer 上,使得原先1个Region的压力得以分流到2个Region上。�由此过程可知,HBase只是增加数据,有所得更新和删除操作,都是在Compact阶段做的,所以,用户写操作只需要进入到内存即可立即返回,从而保证I/O高性能;

    三、大数据离线处理和常用工具
    1、Hdfs 介绍
    Hdfs 是一种分布式文件系统,和任何文件系统一样 Hdfs 提供文件的读取,写入,删除等操作。Hdfs 是能够很好的解决离线处理中需要存储大量数据的要求。Hdfs和本地文件系统的区别如下:

    Hdfs 不支持随机读写;
    Hdfs 是分布式文件系统,支持数据多备份;
    Hdfs 多备份数据存放策略: 第一个副本放在和client所在的node里(如果client不在集群范围内,则这第一个node是随机选取的,当然系统会尝试不选择哪些太满或者太忙的node);第二个副本放置在与第一个节点不同的机架中的node中(随机选择);第三个副本和第二个在同一个机架,随机放在不同的node中。如果还有更多的副本就随机放在集群的node里。

    客户端读取数据流程图

    客户端写入数据流程图

    2、MapReduce 介绍
    MapReduce 是一种分布式批量计算框架,分为 Map 阶段和 Reduce 阶段。 MapReduce 能够很好的解决离线处理中需要进行大量计算的要求。 MapReduce 从出现到现在经历了第一代 MapReduce v1 和 第二代 MapReduce Yarn。

    Yarn 框架相对于老的 MapReduce 框架有以下优势:

    减小了 JobTracker的资源消耗,之前JobTracker 既负责资源分配,也负责任务监控,Yarn 将这两项任务分别交给了 ResourceManager 和 ApplicationMaster  ,减少了之前 JobTracker 单点失败的风险;

    MRv1 将资源分别 Map slot 和 Reduce slot 而且相互之前不能使用,Yarn将资源分别CPU、内存,相互之前能够通用,更加灵活也更加合理;

    3、Hive 介绍
    Hive 是一种数据仓库,Hive 中的数据存储于文件系统( 大部分使用 Hdfs),Hive 提供了方便的访问数据仓库中数据的 HQL 方法,该方法将 SQL 翻译成MapReduce。 能够很好的解决离线处理中需要对批量处理结果的查询。 Hive 将元数据存放在 metastore 中, Hive 的 metastore 有三种工作方式:

    内嵌Derby方式: 在同一时间只能有一个进程连接使用数据库;
    Local方式 : 使用本地 Mysql 数据库存储元数据;
    Remote方式: 使用远程已经搭建完成的 Mysql 数据库存储元数据;


    四、OLAP 和 OLTP处理和常用工具
    OLAP 和 OLTP 特点

    OLAP (联机分析处理) 和 OLTP (联机事务处理) 在查询方面的特点:
    OLTP 单次查询返回数据量小,但是经常会涉及服务器端简单的聚合操作,要求查询响应速度快,一般应用于在线处理;
    OLAP 单次查询返回数据量巨大,服务器端进行的处理复杂,经常包含上卷(从细粒度数据向高层的聚合)、下钻(将汇总数据拆分到更细节的数据)类似的操作;
    Elasticsearch 介绍
    Elasticsearch 是一种基于 文档 的 底层使用 Lucene 进行检索的分布式NoSql 集群。Elasticsearch 检索大量文档类数据响应速度很快,更够为 在线 OLTP 提供支持。类似的大数据开源系统有 Solr。

    两者的区别如下

    Elasticsearch是分布式的。不需要其他组件,分发是实时的,被叫做”Push replication” 并且完全支持 Apache Lucene 的接近实时的搜索;
    建立索引时,搜索效率下降,实时索引搜索效率不高;
    随着数据量的增加,Solr的搜索效率会变得更低,而Elasticsearch却不会有明显变化
    所以, Solr的架构不适合实时搜索的应用,也就不适合 OLTP 处理

    Impala 介绍
    Impala 是 Cloudera 公司主导开发的新型查询系统,它提供 SQL 语义,能查询存储在 Hadoop 的 Hdfs 和 Hbase 中的 PB 级大数据。已有 的 Hive 系统虽然也提供了 SQL 语义,但由于 Hive 底层执行使用的是 MapReduce 引擎,仍然是一个批处理过程,难以满足查询的交互性。相比之 下,Impala 的最大特点就是它的快速。

    所以, Impala 使得在 TB 甚至 PB 级数据上进行 OLTP 分析成为可能。

    Impala 主要通过以下两种技术实现快速查询大量数据:

    实现了嵌套型数据的列存储;
    使用了多层查询树,使得任务可以在数千个节点上并行执行和聚合结果;
    列存储可以减少查询时处理的数据量,有效提升 查询效率。多层查询树则借鉴了分布式搜索引擎的设计,查询树的根节点负责接收查询,并将查询分发到下一层节点,底层节点负责具体的数据读取和查询执行,然后将结果返回上层节点。

    Kylin 介绍
    Kylin 是由国人作为主要贡献者的一个旨在对 Hadoop 环境下分析流程进行加速、且能够与 SQL 兼容性工具顺利协作的解决方案,目前 Kylin 已经成功将SQL接口与多维分析机制(OLAP)引入 Hadoop,旨在对规模极为庞大的数据集加以支持。

    Kylin 能够在大数据分析领域实现以下各项特性:

    规模化环境下的极速 OLAP 引擎: 削减 Hadoop 环境中处理超过百亿行数据时的查询延迟时间;
    Hadoop上的 ANSI SQL 接口: Kylin 能够在 Hadoop 之上提供 ANSI SQL 并支持大部分 ANSI SQL查询功能;
    利用 OLAP cube(立方体)对数百亿行数据进行查询;


    Kylin 的大体设计思路:

    从Hive当中读取数据(这些数据被保存在HDFS之上);
    运行Map Reduce任务以实现预计算 ;
    将cuba数据保存在HBase当中 
    利用Zookeeper进行任务协调
    ————————————————
    版权声明:本文为CSDN博主「chenshiying007」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
    原文链接:https://blog.csdn.net/qq_27384769/article/details/80159953

  • 相关阅读:
    bzoj 1176 cdq分治套树状数组
    Codeforces 669E cdq分治
    Codeforces 1101D 点分治
    Codeforces 1100E 拓扑排序
    Codeforces 1188D Make Equal DP
    Codeforces 1188A 构造
    Codeforces 1188B 式子转化
    Codeforces 1188C DP 鸽巢原理
    Codeforces 1179D 树形DP 斜率优化
    git commit -m "XX"报错 pre -commit hook failed (add --no-verify to bypass)问题
  • 原文地址:https://www.cnblogs.com/hanease/p/14488821.html
Copyright © 2011-2022 走看看