百度马如悦——Beyond OLAP: Online Data Serving,DCon2015文字实录

image001.jpg

今天给大家介绍下OLAP相关的东西,介绍以前想和大家分享一下对系统判断的标准,因为标准会影响到大家对系统好坏的判断。对于工程出身的人,在用一个系统的时候,比如在选用Oracle,HP等系统的时候,需要看哪个公司的好,大家基本上就是POC等,很多时候考虑的更多是比性能。但是好用不好用,好维护不好维护不比。一般为什么不比,像OLAP这种系统,它卖给中国很多企业一个单子,它的服务费用非常贵,而这些服务费是什么,就是未来它给你维护、给你做调整的费用。但是当你在选择自己公司使用开源系统的时候,用什么东西就不只单独看性能的问题。咱们很多人都是工程师出身,要考虑系统怎么易用怎么简单。
像前几天看微信,有人在上面不停地比谁的系统性能更牛。我就发了一个例子说,你们觉得一辆法拉力好,还是拖拉机好,你肯定认为法拉力好。那对一个农村的人,干农活的时候是法拉力好还是拖拉机好,法拉力到地里就出不来了。我的意思是,大家一定要根据自己的业务场景,不是在任何场合速度都是最重要的。有时性能是要点到为止,你在中国的路上最高120公里,开到400公里根本没有意义。所以还是想和大家说,一个系统,判断好坏的标准不能总是比性能。在百度内部,和我们类似产品的竞争者说要与我们比比性能,我说你一个裸奔的系统,你跟我比性能,不是在耍流氓吗?我脱光了也跑得比你更快。关键我们的系统有认证、要做校验,在网络要做加密等各个方面,你什么都没有,只是和我比性能,看谁扫描的快。所以说大家比的时候,不要上来就比性能,性能只要点到为止,还要考虑其他的方面。

image003.jpg

我在百度现在负责的是在线数据服务,原来是做分布式计算出身的,主要是Batch层等,百度内部的离线大数据分析,大约几万台机器,原来我就是做这个的。后来发现需要上面一层的Serving层,我就转到这个方向上去了。很多公司没有上面那一层Data Serving层,没有单独提出来,但是在百度这是单独提出来的一层服务层。就像传统的web search,依赖网页处理系统,离线建完库以后,想在线用的话,需要有一个在线检索系统。数据服务也得需要有一个检索系统。像国家的电力系统是一样的,各个电厂发的电是需要通过电网来供应给千家万户。不可能看到有人说,家里做个粥什么,把电饭锅拿到电厂去做,而必须是要有一套好的电网。产出的数据同样需要一个好的数据服务层,才能更好的满足上层的应用。
那我负责的团队,在数据服务层实际上有三个产品:第一个是SimpleDB,这个SimpleDB不简单的是个KV,如果只是一个简单KV,那它只能叫做存储,而像SimpleDB它有一层查询层,这个系统在百度大约部署了3000多台机器,量是非常大的,每秒几十万的QPS。它主要承载什么东西呢,比如说有离线产出的一些批量的简单数据,或者一些简单的结构的数据,放在线上比如说广告的物料,用户的历史行为,实施session行为数据,他们不需要复杂的结构和不需要OLAP,它只需要快速检索出来。但是它的数据源头可能来自批量,也有来自实时的。查询的时候可能有一些简单的过滤条件可能还有一些其他的东西。所以在KV存储上,提供了一个简单的Query Engine。

image005.png

第二个是OlapDB,经历了三款产品(Doris/OLAPEngine/palo)。它的引擎有一点复杂,叫OLAP引擎或者分析引擎,它有一些聚合的能力,所以查询引擎就要复杂一些。
第三个是SearchDB,上面有一层叫Search Engine。 

image007.png

简单介绍一下SimpleDB,大家可以看到有一个机器池,里面有实时KV和批量KV。上面有个统一介入层,UAS层,上面有API和SQL接口。这个SQL做什么?做join  merge,因为经常有用户要查实时和批量的数据,它通过SQL可以做一个简单的join,然后做一些过滤和投影。有时也要用一些UDF的调用,因为用户希望把很多计算推到服务端去算,这样算得要快一点。所以一定得有一个Simple  Query层,它不是一个简单的NO SQL,它需要支持服务计算,而这个服务端计算,是很重要的一块,是和简单的NoSQL不一样的地方。再就是需要解决跨机房副本冗余度的减少问题,因为可能我们要做多个机房。这个系统当前大约有3000台机器。在百度上的每一次搜索都会进入这个系统中,比如你刚在一个网站上搜过手机,在百度上就知道你搜索过手机,可能会按需出广告,或者会推荐一些内容,都是有这个系统提供功能。

image009.png

