Apache HBase

HBase模式案例日志数据和时间序列数据

狂风中的少年 提交于 2020-04-11 12:08:07
感谢平台分享- http://bjbsair.com/2020-04-10/tech-info/53339.html 本文为你介绍了 HBase 模式案例之一:日志数据和时间序列数据 假设正在收集以下数据元素。 主机名(Hostname) 时间戳(timestamp) 日志事件(Log event) 值/消息(Value/message) 我们可以将它们存储在名为 LOG_DATA 的 HBase 表中,但 rowkey 会是什么呢?从这些属性中,rowkey 将是主机名,时间戳和日志事件的一些组合,但具体是什么? 行密钥(Rowkey)主导位置中的时间戳(Timestamp) rowkey [timestamp][hostname][log-event] 受单调递增的行键/时间戳数据(Monotonically Increasing Row Keys/Timeseries Data)中描述的单调增长 rowkey 问题的影响。 通过在时间戳上执行 mod 操作,在关于 "bucketing" 时间戳的 dist-lists 中经常提到另一种模式。如果时间扫描很重要,这可能是一个有用的方法。必须注意 bucket 的数量,因为这需要相同数量的扫描来返回结果。 构造: 如上所述,要选择特定时间范围(timerange)的数据,需要为每个存储 bucket 执行 Scan。例如

HBase模式案例研究列表数据

谁说胖子不能爱 提交于 2020-04-11 12:07:23
感谢平台分享- http://bjbsair.com/2020-04-10/tech-info/53341.html 以下是用户 dist-list 中关于一个相当常见问题的的交流:如何处理 Apache HBase 中的每个用户列表数据。 问题: 我们正在研究如何在 HBase 中存储大量(每用户)列表数据,并且我们试图弄清楚哪种访问模式最有意义。一种选择是将大部分数据存储在一个密钥中,所以我们可以有如下的内容: 我们的另一个选择是完全使用如下内容: 每行将包含多个值。所以在一种情况下,读取前三十个值将是: 而在第二种情况下会是这样: 一般的使用模式是只读取这些列表的前30个值,并且很少的访问会深入到列表中。一些用户在这些列表中总共有30个值,并且一些用户将拥有数百万(即幂律分布)。 单值格式似乎会占用 HBase 上的更多空间,但会提供一些改进的检索/分页灵活性。是否有任何显着的性能优势能够通过获取和扫描的页面进行分页? 我最初的理解是,如果我们的分页大小未知(并且缓存设置恰当),那么执行扫描应该会更快,但如果我们始终需要相同的页面大小,则扫描速度应该更快。我听到不同的人告诉了我关于表现的相反事情。我假设页面大小会相对一致,所以对于大多数使用情况,我们可以保证我们只需要固定页面长度的情况下的一页数据。我还会假设我们将不经常更新,但可能会插入这些列表的中间

基于Flink流处理的动态实时电商实时分析系统

女生的网名这么多〃 提交于 2020-04-11 08:51:03
在开始学习前给大家说下什么是Flink? 1. Flink 是一个针对流数据和批数据的分布式处理引擎,主要用Java代码实现。 2.Apache Flink作为Apache的顶级项目,Flink集众多优点于一身,包括快速、可靠可扩展、完全兼容Hadoop、使用简便、表现卓越。 通过以上的描述大家对Flink有了一个基本的认识,本套课程不会讲解基础内容,因此建议有Flink基础的同学进行认购。 开始学习前建议大家认真阅读下文: 随着人工智能时代的降临,数据量的爆发,在典型的大数据的业务场景下数据业务最通用的做法是:选用批处理的技术处理全量数据,采用流式计算处理实时增量数据。在绝大多数的业务场景之下,用户的业务逻辑在批处理和流处理之中往往是相同的。但是,用户用于批处理和流处理的两套计算引擎是不同的。 因此,用户通常需要写两套代码。毫无疑问,这带来了一些额外的负担和成本。阿里巴巴的商品数据处理就经常需要面对增量和全量两套不同的业务流程问题,所以阿里就在想,我们能不能有一套统一的大数据引擎技术,用户只需要根据自己的业务逻辑开发一套代码。这样在各种不同的场景下,不管是全量数据还是增量数据,亦或者实时处理,一套方案即可全部支持,这就是阿里选择Flink的背景和初衷。 随着互联网不断发展,数据量不断的增加,大数据也是快速的发展起来了。对于电商系统,拥有着庞大的数据量,对于这么庞大的数据

读者来信 | 如何判断HBase Major Compact是否执行完毕?(已解决)

