Apache Kylin最新的Streaming OLAP实现

Apache Kylin最新的Streaming OLAP实现_第1张图片

本文来自作者在GitChat(ID:GitChat_Club)上的精彩分享,CSDN独家合作发布。


Apache Kylin是第一个来自中国的Apache顶级开源项目,连续两年获得了InfoWorld最佳开源大数据工具奖,2016年更是与Google TensorFlow一起获得该奖。 Apache Kylin的社区也非常活跃,目前Kylin被用于eBay、Expedia、网易、美团、百度、唯品会、京东、搜狐、OPPO等知名公司,在全球范围有200多家公司正式使用,而且都应用得非常大。


Kylin解决的是什么?


Kylin所带来的,是大数据场景下快速分析的能力。举一个例子,今日头条看新闻的时候,前面会有一些推送,需要用到一些转换,把数据拿下来之后做分析。单个应用的数据量有多大?3万亿条。Kylin里面3万亿条的数据,任何搜索查询的速度只需要1秒。这就是我们的能力。


现状:Hadoop的生产力未得到充分释放。


绝大多数平台公司的平台结构,在以前没有Hadoop的时候都会把数据放到数据仓库中,用数据库进行分析。十年前最大的数据仓库是沃尔玛,大概是3个P,eBay的数据仓库是10P左右,但Hadoop超过200P。当时没有在大数据平台上提供数据仓库的能力。因此在2013年我们评估了七八种商业的和开源的技术方案之后,最后决定自己做。 我们希望把数据仓库的能力在Hadoop之上构建起来,这也就诞生了Kylin。我们在Hadoop之上提供Kylin的数据仓库,最开始做的是一个预先计算的立方体(cube)技术,通过这样的技术扩展到目前支持全部的数据集市、未来可以支持更多的数据仓库的能力。 具体能够提供哪些东西呢?


  • 超高性能:不管数据有多大,十亿、百亿、万亿保证性能在秒级返回,满足传统数据分析应用的时效性要求。最近正在给保险公司做压力测试。


  • 高并发:往往大数据的系统,甚至是数据仓库的系统,即使性能优化得再好,并发也是一个痛,这是由分布式系统决定的缺陷。你有一千台机器,一条SQL下去的时候很快,但是一千人、一万人,乃至十万人同时上线压上去的时候,你的数据不可能永远均匀地存储,200左右的并发一定会打爆。对于此类高并发的问题,我们通过构建一层数据集市层来解决。


  • 标准SQL:用过Hadoop Hive的知道,Hive这个东西挺好,但是你不能给业务人员去用,他们喜欢的是标准的SQL,这也是Kylin非常重要的一个特性。


Apache Kylin的架构


Apache Kylin最新的Streaming OLAP实现_第2张图片


我们会要求把数据放在Hadoop上,用Hive呈现出来。在Kylin里面定义整个元数据,在一个企业里面不是工程师去做,而应该是BI人员或者分析师去做。工程师喜欢底层技术,但是BI及分析人员并不关心底层实现。所以,我们提供了一个非常好的界面,你可以在上面构建,当你把所有的工作做完之后,Kylin会生成MapReduce 或者Spark任务,你不需要写一行代码。Kylin会跟集群交互做计算,过程中你也不需要登录去看,我们都通过界面去给到你,这带来的好处是效率。大数据人才找不到,原因不是被BAT抢了就是被华为抢了。我们提供的工具是降低使用门槛,让分析师自己去做大数据分析,让上层分析师、业务用户通过自己喜欢的BI工具或者自己写个程序,进行访问。在访问的过程中,它不会去运行任何Hive,也不会运行Map Reduce。


V1.5核心组件解耦:


Apache Kylin最新的Streaming OLAP实现_第3张图片


