大数据-预习笔记-1 ｜ 青训营笔记

能鸽善鹉
182 阅读18分钟

大数据-预习笔记-1｜青训营笔记

这是我参与「第四届青训营 」笔记创作活动的的第1天！

一、大数据体系和 SQL

1、生产系统中的大数据体系

大数据系统体系:数据收集、数据存储、资源管理与服务协调、计算引擎、数据分析、数据可视化。具体内容详见链接文章。

2、SQL的基本用法和关系代数基础知识

（1）SQL的基本用法

Sql：结构化查询语言，是一种特殊目的的编程语言，是一种数据库查询和程序设计语言，用于存取数据以及查询、更新和管理关系数据库系统。

sql语言分为四个种类

  • DDL：数据定义语言，用来定义数据库对象：库，表，列等
  • DML：数据库操作语言，用来定义数据库记录（数据）增删改
  • DCL：数据库控制语言，用来定义访问权限和安全级别
  • DQL：数据库查询原，用来查询记录（数据）

SQL中的四种语言具体用法详见链接文章。

（2）关系代数

关系代数包括选择、投影、集合操作（并、差、交、重命名）、连接（等值连接、自然连接、外连接、左外连接、右外连接、全外连接、半连接）、除法等。详见链接文章。

3、编译原理相关的基础知识

  • 词法分析（Lexical Analysis）

    词法分析的输入是源程序,输出是识别出的记号流.目的是识别单词. 至少分以下几类：关键字(保留字)、标识符、字面量、特殊符号

  • 语法分析（Syntactic Analysis）

    输入是词法分析器返回的记号流,输出是语法树.目的是得到语言结构并以树的形式表示.对于声明性语句,进行符号表的查填,对于可执行语句,检查结构合理的表达式运算是否有意义.

  • 抽象语法树（Abstract Syntax Tree，AST）

是源代码的抽象语法结构的树状表示，树上的每个节点都表示源代码中的一种结构，之所以说是抽象的，抽象表示把js代码进行了结构化的转化，转化为一种数据结构。这种数据结构其实就是一个大的json对象，json我们都熟悉，他就像一颗枝繁叶茂的树。有树根，有树干，有树枝，有树叶，无论多小多大，都是一棵完整的树。

简单理解,就是把我们写的代码按照一定的规则转换成一种树形结构。

详细内容见链接文章。

4、SQL 里的执行计划

逻辑计划阶段被定义为LogicalPlan类，主要有三个阶段：

（1） 由SparkSqlParser中的AstBuilder将语法树的各个节点转换为对应LogicalPlan节点，组成未解析的逻辑算子树，不包含数据信息与列信息.

（2）由Analyzer将一系列规则作用在未解析逻辑算子树上，生成解析后的逻辑算子树

（3）有Optimizer将一系列优化规则应用在逻辑算子树中，确保结果正确的前提下改进低效结构，生成优化后的逻辑算子树

物理计划是将Spark SQL生成的逻辑算子树映射成物理算子树，并将逻辑计划的信息映射到Spark Core模型中的RDD、Transformation、Action的过程。生成物理计划后，一条SQL语句就变成了可以执行的Spark任务。

SQL 里的执行计划详见官方文档。

5、SQL 执行的基本流程

作为编程的基础，少不了和数据库打交道。一般都知道sql的基本语法，包括表查询、删除、插入、创建等语句的使用，那么从sql脚本到最终返回结果，这中间有哪些流程呢？本着好奇心，了解一下sql执行流程。

image.png （1）在打开客户端后，最初需要和sql服务器建立连接，账号认证和校验权限。

（2）认证后，客户端发生查询sql脚本给服务器

（3）服务器先检查查询缓存，如果命中了缓存，则立刻返回存储在缓存中的结果。否则进入下一阶段。

（4）服务器端进行SQL解析、预处理，再由优化器生成对应的执行计划。

（5）MySQL根据优化器生成的执行计划，再调用存储引擎的API来执行查询。

（6）将结果返回给客户端。

具体内容详见链接文章。

6、分布式系统中 shuffle 的实现方式

详见链接文章。

7、SQL 中 group-by 和 join 的执行方式

详见链接文章。

三、常见的查询优化器

详见链接文章。

1、Top-down Optimizer

自上而下优化器

2、Bottom-up Optimizer

自下而上优化器

3、Rule-based Optimizer，RBO

RBO-Rule_Based Potimizer基于规则的优化器

4、Cost-based Optimizer，CBO

CBO-Cost_Based Potimizer 基于成本的优化器

