论文标题：Column-Stores vs. Row-Stores: How Different Are They Really?

论文: http://www.cs.umd.edu/~abadi/papers/abadi-sigmod08.pdf

概述

从论文的标题可以看出这篇论文不是陈述一种新的技术、架构，而更偏议论文一点，它主要的目的在于搞清楚对于分析类的查询为什么Column-Store比Row-Store好那么多？好在哪里？

一般认为原因是:

分析类查询往往只查询一个表里面很少的几个字段，Column-Store只需要从磁盘读取用户查询的Column，而Row-Store读取每一条记录的时候你会把所有Column的数据读出来，在IO上Column-Store比Row-Store效率高很多，因此性能更好。

而本文的目的是要告诉你Column-Store在存储格式优势只是一方面，如果没有查询引擎上其它几个优化措施的配合，性能也不会太好的，这篇论文认为Column-Store在查询引擎层有以下几种大的优化手段:

• 块遍历(Block Iteration)
• 压缩(Compression)
• 延迟物化(Late Materialization)
• Invisible Join

其中前三点是前人就已经总结过的、在现有Column-Store上实现过了的，而最后一点是本论文的创新。下面我们一一看一下这几种优化手段的细节，最后再看看它们优化效果的对比。

什么是列式存储

在传统的行式数据库系统中，数据按如下顺序存储：

处于同一行中的数据总是被物理的存储在一起。

常见的行式数据库系统有：MySQL、Postgres和MS SQL Server。

在列式数据库系统中，数据按如下的顺序存储：

这些示例只显示了数据的排列顺序。来自不同列的值被单独存储，来自同一列的数据被存储在一起。

Hadoop2.9 单机/伪分布式安装(Centos7环境)

准备

需要准备的软件: Java , ssh

下载Haddop:http://www.apache.org/dyn/closer.cgi/hadoop/common/

安装SSH、配置SSH无密码登陆

集群、单节点模式都需要用到 SSH 登陆（类似于远程登陆，你可以登录某台 Linux 主机，并且在上面运行命令），一般情况下，CentOS 默认已安装了 SSH client、SSH server，打开终端执行如下命令进行检验：

1

rpm -qa | grep ssh

若需要安装，则可以通过 yum 进行安装

1
2

sudo yum install openssh-clients
sudo yum install openssh-server

测试ssh 是否可以用

1

ssh localhost

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

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，绝壁算不算一个数据库，没条件做性能测试，期待其他第三方的全方位评测

Apache Kudu 简介

Kudu是Cloudera开源的新型列式存储系统，是Apache Hadoop生态圈的新成员之一(incubating)，专门为了对快速变化的数据进行快速的分析

特性：

• OLAP
• 对数据扫描(scan)和随机访问(random access)同时具有高性能，简化用户复杂的混合架构
• 支持单条或批量的数据读写，支持schema的创建修改
• 既可以当作简单的key-value 使用，也可以作为复杂的几百不同的强类型属性。

常见的几个应用场景:

1. 实时更新的应用。刚刚到达的数据就马上要被终端用户使用访问到
2. 时间序列相关的应用，需要同时支持
3. 根据海量历史数据查询
4. 非常快地返回关于单个实体的细粒度查询
5. 实时预测模型的应用，支持根据所有历史数据周期地更新模型

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上都会存一些比较关键的检索信息，我们需要提前想好数据具体需要如何查询，根据查询方式进行数据存储格式的设计，要避免做全表扫描，因为效率特别低。