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

感谢平台分享-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。例如,100个存储 bucket 将在密钥空间中提供广泛的分布,但它需要 100 次 Scan 才能获得单个时间戳的数据,因此存在权衡。

行密钥(Rowkey)主导位置中的主机(Host)

如果有大量的主机在整个密钥空间中进行写入和读取操作,则 rowkey [hostname][log-event][timestamp] 是一个候选项。如果按主机名扫描是优先事项,则此方法非常有用。

时间戳或反向时间戳

如果最重要的访问路径是拉取最近的事件,则将时间戳存储为反向时间戳(例如,timestamp = Long.MAX_VALUE – timestamp)将创建能够对 [hostname][log-event] 执行 Scan 以获取最近捕获的事件的属性。

这两种方法都不是错的,它只取决于什么是最适合的情况。

反向扫描 API

HBASE-4811 实现了一个 API,它以反向扫描表格或范围内的表格,从而减少了对正向或反向扫描进行模式优化的需求。此功能在 HBase 0.98 和更高版本中可用。

可变长度或固定长度的行键

记住,在 HBase 的每一列上加盖行密码是非常重要的。如果主机名为 a,并且事件类型是 e1,那么结果 rowkey 会很小。但是,如果摄入的主机名是myserver1.mycompany.com 和事件类型是 com.package1.subpackage2.subsubpackage3.ImportantService,会怎么样?

在 rowkey 中使用一些替换可能是有意义的。至少有两种方法:哈希和数字。在 Rowkey Lead Position 示例中的主机名中,它可能如下所示:

带有哈希的复合 Rowkey:

  • [主机名的MD5哈希] = 16个字节([MD5 hash of hostname] = 16 bytes)
  • [事件类型的MD5哈希] = 16个字节([MD5 hash of event-type] = 16 bytes)
  • [时间戳] = 8个字节([timestamp] = 8 bytes)

具有数值替换的复合 Rowkey:

对于这种方法,除了 LOG_DATA(称为LOG_TYPES)之外,还需要另一个查找表。LOG_TYPES 的 rowkey 是:

  • [type],(例如,指示主机名与事件类型的字节)。
  • [bytes],原始主机名或事件类型的可变长度字节。

此 rowkey 的列可能是一个具有指定编号的长整数,可通过使用 HBase 计数器获得。

所以得到的复合 rowkey 将是:

  • [代替主机名长] = 8个字节([substituted long for hostname] = 8 bytes)
  • [长时间取代事件类型] = 8个字节([substituted long for event type] = 8 bytes)
  • [时间戳] = 8个字节([timestamp] = 8 bytes)

在 Hash 或 Numeric 替换方法中,主机名和事件类型的原始值可以存储为列。

原文地址:https://blog.51cto.com/14744108/2486399

时间: 2024-09-28 01:36:23

HBase模式案例日志数据和时间序列数据的相关文章

面板数据、截面数据、时间序列数据

截面数据.时间序列数据.面板数据是最常见的三种样本数据形式,网上对于此类数据的介绍比较零散,我在此做一个汇总归纳,如有错误,欢迎指正,我在此只做简单介绍,并不涉及具体分析,特别是面板数据,分析比较复杂,有专门的书籍可以参阅. 一.截面数据(Cross Section data) 1.概念: 截面数据是指由同一时期.不同个体的一个或多个统计指标所组成的数据集.该数据强调同一时期,因此也称为静态数据,我们平时获取的样本数据,大都具有同期性,因此截面数据也是最常见的 样本数据.例如:2016年各省份人

横截面数据、时间序列数据、面板数据

面板数据(Panel Data)是将"截面数据"和"时间序列数据"综合起来的一种数据类型.具有"横截面"和"时间序列"两个维度,当这类数据按两个维度进行排列时,数据都排在一个平面上,与排在一条线上的一维数据有着明显的不同,整个表格像是一个面板,所以称为面板数据(Panel Data). 实际上如果从数据结构内在含义上,应该把Panel Data称为"时间序列-截面数据",更能体现数据结构本质上的特点.该数据

HBase模式案例研究列表数据