落花浮王杯 提交于 2020-04-10 13:47:47
前言: 之前有朋友加好友与我探讨一些问题,我觉得这些问题倒挺有价值的;于是就想在本公众号开设一个问答专栏,方便技术交流与分享,专栏名就定为: 《读者来信》 。欢迎关注本人微信公众号《HBase工作笔记》,扫描文末二维码解锁更多姿势! 来信人:罗*铭 小猿提问 如何判断HBase Major Compact是否执行完毕? 小猿解答 这里提供两种查看方式: 一种是HBase WebUI 界面; 另外一种是HBase Shell命令行 。 我们下面看一下。 1. HBase WebUI 点击Web首页 Compactions 按钮查看每一个RS Compact完成情况; 点击 ServerName 进入RS Web页后点击 Compaction Metrics 可查看该RS上每一个Region Compact 完成情况。 2. HBase Shell 通过Shell方式查看同WebUI查看大同小异,只不过没有将这些指标可视化而已。如果有兴趣,可以自己采集这些指标做一个漂亮的监控界面~ 通过命令 status 'simple' 可查看HBase RS级别的一些指标,其中 compactionProgressPct= 1.0 即表明RS Compact完成。如下: hbase(main):002:0> status 'simple' active master: xxx.xx.xx.xx

从零开始学数据库mysql--数据库的简介

五迷三道 提交于 2020-04-10 11:20:14
数据库介绍 什么是数据库 数据库是是按照数据结构来组织、存储和管理数据的仓库 数据库的发展史 最早的数据库: 通过大量的分类、比较和表格绘制的机器运行数百万穿孔卡片来进行数据的处理,其运行结果在纸上打印出来或者制成新的穿孔卡片。 而数据管理就是对所有这些穿孔卡片进行物理的储存和处理。 现在的数据库 当时计算机开始广泛地应用于数据管理,对数据的共享提出了越来越高的要求。传统的文件系统已经不能满足人们的需要。能够统一管理和共享数据的数据库管理系统(DBMS)应运而生。 数据库管理系统DBMS 数据库是一种操纵和管理数据库的大型软件,用于建立、使用和维护数据库,简称DBMS。 它对数据库进行统一的管理和控制,以保证数据库的安全性和完整性。 用户通过DBMS访问数据库中的数据,数据库管理员也通过dbms进行数据库的维护工作。 数据库管理系统是数据库系统的核心,是管理数据库的软件。 我们一般说的数据库,就是指的DBMS: 数据库服务器 常见的数据库 Oracle:运行稳定,可移植性高,功能齐全,性能超群!适用于大型企业领域。 DB2:速度快、可靠性好,适于海量数据,恢复性极强。适用于大中型企业领域。 MySQL:开源,体积小,速度快。适用于于中小型企业领域。 SQL Server:全面,效率高,界面友好,操作容易,但是不跨平台。适用于于中小型企业领域。 结构化查询语言SQL

面试题汇总