5、RBO 优化规则

RBO :RBO所用的判断规则是一组内置的规则，这些规则是硬编码在数据库的编码中的，RBO会根据这些规则去从SQL诸多的路径中来选择一条作为执行计划（比如在RBO里面，有这么一条规则：有索引使用索引。那么所有带有索引的表在任何情况下都会走索引）所以，RBO现在被很多数据库抛弃（oracle默认是CBO，但是仍然保留RBO代码，MySQL只有CBO）

RBO最大问题在于硬编码在数据库里面的一系列固定规则，来决定执行计划。并没有考虑目标SQL中所涉及的对象的实际数量，实际数据的分布情况，这样一旦规则不适用于该SQL，那么很可能选出来的执行计划就不是最优执行计划了。

6、CBO 相关概念

CBO :CBO在会从目标诸多的执行路径中选择一个成本最小的执行路径来作为执行计划。这里的成本他实际代表了MySQL根据相关统计信息计算出来目标SQL对应的步骤的IO，CPU等消耗。也就是意味着数据库里的成本实际上就是对于执行目标SQL所需要IO,CPU等资源的一个估计值。而成本值是根据索引，表，行的统计信息计算出来的。

四、查询优化器的社区开源实践

1、Apache Calcite

Apache Calcite是一款开源SQL解析工具, 可以将各种SQL语句解析成抽象语法术AST(Abstract Syntax Tree), 之后通过操作AST就可以把SQL中所要表达的算法与关系体现在具体代码之中。

Calcite的生前为Optiq(也为Farrago), 为Java语言编写, 通过十多年的发展, 在2013年成为Apache旗下顶级项目，并还在持续发展中, 该项目的创始人为Julian Hyde, 其拥有多年的SQL引擎开发经验, 目前在Hortonworks工作, 主要负责Calcite项目的开发与维护。

目前, 使用Calcite作为SQL解析与处理引擎有Hive、Drill、Flink、Phoenix、Phoenix和Storm，可以肯定的是还会有越来越多的数据处理引擎采用Caclite作为SQL解析工具。

2、Orca

Orca是一个现代的自顶向下的，基于Cascades优化框架的查询优化器。Orca和数据库系统是松耦合的，这样它可以支持不同的计算架构（如MPP和Hadoop）。

3、Volcano/Cascade 框架

Volcano主要是基于Kubernetes做的一个批处理系统，希望上层的HPC、中间层大数据的应用以及最下面一层AI能够在统一Kubernetes上面运行的更高效。

五、SQL 相关的前沿趋势

1、存储计算分离

随着计算机应用的普及，存储系统由传统的直连式存储（DAS）走向分离式存储的趋势日见明显，网络存储成为存储的主流。这主要缘于以下的原因：

  • 计算机用户对于数据服务的高性能、可扩展性、高可用性的要求大大提高，数据的安全、冗余、备份及恢复等技术日益变得重要。在传统模式下，数据存储资源和某一台固定的计算设备联系在一起，在运行过程中相互约束。存储设备变更要求计算设备随之改变。与单独的计算资源可连结的存储设备和DAS工作模式都已经无法满足用户在线可扩展的需求。计算资源和存储资源分离后，多个计算设备和多个存储设备可以通过网络各自组成计算资源群组和存储资源群组，既可以独立地提供计算和存储服务，又可以动态组合，建立计算系统环境。这样，才能从根本上解决上面的问题。
  • 由于信息量的大量增加，在存储容量大大增加的同时，存储管理费用也大大增加。据Gartner Group统计，对于最终用户，其存储容量与存储管理的开销大约为1:3。存储管理效率低下造成管理人员成本在管理费用中所占比例过高。使用DAS方式存储系统分散在各自独立的计算系统中，难以集中管理，必然会增加存储管理人力成本。在网络存储环境下，由于存储设备可以脱离主机的物理位置并进行集中管理使管理效率大大提高。如图2所示，相对于传统的存储环境，网络存储环境下每个人员所能管理的存储容量大大提高。

2、HSAP, HTAP, HTSAP

  • HSAP，Hybrid Serving/Analytical Processing（混合服务/分析处理） image.png

  • HTAP，Hybrid transaction/analytical process（混合事务/分析过程） image.png

  • HTSAP image.png

3、Cloud Native, Serverless

  • Cloud Native，云原生

到了 2015 年 Google 主导成立了云原生计算基金会（CNCF），开始围绕云原生的概念打造云原生生态体系，起初CNCF对云原生的定义包含以下三个方面：

