数据计算

很多小微型应用程序也需要一些数据处理和计算能力，如果集成一个数据库就显得太沉重了，这种情况下 SQLite 是一个不错的选择，它架构简单，集成方便，可持久化存储数据，并提供 SQL 实现计算能力。 但

数据湖概述 提到数据湖就要先说一下数据仓库，数据仓库是集成多业务系统数据、面向主题的、专门用于数据查询分析的数据组织形式。当业务系统数据量不断增大、业务系统数量不断增多以后，数据仓库的出现就会成为必然

使用分布式集群来处理大数据是当前的主流，将一个大任务拆分成多个子任务分布到多个节点进行处理通常能获得显著的性能提升。因此，只要发现处理能力不足就可以通过增加节点的方式进行扩容，这也是很多拥趸者最朴素的

SQL 正在消耗数据科学家的生命 SQL 难写 数据科学家几乎都会用 SQL 做探索分析，SQL 看上去很简单，也有一定的交互性，做数据探索分析似乎很不错。 比如要进行过滤、分组等计算，简单一句就能完

先说观点：因为还没找到更好的。 接下来说原因，首先来看看大数据平台都在干什么。 原因 结构化数据计算仍是重中之重 大数据平台主要是为了应对海量数据存储和分析的需求，海量数据存储的确不假，除了生产经营产

教科书中 SQL 例句通常都很简单易懂，甚至可以当英语来读，这就给人造成 SQL 简单易学的印象。 但实际上，这种三行五行的 SQL 只存在于教科书和培训班，我们在现实业务中写的 SQL 不会论行，而

没错，就是著名的 JOIN。 JOIN 一直是数据库计算的老大难问题，业界想了很多办法来计算它。如果不做任何优化，那就是两个关联表循环遍历，这是个乘法级的复杂度，数据量稍大一点就受不了。成熟的数据库当

就是非常不起眼的帐号去重计数，用 SQL 写就是 COUNT(DISTINCT …)。 帐号去重计数在商业分析中很常见也有重要的业务意义。这里的帐号可能是用户 ID、银行帐户、手机号、车牌号、…。计算

json 是个好东西，它可以使用公共的文本形式承载了丰富的结构化数据的信息。现代很多技术都在喜欢使用 json 作为数据传输格式，比如 Elastic Search,Restful,Kafka 等，M

大数据时代的分布式数仓（如 MPP）是个热门技术，甚至到了提到数据仓库言必称分布式的地步。 但是，分布式数仓真有必要吗？毕竟这些分布式数仓产品都不便宜，无论是采购成本还是运维成本都很高。是不是有低成本

当前绝大部分数据仓库都会采用 SQL，SQL 发展了几十年已经成为数据库界的标准语言，用户量巨大，所以支持 SQL 对于数据仓库来讲也是很正常的。但是，在当代大数据背景下，业务复杂度节节攀升，在以计算

很多小微型应用程序也需要一些数据处理和计算能力，如果集成一个数据库就显得太沉重了，小巧轻量的 SQLite 是个不错的选择，因而被广泛应用。 不过，SQLite 也有些不方便的地方。SQLite 对外

Java 很长时间都没有提供直接的数据集运算语法，写个简单的 SUM 都要很多行，更不要说分组、排序等复杂运算了。完全同样数据处理功能的代码远比 SQL 长，开发效率低下。 从 Java8 开始，St

SQL 经常跑得很慢 SQL 是最常用的大数据计算语言，但是，SQL 经常跑得很慢，严重浪费硬件资源。 某银行的反洗钱准备计算，36 亿行，11 节点的 Vertica 集群跑了 1.5 小时。 某电

是的！你没看错，SPL，Structured Process Language，就是这样一种写在格子里的开源程序设计语言，专门用于处理结构化数据。 我们知道，几乎所有编程语言都是写成文本的，那写在格子

我们再来研究如何利用 JOIN 的特征实现性能优化，这些内容的细节较多，我们挑一些易于理解的情况来举例，更完善的连接提速算法可以参考乾学院上的《性能优化》图书及课程。 六、外键预关联 先看全内存下外键

五. 解决关联查询 我们重新审视和定义了等值 JOIN 运算，并简化了语法。一个直接的效果显然是让语句书写和理解更容易。外键属性化、同维表等同化和子表集合化方案直接消除了 JOIN 关键字，也更符合自

四. 维度对齐 我们再回顾前面的双子表例子的 SQL： 那么问题来了，这显然是个有业务意义的 JOIN，它算是前面所说的哪一类呢？ 这个 JOIN 涉及了表 Orders 和子查询 A 与 B，仔细观

我们来考察下面三种等值 JOIN： 1. 外键关联 表 A 的某个字段和表 B 的主键字段关联（所谓字段关联，就是前一节说过的在等值 JOIN 的过滤条件中要对应相等的字

一英里不是个很长的距离，一立方英里相对于地球也不会让人觉得是个很大的空间。然后我说，这个空间内能装下全世界所有人，你会不会觉到很惊讶？其实不过这话不是我说的，是美国作家房龙写的。 业内有个著名的数据仓