2019ICDE-Presto: SQL on Everything

本文发表于2019年，但是presto从2013年开始就有了，2019年原作者从Facebook分道扬镳。有关这段爱恨情仇可以在trino官网（presto主流继承版本）中看到。本文的作者是presto的原作者，发表于2019年，此时presto已经是比较成熟完善的系统了，学习的价值更大。

Abstract

Presto是分布式查询引擎，支持SQL负载。既能承担亚秒级别的交互式查询，也要能支持几小时的ETL任务。
主要特性是：灵活、自适应、扩展性强（支持多个外部源，包括HDFS、RDBMS、NoSQL、流处理系统）。

I. INTRODUCTION

Presto作为交互式的查询引擎，从2013年诞生开始，已经在Facebook以及世界上众多大公司使用，以满足端上用户交互式查询分析的需求。它主要有以下特性：

• 多租户系统。要支持几百个查询并行；要有扩展性，能扩展到几千个节点去。
• 集成性。管理员可以设置集群，让它可以兼容多个外部数据源，甚至在一条SQL里用多个数据源。
• 灵活性。能应对各种工作负载。
• 高度优化。多个query可以共享一个JVM运行，当然这就需要调度、资源管理、隔离等。

Presto架构

Presto是一个在一组机器上运行的分布式系统。 完整安装包括协调员和多个工作人员。 查询从客户端（Presto CLI、presto-jdbc）提交给协调器。 协调器解析， 分析和计划查询执行，然后将处理分发给worker工作进程。

presto硬件架构

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

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内时，让人难以理解；
原因：图表在不同时间创建和缓存的，在时间差内，相关的数据发生了变更