应用容器化(software stack to be Containerized) 面向微服务架构(Microservices oriented) 应用支持容器的编排调度(Dynamically Orchestrated) 2017年, 云原生应用的提出者之一的Pivotal在其官网上将云原生的定义概况为DevOps、持续交付、微服务、容器这四大特征，这也成了很多人对 Cloud Native的基础印象。

  • Serverless，无服务器计算

Serverless是一种构建和管理基于微服务架构的完整流程，允许你在服务部署级别而不是服务器部署级别来管理你的应用部署。它与传统架构的不同之处在于，完全由第三方管理，由事件触发，存在于无状态（Stateless）、暂存（可能只存在于一次调用的过程中）计算容器内。构建无服务器应用程序意味着开发者可以专注在产品代码上，而无须管理和操作云端或本地的服务器或运行时。Serverless真正做到了部署应用无需涉及基础设施的建设，自动构建、部署和启动服务。

4、数据仓库，数据湖，湖仓一体，联邦查询

详情见链接文章。

（1）数据仓库

  • Wikipedia对数据仓库的定义：

在计算机领域，数据仓库（英语：data warehouse，也称为企业数据仓库）是用于报告和数据分析的系统，被认为是商业智能的核心组件。数据仓库是来自一个或多个不同源的集成数据的中央存储库。数据仓库将当前和历史数据存储在一起，用于为整个企业的员工创建分析报告。

比较学术的解释是，数据仓库由数据仓库之父W.H.Inmon于1990年提出，主要功能乃是将组织透过信息系统之在线交易处理(OLTP)经年累月所累积的大量数据，透过数据仓库理论所特有的数据存储架构，作一有系统的分析整理，以利各种分析方法如在线分析处理(OLAP)、数据挖掘(Data Mining)之进行，并进而支持如决策支持系统(DSS)、主管信息系统(EIS)之创建，帮助决策者能快速有效的自大量数据中，分析出有价值的信息，以利决策拟定及快速回应外在环境变动，帮助建构商业智能(BI)。

  • 数据仓库的本质包含如下三部分：

①内置的存储系统，数据通过抽象的方式提供（例如采用Table或者View），不暴露文件系统。

②数据需要清洗和转化，通常采用ETL/ELT方式

③强调建模和数据管理，供商业智能决策

从上述的标准判断，无论传统数据仓库（如Teradata）还是新兴的云数据仓库系统（AWS Redshift、Google BigQuery、阿里云MaxCompute）均体现了数仓的设计本质，它们均没有对外暴露文件系统，而是提供了数据进出的服务接口。

（2）数据湖

  • Wikipedia对数据湖的定义：

数据湖是指使用大型二进制对象或文件这样的自然格式储存数据的系统。它通常把所有的企业数据统一存储，既包括源系统中的原始副本，也包括转换后的数据，比如那些用于报表, 可视化, 数据分析和机器学习的数据。数据湖可以包括关系数据库的结构化数据(行与列)、半结构化的数据(CSV，日志，XML, JSON)，非结构化数据 (电子邮件、文件、PDF)和 二进制数据(图像、音频、视频)。储存数据湖的方式包括 Apache Hadoop分布式文件系统， Azure 数据湖或亚马逊云 Lake Formation云存储服务，以及诸如 Alluxio 虚拟数据湖之类的解决方案。数据沼泽是一个劣化的数据湖，用户无法访问，或是没什么价值。

  • AWS的定义相对简洁：

数据湖是一个集中式存储库，允许您以任意规模存储所有结构化和非结构化数据。您可以按原样存储数据（无需先对数据进行结构化处理），并运行不同类型的分析 – 从控制面板和可视化到大数据处理、实时分析和机器学习，以指导做出更好的决策。

但无论数据湖的定义如何不同，数据湖的本质其实都包含如下四部分：

①统一的存储系统

②存储原始数据

③丰富的计算模型/范式

④数据湖与上云无关

从上述四个标准判断，开源大数据的Hadoop HDFS存储系统就是一个标准的数据湖架构，具备统一的原始数据存储架构。而近期被广泛谈到的数据湖，其实是一个狭义的概念，特指“基于云上托管存储系统的数据湖系统，架构上采用存储计算分离的体系”。

（3）湖仓一体

湖仓一体，即打通数据仓库和数据湖两套体系，让数据和计算在湖和仓之间自由流动，从而构建一个完整的有机的大数据技术生态体系。

①湖和仓的数据/元数据无缝打通，且不需要用户人工干预