然后再看一下SearchDB,它可以用来分析经常在百度搜索洗发水相关的query哪个最多,类似这些东西。还可以用在其它领域,比如广告系统中的DMP领域。就是每一个用户有一堆标签。广告主通过圈一堆标签,向拥有这些标签的人进行投放广告。用数据库做匹配那个速度慢了,ES可以在毫秒,那个十几分钟才匹配出来.今天我们不能把Search仅当成一个通用的搜索,它已经被大规模的用于对数据进行探索。
一个什么叫好的系统,像刚才有人说的,我系统非常好,为什么没有人用。我觉得大家都要去仔细想想是为什么,我参加ES的会,上去了几个工程师,说ES真TMD的好用,就是这么一句不文雅的话,是对一个项目,对大的嘉奖。这个项目做的非常好,任何一个人在5分钟之类就可以用起来,所以我们作了些改进。我们部署了有300台左右的机器,在上面有大约30多个业务。
然后给大家介绍Palo,我的团队大约有20多人,做了三个方向。一个简单的KV上的SimpleDB,这个系统我们基本上可以保证在过去的全年基本上没有停过,不能停。如果停了,每5分钟会影响很多收入。而这个SearchDB是我们现在在内部正大规模推。但是只推了一年左右,只有30多个业务在用。另一个项目,就是Palo,我们做了三年,三年的时间投了6、7个人。
先给大家说一下Palo的使用,非常简单,不跟大家比性能,这个系统在百度十年来,绝对是最简单易用的,10分钟内就可以搞定使用。
Palo是直接可以使用MySQL工具连接上使用的。对于互联网的公司大家MySQL很了解,所以我们兼容的是MySQL, 比如说创建一个datebase,一个table,怎么分布,分布多少个。大家会看到这里面有一些聚合的东西,怎么显示我的状态,怎么去查询。整个架构非常简单。我当年做过百度的Hadoop,而整个Hadoop已经发展的非常复杂,提交代码的人也非常多,每个人的品位爱好不一样,造就了这个系统组件非常之多,配置非常复杂。到现在,很多人都记不清Hadoop到底有多少组件。所以现在用起来难度很大,为了解决一个问题,经常需要搭建6、7套系统。
所以我们在做OLAP的时候,力争将它做得易用。我们这个系统就是两层,一个FE,一个BE。FE有瓶颈,需要扩展,就可以再起一个。好多人可能通过挂一个ZK来解决,我们觉得那个还是比较复杂。在前端用JAVA效率会高,后端是C++去写,C++写它的查询性要高很多。不想把他俩融在一起,社区的一个最大问题就是JAVA中调C++,C++调JAVA,调试起来痛苦无比。所以我们的系统C++就是C++,没有JAVA,JAVA就是JAVA没有任何C++的代码。
    大家做了两层分区。为什么两层分区,比如根据业务需求,一个月有一个分区,这样可以简化对Shard数的调整,我选这个月的shard是100个,假如下个月数据量增加了,你就可以设置下个月的Shard数200个。 所以原来一开始就要固定好shard总数,造成选少了,就需要经常扩容,选多了就会造成查询的时候扇出太大,性能降低。好多用户可能通过建不同的表来解决,但是在Palo内部这些都是隐藏在一个表内部的。
然后是分级存储,好多系统有SATA盘,SSD。数据被访问的非常少的放入SATA上。而最近的放入SSD,读取效率要高很多。分级存储可以做自动迁移,可以让表一开始在SATA上,大概在多天以后,它会自动迁到SSD去,这全是系统内部做的。
 

image011.png

再一个就是资源隔离,大家通过共用一个平台,集群做的比较大。但是多个用户共享,有多租户的问题。一个人写错了一个东西,把这个系统搞崩了。所以内部要做资源隔离,一个是多用户间的隔离;一个是单用户多任务间的隔离,做了两层。像上面两个用户,他们有一个资源分配。并且这个root自己又分三级,又分High  low  normal。用户通过使用不同的账户来指明使用哪个级别。这些是用CGroup做的。这些在传统数据库是考虑的不多的地方。 所以我们的系统稳定性做的比较好。
再一个就是导入,既支持Hadoop的batch导入, 系统并不集成Hadoop,只是你指定一个Hadoop,我会把计算推过去,给你算。也支持像HTTP这种的mini-batch导入。好多用户数据量比较小的时候,可以采用这种小批量的导入。
 

image013.png

向量化执行,这是为了加快速度的。比如说你用C++,for循环10000次累加一个数据,C++的函数调用开销可能远远高于实际的加法计算。所以我们就改成向量化。它一次处理一个批量,所以速度非常快,会提高很高。大约有3到4倍的性能提升。

image015.png

再就是引入了一些窗口函数。同一个部门薪水最高的三位,这么一个简单的问题,很多数据库,如果没有analysis函数,也就是窗口函数根本搞不定。再一个就是我们引入了INT128类型,因为在百度内部,好多数据累加以后,或者有一些数据,64位不够了。我们可能是全球第一个引入这个数据类型到数据库内,解决INT64溢出,签名字段的问题。
再就是Palo有在线的HELP,大家可以看到,我们所有的文档,都是在线HELP的,就是大家敲了HELP以后,还可以看到这些帮助。拿Mysql客户端就可以看,主要为了解决工程师在用的时候,就可以在旁边查文档。解决文档和系统版本经常对不上的问题。Palo的文档是被打包到程序包里面去了。也提供了类似Linux的PROC系统,可以使管理员看到数据库内部的一些状态,就是说你可以不离开Mysql的客户端,就可以探查内部的各种结构变量以及它有多少张表,客户端是什么,IP是什么。
 

