Hbase rowKey 设计原则

Hbase RowKey 设计

一、引言

HBase由于其存储和读写的高性能,在OLAP即时分析中越来越发挥重要的作用,在易观精细化运营产品–易观方舟也有广泛的应用。作为Nosql数据库的一员,HBase查询只能通过其Rowkey来查询(Rowkey用来表示唯一一行记录),Rowkey设计的优劣直接影响读写性能。HBase中的数据是按照Rowkey的ASCII字典顺序进行全局排序的,有伙伴可能对ASCII字典序印象不够深刻,下面举例说明:

假如有5个Rowkey:”012”, “0”, “123”, “234”, “3”,按ASCII字典排序后的结果为:”0”, “012”, “123”, “234”, “3”。(注:文末附常用ASCII码表)

Rowkey排序时会先比对两个Rowkey的第一个字节,如果相同,然后会比对第二个字节,依次类推… 对比到第X个字节时,已经超出了其中一个Rowkey的长度,短的Rowkey排在前面。

由于HBase是通过Rowkey查询的,一般Rowkey上都会存一些比较关键的检索信息,我们需要提前想好数据具体需要如何查询,根据查询方式进行数据存储格式的设计,要避免做全表扫描,因为效率特别低。


如何处理好一项复杂的任务

如何处理好一项复杂的任务

什么是复杂的任务

  • 目标不清晰
  • 路径不清晰
  • 标准不清晰
  • 范围无界定


大数据分析的下一代架构--IOTA架构设计实践

大数据分析的下一代架构–IOTA架构设计实践

基于 易观CTO 郭炜 文章 Lambda架构已死,去ETL化的IOTA才是未来 易观方舟IOTA架构实践整理而成

IOTA架构提出背景

在过去,Lambda数据架构成为每一个公司大数据平台必备的架构,它解决了一个公司大数据批量离线处理和实时数据处理的需求。一个典型的Lambda架构如下:

数据从底层的数据源开始,经过各种各样的格式进入大数据平台,在大数据平台中经过Kafka、Flume等数据组件进行收集,然后分成两条线进行计算。一条线是进入流式计算平台(例如 Storm、Flink或者Spark Streaming),去计算实时的一些指标;另一条线进入批量数据处理离线计算平台(例如Mapreduce、Hive,Spark SQL),去计算T+1的相关业务指标,这些指标需要隔日才能看见。


数据分析中可视化图表缓存策略

数据分析中可视化图表缓存策略

每一次ad-hoc查询,均是会占用有限的计算资源,而OLAP 系统在现有技术下,并不能支撑很高的查询并发,为了有效改善这个问题,在查询时间范围内数据未发生变化或者变化量小,有效运用缓存可以有效提高查询效率和用户体验

1. 问题

单纯的N小时缓存失效的机制,会导致数据刷新不及时,造成数据理解上的偏差:

现象:在相同指标在不同图表数据不一致,尤其是在同一个DashBoard内时,让人难以理解;
原因:图表在不同时间创建和缓存的,在时间差内,相关的数据发生了变更


数据可视化_企业级BI工具Superset简介

简介

  • 企业级BI工具
  • Superset 是一个数据探索和可视化平台,设计用来提供直观的,可视化的,交互式的分析体验
    最初由Airbnb开源,后面进入Apache 软件基金会孵化项目

特性:

  • 开源, Apache 孵化项目,迭代进度正常,star数量 2w+
  • 可视化方面非常出色,静态的日报、报表,Superset表现力很好
  • 图表类型丰富,有时间序列、GEO地理位置、词汇云、等近50种图表类型
  • 支持数据源丰富,包括Apache Kylin、Clickhouse、Hive
  • 支持数据切片、SQL-Lab
  • 数据能力取决于数据源

项目地址:


Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×