我们是预计算的一个系统,带来的好处是数据可以跑批,我们解决的是第一个问题。第二个问题,批量的计算量太大了,越来越多的需求是要做实时、做近实时、做流式。在数据生产的点出来的时候,把那个时间点缩到最短,这是我们当时工作的目的。 我们第一件事情是把输入、输出和计算引擎全部解耦掉,我们花很大的力气做了一个架构的重构,在新的组件中叫可插拔的架构。今天Kylin无论是输入、输出都可以被插拔,可以换,非常方便。


eBay网站SEO的流量,整个搜索引擎过来的流量,被eBay的tracking 系统抓下来,以前是一两天分析师才能看到报表,我们把它降到5分钟左右,这是我离开eBay之前做得最大的项目。怎么做的呢?Kafka两个集群过来,我们自己写了一整套的程序去跑。当然,这里带来的问题是要写很多的手工配置,如下图是1.5版本。


Apache Kylin最新的Streaming OLAP实现_第4张图片


在2016年11月的时候改了很多东西。最开始是怎么处理的?可以看到,数据流进来的时候,这是一段一段的,我们会切一段,把一段数据拿过来做聚合。给我一个时间窗,把数据拿出来做一个聚合,扔给Cube。如下图所示。


Apache Kylin最新的Streaming OLAP实现_第5张图片


带来另外一个问题,因为这是可以被配置的,从毫秒级原始的流,我们去聚合的时候,5分钟、10分钟、1小时,如果里面小的太多的话,到最后碎片是很大的,一天下来24小时,那得多大的碎片?如果放三天就了不得。我们做自动合并,前面3分钟,前面的数据过来了不管你,我们会自动地三分钟合并一下,再到下面的三分钟合并四分分钟,合并一小时等等。通过这种方式减少碎片,这种情况下碎片不会超过上限。如下图所示。


Apache Kylin最新的Streaming OLAP实现_第6张图片


收获和缺陷:


收获很明显,我们解决了从无到有的问题。但在当时,也存在着一些缺陷。


  • 构建不能自动伸缩。当时我们是两个数据中心,两个集群,eBay的流量非常厉害,再加一个东西的时候,很多需要改配置或者重启,这个很难办。

  • 近似二分查找会丢失数据,基本上是二分查找,硬切的。

  • 构建任务难以监控。这种维护成本是非常高的。

  • 错误恢复困难。

  • 整体运维成本高。


插拔架构下的完美实现:


Apache Kylin最新的Streaming OLAP实现_第7张图片


基于之前已经把它变成了可插拔架构了,我们再次更改了一下,加了一些应用,希望利用成熟的Kylin的后台体系。换一个角度看,如果把Kafka变成像Hive一样一个table的话,这件事情就解掉了。这里带来一个非常有意思的假设,在OLAP里面实时性的延迟其实要求没有那么高,这是非常重要的。


如果你想把Kylin这个实时的东西拿去做实时监控和监控告警并不一定合适,因为那个是毫秒级别的,它是机器处理的。Kylin是给人用的,人去看一个报表或者查一个东西的时候,对于延迟的容忍性比较高。Kafka,其实可以等一等,带来几个好处:


  • 数据处理的时候,OLAP不会太大,Hold个几分钟,把数据一大批地往后扔,对于CPU、内存影响非常小。

  • 这样的方式,整个架构变得非常简单,维护容易。


Cube Segment 按offset切分:


Apache Kylin最新的Streaming OLAP实现_第8张图片


对于Hive数据源,分区时间做segment的offset,保证了向前的兼容。对于Kafka数据源,各个Partition的offset之合,作为segment的offset。牺牲了存储,带来上层应用的一致性。


带来的好处:完全可伸缩


  • 大部分代码重用既有构建引擎,易于维护。

  • 几千条到几亿条数据,一次均可轻松构建。

  • 可随时暂停/恢复,可任意更改构建频率。中国会有双11,业务流进来的数据是不一致的,它有高峰,也有低谷,通过这种方式就可以有很好的方式去更改。