image017.png

 PALO
image019.png

现在大概有120+产品线,500+的机器,最大的像百度的统计,5分钟导入300+的表,日1TB,峰值大概在1400qps左右。这是和上一代系统的对比,平均从60毫秒降到30毫秒,机器从原来的大约220台降到58台。
截了一个图,从公司用户来看Palo的性能。比如说数据平均速度提升了30倍,这是糯米做电影销售的,说由5.9分钟变成只有4秒。就是类似这种上100倍几十倍的提升比。我们未来会增加,像SQL  DAG,好多用户不使用Palo,迁往Spark,就是因为很多问题,单独一个SQL不能解决,需要多个SQL联合。所以新的SQL  DAG就是类似这样可以将三个用户sql可以同时发下去,可以一下拿到两个结果,中间就访问一次。这是我们现在做的,解决完以后,再就是解决嵌套的数据类型。 
   
    然后我们也做了一些云化产品, 现在大约有20多个客户在用我们的产品做测试。9月份推出alpha版,12月份可能会正式开始售卖。大家在百度公有云的页面上可以看到这个产品的介绍。它的架构非常简单。 
 

image021.png

这里想跟大家再强调一下,就是目前做的Palo不仅仅是说要解决问题,还要把这个东西做简单,任何人看了以后都觉得简单。包括日志、配置我们都要求做的要标准一些。就是使得它的生命力要强一点。好多的百度系统,就是大家改一改,改到一半改的要命了,重新来一套吧,就这样一个新东西就又造出来了。但是如果你系统一开始写得比较好,大家就会愿意在上面贡献代码,愿意用,愿意不断的更新。

image023.png

再来聊聊KUDU。 KUDU我认为它从一个极端走向另一个极端,也有篇文章有人在置疑说,KUDU不支持批量导入。他们想实时做成类似OLTP式的,一条一条的插,不支持批量的。大家可能会觉得实时的总是要优于批量的,我觉得这是大家非常错误的观点,批量的性能可以做到很高,因为它不需要路径来回检查。还有批量你可以做事务的一致性,但是如果实时导入,你只能做到,比如说单Key的一致性,多key的比较难做,像KUDU现在还做不到,多key的事务一致性。

image025.png

todd的回答,他承认当前kudu的写入路径是不利于bulk导入的,如果未来有需求,他们会增加bulk loading功能。但是我想提的是,KUDU的Lead他一直认为他的决定是对的,当然也有咱们中国的好多人,在为他摇旗呐喊,一般是在生产实践中没有用过,更多是在为他摇旗呐喊,更多是喜欢这个人。大家可以看看MESA这个系统,其中一大特性就是它就一直在讲,我们谷歌为什么要选择小批量导入,这个实时的导入需求非常小,而带来的问题非常多。KUDU花了大量的时间搞实时更新,这个东西有点被他们搞复杂了。
    但是谷歌说,小批量的导入带来的好处非常之多。百度也是吸收了它的东西。原子更新,我们内部叫事务原子更新,比如说我有10张表,用户做了好多聚合。比如说点击展现,它要放在两张表里面,批量的数据要么全灌入,要么不全灌入。你用KUDU怎么实现,你一个记录进了点击表了吗,展现表还没进。这个有人查,这个是对不上的。你说可以做分布式事务,在分布式里面做事务,相当复杂的。就是做成了,性能也会很差。如果量不大,小批量导入也可以逼近到秒级别左右。
    
传统数据库厂商一直说它比开源好就是这个原因,比如类似Impala+HDFS,它那个数据是没有排序的,没有做过索引,没有做过任何东西。你查任何一条记录,就全扫描。所以传统数据库有索引,有排序,所以会快。KUDU它也看到了这个问题,但是 KUDU马上就走到了另一个极端。它是要实时插入、一条一条地插入。而你看到传统的数据库,像好多的系统,它更多的支持批量多一点。这样会误导很多的没有太多技术判断能力的公司,有好多的公司会直接学你们。
最后一页,很多人搞不明白说,Palo到底是个什么东西。百度内部好多人Mesa,想用Dremel,想用SparkSQL+HDFS等等,很多东西。但是又不希望使用多个系统,因为多个系统需要依赖的东东太多,太复杂,也没人力搞定。Palo就是这么一套系统,可以解决上面系统所有的问题,并且还很简单。当然,它可能在任何单一场景下不如专用系统,但是它追求的更多的是通用性。因为在很多公司,性能并不是唯一最重要的。
 

image027.png


请点击下载

 

fish - Hadooper

赞同来自:

要回复问题请先登录注册