数据科学人
本周的主题是 SQL。
我们对 SQL 有说不完的抱怨：冗长，不能复用代码，难以调试，各种方言之间有着微妙的区别。是的，没有人怀疑，我们需要更好的 SQL，至少像其他编程语言一样好……一旦我们这样思考问题，就意味着我们承认分析是一个技术问题。
事实上，SQL 也不是一门为建造者而设计的语言，表达能力和可组合性并不是它首要目标，尤其在绝大部分用 SQL 来查询数据的场景中，人们只想知道某个具体问题的答案。
数据分析的关键能力从来就不是技术，而是过度的好奇心，是抽丝剥茧的推理能力，是在某个领域内的深厚积累，是和其他人沟通交流的能力，它们中任何一个都比会某项技术要更重要。
另一方面，优秀的分析师在哪里都千金难求，而技术可以更广泛地传播，并通过文档进行传授，并在明确的时间内完成培训，甚至出现在招聘启示之中，最终对社会产生更大的影响。
以下是本周的推荐。
1. Against SQL
本文是一则反对 SQL 的 manifesto，给我带来了非常多的启发。作者 Jamie Brandon 在成为一名独立研究者前，曾为 Materialize 和 Eve 等项目开发过数据库引擎和编译器，对语言和编译有着非常深入的理解，目前他正在做一个叫 imp 的项目，目标就是取代 SQL。Brandon 认为作为一种关系模型语言，SQL 有三个缺点导致它很难用，并降低了使用者的效率。
首先是表达能力差（Inexpressive）。SQL 和绝大部分编程语言不一样的点在于，使用者不能自己扩展类型和功能，导致写 SQL 的人不得不打更多的字来做非常基础的事情，最典型的例子就是 SQL 在实现 json 、正则和窗口函数（名字叫函数）这些基础功能时，把它们 hard code 到了语言规范中。
其次，SQL 代码不能压缩（Incompressible）。众所周知，程序员通过从不同代码中提取相同的结构来压缩代码，提高代码的可维护性，但 SQL 中基本就没有变量和函数的概念；由于函数和类型不是一等公民，因此也没有泛型和回调这样的高级语法；而且一个表达式时候不能直接平移到另一个表达式中，原因是 SQL 中表达式有可能返回两种不同类型：scalar或者 table。table 表达式有时可以返回 scalar，前提它只有一行一列，这种写法虽然很方便，但也很容易出错：
select
manager.name,
(select employee.name
from employee
where employee.manager = manager.name
order by employee.salary desc
limit 1)
from manager;
最后是 SQL 是封闭的（Non-porous），与之对应的是开放——能够轻松地与现有系统交互，并充分利用现有的库或者工具。SQL 设计上的缺陷导致 SQL 每添加一种新的功能时，就不得不增加一种新的语法，而这在其他编程语言中，通常都是通过 stdlib 来实现的，导致这些语法几乎是不可移植的。
由于 SQL 从一开始就没有引入函数、变量和类型的设计，导致使用者在写 SQL 时无法压缩代码，并抽象出通用组件，每次都从头开始，写出冗长的 SQL。而在发展过程中，各个实现为了能让使用者少写代码，逐渐在自己的方言中添加了这些本该由 stdlib 实现的特性，于是变得越来越封闭……
这种封闭性严重扼制了新的数据系统和相关工具的创新：
在现代编程语言中，语言本身由少量精心挑选的源语所组成。程序员将这些基元结合起来，构建其余的功能，这些功能可以以库的形式共享。这降低了语言设计者预先考虑每一种可能需求的负担，并允许新的实现复用已经有的功能。例如，如果你实现了一个新的 javascript 解释器，你就可以免费得到整个 javascript 生态系统。
每当你为一个数据系统开发一个基于 SQL 的新实现时，不得不从头实现整个生态系统。这最终导致一个庞然巨物，SQL 规范仅核心语言就有 1732 页，JavaScript 语言规范只有 800 多页，C++ 语言规范也不过 1800 多页。
即便如此，我们对 SQL 的认知还是：它是如此缺乏规范，SQL 甚至没有规定怎么做类型推断。由于缺乏规范，导致每个数据库最终都以非标准的扩展的形式来进行填补。即使是世界上最先进的数据库甚至也没有完全遵守 SQL 规范。
这种复杂度让很多基于 SQL 的创新只能停留在玩具的阶段，因为将它们提升到可用水平需要大量时间和金钱的投入。Brandon 说 Materialize 支持不同的 SQL 数据源的代码量大概是 13 万行(换算成人力成本是 15 到 20 人年)，而把 SQL 转化为逻辑执行计划就要用 3 万行代码。
这也让 SQL 的网络效应其他编程语言都要弱得多：
Similarly, users will be able to carry across some SQL knowledge, but will be regularly surprised by inconsistencies in syntax, semantics and the set of available types and functions. And unlike the programming language world they won't be able to carry across any existing code or libraries.
历史上， SQL 并非实现关系模型查询的唯一语法，既有在表达式语言中嵌入关系模型的框架，例如：Spark、Flink、Pandas 和 LINQ，也有 Logica 那样基于 datalog 的查询语言。
虽然 SQL 已经存在 50 多年了，它是否还会一直存在下去？也许我们今天没有确切答案，但至少我们看到了 Brandon 这样深刻的反省。
2. For SQL
本文的作者是 Hightouch 的 Pedram Navid。Navid 反对了 Brandon 的反对，因为他认为来自工程世界的挑剔眼光会打击那些将 SQL 作为主力语言的人，和所有正在学习 SQL 的人。这种批判对于现状无济于事，只能延续数据分析是二流技能的迷思。
When I see these arguments against SQL, and they pop up now and again, they’re almost always from software engineers and from a strictly software engineering lens. My worries with articles like this are not, to be clear, that SQL will die. SQL will live on long after I am gone. My real fear is that it discourages people from learning SQL and that it makes those whose primary language is SQL feel inadequate.
Navid 的一条非常有力的辩护是，很多 SQL 中有缺陷的问题，现实情况中几乎没有人会用。事实上 SQL 本来就不是一门为建造者而设计的语言，表达能力和可组合性并不是它首要目标，尤其绝大部分使用 SQL 的人，只是想快速地知道某个问题的答案。
Navid 表达了对 SQL 的支持，实质上是对使用 SQL 背后这个群体——data people 的声援，无论是数据工程师、数据分析师，抑或数据科学家——他们工作的重要程度不亚于构建网站、后端应用或基础设施。
The people who do the work are not any less skilled. And the tools and languages they use are not any less useful because they don’t have features of other languages. A good analyst is worth their weight in gold. They’re ruthless in their precision and excellent communicators. They’re empathetic to the business and have endless curiosity. Data people are some of the smartest, kindest people I’ve met.
从事这项工作的人的技能也并不逊色，虽然他们使用的工具和语言没有其他语言的功能，但这不影响他们工作的价值。好的分析师千金难求，他们冷静而准确，有出色的沟通能力，他们对业务有同情心，有无尽的好奇心。数据人员是我见过的最聪明、最善良的人。
3. Analytics is at a crossroads
在这篇文章里，Benn Stancil 延续了 Navid 在 For SQL 中的观点，他指出技术压根不是分析这项工作最难的部分。Stancil 打了一个比方，分析需要的是福尔摩斯那般推理问题的能力，而不是培训班教授的那些技能：
总的来说，分析师研究的最难和最重要的问题不是技术问题，甚至不是数学问题。启动数据库令人沮丧；使用数据库中的数据来推断某个模糊业务问题很困难；构建一个花哨的模型来预测客户流失很复杂；推测一个模型在什么情况下有效也是很难；解决这些问题需要好奇心和归纳推理，而不是 CS 教科书和计算器。如果可以选择，我会聘请夏洛克·福尔摩斯来做分析，而不是现如今 MIT 的任何工程学博士。
成为一名优秀的分析师，没有任何捷径。它需要强烈的好奇心，也需要在一个领域有大量的积累。我们经常形容在某个领域积累很深，和他聊聊天都能产生「听君一席话，胜读十年书」的感受，这是因为高手们厚积薄发，他们对信息的掌握是网状的，可以迅速连点成线。
我自然同意 Benn 的这个想法，优秀的分析师在哪里都千金难求，但不可忽视的是，技术，甚至是技能化以后的技术，才能更广泛地传播，通过文档进行传授，并在明确的时间内完成培训，甚至出现在用人单位的招聘启示中。例如 dbt 将工程技能从数据处理中剥离出来，提供了工具和相关培训，满足了大量企业对人才的需求。
他说我们正处在一个十字路口，道路的左边，数据团队可以聘请任何背景的分析师，他们将在分析工程师的帮助和下，专注于成为谜题解决者：
When someone questions if we’re real engineers, we shouldn’t feel the need to pull out our technical credentials. We should instead say, “So what? That’s not our job.”
而在道路的另一边，分析工程师则成为分析师的另一条职业发展路线，分析师一旦掌握了足够多的技术，就会成为分析工程师。
Project of the Week
本周 Count 对 Brandon 的「SQL 冗长且不可压缩的」观点做出了有趣的回应，他们推出了一个 SQL 「众包」的页面：
与其他语言不同，将常见的代码部分重用为函数或方法并非易事。在 Python 中，我可以轻松地将一段常用代码转换为函数，甚至可以将该函数作为开源包的一部分共享，以便任何其他 Python 用户也可以使用它。
如果你和我一样，为了应对这一挑战，你的桌面上有随机的 Notion 页面或 Word 文档，里面装满了你想要「下次再用」的片段。这是一个粗略的解决方案，我正在做一些事情来解决它。
Tweet of the Week
analysts are problem solvers, not builders. As long as you solve problems doesn't matter if you do it with Python, SQL, spreadsheet, calculator, or abacus. And yeah SQL is usually necessary but any "problem solver" can learn it in <1 week
硅谷非常鼓吹「创造」，所以出现了 10x engineer 这样的说法，但我好像从没听到有人说 10x analyst。
我认为这种说法表面上是硅谷将技术奉若神明，其实是把技术当做一种资源的体现，因为建造出来的代码是可以规模化的，而解决问题不能规模化。
以上是本期的推荐，希望对你有用。
就在写这篇 Newsletter 前不久，我们就遇到了业务分析代码被锁定在了 SparkSQL，导致技术选型受到了非常严重的限制。
下周见，
Dreamsome
❤️ 想支持《数据科学人》？把它推荐给 3 个朋友吧！
🚀 欢迎用电邮订阅《数据科学人》，我将以周报的形式发布内容