我司大数据项目数据查询引擎使用到了presto，但是对于presto本身来说并没有人员及数据权限粒度的权限控制，我在上面做了一层封装。

Apache Ranger权限控制

Apache Ranger是Apache开源的一款Hadoop生态的安全管理框架，它可以管理诸如：HDFS、HBASE、YARN等的权限访问和控制，提供了统一的权限管理后台，可以实施在线的权限变更和访问日志审计。
具体怎么使用Ranger进行权限控制及自定义服务的新增，可以参考以前的一篇文章：Ranger自定义插件开发

本文原文：Solr TTL - Auto-Purging Solr Documents & Ranger Audits

背景

最近公司的使用的大数据项目中频繁出现以下的报错:

ERROR [org.apache.ranger.audit.queue.AuditBatchQueue0] o.a.s.c.solrj.impl.CloudSolrClient:924- Request to collection ranger_audits failed due to (400) org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://172.18.2.6:8886/solr/ranger_audits_shard1_replica1: Exception writing document id bc8d53c6-0878-450c-a9b0-1b8d34c55e1d to the index; possible analysis error: number of documents in the index cannot exceed 2147483519, retry? 0

搜索了一下原因，大致是说solr分片的索引量不能超过最大值（2的32次方）。由于线上solr是单机版本，所以数据量上已经超了，为了解决这个问题，我搜索到了下面这篇文章。

这篇文章将讲述如何在Solr文档上使用TTL(time to live)来自动清理过期文档。

这篇文章我们将关注如何自动地从Solr集合中删除文档，关于solr文档TTL的问题如下：

• 节点磁盘满
• 公司策略要求删除旧的审计日志(audit logs)
• 自动清理等

SOLR-5795介绍了一个新的UpdateProcesser叫做DocExpirationUpdateProcessorFactory,它允许我们在solr文档上添加一个过期时间，并且确保过期的文档能够自动的被清除。

在上一篇文章中，主要讲解了AQS的大体结构和用法，在本篇文章中则主要讲述AQS中等待队列的原理及实现。希望通过对AQS源码的解读加深自己去AQS的原理理解以及对AQS使用的熟练度。

注：本文基于JDK 8，全文中所有的叙述都是基于该版本。

概述

AbstractQueuedSynchronizer类是JUC类库的核心实现，它是实现Java并发核心库众多并发工具的基础，基于它及它的衍生品的并发核心包括ReentrantReadWriteLock,ArrayBlockingQueue,CopyOnWriteArrayList,CountDownLatch,CyclicBarrier等等。它为实现同步锁以及相关的基于FIFO等待队列的同步器（如：semaphores,events等）提供了一个统一框架。该类被设计用来为绝大多数基于一个原子int型状态值的同步器提供有用的基础设施。子类必须实现protected方法来改变这个状态值，该状态值决定了对象是被acquired还是released。该类的其它方法提供了所有的队列和阻塞管理。子类可以维护其它的状态字段，但是只有通过使用getState,setState,compareAndSetState方法才能被同步追踪。

在使用Git作为版本管理的过程中，在一个分支上开发很久了以后，当你回顾以前的提交时，会发现以前的提交非常杂乱而且提交的日志标注不清时，这个时候你就会非常想重新整理一下你的提交了。将多个提交日志合并成一个提交，而这个操作Git提供了这样的方法： git rebase -i

Presto的运行机制

Presto的运行机制如下：

不管是coordinator还是worker配置项中都有一项discovery.uri,这个是一个比较核心的东西，简单来说就是服务发现的地址。

coordinator和worker都会将自身注册到这个服务发现地址上，供彼此发现对方，coordinator可以通过个发现服务知道有多少worker节点，而worker节点可以通过这个发现服务知道coordinator是谁，这样做的好处是coordinator和worker做到了完全的解耦，彼此都不需要在启动时配置对方，而是通过第三方服务来发现对方。

如果你正计划使用HDP的发行版，那么你可以使用Ambari和Apache Slider来执行基于YARN的Presto的自动安装和集成，在安装过程中，Apache Slider和Presto的包都会被安装。

部署Presto到基于YARN的集群

安装部署的前提是假设你有一些关于Presto的基础知识以及了解它的一些配置文件。所有的例子引用都来至于：https://github.com/prestodb/presto-yarn/

前提条件

• 基于HDP 2.2+ 或者 CDH 5.4+ 的集群
• Apache Slider 0.80.0（可以从这个地址下载）
• JDK 1.8
• Zookeeper
• openssl >= 1.0.1e-16
• Ambari 2.1

