文章列表

1.8k 2 分钟

平时我们经常需要解析和修改 Avro 文件,本篇简略描述下命令行读写 Avro 文件的方式,其实就是使用官方提供的 Java 工具。

2.5k 2 分钟

平时在定位问题或优化性能问题时,profile 有着至关重要的作用,所以本篇来整理下 profile 文件中的内容。

1.6k 1 分钟

# 背景

使用 hive jdbc 连接 impala 查询,最近遇到了三个问题,查询表现都是 jdbc 拿到的结果数量不对。

  1. 查询计算成功,在拉取数据的时候,客户端处理数据比较慢,所以拉数据也慢,导致拉取的两批数据之间间隔超过了 impala 默认的设置(FETCH_ROWS_TIMEOUT_MS=10000),impala 报错 session closed,客户端没有获取到这个报错,误认为拉取数据结束,返回给客户端的数据少了很多。这种情况调大 FETCH_ROWS_TIMEOUT_MS 就解决了。
  2. 客户端查询到的结果是空的,看那个查询的 profile,state 显示 FINISHED,status 显示 OK,但是在查询时间线中,Rows available 之后是 Execution cancelled,耗时 10s,正常情况下应该是 First row fetched。在 impala-shell 中无法复现,但是这两个的时间间隔有 3m10s,看执行情况,scan kudu 耗时 1 或 2 分钟,数据却在 4s 的时候准备好了,应该是边向客户端输出,边进行后续的数据扫描,而刚开始的输出可能是空的(其实这个地方不太理解,impala 究竟是怎么处理数据的,有空研究下)。但是 3m10s 的间隔肯定是超出了 10s 的限制,所以尝试调整了 FETCH_ROWS_TIMEOUT_MS 到 10min,问题解决。
  3. 服务端计算完成后,客户端在拉数时,服务端因为行数大小超出了 MAX_ROW_SIZE 大小报错,但是客户端并没有拿到这个失败,误认为服务端计算结果是空的,调大 impala 的 MAX_ROW_SIZE 可解决。

5.5k 5 分钟

CatalogServiceCatalog 管理所有 Catalog 元数据的加载以及处理 DDL 请求。它维护了一个全局版本,每当从 Catalog 中新增、修改或删除时,版本就会新增并分配给 CatalogObject。这意味这每一个 CatalogObject 将有一个单独的版本,被分配的版本会严格递增。

2.5k 2 分钟

CatalogObjectCache 是个缓存对象,为了缓存 CatalogdObjects,它是线程安全的。仅在新建或更新较新版本时执行真正的更新,add 和 remove 方法也需要更新全局实例 CatalogObjectVersionSet,它保持 catalog 版本的跟踪。