数据分析的方式
数据分析的方式大致上可以划分为 SQL 和 命令式两种
命令式
在前面的 RDD
部分, 非常明显可以感觉的到是命令式的, 主要特征是通过一个算子, 可以得到一个结果, 通过结果再进行后续计算.
命令式的优点
命令式的缺点
SQL
对于一些数据科学家, 要求他们为了做一个非常简单的查询, 写一大堆代码, 明显是一件非常残忍的事情, 所以 SQL on Hadoop
是一个非常重要的方向.
SQL 的优点
SQL
明显就是为了查询三个字段, 又比如说这段 SQL
明显能看到是想查询年龄大于 10 岁的条目SQL 的缺点
SQL
, 维护起来应该挺力不从心的吧SQL
来实现机器学习算法, 也挺为难的吧SQL
擅长数据分析和通过简单的语法表示查询, 命令式操作适合过程式处理和算法性的处理. 在 Spark
出现之前, 对于结构化数据的查询和处理, 一个工具一向只能支持 SQL
或者命令式, 使用者被迫要使用多个工具来适应两种场景, 并且多个工具配合起来比较费劲.
而 Spark
出现了以后, 统一了两种数据处理范式, 是一种革新性的进步.
SparkSQL 的特点
因为 SQL
是数据分析领域一个非常重要的范式, 所以 Spark
一直想要支持这种范式, 而伴随着一些决策失误, 这个过程其实还是非常曲折的
Hive
解决的问题
Hive
实现了 SQL on Hadoop
, 使用 MapReduce
执行任务MapReduce
任务新的问题
Hive
的查询延迟比较高, 原因是使用 MapReduce
做调度Shark
解决的问题
Shark
改写 Hive
的物理执行计划, 使用 Spark
作业代替 MapReduce
执行物理计划Shark
的查询效率很高新的问题
Shark
重用了 Hive
的 SQL
解析, 逻辑计划生成以及优化, 所以其实可以认为 Shark
只是把 Hive
的物理执行替换为了 Spark
作业Hive
, 想要增加新的优化非常困难Hive
使用 MapReduce
执行作业, 所以 Hive
是进程级别的并行, 而 Spark
是线程级别的并行, 所以 Hive
中很多线程不安全的代码不适用于 Spark
由于以上问题, Shark
维护了 Hive
的一个分支, 并且无法合并进主线, 难以为继
SparkSQL
解决的问题
Spark SQL
使用 Hive
解析 SQL
生成 AST
语法树, 将其后的逻辑计划生成, 优化, 物理计划都自己完成, 而不依赖 Hive
Catalyst
SQL
解析器, 可以不使用 HQL
, 此外, 还引入和 DataFrame
这样的 DSL API
, 完全可以不依赖任何 Hive
的组件Shark
只能查询文件, Spark SQL
可以直接降查询作用于 RDD
, 这一点是一个大进步新的问题
SparkSQL
, 依然有挺多问题, 例如只能支持 SQL
的使用, 不能很好的兼容命令式, 入口不够统一等Dataset
SparkSQL
在 2.0 时代, 增加了一个新的 API
, 叫做 Dataset
, Dataset
统一和结合了 SQL
的访问和命令式 API
的使用, 这是一个划时代的进步
在 Dataset
中可以轻易的做到使用 SQL
查询并且筛选数据, 然后使用命令式 API
进行探索式分析
重要性
SparkSQL
不只是一个 SQL
引擎, SparkSQL
也包含了一套对 结构化数据的命令式 API
, 事实上, 所有 Spark
中常见的工具, 都是依赖和依照于 SparkSQL
的 API
设计的总结
**SparkSQL
是一个为了支持 SQL
而设计的工具, 但同时也支持命令式的 API
**
SparkSQL 的应用场景
定义 | 特点 | 举例 | |
---|---|---|---|
结构化数据 | 有固定的 Schema | 有预定义的 Schema | 关系型数据库的表 |
半结构化数据 | 没有固定的 Schema,但是有结构 | 没有固定的Schema,有结构信息,数据一般都是自述的 | 指一些有结构的文件格式。例如JSON |
非结构化数据 | 没有固定的 Schema,也没有结构 | 没有固定的 Schema,也没有结构 | 指文档图片之类的格式 |
结构化数据
一般指数据有固定的 Schema
, 例如在用户表中, name
字段是 String
型, 那么每一条数据的 name
字段值都可以当作 String
来使用
+----+--------------+---------------------------+-------+---------+
| id | name | url | alexa | country |
+----+--------------+---------------------------+-------+---------+
| 1 | Google | https://www.google.cm/ | 1 | USA |
| 2 | 淘宝 | https://www.taobao.com/ | 13 | CN |
| 3 | 菜鸟教程 | http://www.runoob.com/ | 4689 | CN |
| 4 | 微博 | http://weibo.com/ | 20 | CN |
| 5 | Facebook | https://www.facebook.com/ | 3 | USA |
+----+--------------+---------------------------+-------+---------+
// 1.字段有约束
// 2.字段类型也有的约束
半结构化数据
一般指的是数据没有固定的 Schema, 但是数据本身是有结构的
{
"firstName": "John",
"lastName": "Smith",
"age": 25,
"phoneNumber":
[
{
"type": "home",
"number": "212 555-1234"
},
{
"type": "fax",
"number": "646 555-4567"
}
]
}
// 有列、每一列有类型,可以修改没有严格的约束
没有固定 Schema
指的是半结构化数据是没有固定的 Schema 的, 可以理解为没有显式指定 Schema
比如说一个用户信息的 JSON 文件, 第一条数据的 phone_num 有可能是 String, 第二条数据虽说应该也是 String, 但是如果硬要指定为 BigInt, 也是有可能的
因为没有指定 Schema, 没有显式的强制的约束
有结构
虽说半结构化数据是没有显式指定 Schema 的, 也没有约束, 但是半结构化数据本身是有有隐式的结构的, 也就是数据自身可以描述自身
例如 JSON 文件, 其中的某一条数据是有字段这个概念的, 每个字段也有类型的概念, 所以说 JSON 是可以描述自身的, 也就是数据本身携带有元信息
SparkSQL 处理什么数据的问题?
SparkSQL 相较于 RDD 的优势在哪?
总结: SparkSQL 适用于什么场景?
SparkSQL 适用于处理结构化数据的场景
本章总结