其他的改进:


  • 自动寻找开始和结束的offset

  • 支持嵌套式JSON消息

  • 支持自定义时间格式

  • 允许多segment并行构建/合并

  • 通过Rest API触发


Kylin Streaming 先决条件


  • Kafka版本不能太低,0.10或以上。

  • Kafka消息为JSON格式,必须有一个timestamp字段。

  • 模型仅支持一张表。


Kafka Streming进来之后,通过插拔把数据收回来,Kafka做了一个缓冲,如图9所示。好处是所有的东西和现有的架构是一模一样的。在eBay做的Kafka设计的是7天的数据,后来跑了大概30天的数据,基本上也没有问题。


Apache Kylin最新的Streaming OLAP实现_第9张图片


使用Kylin分析Twitter消息


Demo环境:AWS 5台VM的Hadoop集群,Kafka 3个Broker。


Twitter消息,这是原始数据,如下图所示。原始数据没有办法直接去分析,因为把它给分析师的时候,分析师会跳起来的,分析师只懂SQL。


Apache Kylin最新的Streaming OLAP实现_第10张图片


Twitter的Tag消息,如下图所示。总统大选上有很多Tag,Tag上有很多数字。


Apache Kylin最新的Streaming OLAP实现_第11张图片


将JSON消息映射成表结构


通过图形化界面把它抽象成一张表,如图12所示。前面是JSON的东西,我们通过图像界面把它抽象成一张表,在这里模拟了一个Table。重要的一点是需要去指定Column Type,也就是说,Kafka过来的那个东西是不带类型的,你在转换的过程中先指定它,后面会用到这个转换,否则一些数字、日期会出问题。


另外一个很重要的东西是解析器,这个解析其是通用的,你可以拿到这个东西去做解析。表结构影射完成。这就是分析师看到的结果,你看到的就是一个Table。构建Cube完之后,数据从Kafka中读出来,基于HDFS上的消息进行,与Hive雷同。


Apache Kylin最新的Streaming OLAP实现_第12张图片


Apache Kylin最新的Streaming OLAP实现_第13张图片


Apache Kylin最新的Streaming OLAP实现_第14张图片


Apache Kylin最新的Streaming OLAP实现_第15张图片


Apache Kylin最新的Streaming OLAP实现_第16张图片


Apache Kylin最新的Streaming OLAP实现_第17张图片


Apache Kylin最新的Streaming OLAP实现_第18张图片


Apache Kylin最新的Streaming OLAP实现_第19张图片


Apache Kylin最新的Streaming OLAP实现_第20张图片


Apache Kylin最新的Streaming OLAP实现_第21张图片


Dashboard,如下图所示。


Apache Kylin最新的Streaming OLAP实现_第22张图片


你可以看到这条线,带来的好处是可以把一个批处理的整个框架变成了一个Streming的框架,现在跑在线上大概是5分钟一次,图中的间隔是5分钟,但我们之前做了压力测试,调到了2、3分钟。


左右两张图中都是通过标准的SQL访问的后台,分析师发现用它之后有能力用SQL分析。这个架构还不够不完美,数据还是有两条线,一个数据模型我们可以同时支持批处理和实时处理,但是问题是这两条线是两条路径,未来我们有一个想法数据直接去Memory中去,后台可以直接去读。我们希望降到秒级,对相应的要求比较高,今天还是有很大的挑战。


未来工作


  • 优化Map Reduce引擎,提升构建速度。

  • 尝试持续构建引擎,Spark Streaming/Flink等。明年我们会考虑这方面的应用,希望通过 这些方式更快地处理流的这方面问题。

  • 补充实时节点。


声明:"Apache and Apache Kylin are either registered trademarks or trademarks of The Apache Software Foundation in the US and/or other countries. No endorsement by The Apache Software Foundation is implied by the use of these marks."

阅读原文查看交流实录。

你可能感兴趣的:(Apache Kylin最新的Streaming OLAP实现)