Metabase Impala Driver

更新日志

  1. Metabase Impala Driver 0528更新日志
  2. Metabase Impala Driver 0710更新日志

背景

我们的数据仓库是 Hadoop/Hive 体系的。Hadoop 版本采用的是 CDH 发行版。在这个背景下 SQL on Hadoop 的方案有 Hive/Impala/(SparkSQL)。作为 BI 数据库,Impala 在我们的场景下比较合适。

  1. Hive:太慢了。做 ETL 可以,BI 非常不适。
  2. SparkSQL:CDH 官方 Spark 不含 Thrift Server。为了能够使用 Metabase ,独立于 CDH 启了个 Thrift Server,用着还不错。问题就在于缺乏统一管理,比如 Kerberos 的管理就得自己写脚本处理、进程 OOM 挂掉了 CDH Manager 也监测不到。
  3. Impala:CDH 官方出品,为 BI 而设计,由 CDH Manager 管理。根据这份报告,见下参考链接,Impala 好于 SparkSQL。

出于尽可能复用已有基础设施的目的,选择 Impala。而 Metabase 官方、社区并不提供 Impala 驱动。本文就是为了探索并解决这个问题。

参考:

  1. 开源OLAP引擎测评报告(SparkSql、Presto、Impala、HAWQ、ClickHouse、GreenPlum) http://www.clickhouse.com.cn/topic/5c453371389ad55f127768ea

现有驱动探索

搭建 Impala 开发环境

使用 Cloudera Quickstart Docker 镜像(官方已经下架 quickstart vm )。其中,Impala版本 2.5.0。(我们的生产环境:CDH 6.3.2 Impala 3.2.0 Hive 2.1.1)

微信用户授权头像内容带随机干扰的问题

项目需要基于头像、昵称对不同实体账号下的微信用户进行匹配。基于这个思路,打算先下载微信头像的图像,后计算其MD5,“单元测试”了下这个简单方法,结果惊人。

同一个人的同一个头像链接返回的图像内容都不一样。内容不一样,MD5值也就不一样。

看来微信对我们这些拙劣的手段早有防备。

微信头像内容分析

同一个头像链接下载两次。

$ wget -O 1.png https://wx.qlogo.cn/mmopen/vi_32/DYAIOgq83eoc614h6RfCUnwQTblG9y2dq4g5PKVicVZd5CQO9JNdPCWCovl8cmsvxQcWDemcLYGW6pSt97uUW5A/132
$ wget -O 2.png https://wx.qlogo.cn/mmopen/vi_32/DYAIOgq83eoc614h6RfCUnwQTblG9y2dq4g5PKVicVZd5CQO9JNdPCWCovl8cmsvxQcWDemcLYGW6pSt97uUW5A/132

$ md5 1.png
MD5 (1.png) = dd6aa938cbec381a3e83702776be88a3
$ md5 2.png
MD5 (2.png) = 83668a6ad7eeee8fa8e5e0db339233d1

肉眼比较

肉眼完全无法区分。

../../images/image-20200514134445598.png

字节级比较

两张图,可以看出差异很大。

../../images/image-20200514134712953.png

像素级比较

为了方便对比,图先灰度化(一个像素点的RGB三值改为1个值)。

../../images/image-20200514184021629.png

两张灰度图差值的数据分布。x轴为差值,y轴为出现次数。

0代表相同位置的像素点相同,非0代表相同位置像素点有差异及其差异幅度。

0出现次数最多,可见两张图的大部分像素点的值是相同的。差异主要分为两部分,1-10 闭区间。(试了几张图)

../../images/image-20200515094333720.png

NUC8i5BEH Hackintosh

买了个 NUC8i5BEH 当玩具,不怎么折腾的方式体验下黑苹果。

../../images/image-20200504145011481.png

效果

../../images/image-20200504132303349.png

与我的 2018 MBP 13.3 做对比。处理器、显卡是一样的。用很少的钱提升内存,16GB 2133 DDR3 -> 32GB 2400 DDR4。

../../images/image-20200504132417310.png

成本

大概 ¥4000。2018年买的MacBook近¥15000。

  1. NUC8i5BEH ¥2379
  2. DDR4 2400 16 GB X 2 笔记本内存条 ¥978
  3. 500GB M.2 SSD 大约¥600(不在这次消费计划里,从现有机器抠出来的)

不足

WiFi、蓝牙,以及之上的AirDrop等功能缺失。

网上有解决方案,主要是网卡使用Macbook的配件替代。感觉配件也不便宜,应该是炒热了。用网线,不折腾了。

WHY NUC8i5BEH

豆子峡谷 NUC8i5BEH 机箱真的小!性能也不差。可以说,是最具性价比的了。

能做这么小,机箱与电源分离的设计功不可没。- -!

