始终

最近在读各种 Hive SQL，发现一个可读性问题，让我很无奈。这里记录一下，希望看到的读者能够写出可读性更好的代码。

因为业务比较复杂，所以大家经常会用到各种子查询（sub-query）。于是会写成类似这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

SELECT
  t1.foo,
  t2.bar,
  t3.baz
FROM (
    SELECT
      foo,
      bar
    FROM
      tb1
    WHERE
      <conds>
  ) AS t1 INNER JOIN (
    SELECT
      baz
    FROM
      tb2
    WHERE
      <conds>
  ) AS t2 ON <conds>
WHERE
  <conds>;

这样写子查询会有两个问题。一是子查询的结果如果要在多个不同地方用到，那么就要复制粘贴多次，实际执行的时候也可能执行多次。二是当子查询或/和 JOIN 特别多的时候，整个查询就会变得无比复杂，可读性极差。为解决问题，可用视图（VIEW）解决，也可用 WITH ... AS ... 子句来解决。

这些天使用 Hive 的过程中遇到了新的知识点，于是将 LATERAL VIEW 的使用方法记录下来。

在很早的上一篇文章中，我们讲了英语当中的时态选择。时态选择涉及到的主要是谓语动词的形态变化。此篇继续讲动词，不过话题转向非谓语动词。

希望若干年后的史书，会这样记载 2020 年初的疫情。

本着 Homebrew 真香的原则，我尝试在 CentOS 上安装 Linuxbrew。至于不用 Yum 的原因，请看刚才提到的真香原则。

但随即，我就陷入到了 Glibc 的泥潭。这个泥潭是一个需要自举（bootstrap）的循环依赖；这个泥潭长这样：

• Linuxbrew 安装任何东西都依赖 curl 和 git，而且它不想用系统中自带的 curl 和 git。
• curl 和 git 都直接或间接依赖 Glibc。
• Linuxbrew 里的 Glibc 版本比较高，目前是 2.23，因此依赖高版本的 GCC（>= 4.7），以及因为 Linuxbrew 的缘故依赖 curl 和 git。
• 系统里的 GCC 版本较低，因此 Linuxbrew 安装 Glibc 失败；而通过 Linuxbrew 安装高版本的 GCC 又再次依赖 Glibc。

泥潭里有两个循环依赖：

• Glibc 和 curl 及 git 等基础工具相互依赖；
• Glibc 和 GCC 相互依赖。