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
  • 数据能力取决于数据源

项目地址:


Clickhouse_Table_Engine_总结

Clickhouse_Table_Engine_总结

Clickhouse表引擎决定了:

  • 数据如何存储,如何读取
  • 支持何种查询
  • 并发数据访问能力
  • 索引的使用
  • 是否支持多线程请求执行
  • 数据如何同步

当读取数据时, 引擎只需要抽取必要的列簇. 然而,在一些场景下,引擎可以半处理数据

对于大多数场合下,应该使用 MergeTree家族 引擎

以下包括官方介绍的17种表引擎的介绍:


Clickhouse Dictionaries 使用样例

Clickhouse Dictionaries 字典使用

clickhouse支持从各种数据源添加自己的字典。字典的数据源可以是本地文本、可执行文件
、HTTP(s)资源或其他DBMS。有关更多信息,请参阅“外部词典的来源”。

  • 完全或部分将字典存储在RAM中。
  • 定期更新字典并动态加载缺失值。换句话说,可以动态加载字典。

外部词典的配置位于一个或多个文件中。 配置的路径在dictionaries_config参数中指定。

字典配置:

1
<dictionaries_config>*_dictionary.xml</dictionaries_config>

当前配置文件目录下,以_dictionary.xml结尾的均作为字典配置文件进行字典加载。

字典可以在服务器启动时或首次使用时加载,具体取决于dictionaries_lazy_load设置。


Clickhouse Dictionaries 外部字典的数据源配置

Clickhouse Dictionaries - Sources of External Dictionaries

Clickhouse允许从不同的源构造外部字典,配置文件通常像这样:

1
2
3
4
5
6
7
8
9
10
11
12
<yandex>
<dictionary>
...
<source>
<source_type>
<!-- Source configuration -->
</source_type>
</source>
...
</dictionary>
...
</yandex>

数据源则是通过source项进行配置

其中支持的数据源的类型有(source_type):

  • Local file
  • Executable file
  • HTTP(s)
  • DBMS
    • MySQL
    • ClickHouse
    • MongoDB
    • ODBC

Clickhouse Dictionaries 在内存中的存储方式

Clickhouse Dictionaries -Storing Dictionaries in Memory

Clickhouse支持多种方式将字典存储在内存中

一般推荐flathashedcomplex_key_hashed,这些提供了最佳的处理速度,但是不推荐使用cache,因为可能会出现性能差且难以选择最佳参数的问题。

有以下几种方式提升字典的使用性能:

  • 在使用Group By之后再调用函数处理字典
  • 将属性标记为单射(injective).如果不同的属性值对应不同的键,则属性被称为单射。因此,当group by 中使用通过key获取字典value的函数时,此函数将自动从group by中取出。

Clickhouse Dictionaries 键值配置说明

Clickhouse_Dictionary Key and Fields

字典键值配置说明

字典键、值的配置是在配置文件中的structure节点

整体的配置结构

1
2
3
4
5
6
7
8
9
10
11
<dictionary>
<structure>
<id>
<name>Id</name>
</id>
<attribute>
<!-- Attribute parameters -->
</attribute>
...
</structure>
</dictionary>

Columns are described in the structure:

  • <id> - key column.
  • <attribute> - data column. 这里可以配置很多数据列

Your browser is out-of-date!

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

×