物联网产生的数据通常具有以下明显的特征:

1: 数据是时序的，一定带有时间戳；

2：数据是结构化的；

3: 数据极少有更新或删除操作；

4：数据源是唯一的；

5：相对互联网应用，写多读少；

6：用户关注的是一段时间的趋势，而不是某一特点时间点的值；

7: 数据是有保留期限的；

8：数据的查询分析一定是基于时间段和地理区域的；

9：除存储查询外，还往往需要各种统计和实时计算操作；

10：流量平稳，可以预测；

11：往往需要有插值等一些特殊的计算；

12：数据量巨大，一天采集的数据就可以超过100亿条。

TDengine简单总结

1. 总结

先放总结：

1. 核心代码全部开源，目前是单机开源，如果要用集群版，还是要商业版收费，毕竟带着商业目标，小数据量单机可以玩玩
2. 未披露扩展性、数据一致性、容错性、可用性等分布式技术细节，也未披露数据库的相关特性实现细节
3. 做性能对比选择的视角比较奇怪：客户端数对单机服务器性能的影响，其他数据库评测的都是单机性能和集群机器数带来的水平扩展能力
4. 只支持定长的数据类型（数值、bool和字符串），字符串只支持定长，如果超出申明长度会被截断（评测也全为定长数据）
5. 聚合函数性能对比，tdengine的函数均是非常简单的函数，所有函数加起来不到20个，并且每个数据块都已经做了预聚合（和、最大、最小值等)，所以这个评测应该是 预计算 VS 即席查询，结果就不公平了
6. 提供了简版的缓存、MQ等组件。这些组件的分布式特性未可知
7. 可以根据查询的时间范围直接对内存数据和本地文件进行聚合查询，SQL层面不需要关心
8. 函数和特性过少，不合适做大数据分析，针对物联网数据的特点做了针对性优化，不过其定位领域也是IOT ，如果要扩展到其他非IOT时序场景，需要多考虑考虑

有人说只是个WAL，绝壁算不算一个数据库，没条件做性能测试，期待其他第三方的全方位评测

Hadoop_Shell

1
2
3
4
5
6
7
8
9
10
11
12
13
14

hdfs文件的相关操作主要使用hadoop fs、hadoop dfs、hdfs dfs 命令，以下对最常用的相关命令进行简要说明。
hadoop fs -ls  显示当前目录结构，-ls -R 递归显示目录结构
hadoop fs -mkdir  创建目录
hadoop fs -rm   删除文件，-rm -R 递归删除目录和文件
hadoop fs -put  [localsrc] [dst]  从本地加载文件到HDFS
hadoop fs -get  [dst] [localsrc]  从HDFS导出文件到本地
hadoop fs - copyFromLocal [localsrc] [dst]  从本地加载文件到HDFS，与put一致
hadoop fs -copyToLocal [dst] [localsrc]  从HDFS导出文件到本地，与get一致
hadoop fs -test -e  检测目录和文件是否存在，存在返回值$?为0，不存在返回1
hadoop fs -text  查看文件内容
hadoop fs -du  统计目录下各文件大小，单位字节。-du -s 汇总目录下文件大小，-du -h 显示单位
hadoop fs -tail  显示文件末尾
hadoop fs -cp [src] [dst] 从源目录复制文件到目标目录
hadoop fs -mv [src] [dst] 从源目录移动文件到目标目录

Presto 主动Kill 机制

背景：用户界面中，为了改善用户使用体验，移除了 查询时点击按钮的操作，变更为只要检测到查询条件的修改都会自动触发计算。而实际使用过程中，用户在最终条件确定前，所有条件变更导致的查询计算均是计算资源的浪费

目的：为了避免自动触发的计算导致Presto 计算资源的浪费

如图所示，左侧指标、细分维度、公共过滤条件以及 日期范围、日期粒度、人群的变化都会导致分析查询的调用

方案:

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架构设计实践

基于 易观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 是一个数据探索和可视化平台，设计用来提供直观的，可视化的，交互式的分析体验
  最初由Airbnb开源，后面进入Apache 软件基金会孵化项目

特性：

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

项目地址：

• https://airbnb.io/projects/superset/
• https://github.com/apache/incubator-superset

Clickhouse_Table_Engine_总结

Clickhouse表引擎决定了：

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

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

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

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

Clickhouse Dictionaries 字典使用

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

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

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

字典配置：

1

<dictionaries_config>*_dictionary.xml</dictionaries_config>

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

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