扶醉桌前 提交于 2020-04-10 10:47:04
基础问题 linux和网络基础 (1)linux系统内核态和用户态是什么,有什么区别? (2)BIO、NIO、AIO都是什么,有什么区别? (3)TCP和UDP的区别? (4)详细叙述TCP3次握手,TCP和HTTP的区别,其中字节面试官问的最细,他会具体问TCP底层的3次握手的具体实现逻辑,第三次握手如果失败会怎样。 建议把TCP关闭时的4次挥手也看看,敖丙的文章就有,看了至少表面的东西难不倒你们,由于这个是最基础的问题,如果回答不好,面试官的印象分就你懂得。 (5)rpc和http的区别,你知道有什么rpc框架。 (6)https相对http都实现了什么加密方式,是对称加密还是非对称加密? (7)用linux命令怎么做分组求和,怎么把字符串根据分隔符变成数组(这里建议大家读读敖丙的linux命令篇) JVM基础 (1)简要介绍一下JVM虚拟机(这个问题不是把JVM分成JMM,类加载和GC来问,一定要想好怎么描述JVM) (2)简述一次GC的过程(Minor gc和Major gc过程还记得么) (3)JMM是什么? (4)JVM共享内存都有什么,什么是堆外内存? (5)GC区域,垃圾回收算法,垃圾回收器,G1、CMS、ParNew等垃圾回收器的简介和之间的区别。 (6)类加载过程(5个过程最好能研究明白,因为还涉及到栈帧、局部表量表、操作数栈、动态链接和方法出口等知识

HBase生产环境配置与使用优化不完全指南

六月ゝ 毕业季﹏ 提交于 2020-04-10 09:37:35
HBase上线至今,承载了线上所有实时交易量,虽然大部分请求都能够保证服务稳定(99.56%响应时间毫秒级),但是一旦HBase出现问题就是鸡飞狗跳的灾难。 从老机器到新集群,从老机房到新机房,期间经历过各种问题和生产故障,总结一番以备不时之需。 HBase使用定位: 大规模数据+高并发+毫秒级响应的OLTP实时系统(数据库)。 集群部署架构 HBase集群一旦部署使用,再想对其作出调整需要付出惨痛代价,所以 如何部署HBase集群是使用的第一个关键步骤。 以下是HBase集群使用以来的部署架构变化以及对应的分析。 第一阶段 硬件混合型+软件混合型集群 集群规模:20 部署服务:HBase、Spark、Hive、Impala、Kafka、Zookeeper、Flume、HDFS、Yarn等 硬件情况:内存、CPU、磁盘等参差不齐,有高配有低配,混搭结构 硬件混合型指的是该集群机器配置参差不齐,混搭结构。 软件混合型指的是该集群部署了一套CDH全家桶套餐。 这个集群不管是规模、还是服务部署方式相信都是很多都有公司的”标准“配置。 那么这样的集群有什么问题呢? 如果仅仅HBase是一个非“线上”的系统,或者充当一个历史冷数据存储的大数据库,这样的集群其实一点问题也没有,因为对其没有任何苛刻的性能要求。 但是如果希望HBase作为一个 线上能够承载海量并发、实时响应的系统

Docker上安装运行Hbase

谁都会走 提交于 2020-04-09 18:40:16
下载安装Hbase docker search hbase : 查找Hbase docker pull harisekhon/hbase:1.3 注意:不要安装最新版本的,不稳定 (我安装的是1.3) 运行Hbase(运行时指定主机名,端口映射等) docker run -d --name hbase001 -P harisekhon/hbase:1.3 或 ocker run -d --name hbase001 -p 16010:16010 harisekhon/hbase:1.3 或 docker run -d -h myhbase -p 2181:2181 -p 8080:8080 -p 8085:8085 -p 9090:9090 -p 9095:9095 -p 16000:16000 -p 16010:16010 -p 16201:16201 -p 16301:16301 --name hbase1.3 harisekhon/hbase:1.3 -p : 指定主机的端口 16010映射到宿主机上(容器)的开放端口 16010 -P :主机随机分配端口与宿主机上的端口进行映射 注意:hbase60010端口无法访问web页面,web端访问的接口变更为16010 修改虚拟机的etc/hosts文件 sudo vi /etc/hosts 即:192.168.99.100

资料下载 | 58同城HBase平台及生态建设实践

怎甘沉沦 提交于 2020-04-09 12:44:17
前言: 2020年3月7日晚7点,大佬张祥在微信群向大家详细介绍了58同城HBase平台及其生态的建设实践与相关经验,确实讲得很好。今天花了点时间帮大家整理了一下,希望更多的没有参与直播的朋友能够看到它,也欢迎大家积极转发一下,视频与PPT 相关资料附于文末 。 亮点在哪 该分享的亮点在哪儿里呢?这里我就自己的理解阐述一下自己的想法,不喜勿喷哈~ 1. 数据接入层 第一个亮点是:58同城在HBase之上做了进一步封装(SCF),融入了微服务,充分利用了微服务的优势和特点,比如熔断、监控、权限、动态扩缩容等等都可以在这一层做,虽然也多了一层运维成本,但微服务技术应该也算有比较成熟的体系了。 之前也听过诸多言论,比如HBase之上封装一层HTTP或是RPC服务会导致性能降低之类的说法,其实我倒是觉得影响还是比较小的,当然肯定会有些影响。对性能影响比较大的只可能是过度封装或是对HTTP/RPC框架不熟。 当然,性能与服务器成本是挂钩的,性能的提升会带来服务器成本的降低,诸多好处和不足还应权衡一下。58同城,也算是在这一方面开了一个不错的先例(恕我孤陋寡闻~)。 2. 多租户打通与数据隔离 听完整个视频,我觉得第二个亮点算是多租户的全线打通了,这里主要是一个解决方式:Hadoop ugi 的提出。可能是我孤陋寡闻吧,这个对我的启发确实挺大的

HBase最佳实践之HBase查询优化

陌路散爱 提交于 2020-04-08 10:57:06
1.概述 HBase是一个实时的非关系型数据库,用来存储海量数据。但是,在实际使用场景中,在使用HBase API查询HBase中的数据时,有时会发现数据查询会很慢。本篇博客将从客户端优化和服务端优化两个方面来介绍,如何提高查询HBase的效率。 2.内容 这里,我们先给大家介绍如何从客户端优化查询速度。 2.1 客户端优化 客户端查询HBase,均通过HBase API的来获取数据,如果在实现代码逻辑时使用API不当,也会造成读取耗时严重的情况。 2.1.1 Scan优化 在使用HBase的Scan接口时,一次Scan会返回大量数据。客户端向HBase发送一次Scan请求,实际上并不会将所有数据加载到本地,而是通过多次RPC请求进行加载。这样设计的好处在于避免大量数据请求会导致网络带宽负载过高影响其他业务使用HBase,另外从客户端的角度来说可以避免数据量太大,从而本地机器发送OOM(内存溢出)。 默认情况下,HBase每次Scan会缓存100条,可以通过属性hbase.client.scanner.caching来设置。另外,最大值默认为-1,表示没有限制,具体实现见源代码: /** * @return the maximum result size in bytes. See {@link #setMaxResultSize(long)} */ public long