6.大数据架构详解：从数据获取到深度学习 --- 交互式分析

6.1 交互式分析的概念 在数仓领域有个概念 "即席查询"(Adhoc Query)，指的是用户在使用系统时，根据自己当时的需求定义查询。在大数据领域，扩展到 Interactive Query(交互式查询)是
最常见的一种，通常用于客户投诉处理，实时数据分析，在线查询等。具有如下特点：1.时延低(在数十秒在数分钟之间)2.查询条件复杂(多个维度)3.查询范围大(通常查询表记录在几十亿级别)4.返回结果小(几十条甚至几条)5.并发数要求高(几百，上千条同时并发)6.需要支持sql等接口传统上，常常使用数据仓库来承担Adhoc Query 的责任。想了很多办法，如数据库索引，Sybase IO的列式存储等。建立索引的思路是通过索引减少扫描的数据，更适合传统的
TP场景，如并发要求高，获取数据少的场景。列式存储则根据查询的列的选择性比较强的特性来减少数据的获取，是个不错的思路。6.2 MPP DB技术 6.2.1 MPP的概念 MPP 是系统架构角度的一种服务器分类方法。从系统架构来看，目前的商用服务器大体可以分为三类，即对称多处理结构(SMP)，非一致存储访问结构(NUMA)，以及海量并行处理结构(MPP)。 1.SMP所谓对称多处理器结构，是指服务器的多个cpu对称工作，无主次或从属关系。各cpu共享的物理内存，每个cpu访问内存中的任何地址所需要的时间是相同的，因此SMP也被称为一致性存储器访问结构(UMA)。2.NUMANUMA 服务器的最基本特征是拥有多个cpu模块，每个cpu模块由多个cpu组成，并且具有独立的本地内存，IO槽口等。缺陷，由于访问异地内存的时延远远超过访问本地内存，因此，当cpu数量增加的时候，系统性能无法线性增加。3.MPPMPP 由多台SMP服务器通过一定的节点互联网络进行连接，协同工作，完成相同的任务，从用户角度来看是一个服务器系统。其基本特征是由多台SMP服务器通过节点互连网络连接而成，每个节点只访问自己的本地资源，是一种完全无共享结构因而扩展能力最强，理论上可以无限扩展。5.数据仓库的选择典型的数仓环境具有大量复杂的数据处理和综合分析，要求系统具有很高的IO处理能力，并且存储系统需要提供足够的IO带宽与之匹配。而一个典型的OLTP系统则以联机事务处理为主，每次交易所涉及的数据不多，要求系统具有很高的事务处理能力，能在在单位时间内尽量处理多的交易。从NUMA架构来看，它可以在一台物理服务器内集成多个cpu，使系统具有较高的事务处理能力，但由于异地内存访问延时远长于本地内存访问，因此需要尽量减少不同cpu模块之间的数据交互。显然，NUMA架构更适合用于OLTP事务处理环境，当用于数仓环境时，由于大量复杂的数据处理必然导致大量的数据交互，将使cpu的利用率大大降低。相对而言，MMP服务器架构的并行处理能力更优越，更适合复杂的数据综合分析与处理环境。当然需要借助支持MPP技术的关系数据库系统来屏蔽节点之间的负载均衡与调度的复杂性。显然，适应数据仓库环境的MPP服务器，其节点互连网络的IO性能应该非常突出。6.MPP数据仓库架构分类前面讲到MPP架构非常复杂，通常用到数据库系统来屏蔽节点之间的负载平衡和调度的复杂性，在数据库架构设计中，又有多种架构，主要分为Share Disk 和 Share Nothing。1.Share Disk各个处理单元使用自己私有的cpu和memory，共享磁盘系统。2.Share Nothing各个处理单元都有自己私有的cpu，内存，硬盘等，不存在共享资源，类似于MPP(大规模并行处理)模式，各处理单元之间通过协议通信，并行处理和扩展能力更好。我们常说的sharding 其实就是share nothing 架构，它把某张表从物理存储存储上水平分隔，并分配给多态服务器(或者多个实例)，每台服务器可以独立工作，具备共同的schema，如MySQL Proxy和Google的各种结构，只需要增加服务器数量就可以增加处理能力和容量。Share Nothing 因为数据尤其是元数据存储在不同的服务器上，所以对各台服务器间元数据同步及故障恢复来说是一个灾难。相对而言，share disk 不存在同步问题，计算节点故障后简单复位就可以恢复工作，但是存在共享存储导致的存储瓶颈问题。6.2.2 典型的MPP数据库 6.2.3 MPP DB调优实战 1.Linux 的cpu调度2.Linux 的内存架构3.虚拟内存管理4.模块化的IO调度器5.网络子系统数据库调优思路：1.业务优化2.读写分离3.查询缓存4.分表分区5.中间表6.索引7.sql优化8.系统优化6.2.4 MPP DB适用场景 6.3 SQL on Hadoop SQL on Hadoop 是一种泛化的概念，是指Hadoop领域里一系列支持sql接口的组件和技术。下面是几种常见的 SQL on Hadoop 技术。6.3.1 Hive Hadoop 和 MapReduce 是 Hive 架构的根基。Hive 架构组件包括：CLI,JDBC/ODBC,Thrift Server,Web GUI,MetaStore和Drive。这些组件包括服务端和客户端组件。服务端：1.Drive 组件该组件包括Complier,Optimizer和Executor，其作用是将HiveQL(类SQL)语句进行解析，编译优化，生成执行计划，然后调用底层的MapReduce计算框架。2.MetaStore组件元数据服务组件，这个组件存储Hive的元数据。Hive的元数据存储在关系型数据库里，Hive支持的关系型数据库有Derby,MySQL。元数据对于Hive来说十分重要，因此Hive把MetaStore服务独立出来，安装到远程的服务器集群里面，从而解耦Hive服务和MetaStore服务，保证Hive运行的健壮性。3.Thrift 服务Thrift是Facebook开发的一个软件框架，用来进行可扩展且跨语言的服务的开发，Hive集成了该服务，能让不同的编程语言调用hive的接口。客户端：1.CLI命令行接口2.Thrift客户端3.Web GUIhive客户端提供了一种通过网页的方式访问hive所提供的服务。这个接口对应hive的HWI(Hive Web Interface)组件，使用前要启动HWI服务。Hive 是基于 Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的sql查询功能，可以将sql语句转换为MapReduce任务运行。Hive支持 HSQL，这是一种类sql。也正是由于这种机制，导致hive的最大缺点是慢。Map/Reduce 调度本身只适合批量，长周期任务，类似查询这种要求短平快的业务，代价太高。6.3.2 Phoenix HBase 是一个分布式的，面向列的开源数据库，该技术来源于Google 的 Bigtable：一个结构化数据的分布式存储系统。就像bigtable利用了google文件系统所提供的分布式数据存储一样，HBase在Hadoop之上提供了类似bigtable的能力。HBase是apache的Hadoop项目的子项目。hbase不同于一般的关系型数据库，它是一个适合非结构化数据存储的数据库，而且hbase是基于列的，不是基于行的。hbase的核心是将数据抽象成表，表中只有rowkey和columnfamily。rowkey是记录的主键，通过key/value很容易找到；columfamily中存储实际的数据。仅能通过主键(rowkey)和主键的range来检索数据，仅支持单行事务(可通过hive支持来实现夺标join等复杂操作)。主要用来存储非结构化和半结构化的松散数据。hbase不支持sql语法，使用非常不方便，所以诞生了Phoenix。Phoenix 是通过一个嵌入的jdbc驱动存储在hbase中的数据查询。Phoenix可以让开发者在hbase数据集上使用sql查询。Phoenix查询引擎会将sql查询转换为一个或者多个hbase的扫码操作，并合并执行以生成标准的jdbc结果集。对于简单查询来说，Phoenix的性能甚至胜过hive。6.3.3 Impala Impala 实时交互 SQL 大数据查询工具。Impala 没有再使用缓慢的 hive + mapreduce 批处理，在架构上使用了与传统并行关系数据库中类似的分布式查询引擎(由QueryPlanner，QueryCoordinator和 QueryExecEngine 三部分组成)，可以直接从hdfs或者habse中用select,join和统计函数查询数据，从而大大降低了延时。6.4 大数据仓库 前面讲到的 MPP DB，SQL on Hadoop 实际解决的都是传统数据仓库的多维度查询问题，但为什么大家不适用数据仓库去解决呢？核心问题有2个：1.在大数据时代，数据量的大小已经远远超过传统数据库处理的范围了，数据的量变带来了对技术需求的质变。用新技术解决传统数据仓库的问题，可以称之为大数据数仓。2.成本的原因。相比传统的数据仓库的高性能硬件，Hadoop技术一般使用大量的廉价硬件，相对而言，有很大的成本优势。6.4.1 数据仓库的概念 数据仓库，其主要功能是将 OLTP 积年累月所积累的大量的资料，通过使用各种分析方法如联机分析处理(OLAP)，数据挖掘(Data Mining)进行系统的分析，从而支持构建如决策支持系统(DSS)，主管资源系统(EIS)等，帮助决策者快速，有效的从大量数据中分析出有价值的知识，从而快速应对变化的商业环境，做出最佳决策，帮助建构商业智能(BI)。数据仓库是一个面向主体的，集成的，相对稳定的，反应历史变化的数据集合，用于支持管理决策。6.4.2 OLTP/OLAP对比 数据仓库里面有 OLTP/OLAP 之分，OLTP 是传统关系型数据库的主要应用，其主要面向基本的，日常的事务处理，如银行交易；OLAP 是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。6.4.3 大数据场景下的同与不同 在大数据时代,大数据仓库面对的最基本,最典型的场景还是传统的OLAP场景，最明显的区别是数据规模的急剧增长，从传统的单表千万到现在的单表百亿，万亿级，维度也从传统的几十个维度到现在的一些互联网企业的可能存在的万维。要解决传统数据仓库不能解决的扩展性和性能问题，需要从存储引擎和查询引擎两个层面进行优化。6.4.4 查询引擎 1.直方图技术。6.4.5 存储引擎1.Kudu2.Mesa6.5 小结为了应对BI领域少量更新和大量扫描分析场景，Kudu 借鉴了很多传统的数据仓库技术。在这个领域，目前是 Impala + Kudu/Hive/Spark SQL/Greenplum MPP 数据库在混战，
未来将走向融合，传统的MPP 数据库在分析领域可能会是一个过渡产品。相比传统数据仓库，大数据也有很多劣势：1.小数据量时比传统的MPP差，大数据量时不能满足交互式分析秒级响应的需求2.对sql的支持不充分等。所以业界有不少厂商在做这方面的探索，如Cloudera的Impala，星环的Inceptor，阿里的ADS，百度的Palo等。

