① Presto Web UI
Presto Web UI 可以用来检查和监控Presto集群，以及运行的查询。他所提竖咐供的关于查询的详细信息可以更好的理解以及调整整个集群和单个查询。
需要注意的是，Presto Web UI所展示的信息都来自于Presto系统表，关于Presto系统表之后文章中再补充，这里不再多说；
当你进入Presto Web时，你将会看到如同1所示的界面：主要分为上下两部分，上面描述了集群信息，下面是查询列表；
Running Queries
当前在集群中正在执行的查询的个数。包含所有用户提交的查询；例如，如果Alice正在执行两个查询，Bob正在执行五个查询，那么在这个指标下显示的是7。
Queued Queries
当前集群队列中正在等待的查询的个数，也是包粗纤念含所有用户的查询。队列中的查询表示这些查询正在等待Coordinator根据Resource Group的配置为他们安排调度；
Blocked Queries
集群中被阻塞的查询的个数；被阻塞的查询意味着该查询因为缺少可用的Splits或者资源而无法继续执行（关于Splits的概念 以及查询何时被阻塞可以参考上一篇文章：Presto On Everything）；
Active Workers
集群中当前活跃的节点的个数；任何手动会自动添加或删除的节点都会注册到Discovery 服务，同时这里展示的数字将会更新、
Runnable Drivers
集群中可运行的Drivers的平均数量（当Task被创建之后，他为每一个Split实例化一个Driver，每一个Driver就是一个Pipeline 中Operators的实例，并对来自Split的数据进行处理，一旦Driver完成，数据将会被传给下一个Split），
Reserved Memory
集群中Reserved Memory的大小，单位是bytes。(关于Reserved Memory的概念请参考上一篇文章：Presto On Everything)
Rows/Sec
集群中所有查询在每一秒钟处理的行数
Bytes/Sec
集群中所有查询在一秒钟处理的总共的Bytes
Worker Parallelism
Worker的并发总数，在集群中运行的所有Worker和所有查询的CPU Time总和
WBE UI首页下部分就是查询列表的展示，当前列表中可以展示的查询的数量时可以配置的。如图二所示
如图所示你可以根据一些条件过滤和定位你想要的查询；同时提供了搜索输入框用于定位查询，输入的值会匹配很多项，包括：用户名、查询发起人，查询source，查询ID，resource group甚至sql文本，和查询状态。同样你可以根据后面预设的一些状态（running, queued, finished, and failed）对查询进行筛选；
最左边的控件允许你确定显示的查询的排序顺序、重新排序的时间以及要显示的查询的最大数量。
下面的每一行表示一个查询，左侧如图三所示岩困，右侧为查询的SQL文本；
根据图三可以观察当前查询的细节； 对于每个查询运行，左上角的文本是查询ID，图三中为： 20190803_224130_00010_iukvw
前面是YYYYMMDD_HHMMSS格式的日期，具体的时间是当前查询运行时的时间，后半部分是一个自增的计数器，00010的含义表示这个查询时Coordinator重启以来第10个查询，最后的字符：iukvw，是随机生成的Coordinator的标识符，每次coordinator重启会充值标识符和计数器。
后面紧跟的三个值： ec2-user , presto-cli , 以及global 分别表示，提交该查询的用户，查询的来源，当前查询的Resource Group。在实例中，当前查询的用户是ec2-user，查询时通过Presto-cli提交的，如果你在Presto CLI中提交SQL 时使用--user指定用户，那么界面该查询展示的就是你所指定的用户。至于查询来源除了Presto-CLI之外也可以是：Presto-jdbc ，当你使用JDBC连接Presto时。
图三最下面的9个指标对应下面的表格；
Completed Splits : 查询的已完成Splits的数目。这个例子显示了25个已完成的Splits。在查询执行的开始时和执行完成时这个值是0。当查询正在进行期间这个值会一直增加
Running Splits : 查询中正在运行的运行Splits的数量。当查询完成时，这个值总是0。但是，在执行过程中，随着Splits的运行和完成，这个数字会发生变化
Queued Splits ： 当前查询里出于队列中的Splits数。当查询完成时，这个值总是0。但是，在执行期间，这个数字会发生变化。
Wall Time ： 执行查询所花费的Wall Time。即使在分页结果时，此值也会继续增长。
Total Wall Time : 此值与Wall Time相同，但它也包括排队时间。Wall Time不包括查询排队的任何时间。这是您观察的总时间，从您提交查询到您接收结果。
CPU Time ： 处理查询所花费的总CPU时间。这个值通常比wallTine时间大，因为如果使用四个CPU花费1秒来处理一个查询，那么总的CPU时间是4秒。
Current Total Reserved
Memory ：当前用于查询执行总的reserved memory使用。对于已完成的查询，此值为0.
Peak Total Memory ： 查询执行期间的峰值总内存使用量。查询执行期间的某些操作可能需要大量内存，了解峰值是多大是很有用的
Cumulative User Memory ： 在整个查询处理过程中使用的累积内存。这并不意味着所有的内存都是同时使用的。它是累积的内存总量。
Presto Web UI中的许多图标和值都有弹出的工具提示，当您将鼠标悬停在图像上时，这些工具提示是可见的。如果您不确定某个特定值代表什么，这将非常有用。
当正在运行的查询在等待某些东西(如资源或要处理的其他Splits)时可能会发生BLOCKED状态。看到查询往返于此状态是正常的，但是如果查询陷入BLOCKED状态，可能存在许多潜在的理由，这可能表明当前查询或者集群可能存在问题，如果发现有查询卡在这个状态，那么应该检查集群的状态和相关配置，也可能是这个查询需要非常大的内存或者计算开销很大。 此外，如果客户端没有获取到返回的结果，或者不能足够快地读取结果，反压机制也会使查询处于BLOCKED状态
如果查询长时间出于PLANNING状态，这通常发生在较大的复杂的查询中，因为查询要进行大量的规划和优化处理；但是如果你经常看到这个状态，并且查询出于该状态很长时间，那很可能是因为coordinator内存问题导致的（之前曾遇到过因HiveMetaStore服务而导致的长时间的PLANNING状态）。
通过点击查询ID可以跳转到该查询的明细界面，如图四所示
Overview页面包括查询列表的查询细节信息如图4.1下：
最下面为Stage部分如图5所示
这是一个简单的SELECTCOUNT(*)的查询，所以只有两个stages
Stage0 是一个单任务的Stage，运行在coordinator上并且合并来自Stage1的Task（共4个）的数据，以完成最后的聚合；
Stage1是一个分布式的Stage，他在所有的Worker上执行Task，这个Stage负责读取数据并进行部分聚合；
其中每个Stage的指标如下：
TIME—SCHEDULED
在完成Stage的所有Task之前，该Stage被调度的时间。
TIME—BLOCKED
因等待数据被阻塞的时间
TIME—CPU
Stage中所有Task的总共的CPU时间
MEMORY–CUMULATIVE
在整个Stage 运行期间的累积内存。这并不意味着所有的内存都是同时使用的
MEMORY—CURRENT
当前stage总共的reserved内存，当查询结束时，改值为0
MEMORY—BUFFERS
当前正在等待被处理的数据所消耗的内存
MEMORY—PEAK
该Stage的峰值总内存。查询执行期间的某些操作可能需要大量内存，了解峰值是多少是很有用的。
TASKS—PENDING
Stage中待完成的Task的数量，执行完成时，为0
TASKS—BLOCKED
stage阻塞Task的数量。当查询完成时，这个值总是0。但是，在执行过程中，随着Task在阻塞状态和运行状态之间移动，这个数字会发生变化
TASKS—TOTAL
已经完成的Task的数量
最后的图6描述了Stage更多的细节：
如图6中指标具体含义如下表所示：
ID：Task的标识符，StageID.TaskID,中间用点分割，如0.0即Stage0的第0个任务
Host：Task运行所在的Worker节点
State ：Task的状态：PENDING , RUNNING , or BLOCKED
Pending Splits：Task的挂起的Splits的数量。此值在Task运行时更改，并在Task完成时显示0
Running Splits：Task 中正在运行的Splits的数量，在Task运行时改变，Task完成后显示0
Blocked Splits：Task 中出于阻塞状态的任务数，Task完成后为0
CompletedSplits：Task完成的Splits的数量
Rows：Task处理的行数
Rows/s：每秒处理的行数
Bytes：Task处理的字节数
Bytes/s：Task每秒处理的字节数 |
Elapsed：Task调度期间 wall time的总和
CPU Time：Task调度期间CPU时间总和
Buffered：当前等待被处理的缓存数据大小
Live Plan页面中你可以实时查询执行处理过程；如图7所示
在查询执行期间，计划中的计数器在查询执行过程中更新。Plan中的值与Overview选项卡中描述的相同，但是它们在查询执行计划上实时覆盖。 查看此视图有助于可视化查询被阻塞或花费大量时间的位置，以便诊断或改进性能问题
Stage Performance提供了查询处理完成后Stage 性能的详细可视化。如图8所示
该视图可以看作是Live Plan视图的下钻，在Live Plan视图中可以看到Stage中Task的operator pipeline。计划中的值与Overview选项卡中描述的值相同。 查看此视图有助于了解查询在何处卡住或花费大量时间，以便诊断或修复性能问题。您可以单击每个operator来访问详细信息
② presto中如何提取文本中的纯汉字
没办法提取纯文字。
Presto是一款功能强大的分布式sql查询引擎。
Presto是专门为程序员查询大数据研究开发的，能够支余谨洞持gb到pb字节大小的海量数据，提高了数据库晌芦搜索的回应速度，竖枯只需要几秒就可以得到搜索结果，大大节省了搜索时间，提高效率。
③ 在presto SQL中两个with as 函数怎么union在一起
向表中插入搏衡兄行。
INSERT INTO table_name query1
目前尚不支基袭持指定列名。
因此， 查询语句中的列与要插入的表中的列必须完全拦弊匹配。
例如：
INSERT INTO orders SELECT * FROM new_orders;INSERT INTO cities VALUES (1, 'San Francisco');NSERT INTO cities VALUES (2, 'San Jose'), (3, 'Oakland');
④ Linux里面presto作用是什么
Presto是一个开源的分布式SQL查询引擎，适用于交互式分析查询，数据量支持GB到PB字节。
Presto的设计和编写完全是为了解决像Facebook这样规模的商业数据仓库的交互式分析和处理速迅肆度的问题。
Presto支持在线数据查询，包括Hive, Cassandra, 关系数据库以及专有数据存储。一条Presto查询可以将多个数据源的哗孙数据进行合并，可以跨越整个组织进行分析。
Presto以分析师的需求作为目标，他们期望响应时间小于1秒到几分钟。 Presto终结了数据分析的两难选择，乱昌链要么使用速度快的昂贵的商业方案，要么使用消耗大量硬件的慢速的“免费”方案。
目前用的不是很多。
⑤ presto查询数据怎么实现分页
在Spark,Storm横行的时代，spark由于耗用内存高而很难满足这种改良的需求，Storm由于和hive不是一个套路，本身实时流处理的思路也和我们的需求差距较大，所以，
寻求一个能提供类似SQL查询接口，并且速度比较接近于实时，能利用现有集群硬件的实时SQL查询引擎成为一个现有hive的替代查询引擎。
⑥ Hive表数据质量校验的设计与开发
一张Hive计算完成后，开发者会希望知道计算结果是否符合预期，比如是否有脏数据，是否数据量符合预期。这里就有两个问题，一个是校验什么，另一个是怎么校验。
Hive表的校验自然是跑SQL最方便，每当Hive表更新完要执行SQL校验，需要考虑两个问题
基于上述考虑，就要选择既省资源，又快的计算引擎，MapRece可直接排除，备选方案是Spark SQL和Presto。
回过头看校验要执行的SQL，大部分是简单SQL，例如count(), min/max等，Presto在这种简单查询展示出了非常优异的性能，无论消耗资源，还是执行时间都很好。实际测试中，一张2亿行的表查询最新的总行数，执行select count() from table_name，只消耗了2.4 CPU-Second，执行时长也是2秒左右，消耗的资源和运行时长都可忽略不计。Presto跑的快的原因有很多，不用去yarn上申请资源，对orc文件查询做了很多优化，简单查询会直接基于orc的meta做计算，具体原因就不在赘述。
相同的SQL，Spark SQL一般的执行时间都要多很多，消耗的资源也会更多。不过两着对资源的计算方法肯定是不一样的，所以不能完全保证Presto更省资源，此处没有严格考证。
还有一些复杂的SQL，比如大表亩闹的字段唯一性校验，Presto很容易出现内存不足的异常，这时候可以考虑切换到Spark SQL来执行，至少保证能运行成功。
我们记录了每个枚举值，在表中出现的次数，每天记录一个值，久而久之可以形成变化趋势，可以发现某些业务细节的波动，发现异常的用户行为。
还尝试了对关键业务指标做了统计值校验，比如N个商品销量的最大最小、中位数、90%位数、平均数、标准差等，同样是每天采集并形成变化趋势，可以发现异常业务情况，Presto自带了这些算法。
在数仓小组内迅碰罩部，给重要表加上规则，再也不用担心报表出现重大问题，而一无所知。
功能上线后有冷启动的问题，用户不了解，也不能感知产品价值，所以很少有用户主动配置。于是我们通过默认的表级行数波动校验，采集每次表更新完的最新行数，发现异常波动，帮助用户发现问题，逐渐吸引用户使用。偶尔还会有用户惊叹，这么隐蔽的问题也能被发现，这就体现了业务监控的价值。随后我们通过培训、开发者访谈等方式，逐步推广。
后续有不少开发者，纯粹为了执行校验规则，发现业务异常数据，而把业务数据导入Hive中。也有DBA来查看采集到的数据量波动，来观察DB的数据量吵迹增长情况。
数据质量是个很大话题，除了数据准确性，至少还包括数据产出及时性、表间的数据一致性，用户甚至会把任何的数据看不懂都认为是数据质量问题，有些可能只是理解上的偏差。给Hive表配置了数据质量校验规则，只是一定程度保证了准确性，要真正解决数据质量问题，还需要更多技术和规范的努力。
⑦ presto sql如何忽略中英文括号匹配
中英文括号是不同的符号，匹配不上很正常。
可以通过下面几种方式处理：
1. 统一输入，所有公司名在输入的时候都把括号统一成中文或英文（直接用字符串替换就行了），搜索的时候也统一一下。
旧的数据可以直接操作数据库替换（操作前记得备份）
2. 搜索前将括号替换为通配符，使用like做条件检索。
如：搜索关键字 你好（北京）信息技术有限公司
则sql语句生成为 where companyname like '你好%北京%信息技术有限公司' （如果之前是用 = 作条件的话，两边不加% ，如果之前就是用like，在之前的条件中调整）
⑧ presto 配置 优先级
presto主要配置文件如下： catalog/:配置各数据源的信息。presto是由facebook开源，基于内存的分布式查询引擎。支持多数据源，可支持PB级海量数据查询，本身不作数据存储。由于基于内存查询，减少了IO开销，故查询效率很高，但不适用于多表联合查询。
拓展资料：
1、presto架构 ：
与众多分布式框架类似，由某组件进行请求处理以及分发任务至各执行节点。在presto架构中，Coordinator即为这样的角色。负责解析SQL，生成执行计划，分发任务到各节点。 Worker即各实际执行查询的节点。worker收到任务后,通过各种connector取各数据源中的数据。 Discovery service即联系Coordinator及Worker的服务。Worker启动会向Discovery server注册服务，Coordinator向Discovery server获取Worker节点信息。
2、Presto因其优秀的查询速度被我们所熟知，它本身基于MPP架构，可以快速的对Hive数据进行查询，同时支持扩展Connector，目前对Mysql、MongoDB、Cassandra、Hive等等一系列的数据库都提供了Connector进行支持。是我岩举们常用的SQL on Hadoop的解决方案。那么我们今天就来看一下，当我们选择Presto作为我们的查询引擎之后，我们需要考虑的问题。
3、单机维度
GENERAL_POOL每次内存申请时，都会判断内存使用量是否超过了最大内存，如果超过了就报错，错误为“Query exceeded local memory limit of x”，这保护了Presto会无限申请内存，只会导致当前查询出错。同时，如果该节点的GENERAL_POOL可使用内存以及可回收内存为0，那么认为该node为Block node。RESERVED_POOL可以认为是查询最大的SQL，其能满足GENERAL_POOL的内存限制策略，那么肯定会满足RESERVED_POOL的策略(复用了GENERAL_POOL策略)。
4、Resource Groups
Resource Groups 可以认为是Presto实现了一个弱资源限制和隔离功能。其可以为每个group指定队列大小、并发大小、内存使用大小。为每个group设置合理的hardConcurrencyLimit(最大并发数)、softMemoryLimit(内存最大使用值)及maxQueued(队列大小)一方面可以使不同业务影响降低，另一方面也大概率粗扒碧避免OOM问题，当此拦然善于运用user及做下二次开发，就可以让Presto支持多用户共用同一分组和权限认证功能。
⑨ 什么是大数据的主流框架
市场上有许多可用的框架。其中一些更受欢迎，例如Spark，Hadoop，Hive和Storm。Presto在效用指数上得分很高，而Flink具有巨大的潜力。
1. Apache Hadoop
Hadoop是基于Java的平台。这是一个开放源代码框架，可跨集群排列的一组硬件机器提供批处理数据处理和数据存储服务。Hadoop同样适用于可靠，可扩展和分布式的计算。但是，它也可以用作通用文件存储。它可以存储和处理PB的信息。Hadoop由三个主要组件组成。
2. Apache Spark
Spark框架由加利福尼亚大学伯克利分校成立。它是具有改进的数据流处理的批处理框架。借助完整的内存计算以及处理优化，它保证了极其快速的集群计算系统。
3.Apache Storm
Apache Storm是另一个引人注目的解决方案，专注于处理巨大的实时数据流。Storm的主要亮点是可伸缩性和停机后的迅速恢复能力。
4. Apache Flink
Apache Flink是一个开源框架，同样适用于批处理和流数据处理。它最适合于集群环境。该框架基于转换–流概念。它也是大数据的4G。它比Hadoop – Map Rece快100倍。
5. Presto
Presto是最适合较小数据集的开源分布式SQL工具。Presto配备了协调员以及各种工人。当客户提交查询时，将对这些查询进行解析，分析，计划执行并分配给协调员在工作人员之间进行处理。
6. Samza
Apache Samza是有状态的流，准备与Kafka共同开发的大数据系统。Kafka提供数据服务，缓冲和容错能力。
⑩ presto简介
MapRece不能满足大数据快速实时adhoc查询计算的性能要求，Facebook2012年开发，2013年开源
基于内存的并行计算，Facebook推出的分布式SQL交互式查询引擎 多个节点管道式执行
支持任意数据源 数据规模GB~PB 是一种Massively parallel processing（mpp）(大规模并行处理)模型
数据规模PB 不是把PB数据放到内存，只是在计算中拿出一部分放在内存、计算、抛出、再拿
多数据源、支持SQL、扩展性（可以自己扩展新的connector）、混合计算（同一种数据源的不同库 or表；将多个数据源的数据进行合并）、高性能、流水线（pipeline）
数据仓库 交互式略弱的查询引擎 只能访问HDFS文件 磁盘
但是presto是无法代替hive的
基于spark core mpp模式 详细课件spark sql一文
cube预计算
时序，数据放内存 索引 预计算
不适合多个大表的join操作，因为presto是基于内存的，太多数据内存放不下的
如果一个presto查询查过30分钟，那
就kill吧，说明不适合 也违背了presto的实时初衷
相当于MySQL的一个实例，
相当于MySQL的database
大内存、万兆网络、高计算能力
presto 查询引擎是一个Master-Slave的拓扑架构
中心的查询角色 接收查询请求、解析SQL 生成执行计划 任务调度 worker管理
coordinator进行是presto集群的master进程
执行任务的节点
presto以插件形式对数据存储层进行了抽象，它叫做连接器，不仅包含Hadoop相关组件的连接器还包括RDBMS连接器
具体访问哪个数据源是通过catalog 中的XXXX.properties文件中connector.name决定的
提取数据 负责实际执行查询计划
将coordinator和worker结合在一起服务；
worker节点启动后向discovery service服务注册
coordinator通过discovery service获取注册的worker节点
1、coordinator接到SQL后，通过SQL语法解析器把SQL语法解析变成一个抽象的语法树AST，只是进行语法解析如果有错误此环节暴露
2、语法符合SQL语法，会经过一个逻辑查询计划器组件，通过connector 查询metadata中schema 列名 列类型等，将之与抽象语法数对应起来，生成一个物理的语法树节点 如果有类型错误会在此步报错
3、如果通过，会得到一个逻辑的查询计划，将其分发到分布式的逻辑计划器里，进行分布式解析，最后转化为一个个task
4、在每个task里面，会将位置信息解析出来，交给执行的plan，由plan将task分给worker执行
1、如果某个worker挂了，discovery service 会通知coordinator
2、对于query是没有容错的，一旦worker挂了，query就执行失败了，与其在这里容错不如直接执行
3、coordinator 和discovery service 的单点故障问题还没有解决