StreamSQL（主讲人：强琦）在线视频

下面我们简单介绍一下

我们在streamSQL

方面的一些工作

大家都知道从用户自己写

利用（）的API

到实现

MapReduce Merge的API

再到实现算子层API

再到使用UDEF

你可以（）自己的UDEF

UDAF和UDTF

可以看到它的易用性

是逐渐递增

但是表达能力

下面是越来越强

最近阿里巴巴云计算

推出的一个功能产品

叫streamSQL

它是支持用SQL一样的语意

来表示

让用户使用SQL来操作流计算

除了streamSQL在其下面

提供了算子层语意

也就是说

提供了5个基本原语

MapReduce Shuffle Union

和Merge

当然我们也实现了一些高级算子

用户也可以去扩展

这样的高级算子

包括Topk distinct Join windows

滑窗和固窗等

最底下的引擎

是整个流计算的

一个并行的DAG

在上层可以看到

是一个MRM层

其中最主要的部分

分为消息控制 容错

以及计算模型

那么在此之上定义了算子层

算子层再往上是SQL层

SQL层分为

SQL的解析（）

制定逻辑执行计划

根据拓普运行情况

和原信息

进行物理执行计划的优化

和SQL的改写

目前streamSQL

当然现在可以通过官网

去查看这样相应的文档

它的数据类型 它的表

它的DDL DML

和它的SQL语法

目前支持的一些UDF

UDAF等

那么我们可以定义我们的源表

也就是数据源

你可以create一个stream table

当然你这个stream table

你的输入可以是一个Q

可以是一个别的什么存储

属性可以附着进去

那么你的结构表

那么我们可以create

result table

可以去查到Hbase

这些都是很多的plugin的

一个系统

用户可以plugin自己的系统进去

用户还可以定义自己的维表

除了定义维表之外

用户也可以定义临时表

临时表其实作为一个

SQL的极联存在

它定义了内部数据流的一个Schema

实际上它是不存储任何的数据

它只是做串联上下游的逻辑

构造复杂DAG

这个就是一个简单的示例

worldcount的一个DDL

和一个DML

这是一个线上case的一个

物理执行计划

streamSQL底层的

有基本的算子源域

当然我们可以在算子层

有非常复杂的优化策略

和算子write的策略

本地化 包括下推逻辑

这块的优化以及

类似于数据库的物理执行计划

优化SQL改写

我将在下次课

也就是内存计算中

重点去介绍

用户除了写SQL之外

可以自定义函数算子

来实现它的逻辑

这是一个简单的GroupBy

然后union的例子

那这是它的对应的SQL的

一个实现

那么streamSQL它的系统架构

如图所示

分成gateway层

控制集群层和worker执行层

从这里可以看出

实际上对用户看到的

其实是物理的多个集群

但实际上对用户看到的

是统一的逻辑集群

上面我们提供了开发平台

就是一个Web的Id

监控报警

以及profiling debug

和Metric子系统

介绍了流计算后

今天我们在实际业务场景中

会发现很多很多的问题

什么问题

就是今天一个业务场景

它既有离线任务

又有流计算任务

还有实时的图计算 图分析任务

进而它又有一个ad-hoc的

一个查询任务

那么如果用户要完成

这样子的完整的链路

任务处理周期

这几个系统之间的数据

是要完全地复制

也就是说我用到的三个系统

都用了这张表数据

那实际上这张表

是要被重新加载三次

也就是说任务之间

是没有办法复用数据的

这在有些场景下是致命的

也就是说

用户的集群是有限的

你完成它的业务

需要用四五套系统

而这四五套系统

需要把这样的数据

全部重复地加载

会在整个的

这个部署集群规模上面

受到非常大的影响

而且我完成一个业务

需要各种各样的计算引擎

和计算模型

需要用户业务层

把多个系统进行融合

系统之间无法共享数据

那么

我们经常说云 云计算 大数据

那实际上在我们内部

我们认为应该是云数据与大计算

数据如果不能共想互通

大计算也很难做到完美

但是现在的目前现状是说

离线计算与在线计算

与实时计算鸿沟依然明显

从底层的处理框架

到用户态

完全都是独立的系统

所以我们可以看到

并串型的DAG

我们认Batch内是串行

Batch间才有并行

Batch是个scale ability的概念

是个可以scale的概念

是一个可以扩展的概念

从Shuffle service的概念来说

无论是用流计算的push

还是批量系统用pu的方式

不应该对计算逻辑产生任何影响

因为用户的业务逻辑

Shuffle Service

只是传送的数据的逻辑

应该对用户的功能没有关系

任务的

刚才我们说到的跟踪的方式

是不是能统一

那我们是不是能从

Shuffle的framwork

到Shuffle的Service

至于是不是提前拉起进程

这个与用户的业务逻辑

计算逻辑也没有关系

我们是不是能做到

纯粹的内存计算

那么我们能不能依靠

Batch的引入

将更多的数据更有效地

在内存里头组织

并通过引入并行DAG

和增量模型

离线和在线的鸿沟

所有的请求都走APPMaster

如我们如何去TradeOff吞吐

和延时

这是我们现在正在面临的问题

这也是我们现在的机会所在

在下堂课

我主要就这些问题引申开来

对目前的比较火的内存计算

谈一谈我们的实践经验

和对统一计算框架

一些实现的情况

再跟大家交流分享

以上我跟大家分享了流式计算

和增量计算的关键技术点

分布式计算领域

近期有非常多的新技术涌现

在以上计算系统之间

有哪些继承 延续

和发展呢

我将会在以后的内存计算课程中

有详细地介绍