6.大数据架构详解：从数据获取到深度学习 --- 交互式分析相关推荐

大数据架构详解从数据获取到深度学习读书笔记
我们将大数据按处理时间的跨度要求可以分为以下几类: 1 基于实时数据流的数据处理(streaming Data processing),通常的是假跨度在数百毫秒到数秒之间 2 基于历史数据的交互式查询 ...
《大数据架构详解：从数据获取到深度学习》第八次重印
第八次重印: 个人去年十月份出版的<大数据架构详解:从数据获取到深度学习>卖的还不错,京东,当当,亚马逊一直在热销榜上,一直排在前列,榜首常客! 既上个月重印之后,本月又重印了一次,累计八 ...
《大数据架构详解》一书第16次重印
又收到编辑寄的样书,看了下<大数据架构详解:从数据获取到深度学习>一书从16年10月出版以来,第16次重印. 京东评价超过2万条: 作者手上有少量全新样书,有想要签名样书的同学可以加作者微 ...
大数据架构详解：从数据获取到深度学习.pdf
大数据架构详解:从数据获取到深度学习.pdf ----------------------------- 作者:朱洁,罗华霖著出版社: 电子工业出版社 ISBN:9787121300004 版次: ...
为什么写《大数据架构详解》这本书
花了差不多一年半时间,牺牲了每个周末,费了九牛二虎之力,终于完成个人人生的第一本书<大数据架构详解:从数据获取到深度学习>.整个过程其实挺痛苦的,时常想放弃,幸好坚持下来了. 回想这我50 ...
喜大普奔，《大数据架构详解》一书登陆当当，京东热卖榜
2016-11-27 朱洁大数据和云计算技术最近加班太多,"江郎才尽了",这周不想写博客了,休息下. 讲点高兴的事情,我的新书<大数据架构详解>登陆当当,京东热卖榜 ...
《大数据架构详解》一书再版意见征集
<大数据架构详解:从数据获取到深度学习>这本书从2016年10月出版以来,一直在重印,早就超过3万本,在大数据和云计算专业领域里面卖的还可以的,多谢各位读者和朋友们的厚爱.对大数据技术有学 ...
《大数据架构详解》读后感
<大数据架构详解> -- 读后感作者:朱洁罗华霖出版商:中国工信出版社电子工业出版社版次:2016年10月第1版印数:7001 ~ 12000册定价:69.00元本书花了大 ...
大数据架构详解学习笔记
读书笔记书名<大数据结构详解–从数据获取到深度学习>,作者:朱洁罗华霖运营商大数据平台架构数据获取方法感兴趣章节 6.2.3 Linux 系统调优原理关于虚拟内存部分新了解的一 ...
2.大数据架构详解：从数据获取到深度学习 --- 运营商大数据架构
第2章运营商大数据架构 2.1 架构驱动的因素运营商面临着被管道化,营收下滑,大数据项目承担企业战略转型,数据变现的使命.互联网企业的大数据往往是承担业务创新,未来探索的一种驱动因素,所以对于架构 ...

6.大数据架构详解：从数据获取到深度学习 --- 交互式分析

6.大数据架构详解：从数据获取到深度学习 --- 交互式分析相关推荐

最新文章

热门文章