hbase数据分析,hbase 数据查询
北大青鸟java培训：Hbase知识点总结？
hbase概念:??非结构化的分布式的面向列存储非关系型的开源的数据库，根据谷歌的三大论文之一的bigtable??高宽厚表??作用:??为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题。
??能干什么:??存储大量结果集数据，低延迟的随机查询。
??sql:??结构化查询语言??nosql:??非关系型数据库，列存储和文档存储(查询低延迟),hbase是nosql的一个种类，其特点是列式存储。
??非关系型数据库--列存储(hbase)??非关系型数据库--文档存储(MongoDB)??非关系型数据库--内存式存储(redis)??非关系型数据库--图形模型(graph)??hive和hbase区别???Hive的定位是数据仓库，虽然也有增删改查，但其删改查对应的是整张表而不是单行数据，查询的延迟较高。
其本质是更加方便的使用mr的威力来进行离线分析的一个数据分析工具。
??HBase的定位是hadoop的数据库，电脑培训发现是一个典型的Nosql，所以HBase是用来在大量数据中进行低延迟的随机查询的。
??hbase运行方式:??standalonedistrubited??单节点和伪分布式???单节点:单独的进程运行在同一台机器上??hbase应用场景:??存储海量数据低延迟查询数据??hbase表由多行组成??hbase行一行在hbase中由行健和一个或多个列的值组成，按行健字母顺序排序的存储。
Spark 读取 Hbase 数据
下面这种方式是全表扫描，Spark如果通过RS来访问Hbase数据进行数据分析，对RS会产生很大的压力。不太建议使用下面的方式
在本地测试时返现运行的很慢，后来看到以下日志
由于Hbase表中只有两个region，所以只启动两个Task，此时并行度为二！
那么也就是说Spark读取Hbase的并行度取决于这个表有多少个region。然后根据region的startkey和endkey来获取数据
大数据技术之HBase原理分析
1）Client向HregionServer发送写请求；
2）HregionServer将数据写到HLog（write ahead log）。为了数据的持久化和恢复；
3）HregionServer将数据写到内存（MemStore）；
4）反馈Client写成功。
1）当MemStore数据达到阈值（默认是128M，老版本是64M），将数据刷到硬盘，将内存中的数据删除，同时删除HLog中的 历史 数据；
2）并将数据存储到HDFS中；
3）在HLog中做标记点。
1）当数据块达到4块，Hmaster将数据块加载到本地，进行合并；
2）当合并的数据超过256M，进行拆分，将拆分后的Region分配给不同的HregionServer管理；
3）当HregionServer宕机后，将HregionServer上的hlog拆分，然后分配给不同的HregionServer加载，修改.META；
4）注意：HLog会同步到HDFS。
1）Client先访问zookeeper，从meta表读取region的位置，然后读取meta表中的数据。meta中又存储了用户表的region信息；
2）根据namespace、表名和rowkey在meta表中找到对应的region信息；
3）找到这个region对应的regionserver；
4）查找对应的region；
5）先从MemStore找数据，如果没有，再到StoreFile上读(为了读取的效率)。
1）管理用户对Table的增、删、改、查操作；
2）记录region在哪台Hregion server上；
3）在Region Split后，负责新Region的分配；
4）新机器加入时，管理HRegion Server的负载均衡，调整Region分布；
5）在HRegion Server宕机后，负责失效HRegion Server 上的Regions迁移。
1）HRegion Server主要负责响应用户I/O请求，向HDFS文件系统中读写数据，是HBASE中最核心的模块。
2）HRegion Server管理了很多table的分区，也就是region。
1）HBASE Client使用HBASE的RPC机制与HMaster和RegionServer进行通信
2）管理类操作：Client与HMaster进行RPC；
3）数据读写类操作：Client与HRegionServer进行RPC。
文章转载链接：
HBase写数据的异常问题以及优化
本篇文章来说道说道如何诊断HBase写数据的异常问题以及优化写性能。和读相比，HBase写数据流程倒是显得很简单：数据先顺序写入HLog，再写入对应的缓存Memstore，当Memstore中数据大小达到一定阈值(128M)之后，系统会异步将Memstore中数据flush到HDFS形成小文件。
HBase数据写入通常会遇到两类问题，一类是写性能较差，另一类是数据根本写不进去。这两类问题的切入点也不尽相同，如下图所示：
写性能优化切入点
1. 是否需要写WAL?WAL是否需要同步写入?
优化原理：数据写入流程可以理解为一次顺序写WAL+一次写缓存，通常情况下写缓存延迟很低，因此提升写性能就只能从WAL入手。WAL机制一方面是为了确保数据即使写入缓存丢失也可以恢复，另一方面是为了集群之间异步复制。默认WAL机制开启且使用同步机制写入WAL。首先考虑业务是否需要写WAL，通常情况下大多数业务都会开启WAL机制(默认)，但是对于部分业务可能并不特别关心异常情况下部分数据的丢失，而更关心数据写入吞吐量，比如某些推荐业务，这类业务即使丢失一部分用户行为数据可能对推荐结果并不构成很大影响，但是对于写入吞吐量要求很高，不能造成数据队列阻塞。这种场景下可以考虑关闭WAL写入，写入吞吐量可以提升2x~3x。退而求其次，有些业务不能接受不写WAL，但可以接受WAL异步写入，也是可以考虑优化的，通常也会带来1x～2x的性能提升。
优化推荐：根据业务关注点在WAL机制与写入吞吐量之间做出选择
其他注意点：对于使用Increment操作的业务，WAL可以设置关闭，也可以设置异步写入，方法同Put类似。相信大多数Increment操作业务对WAL可能都不是那么敏感～
2. Put是否可以同步批量提交?
优化原理：HBase分别提供了单条put以及批量put的API接口，使用批量put接口可以减少客户端到RegionServer之间的RPC连接数，提高写入性能。另外需要注意的是，批量put请求要么全部成功返回，要么抛出异常。
优化建议：使用批量put进行写入请求
3. Put是否可以异步批量提交?
优化原理：业务如果可以接受异常情况下少量数据丢失的话，还可以使用异步批量提交的方式提交请求。提交分为两阶段执行：用户提交写请求之后，数据会写入客户端缓存，并返回用户写入成功;当客户端缓存达到阈值(默认2M)之后批量提交给RegionServer。需要注意的是，在某些情况下客户端异常的情况下缓存数据有可能丢失。
优化建议：在业务可以接受的情况下开启异步批量提交
使用方式：setAutoFlush(false)
4. Region是否太少?
优化原理：当前集群中表的Region个数如果小于RegionServer个数，即Num(Region of Table) Num(RegionServer)，可以考虑切分Region并尽可能分布到不同RegionServer来提高系统请求并发度，如果Num(Region of Table) Num(RegionServer)，再增加Region个数效果并不明显。
优化建议：在Num(Region of Table) Num(RegionServer)的场景下切分部分请求负载高的Region并迁移到其他RegionServer;
5. 写入请求是否不均衡?
优化原理：另一个需要考虑的问题是写入请求是否均衡，如果不均衡，一方面会导致系统并发度较低，另一方面也有可能造成部分节点负载很高，进而影响其他业务。分布式系统中特别害怕一个节点负载很高的情况，一个节点负载很高可能会拖慢整个集群，这是因为很多业务会使用Mutli批量提交读写请求，一旦其中一部分请求落到该节点无法得到及时响应，就会导致整个批量请求超时。因此不怕节点宕掉，就怕节点奄奄一息!
优化建议：检查RowKey设计以及预分区策略，保证写入请求均衡。
6. 写入KeyValue数据是否太大?
KeyValue大小对写入性能的影响巨大，一旦遇到写入性能比较差的情况，需要考虑是否由于写入KeyValue数据太大导致。KeyValue大小对写入性能影响曲线图如下：
图中横坐标是写入的一行数据(每行数据10列)大小，左纵坐标是写入吞吐量，右坐标是写入平均延迟(ms)。可以看出随着单行数据大小不断变大，写入吞吐量急剧下降，写入延迟在100K之后急剧增大。
说到这里，有必要和大家分享两起在生产线环境因为业务KeyValue较大导致的严重问题，一起是因为大字段业务写入导致其他业务吞吐量急剧下降，另一起是因为大字段业务scan导致RegionServer宕机。
案件一：大字段写入导致其他业务吞吐量急剧下降
部分业务反馈集群写入忽然变慢、数据开始堆积的情况，查看集群表级别的数据读写QPS监控，发现问题的第一个关键点：业务A开始写入之后整个集群其他部分业务写入QPS都几乎断崖式下跌，初步怀疑黑手就是业务A。
下图是当时业务A的写入QPS(事后发现脑残忘了截取其他表QPS断崖式下跌的惨象)，但是第一感觉是QPS并不高啊，凭什么去影响别人!
于是就继续查看其他监控信息，首先确认系统资源(主要是IO)并没有到达瓶颈，其次确认了写入的均衡性，直至看到下图，才追踪到影响其他业务写入的第二个关键点：RegionServer的handler(配置150)被残暴耗尽：
对比上面两张图，是不是发现出奇的一致，那就可以基本确认是由于该业务写入导致这台RegionServer的handler被耗尽，进而其他业务拿不到handler，自然写不进去。那问题来了，为什么会这样?正常情况下handler在处理完客户端请求之后会立马释放，唯一的解释是这些请求的延迟实在太大。
试想，我们去汉堡店排队买汉堡，有150个窗口服务，正常情况下大家买一个很快，这样150个窗口可能只需要50个服务。假设忽然来了一批大汉，要定制超大汉堡，好了，所有的窗口都工作起来，而且因为大汉堡不好制作导致服务很慢，这样必然会导致其他排队的用户长时间等待，直至超时。
可回头一想这可是写请求啊，怎么会有这么大的请求延迟!和业务方沟通之后确认该表主要存储语料库文档信息，都是平均100K左右的数据，是不是已经猜到了结果，没错，就是因为这个业务KeyValue太大导致。KeyValue太大会导致HLog文件写入频繁切换、flush以及compaction频繁触发，写入性能急剧下降。
目前针对这种较大KeyValue写入性能较差的问题还没有直接的解决方案，好在社区已经意识到这个问题，在接下来即将发布的下一个大版本HBase 2.0.0版本会针对该问题进行深入优化，详见 HBase MOB ，优化后用户使用HBase存储文档、图片等二进制数据都会有极佳的性能体验。
案件二：大字段scan导致RegionServer宕机
案件现场：有段时间有个0.98集群的RegionServer经常频繁宕机，查看日志是由于”java.lang.OutOfMemoryError: Requested array size exceeds VM limit”，如下图所示：
原因分析：通过查看源码以及相关文档，确认该异常发生在scan结果数据回传给客户端时由于数据量太大导致申请的array大小超过JVM规定的最大值( Interge.Max_Value-2)。造成该异常的两种最常见原因分别是：
表列太宽(几十万列或者上百万列)，并且scan返回没有对列数量做任何限制，导致一行数据就可能因为包含大量列而数据超过array大小阈值
KeyValue太大，并且scan返回没有对返回结果大小做任何限制，导致返回数据结果大小超过array大小阈值
有的童鞋就要提问啦，说如果已经对返回结果大小做了限制，在表列太宽的情况下是不是就可以不对列数量做限制呢。这里需要澄清一下，如果不对列数据做限制，数据总是一行一行返回的，即使一行数据大小大于设置的返回结果限制大小，也会返回完整的一行数据。在这种情况下，如果这一行数据已经超过array大小阈值，也会触发OOM异常。
解决方案：目前针对该异常有两种解决方案，其一是升级集群到1.0，问题都解决了。其二是要求客户端访问的时候对返回结果大小做限制(scan.setMaxResultSize(2*1024*1024))、并且对列数量做限制(scan.setBatch(100))，当然，0.98.13版本以后也可以对返回结果大小在服务器端进行限制，设置参数hbase.server.scanner.max.result.size即可
写异常问题检查点
上述几点主要针对写性能优化进行了介绍，除此之外，在一些情况下还会出现写异常，一旦发生需要考虑下面两种情况(GC引起的不做介绍)：
Memstore设置是否会触发Region级别或者RegionServer级别flush操作?
问题解析：以RegionServer级别flush进行解析，HBase设定一旦整个RegionServer上所有Memstore占用内存大小总和大于配置文件中upperlimit时，系统就会执行RegionServer级别flush，flush算法会首先按照Region大小进行排序，再按照该顺序依次进行flush，直至总Memstore大小低至lowerlimit。这种flush通常会block较长时间，在日志中会发现“ Memstore is above high water mark and block 7452 ms”，表示这次flush将会阻塞7s左右。
问题检查点：
Region规模与Memstore总大小设置是否合理?如果RegionServer上Region较多，而Memstore总大小设置的很小(JVM设置较小或者upper.limit设置较小)，就会触发RegionServer级别flush。集群规划相关内容可以参考文章《》
列族是否设置过多，通常情况下表列族建议设置在1～3个之间，最好一个。如果设置过多，会导致一个Region中包含很多Memstore，导致更容易触到高水位upperlimit
Store中HFile数量是否大于配置参数blockingStoreFile?
问题解析：对于数据写入很快的集群，还需要特别关注一个参数：hbase.hstore.blockingStoreFiles，此参数表示如果当前hstore中文件数大于该值，系统将会强制执行compaction操作进行文件合并，合并的过程会阻塞整个hstore的写入。通常情况下该场景发生在数据写入很快的情况下，在日志中可以发现” Waited 3722ms on a compaction to clean up ‘too many store files “
问题检查点：
参数设置是否合理? hbase.hstore.compactionThreshold表示启动compaction的最低阈值，该值不能太大，否则会积累太多文件，一般建议设置为5～8左右。 hbase.hstore.blockingStoreFiles默认设置为7，可以适当调大一些。
写性能还能再提高么?
上文已经从写性能优化以及写异常诊断两个方面对HBase中数据写入可能的问题进行了详细的解释，相信在0.98版本的基础上对写入来说已经是最好的解决方案了。但是有些业务可能依然觉得不够快，毕竟”更快”是所有存储系统活着的动力，那还有提高空间吗?当然，接下来简单介绍HBase之后版本对写性能优化的两点核心改进：
Utilize Flash storage for WAL(HBASE-12848)
这个特性意味着可以将WAL单独置于SSD上，这样即使在默认情况下(WALSync)，写性能也会有很大的提升。需要注意的是，该特性建立在HDFS 2.6.0+的基础上，HDFS以前版本不支持该特性。具体可以参考官方jira：
Multiple WALs(HBASE-14457)
该特性也是对WAL进行改造，当前WAL设计为一个RegionServer上所有Region共享一个WAL，可以想象在写入吞吐量较高的时候必然存在资源竞争，降低整体性能。针对这个问题，社区小伙伴(阿里巴巴大神)提出Multiple WALs机制，管理员可以为每个Namespace下的所有表设置一个共享WAL，通过这种方式，写性能大约可以提升20%～40%左右。
大数据三大核心技术：拿数据、算数据、卖数据！
大数据的由来
对于“大数据”（Big data）研究机构Gartner给出了这样的定义。“大数据”是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力来适应海量、高增长率和多样化的信息资产。
1
麦肯锡全球研究所给出的定义是：一种规模大到在获取、存储、管理、分析方面大大超出了传统数据库软件工具能力范围的数据集合，具有海量的数据规模、快速的数据流转、多样的数据类型和价值密度低四大特征。
大数据技术的战略意义不在于掌握庞大的数据信息，而在于对这些含有意义的数据进行专业化处理。换而言之，如果把大数据比作一种产业，那么这种产业实现盈利的关键，在于提高对数据的“加工能力”，通过“加工”实现数据的“增值”。
从技术上看，大数据与云计算的关系就像一枚硬币的正反面一样密不可分。大数据必然无法用单台的计算机进行处理，必须采用分布式架构。它的特色在于对海量数据进行分布式数据挖掘。但它必须依托云计算的分布式处理、分布式数据库和云存储、虚拟化技术。
大数据需要特殊的技术，以有效地处理大量的容忍经过时间内的数据。适用于大数据的技术，包括大规模并行处理（MPP）数据库、数据挖掘、分布式文件系统、分布式数据库、云计算平台、互联网和可扩展的存储系统。
最小的基本单位是bit，按顺序给出所有单位：bit、Byte、KB、MB、GB、TB、PB、EB、ZB、YB、BB、NB、DB。
大数据的应用领域
大数据无处不在，大数据应用于各个行业，包括金融、 汽车 、餐饮、电信、能源、体能和 娱乐 等在内的 社会 各行各业都已经融入了大数据的印迹。
制造业，利用工业大数据提升制造业水平，包括产品故障诊断与预测、分析工艺流程、改进生产工艺，优化生产过程能耗、工业供应链分析与优化、生产计划与排程。
金融行业，大数据在高频交易、社交情绪分析和信贷风险分析三大金融创新领域发挥重大作用。
汽车 行业，利用大数据和物联网技术的无人驾驶 汽车 ，在不远的未来将走入我们的日常生活。
互联网行业，借助于大数据技术，可以分析客户行为，进行商品推荐和针对性广告投放。
电信行业，利用大数据技术实现客户离网分析，及时掌握客户离网倾向，出台客户挽留措施。
能源行业，随着智能电网的发展，电力公司可以掌握海量的用户用电信息，利用大数据技术分析用户用电模式，可以改进电网运行，合理设计电力需求响应系统，确保电网运行安全。
物流行业，利用大数据优化物流网络，提高物流效率，降低物流成本。
城市管理，可以利用大数据实现智能交通、环保监测、城市规划和智能安防。
体育 娱乐 ，大数据可以帮助我们训练球队，决定投拍哪种 题财的 影视作品，以及预测比赛结果。
安全领域，政府可以利用大数据技术构建起强大的国家安全保障体系，企业可以利用大数据抵御网络攻击，警察可以借助大数据来预防犯罪。
个人生活， 大数据还可以应用于个人生活，利用与每个人相关联的“个人大数据”，分析个人生活行为习惯，为其提供更加周到的个性化服务。
大数据的价值，远远不止于此，大数据对各行各业的渗透，大大推动了 社会 生产和生活，未来必将产生重大而深远的影响。
大数据方面核心技术有哪些？
大数据技术的体系庞大且复杂，基础的技术包含数据的采集、数据预处理、分布式存储、NoSQL数据库、数据仓库、机器学习、并行计算、可视化等各种技术范畴和不同的技术层面。首先给出一个通用化的大数据处理框架，主要分为下面几个方面：数据采集与预处理、数据存储、数据清洗、数据查询分析和数据可视化。
数据采集与预处理
对于各种来源的数据，包括移动互联网数据、社交网络的数据等，这些结构化和非结构化的海量数据是零散的，也就是所谓的数据孤岛，此时的这些数据并没有什么意义，数据采集就是将这些数据写入数据仓库中，把零散的数据整合在一起，对这些数据综合起来进行分析。数据采集包括文件日志的采集、数据库日志的采集、关系型数据库的接入和应用程序的接入等。在数据量比较小的时候，可以写个定时的脚本将日志写入存储系统，但随着数据量的增长，这些方法无法提供数据安全保障，并且运维困难，需要更强壮的解决方案。
Flume NG
Flume NG作为实时日志收集系统，支持在日志系统中定制各类数据发送方，用于收集数据，同时，对数据进行简单处理，并写到各种数据接收方(比如文本，HDFS，Hbase等)。Flume NG采用的是三层架构：Agent层，Collector层和Store层，每一层均可水平拓展。其中Agent包含Source，Channel和 Sink，source用来消费(收集)数据源到channel组件中，channel作为中间临时存储，保存所有source的组件信息，sink从channel中读取数据，读取成功之后会删除channel中的信息。
NDC
Logstash
Logstash是开源的服务器端数据处理管道，能够同时从多个来源采集数据、转换数据，然后将数据发送到您最喜欢的 “存储库” 中。一般常用的存储库是Elasticsearch。Logstash 支持各种输入选择，可以在同一时间从众多常用的数据来源捕捉事件，能够以连续的流式传输方式，轻松地从您的日志、指标、Web 应用、数据存储以及各种 AWS 服务采集数据。
Sqoop
Sqoop，用来将关系型数据库和Hadoop中的数据进行相互转移的工具，可以将一个关系型数据库(例如Mysql、Oracle)中的数据导入到Hadoop(例如HDFS、Hive、Hbase)中，也可以将Hadoop(例如HDFS、Hive、Hbase)中的数据导入到关系型数据库(例如Mysql、Oracle)中。Sqoop 启用了一个 MapReduce 作业(极其容错的分布式并行计算)来执行任务。Sqoop 的另一大优势是其传输大量结构化或半结构化数据的过程是完全自动化的。
流式计算
流式计算是行业研究的一个热点，流式计算对多个高吞吐量的数据源进行实时的清洗、聚合和分析，可以对存在于社交网站、新闻等的数据信息流进行快速的处理并反馈，目前大数据流分析工具有很多，比如开源的strom，spark streaming等。
Strom集群结构是有一个主节点(nimbus)和多个工作节点(supervisor)组成的主从结构，主节点通过配置静态指定或者在运行时动态选举，nimbus与supervisor都是Storm提供的后台守护进程，之间的通信是结合Zookeeper的状态变更通知和监控通知来处理。nimbus进程的主要职责是管理、协调和监控集群上运行的topology(包括topology的发布、任务指派、事件处理时重新指派任务等)。supervisor进程等待nimbus分配任务后生成并监控worker(jvm进程)执行任务。supervisor与worker运行在不同的jvm上，如果由supervisor启动的某个worker因为错误异常退出(或被kill掉)，supervisor会尝试重新生成新的worker进程。
Zookeeper
Zookeeper是一个分布式的，开放源码的分布式应用程序协调服务，提供数据同步服务。它的作用主要有配置管理、名字服务、分布式锁和集群管理。配置管理指的是在一个地方修改了配置，那么对这个地方的配置感兴趣的所有的都可以获得变更，省去了手动拷贝配置的繁琐，还很好的保证了数据的可靠和一致性，同时它可以通过名字来获取资源或者服务的地址等信息，可以监控集群中机器的变化，实现了类似于心跳机制的功能。
数据存储
Hadoop作为一个开源的框架，专为离线和大规模数据分析而设计，HDFS作为其核心的存储引擎，已被广泛用于数据存储。
HBase
HBase，是一个分布式的、面向列的开源数据库，可以认为是hdfs的封装，本质是数据存储、NoSQL数据库。HBase是一种Key/Value系统，部署在hdfs上，克服了hdfs在随机读写这个方面的缺点，与hadoop一样，Hbase目标主要依靠横向扩展，通过不断增加廉价的商用服务器，来增加计算和存储能力。
Phoenix
Phoenix，相当于一个Java中间件，帮助开发工程师能够像使用JDBC访问关系型数据库一样访问NoSQL数据库HBase。
Yarn
Yarn是一种Hadoop资源管理器，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。Yarn由下面的几大组件构成：一个全局的资源管理器ResourceManager、ResourceManager的每个节点代理NodeManager、表示每个应用的Application以及每一个ApplicationMaster拥有多个Container在NodeManager上运行。
Mesos
Mesos是一款开源的集群管理软件，支持Hadoop、ElasticSearch、Spark、Storm 和Kafka等应用架构。
Redis
Redis是一种速度非常快的非关系数据库，可以存储键与5种不同类型的值之间的映射，可以将存储在内存的键值对数据持久化到硬盘中，使用复制特性来扩展性能，还可以使用客户端分片来扩展写性能。
Atlas
Atlas是一个位于应用程序与MySQL之间的中间件。在后端DB看来，Atlas相当于连接它的客户端，在前端应用看来，Atlas相当于一个DB。Atlas作为服务端与应用程序通讯，它实现了MySQL的客户端和服务端协议，同时作为客户端与MySQL通讯。它对应用程序屏蔽了DB的细节，同时为了降低MySQL负担，它还维护了连接池。Atlas启动后会创建多个线程，其中一个为主线程，其余为工作线程。主线程负责监听所有的客户端连接请求，工作线程只监听主线程的命令请求。
Kudu
Kudu是围绕Hadoop生态圈建立的存储引擎，Kudu拥有和Hadoop生态圈共同的设计理念，它运行在普通的服务器上、可分布式规模化部署、并且满足工业界的高可用要求。其设计理念为fast analytics on fast data。作为一个开源的存储引擎，可以同时提供低延迟的随机读写和高效的数据分析能力。Kudu不但提供了行级的插入、更新、删除API，同时也提供了接近Parquet性能的批量扫描操作。使用同一份存储，既可以进行随机读写，也可以满足数据分析的要求。Kudu的应用场景很广泛，比如可以进行实时的数据分析，用于数据可能会存在变化的时序数据应用等。
在数据存储过程中，涉及到的数据表都是成千上百列，包含各种复杂的Query，推荐使用列式存储方法，比如parquent,ORC等对数据进行压缩。Parquet 可以支持灵活的压缩选项，显著减少磁盘上的存储。
数据清洗
MapReduce作为Hadoop的查询引擎，用于大规模数据集的并行计算，”Map(映射)”和”Reduce(归约)”，是它的主要思想。它极大的方便了编程人员在不会分布式并行编程的情况下，将自己的程序运行在分布式系统中。
随着业务数据量的增多，需要进行训练和清洗的数据会变得越来越复杂，这个时候就需要任务调度系统，比如oozie或者azkaban，对关键任务进行调度和监控。
Oozie
Oozie是用于Hadoop平台的一种工作流调度引擎，提供了RESTful API接口来接受用户的提交请求(提交工作流作业)，当提交了workflow后，由工作流引擎负责workflow的执行以及状态的转换。用户在HDFS上部署好作业(MR作业)，然后向Oozie提交Workflow，Oozie以异步方式将作业(MR作业)提交给Hadoop。这也是为什么当调用Oozie 的RESTful接口提交作业之后能立即返回一个JobId的原因，用户程序不必等待作业执行完成(因为有些大作业可能会执行很久(几个小时甚至几天))。Oozie在后台以异步方式，再将workflow对应的Action提交给hadoop执行。
Azkaban
Azkaban也是一种工作流的控制引擎，可以用来解决有多个hadoop或者spark等离线计算任务之间的依赖关系问题。azkaban主要是由三部分构成：Relational Database，Azkaban Web Server和Azkaban Executor Server。azkaban将大多数的状态信息都保存在MySQL中，Azkaban Web Server提供了Web UI，是azkaban主要的管理者，包括project的管理、认证、调度以及对工作流执行过程中的监控等;Azkaban Executor Server用来调度工作流和任务，记录工作流或者任务的日志。
流计算任务的处理平台Sloth，是网易首个自研流计算平台，旨在解决公司内各产品日益增长的流计算需求。作为一个计算服务平台，其特点是易用、实时、可靠，为用户节省技术方面(开发、运维)的投入，帮助用户专注于解决产品本身的流计算需求
数据查询分析
Hive
Hive的核心工作就是把SQL语句翻译成MR程序，可以将结构化的数据映射为一张数据库表，并提供 HQL(Hive SQL)查询功能。Hive本身不存储和计算数据，它完全依赖于HDFS和MapReduce。可以将Hive理解为一个客户端工具，将SQL操作转换为相应的MapReduce jobs，然后在hadoop上面运行。Hive支持标准的SQL语法，免去了用户编写MapReduce程序的过程，它的出现可以让那些精通SQL技能、但是不熟悉MapReduce 、编程能力较弱与不擅长Java语言的用户能够在HDFS大规模数据集上很方便地利用SQL 语言查询、汇总、分析数据。
Hive是为大数据批量处理而生的，Hive的出现解决了传统的关系型数据库(MySql、Oracle)在大数据处理上的瓶颈 。Hive 将执行计划分成map-shuffle-reduce-map-shuffle-reduce…的模型。如果一个Query会被编译成多轮MapReduce，则会有更多的写中间结果。由于MapReduce执行框架本身的特点，过多的中间过程会增加整个Query的执行时间。在Hive的运行过程中，用户只需要创建表，导入数据，编写SQL分析语句即可。剩下的过程由Hive框架自动的完成。
Impala
Impala是对Hive的一个补充，可以实现高效的SQL查询。使用Impala来实现SQL on Hadoop，用来进行大数据实时查询分析。通过熟悉的传统关系型数据库的SQL风格来操作大数据，同时数据也是可以存储到HDFS和HBase中的。Impala没有再使用缓慢的Hive+MapReduce批处理，而是通过使用与商用并行关系数据库中类似的分布式查询引擎(由Query Planner、Query Coordinator和Query Exec Engine三部分组成)，可以直接从HDFS或HBase中用SELECT、JOIN和统计函数查询数据，从而大大降低了延迟。Impala将整个查询分成一执行计划树，而不是一连串的MapReduce任务，相比Hive没了MapReduce启动时间。
Hive 适合于长时间的批处理查询分析，而Impala适合于实时交互式SQL查询，Impala给数据人员提供了快速实验，验证想法的大数据分析工具，可以先使用Hive进行数据转换处理，之后使用Impala在Hive处理好后的数据集上进行快速的数据分析。总的来说：Impala把执行计划表现为一棵完整的执行计划树，可以更自然地分发执行计划到各个Impalad执行查询，而不用像Hive那样把它组合成管道型的map-reduce模式，以此保证Impala有更好的并发性和避免不必要的中间sort与shuffle。但是Impala不支持UDF，能处理的问题有一定的限制。
Spark
Spark拥有Hadoop MapReduce所具有的特点，它将Job中间输出结果保存在内存中，从而不需要读取HDFS。Spark 启用了内存分布数据集，除了能够提供交互式查询外，它还可以优化迭代工作负载。Spark 是在 Scala 语言中实现的，它将 Scala 用作其应用程序框架。与 Hadoop 不同，Spark 和 Scala 能够紧密集成，其中的 Scala 可以像操作本地集合对象一样轻松地操作分布式数据集。
Nutch
Nutch 是一个开源Java 实现的搜索引擎。它提供了我们运行自己的搜索引擎所需的全部工具，包括全文搜索和Web爬虫。
Solr
Solr用Java编写、运行在Servlet容器(如Apache Tomcat或Jetty)的一个独立的企业级搜索应用的全文搜索服务器。它对外提供类似于Web-service的API接口，用户可以通过http请求，向搜索引擎服务器提交一定格式的XML文件，生成索引;也可以通过Http Get操作提出查找请求，并得到XML格式的返回结果。
Elasticsearch
Elasticsearch是一个开源的全文搜索引擎，基于Lucene的搜索服务器，可以快速的储存、搜索和分析海量的数据。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。
还涉及到一些机器学习语言，比如，Mahout主要目标是创建一些可伸缩的机器学习算法，供开发人员在Apache的许可下免费使用;深度学习框架Caffe以及使用数据流图进行数值计算的开源软件库TensorFlow等，常用的机器学习算法比如，贝叶斯、逻辑回归、决策树、神经网络、协同过滤等。
数据可视化
对接一些BI平台，将分析得到的数据进行可视化，用于指导决策服务。主流的BI平台比如，国外的敏捷BI Tableau、Qlikview、PowrerBI等，国内的SmallBI和新兴的网易有数等。
在上面的每一个阶段，保障数据的安全是不可忽视的问题。
基于网络身份认证的协议Kerberos，用来在非安全网络中，对个人通信以安全的手段进行身份认证，它允许某实体在非安全网络环境下通信，向另一个实体以一种安全的方式证明自己的身份。
控制权限的ranger是一个Hadoop集群权限框架，提供操作、监控、管理复杂的数据权限，它提供一个集中的管理机制，管理基于yarn的Hadoop生态圈的所有数据权限。可以对Hadoop生态的组件如Hive，Hbase进行细粒度的数据访问控制。通过操作Ranger控制台，管理员可以轻松的通过配置策略来控制用户访问HDFS文件夹、HDFS文件、数据库、表、字段权限。这些策略可以为不同的用户和组来设置，同时权限可与hadoop无缝对接。
简单说有三大核心技术：拿数据，算数据，卖数据。
使用kylin来分析我们Hbase当中的数据
前面我们已经通过flink将数据介入到了hbase当中去了，那么我们接下来就可以通过hive整合hbase，将hbase当中的数据映射到hive表当中来，然后通过kylin来对hive当中的数据进行预分析，实现实时数仓的统计功能
第一步：拷贝hbase的五个jar包到hive的lib目录下
将我们HBase的五个jar包拷贝到hive的lib目录下
hbase的jar包都在/kkb/install/hbase-1.2.0-cdh5.14.2/lib
我们需要拷贝五个jar包名字如下
hbase-client-1.2.0-cdh5.14.2.jar
hbase-hadoop2-compat-1.2.0-cdh5.14.2.jar
hbase-hadoop-compat-1.2.0-cdh5.14.2.jar
hbase-it-1.2.0-cdh5.14.2.jar
hbase-server-1.2.0-cdh5.14.2.jar
我们直接在node03执行以下命令，通过创建软连接的方式来进行jar包的依赖
ln -s /kkb/install/hbase-1.2.0-cdh5.14.2/lib/hbase-client-1.2.0-cdh5.14.2.jar /kkb/install/hive-1.1.0-cdh5.14.2/lib/hbase-client-1.2.0-cdh5.14.2.jar
ln -s /kkb/install/hbase-1.2.0-cdh5.14.2/lib/hbase-hadoop2-compat-1.2.0-cdh5.14.2.jar /kkb/install/hive-1.1.0-cdh5.14.2/lib/hbase-hadoop2-compat-1.2.0-cdh5.14.2.jar
ln -s /kkb/install/hbase-1.2.0-cdh5.14.2/lib/hbase-hadoop-compat-1.2.0-cdh5.14.2.jar /kkb/install/hive-1.1.0-cdh5.14.2/lib/hbase-hadoop-compat-1.2.0-cdh5.14.2.jar
ln -s /kkb/install/hbase-1.2.0-cdh5.14.2/lib/hbase-it-1.2.0-cdh5.14.2.jar /kkb/install/hive-1.1.0-cdh5.14.2/lib/hbase-it-1.2.0-cdh5.14.2.jar
ln -s /kkb/install/hbase-1.2.0-cdh5.14.2/lib/hbase-server-1.2.0-cdh5.14.2.jar /kkb/install/hive-1.1.0-cdh5.14.2/lib/hbase-server-1.2.0-cdh5.14.2.jar
第二步：修改hive的配置文件
编辑node03服务器上面的hive的配置文件hive-site.xml添加以下两行配置
cd /kkb/install/hive-1.1.0-cdh5.14.2/conf
vim hive-site.xml
property
namehive.zookeeper.quorum/name
valuenode01,node02,node03/value
/property
第三步：修改hive-env.sh配置文件添加以下配置
cd /kkb/install/hive-1.1.0-cdh5.14.2/conf
vim hive-env.sh
export HADOOP_HOME=/kkb/install/hadoop-2.6.0-cdh5.14.2
export HBASE_HOME=/kkb/install/hbase-1.2.0-cdh5.14.2/
export HIVE_CONF_DIR=/kkb/install/hive-1.1.0-cdh5.14.2/conf
第四步：创建hive表，映射hbase当中的数据
进入hive客户端，创建hive映射表，映射hbase当中的两张表数据
create database hive_hbase;
use hive_hbase;
CREATE external TABLE hive_hbase.data_goods(goodsId int ,goodsName string ,sellingPrice string ,productPic string ,productBrand string ,productfbl string ,productNum string ,productUrl string ,productFrom string ,goodsStock int , appraiseNum int)
STORED BY 'org.apache.hadoop.hive.hbase.HBaseStorageHandler' WITH SERDEPROPERTIES
("hbase.columns.mapping" = ":key,f1:goodsName ,f1:sellingPrice ,f1:productPic ,f1:productBrand ,f1:productfbl ,f1:productNum ,f1:productUrl ,f1:productFrom ,f1:goodsStock , f1:appraiseNum")
TBLPROPERTIES("hbase.table.name" ="flink:data_goods");
CREATE external TABLE hive_hbase.data_orders(orderId int,orderNo string ,userId int,goodId int ,goodsMoney decimal(11,2) ,realTotalMoney decimal(11,2) ,payFrom int ,province string ,createTime timestamp )
STORED BY 'org.apache.hadoop.hive.hbase.HBaseStorageHandler' WITH SERDEPROPERTIES
("hbase.columns.mapping" = ":key, f1:orderNo , f1:userId , f1:goodId , f1:goodsMoney ,f1:realTotalMoney,f1:payFrom ,f1:province,f1:createTime")
TBLPROPERTIES("hbase.table.name" ="flink:data_orders");
第五步：在kylin当中对我们hive的数据进行多维度分析
直接登录kylin的管理界面，对我们hive当中的数据进行多维度分析