在星环大数据技术峰会深圳站中，星环的流产品研发经理杨俊给大家做《如何高效开发实时数据分析应用》的演讲。实时流处理一直是很多行业特别需要但门槛又特别高的技术，星环的产品可以让用户实现快速应用，易操作。小编特此推出演讲全文，供大家回味。
以下是演讲全文：
首先了解一下为什么使用实时技术。
这里有几张图：
第一张图是风电的应用。那风电应用为什么需要实时技术呢？以前没有这个技术的时候，它的延迟比较高，一旦有发电机组发生问题，它很晚才能反映过来去维修。这样就耽误了最佳维修时间，也会产生资源的浪费。若此时运用分布式的消息队列加上分布式的流处理，就可以使其达到秒级的实时预警效果。
第二张图是代表金融相关的一些问题。没有实时处理技术的时候，它们往往是在每天下班之前跑一下系统，评估公司的资产和风险状况。运用批处理的话，是将所有的市场数据进行估计运算，计算很多风险值。在这里如果有分布式的实时处理系统，它会在每次市场数据变化的时候重新计算一下公司的估值状况和风险情况，所以当下单结束或者市场交易结束的时候，我们拿到的已经是最新的市场数据，只需要进行查询和返回就可以了，不需要额外的计算。对于上层领导和监管部门来说，如果能及时反馈这些信息的话，可以帮助他们达到更好的决策效果。
最后一张图是交通部门秒抓套牌车的例子。以前没有实时处理的时候，很难想象交警会在下一个红绿灯口等着套牌车过来，也就是在实时处理的情况下，我们彻底改变了这个抓套牌车的场景。也就是说很多业务在原来批处理的角度是不可能实现的。以上是我简单举了几个实时处理的例子。其实类似的例子还有很多，星环的很多客户也已经开始运用我们的实时处理技术，效果都不错。
我的标题是如何高效开发实时数据分析应用，我们公司是从13年开始运用spark streaming来做实时应用，当时也遇到很多困难。
首先就是入门门槛是很高的。无论是我们和客户合作来推动应用的实现，还是和合作伙伴共同推动应用的实现，当时都是很困难的，写出来的应用质量不高。因为实时应用对性能要求很高，所以对代码质量的要求也比较苛刻，如果用spark streaming呢，需要对这个编程模型了解的比较清楚才可能写出高效的代码。所以对于程序员来说，这块的开发成本比较高。
另一方面，迁移成本很高。如果有一个公司，它想要把本身批处理的业务往实时处理的方向迁，那对于原来使用SQL的业务分析人员来说，让他们在转到spark streaming上就比较困难了。我们有的客户原来拥有的PL/SQL的代码量已经是几十万行了，让现有业务分析人员全部弄清楚都是很困难了，别说我们再将这些代码改写成spark streaming了，成本可能就高的离谱了。
最后一个问题就是产品化差。原来运维人员可能只需要会看几个常见错误就行了，但是现在这种写代码方式可能出现各种各样的问题，无法区分是框架本身的错误还是他代码的bug，他就需要去找程序员看出错误然后再解决，不仅麻烦，时间周期也比较长。
综上所述，我们认为直接使用编程的方式是不够高效的。所以我们从去年6月开始就想要完全采用SQL来写实时处理。
接下来有一个非常直观的例子。
左边这部分是用spark streaming 写的代码，这里还不是完整版，完整的需要2页ppt才能展示。如果用SQL写，就只需要右边的这几行代码了。这几行主要就是对test表根据一定的排列方式输出查询结果。这个SQL看上去就比较直观，稍微有点SQL经验的人都可以容易的看懂这些代码。如果让分析人员看左边的代码，那就比较困难了。
而且，右边的SQL代码还可能写的比左边的代码更高效，因为我们在框架层做了更多的优化。
接下来是stream SQL的框架图，分为三层。
最下面是存储层，在这一层上，我们的SQL可以对接各种存储层，例如ORC，Hyperbase,holodesk,Oracle等等。
中间层计算层中，我们对它的改动还是比较大的。对输入有一个Sourcemanager来控制，比如有多个表的时候要怎么去共享内存中的数据。然后有一个Application manager来管理过来的SQL是怎么运行的，运行周期是怎么样的，用户需不需要展开运行值或者状态信息。接下来，Distributed Execution Engine是我们集中改造的，这个引擎无论是对SQL还是执行计划的执行都是进行了比较高的优化的。Storage manager从用户的角度来说，比如存了一些东西，它到底是在内存里还是硬盘里面，中间的这些问题用户是不需要考虑的，我们再这里有一个透明层已经帮你解决掉了，而你是感觉不到我们在这里做的透明层的。Sink manager是和存储层和输出打交道的。比如我要输出到Hyperbase，sink manager就会考虑需要用分批存储的方式，因为这个方式性能比较高。
最后上层就是一些接口层，Inceptor这边你可以用SHELL直接打开连接数据库，或者用JDBC和ODBC来做steam SQL的连接操作，然后通过SQL compiler去把执行计划输入到下面的计算层中。我们还支持一些数据挖掘的接口，到目前主要是支持R语言，之后会有一些SQL的对接和图形化的对接。
那接下来支持语法的部分基本上和我们的数据仓库的语法是相同的，因为我们完全是从Inceptor那一套语法过来的。
SQL2003除了少数无法支持的语法之外，支持程度达到98%以上。这其中比如流上的数据是持续不断的数据，如果你要对它前一秒的数据在流上做修改其实是没有意义的，所以这块我们是不支持的。此外，我们还有一些额外的语法，主要是为了在流上面做更好的特殊化处理，因为原来的语法集是不能完备的支持流上面的特殊处理的。
另外，我们还支持Oracle的PL/SQL和DB2的PL/SQL，其实，支持PL/SQL的目前在这个地球上只有我们一家 :p
接下来我分享一下我们的一些经典案例场景。
第一个是有关于权限控制。团队来了新人，想基于生产集群的数据额外开发一些新的功能，这时候就需要比较高效的开发。或者现在有用户想查看某些信息，但是一些敏感信息只有管理员才能看到。另外，公司里的多租户环境中，多个租户同时在同一台机器上运行程序，不会相互干扰。
对于以上问题，我们抽象出了一个Application的概念，例如图中这个新用户叫做Emily，刚进公司把她归在一个testapp里面，你可以赋予她各种权限。比如她有权利在testapp里创建流应用，她有权利去看当前正在运行的分析系统，她有权利去启动一些以前存储过的存储过程。类似的，公司里可能还有一群人group1，对应他们有一个应用叫app1。如果现在Emily想去看group1的app1里的东西，不给她赋予一个特殊的权限，她是没办法看到的，所以我们就做到了一个这样的隔离。
具体来说是这样的，首先要去创建一个testapp，就是create application testapp，然后把相应的权限都赋给Emily。这样做了之后，一般来说到对应的testapp里去查相应的权限是可以查到Emily有权限的，但是她到另外一个生产集群上去做相应的操作，是没办法成功的。另外，我们的List命令是可以查询到一般的运行状态的，比如现在跑了多少task，运行了多长时间，在什么状态，有没有什么问题等等。额外的信息我们是不给普通权限的人开放的，需要有管理员信息才可以到4040页面查看。最后，不同租户之间，例如刚才的testapp和production之间做到彻底隔离互不干扰。
接下来的第二个案例是ETL任务的例子，像刚开头说到的风电的例子和交通稽查布控的例子其实就是他们主要用我们的系统做ETL任务。
如果有一些实时数据进来，我可能有需求要把他们存储起来，录入到某个库里面，或者后来需要做现场分析，我们要录入holodesk内存表，之后做查询。这就是一个非常常见的ETL任务，无论在什么行业里，当前这个用到的是比较多的。若这个步骤要用编程实现，工作量还是蛮大的，有很多问题需要考虑，接口怎么处理等等。如果是用我们的产品，你可以用过JDBC或者ODBC对接我们的StreamSQL，通过Stargate导到各个不同的数据库里，比如对Hyperbase做一个实时的检索，Holodesk可以做实时的交互分析，HDFS可以做统计分析和跑批等等。我们甚至可以把结果在写回Kafka，给下一个应用做实时告警。
接下来就是实现过程。首先创建流，然后创建几张表如图，最后启动流的时候只需要图中这几行SQL，你的ETL就完成了。其实就是需要这样几行SQL就可以实现流应用，当然，一开始你也可以加入聚合、复杂计算等，但是这也只是一个SQL的复杂化问题。
最后因为时间关系，我们就不详细介绍剩下两个案例。第三个是网站实时统计的一个场景，需求我列在ppt里，其实我们也只需要下面这张ppt里的几行SQL就可以解决。
最后一个案例是比较复杂的金融期货的案例。简单来说，整个过程就和刚才差不多，就不断的create一些stream表，不停的在stream表上做一些转化，再加上一些窗口函数，最后就可以实现一些很复杂的业务。