感谢平台分享-http://bjbsair.com/2020-04-10/tech-info/53341.html 以下是用户 dist-list 中关于一个相当常见问题的的交流:如何处理 Apache HBase 中的每个用户列表数据. 问题: 我们正在研究如何在 HBase 中存储大量(每用户)列表数据,并且我们试图弄清楚哪种访问模式最有意义.一种选择是将大部分数据存储在一个密钥中,所以我们可以有如下的内容: 我们的另一个选择是完全使用如下内容: 每行将包含多个值.所以在一种情况下,读取前三

HBase模式案例Steroids上的日志数据_时间序列上

感谢平台分享-http://bjbsair.com/2020-04-10/tech-info/53335.html 这实际上是 OpenTSDB 的方法.OpenTSDB 做的是重写数据并将行打包到某些时间段中的列中. 但是,这是一般概念的工作原理:例如,以这种方式摄入数据: 每个细节事件都有独立的 rowkeys,但是会被重写成这样: 上述每个事件都转换为存储的列,其相对于开始 timerange 的时间偏移量 (例如,每5分钟).这显然是一个非常先进的处理技术,但 HBase 使这成为可能.

_00017 Flume的体系结构介绍以及Flume入门案例(往HDFS上传数据)

博文作者:妳那伊抹微笑 个性签名:世界上最遥远的距离不是天涯,也不是海角,而是我站在妳的面前,妳却感觉不到我的存在 技术方向:hadoop,数据分析与挖掘 转载声明:可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明,谢谢合作! qq交流群:214293307  (期待与你一起学习,共同进步) # 学习前言 想学习一下Flume,网上找了好多文章基本上都说的很简单,只有一半什么的,简直就是坑爹,饿顿时怒火就上来了,学个东西真不容易,然后自己耐心的把这些零零碎碎的东西整理整理,各种

如何基于日志,同步实现数据的一致性和实时抽取?

一.背景 事情是从公司前段时间的需求说起,大家知道宜信是一家金融科技公司,我们的很多数据与标准互联网企业不同,大致来说就是: 玩数据的人都知道数据是非常有价值的,然后这些数据是保存在各个系统的数据库中,如何让需要数据的使用方得到一致性.实时的数据呢? 过去的通用做法有几种,分别是: DBA开放各个系统的备库,在业务低峰期(比如夜间),使用方各自抽取所需数据.由于抽取时间不同,各个数据使用方数据不一致,数据发生冲突,而且重复抽取,相信不少DBA很头疼这个事情. 公司统一的大数据平台,通过Sqoop

大数据架构和模式(三)——理解大数据解决方案的架构层

摘要:大数据解决方案的逻辑层可以帮助定义和分类各个必要的组件,大数据解决方案需要使用这些组件来满足给定业务案例的功能性和非功能性需求.这些逻辑层列出了大数据解决方案的关键组件,包括从各种数据源获取数据的位置,以及向需要洞察的流程.设备和人员提供业务洞察所需的分析. 概述 这个 “大数据架构和模式” 系列的 第 2 部分 介绍了一种评估大数据解决方案可行性的基于维度的方法.如果您已经使用上一篇文章中的问题和提示分析了自己的情况,并且已经决定开始构建新的(或更新现有的)大数据解决方案,那么下一步就是

大数据架构和模式(五)——对大数据问题应用解决方案模式并选择实现它的产品

摘要:本文使用了一个基于场景的方法,概述了可能有助于定义大数据解决方案的解决方案模式.每个场景都从一个业务问题开始,并说明为什么需要大数据解决方案.本文会将一个具体的解决方案模式(由原子模式和复合模式组成)应用到业务场景.这个逐步分析的方法有助于用户确定解决方案所需的组件.在文章的末尾,提供了一些建议使用的典型产品和工具. 简介 本系列的 第 3 部分 描述了针对最常见的.经常发生的大数据问题及其解决方案的原子模式和复合模式.本文将推荐可以用于架构大数据解决方案的三个解决方案模式.每个解决方案模

大数据架构和模式(三)理解大数据解决方案的架构层

本文件收藏于:http://kb.cnblogs.com/page/510980/ 作者: Divakar等  来源: DeveloperWorks  发布时间: 2015-01-29 18:21   推荐: 0   原文链接   [收藏] 摘要:大数据解决方案的逻辑层可以帮助定义和分类各个必要的组件,大数据解决方案需要使用这些组件来满足给定业务案例的功能性和非功能性需求.这些逻辑层列出了大数据解决方案的关键组件,包括从各种数据源获取数据的位置,以及向需要洞察的流程.设备和人员提供业务洞察所需的