../../images/v2-80ec6cb9eb82fa2c5e0e16cbda516f41_720w.jpg

consul 小结

简单介绍

hashicorp 对 Consul 的定位是服务间网络方案。

Consul is a service networking solution to connect and secure services across any runtime platform and public or private cloud. https://www.consul.io/

官方的两个 use case 就是 service discovery, service mesh。

service discovery

与 etcd 比起来,Consul 的服务发现是开箱即用的。优点如下:

  1. First class 的服务注册和获取接口。不需要像 etcd 那样在 kv 存储基础上做包装。
  2. 服务注册,可以是consul 命令,也可以是HTTP API。
  3. 获取服务注册表,除了 HTTP 接口,还可以使用 DNS 查询接口。
  4. 健康检查。服务注册的时候可以提供健康检查项。健康检查机制保证了拿到的服务注册表是“健康”的。健康检查也包括节点的检查。单纯利用 consul 健康检查这个功能,consul 就是一个分布式监控工具。
  5. Web 管理界面。节点、服务、健康与否一目了然。
  6. Watch 功能。通过 blocking queries/ long-polling HTTP API 的方式得到服务注册表的改变的通知。
  7. 跨数据中心(取资源)。When a request is made for a resource in another datacenter, the local Consul servers forward an RPC request to the remote Consul servers for that resource and return the results. https://learn.hashicorp.com/consul/security-networking/datacenters#data-replication

service mesh

service discovery 只是微服务治理的初级阶段。作为服务请求方,通过 consul/ etcd 获取到服务注册表,下一步就是选择其中一个服务实例,发送请求。这个步骤叫做负载均衡。可以想象,客户端的代码会越来越重了。

etcd 小结

简介

取名有意思。Linux下的/etc目录放的是配置文件。etcd,etc代表配置,d代表distributed,代表分布式配置。

特点:

  1. designed to reliably store infrequently updated data and provide reliable watch queries https://etcd.io/docs/v3.4.0/learning/data_model/
  2. KV 核心用户接口
  3. MVCC Multi-version Concurrency Control 也确实能读历史版本
  4. Raft consensus algorithms 共识算法
  5. Watch 配置更新能及时"通知"应用
  6. RBAC 用户、角色、权限

基于 etcd 可以做哪些事情:

  1. 配置中心。元数据存储。应用的配置集中存储在配置中心。
  2. 服务发现。配置中心的一个特例。相比起来,consul的服务发现是开箱即用的。
  3. 分布式锁。分布式系统协调。选主。像是Hadoop使用Zookeeper做Namenode的选主。

vs. Consul。Consul 官方(https://www.consul.io/)定义的usecase是 service discovery和 service mesh。

etcd and Consul solve different problems. If looking for a distributed consistent key value store, etcd is a better choice over Consul. If looking for end-to-end cluster service discovery, etcd will not have enough features; choose Kubernetes, Consul, or SmartStack. https://github.com/etcd-io/etcd/blob/master/Documentation/learning/why.md#consul

k8s configmap 与热更新

configmap 简介

官方介绍:使用 ConfigMap 配置 Pod https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-pod-configmap/

他人总结:ConfigMap https://jimmysong.io/kubernetes-handbook/concepts/configmap.html

稍微总结下:

  1. 每个configmap都有一个名字,名字全局唯一(命名空间内),重复创建会报错。
  2. 每个configmap本身是键值对。
  3. configmap可以通过环境变量的方式让Pod内容器读取。
  4. configmap可以通过挂载文件的方式让Pod内容器读取。k8s每隔一段时间同步configmap,如果有更新的话。当然,应用本身是不知道的。这个定时更新感觉有点鸡肋。
  5. configmap更新,不会自动重启应用。只能人工方式,滚动重启应用。

把配置更新也当作一次应用变更看待,心情就好很多了。

官方不支持热更新,所以有了各种技巧,提高效率。

  1. create a new ConfigMap with the changes you want to make, and point your deployment at the new ConfigMap https://stackoverflow.com/a/40624029/820682 因为 deployment 文件变化了,触发滚动重启。
  2. 还有deployment 文件中配置 configmap hash值的。配置变化,hash值变化,deployment变化,滚动重启,一级级联动。 https://blog.questionable.services/article/kubernetes-deployments-configmap-change/
  3. 还有使用sidecar的方式做热更新的,太复杂了 https://zhuanlan.zhihu.com/p/57570231

关于热更新

configmap的更新,容器化应用是无感知的。configmap这种方式没有推送更新到应用内的机制,要实现热更新过于复杂。

k8s最核心的功能还是自动部署、伸缩、容器管理以及资源分配。微服务架构还是得需要其他框架来辅助的。

配置热更新应用,就选择 etcd, consul 吧,有 watch 功能。