②湖和仓有统一的开发体验，存储在不同系统的数据，可以通过一个统一的开发/管理平台操作

③数据湖与数据仓库的数据，系统负责自动caching/moving，系统可以根据自动的规则决定哪些数据放在数仓，哪些保留在数据湖，进而形成一体化

（4）联邦查询

5、智能化：AI4DB，DB4AI

（1）AI4DB，利用人工智能技术优化数据库有几个挑战。

①Model Selection
有两个挑战。首先，ML模型有多种（例如正向进给、顺序、图嵌入），手动选择合适的模型并调整参数效率低下。其次，很难评估学习模型在大多数场景中是否有效，对于这些场景，需要验证模型。

②Model Validation
很难评估学习模型是否有效，是否优于非学习方法。例如，旋钮调整策略是否真的适用于工作负载？需要设计验证模型来评估学习模型。

③Model Management
不同的数据库组件可能使用不同的ML模型，提供统一的ML平台以实现统一的资源调度和统一的模型管理非常重要。

④Training data
大多数人工智能模型需要大规模、高质量、多样化的训练数据来实现高性能。然而，在AI4DB中获取训练数据相当困难，因为数据要么是安全关键的，要么依赖于DBA。例如，在数据库旋钮调整中，根据DBA的经验收集训练样本。获取大量的训练样本非常困难。此外，为了建立有效的模型，训练数据应该涵盖不同的场景、不同的硬件环境和不同的工作负载。它需要使用一个小的训练数据集来获得高质量模型的新方法。

⑤Adaptability
适应性是一个很大的挑战，例如，适应动态数据更新、其他数据集、新的硬件环境和其他数据库系统。我们需要应对以下挑战。首先，如何使数据集上经过训练的模型（例如优化器、成本估算）适应其他数据集？第二，如何使经过训练的硬件环境模型适应其他硬件环境？第三，如何使经过训练的数据库模型适应其他数据库？第四，如何使经过训练的模型支持动态数据更新？

⑥Model convergence
学习模型能否收敛是非常重要的。如果模型无法收敛，我们需要提供替代方法，以避免做出延迟和不准确的决策。例如，在旋钮调节中，如果模型不收敛，我们无法利用该模型进行在线旋钮建议。

⑦Learning for OLAP
传统的OLAP侧重于关系数据分析。然而，在大数据时代，出现了许多新的数据类型，例如图形数据、时间序列数据、空间数据，这就需要新的数据分析技术来分析这些多模型数据。此外，除了传统的聚合查询外，许多应用程序还需要使用机器学习算法来增强数据分析，例如图像分析。因此，集成人工智能和数据库技术以提供新的数据分析功能相当具有挑战性。

⑧Learning for OLTP
事务建模和调度对于OLTP系统非常重要，因为不同的事务可能会有冲突。然而，它不能自由地建模和调度事务，它需要更高效的模型，可以在多个核心和多台机器中即时建模和调度事务。

（2）DB4AI，利用数据库技术优化人工智能算法仍然存在一些挑战。

①In-database training
在数据库内部支持人工智能训练具有挑战性，包括模型存储、模型更新和并行训练。首先，将模型存储在数据库中是一个挑战，这样模型就可以被多租户训练和使用，我们需要考虑安全和隐私问题。其次，更新模型是一项挑战，尤其是当数据动态更新时。

②Training acceleration using database techniques
大多数研究集中在人工智能算法的有效性上，但对效率没有太多关注。它呼吁利用数据库技术来提高人工智能算法的性能，例如索引和视图。例如，自动驾驶车辆需要大量示例进行培训，这相当耗时。实际上，它只需要一些重要的例子，例如夜间或雨天的训练案例，但没有太多多余的例子。因此，我们可以对样本和特征进行索引，以进行有效的训练。

③AI optimizer
现有研究使用用户定义函数（UDF）来支持人工智能模型，但这些模型没有得到有效优化。它要求将人工智能模型实现为操作员内部数据库，并为每个操作员设计物理操作员。最重要的是，它需要推下人工智能运营商，并估计人工智能运营商的成本/基数。它需要一个人工智能优化器来优化人工智能训练和推理。此外，在分布式环境中有效支持人工智能操作员更为重要。

④Fault-tolerant learning
现有的学习模型训练没有考虑容错性。如果一个进程崩溃，整个任务将失败。我们可以使用容错技术来提高数据库学习的鲁棒性。然而，为了确保在可预测/不可预测的灾难下业务的连续性，数据库系统必须提供容错和灾难恢复等功能。

avatar
文章
阅读
粉丝