在做大数据查询系统的过程中，需要对Presto对正在进行的查询进行管理，允许用户进行kill。今天有用户反馈线上的任务无法kill，通过查看线上日志得知在解析json的时候报了一个错：

1
2
3
4
5
6

com.alibaba.fastjson.JSONException: autoType is not support. output
   at com.alibaba.fastjson.parser.ParserConfig.checkAutoType(ParserConfig.java:888)
   at com.alibaba.fastjson.parser.DefaultJSONParser.parseObject(DefaultJSONParser.java:325)
   at com.alibaba.fastjson.parser.DefaultJSONParser.parseObject(DefaultJSONParser.java:520)
   at com.alibaba.fastjson.parser.DefaultJSONParser.parse(DefaultJSONParser.java:1335)
   ...

从上图可以看出错误代码出在了：

1

QueryVO query = JSON.parseObject(result, QueryVO.class);

根据错误堆栈，错误发生在323行：

需求背景

最近这段时间一直在做数据查询系统的需求，最近接到一个需求：因为HIVE查询一般需要比较久的查询时间，这期间查询人员需要知道查询的进度，需要在界面上进行进度的展示。

探路过程

我们查询系统连接HIVE使用的是标准的JDBC接口，在标准的JDBC接口中并没有提供这样的一个获取查询日志的接口。翻阅了很多的资料后发现其实在HIVE Server的Thrift接口中是有提供这样的接口的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

public List<String> getQueryLog(boolean incremental, int fetchSize)
      throws SQLException, ClosedOrCancelledStatementException {
    checkConnection("getQueryLog");
    if (isCancelled) {
      throw new ClosedOrCancelledStatementException("Method getQueryLog() failed. The " +
          "statement has been closed or cancelled.");
    }

    List<String> logs = new ArrayList<String>();
    TFetchResultsResp tFetchResultsResp = null;
    try {
      if (stmtHandle != null) {
        TFetchResultsReq tFetchResultsReq = new TFetchResultsReq(stmtHandle,
            getFetchOrientation(incremental), fetchSize);
        tFetchResultsReq.setFetchType((short)1);
        tFetchResultsResp = client.FetchResults(tFetchResultsReq);
        Utils.verifySuccessWithInfo(tFetchResultsResp.getStatus());
      } else {
        if (isQueryClosed) {
          throw new ClosedOrCancelledStatementException("Method getQueryLog() failed. The " +
              "statement has been closed or cancelled.");
        }
        if (isExecuteStatementFailed) {
          throw new SQLException("Method getQueryLog() failed. Because the stmtHandle in " +
              "HiveStatement is null and the statement execution might fail.");
        } else {
          return logs;
        }
      }
    } catch (SQLException e) {
      throw e;
    } catch (Exception e) {
      throw new SQLException("Error when getting query log: " + e, e);
    }

    RowSet rowSet = RowSetFactory.create(tFetchResultsResp.getResults(),
        connection.getProtocol());
    for (Object[] row : rowSet) {
      logs.add(String.valueOf(row[0]));
    }
    return logs;
  }

以上取至HIVE的JDBC接口实现HiveStatement这个类。这个类是标准java.sql.Statement的实现，但是getQueryLog这个方法并不是标准的JDBC方法，因为在我们的程序中运行的就是HIVE查询，所以我们可以在程序中进行强转得到HiveStatement这个类并调用这个方法获取到查询日志。 getQueryLog 这个方法中用到了整个HiveStatement中的一些变量，所以我们要进行HIVE查询日志的获取必须要对HiveStatement对象进行关联，同时一边在执行HIVE查询，一边还要从另一个线程中获取HIVE查询的日志过程。

在以往的开发过程中，Spring体系的文件上传一直使用的是commons-fileupload，在我们的项目中也是一样的，这两天在做公司的大数据查询平台，其中在做大文件上传时遇到了一些问题，记录如下：

问题现象

在开发环境、测试环境中，我们的环境是直接部署的jetty，也就是所有的访问直接经由浏览器后到达jetty服务器，运行良好。

但是当程序上到预发布环境时，文件上传出现了问题，文件上传不成功。服务器返回了一个错误，大体意思就是文件上传的请求体大于服务器端的最大设置，从响应的header看是nginx响应回来的，初步定位到是nginx文件大小上传受限，运维帮助修改了nginx配置后，这个错误不再出现。然而又出现了新的问题，Java程序在上传文件的过程中内存溢出了！

都知道在springmvc中，上传文件的话如果太大会写入临时磁盘文件来避免内存溢出的问题。当然我们的程序中也设置了：

以上的配置信息的解析是：

1
2

文件上传的最大大小为256M
HTTP请求的最大大小为257M，因为HTTP请求包含了文件上传，故要大于文件上传大小。