订阅软件研发RSS CSDN首页> 软件研发

Pinot-LinkedIn如何将大数据做到实时与民主化

发表于2015-07-16 14:44| 次阅读| 来源《程序员》杂志| 0 条评论| 作者吴继业

摘要:最近Pinot开源的消息广为传播,作为在世界上第一个尝试使用并推广Pinot作为分析型工具的LinkedIn团队,前LinkedIn商务分析部数据工程总监、现任Gorwoingio联合创始人吴继业分享了他们使用Pinot的体会和经验。

回国创业已经两个月了,最近Pinot开源的消息布满了我的朋友圈。作为在世界上第一个尝试使用,并推广Pinot作为分析型工具的LinkedIn团队,对我们的Pinot团队由衷赞赏。我代表我的团队在这里与社区的小伙伴们分享下一些体会和经验。

一切都来源于LinkedIn Sponsored Update这个LinkedIn广告业务转型到移动端成功的产品开发。2013年,LinkedIn致力于构建300万的企业与2.3亿(2013年第二季度的用户数)全球用户联通的桥梁,帮助企业直接推送最相关的信息流到用户首页。这是一个重要的战略性产品。之前的应用都是先有网页端产品,然后才会建立移动端的应用。而Sponsored Update是第一个同时在Web和Mobile App上发布的LinkedIn商业应用。实质上,Sponsored Update是链接网页端和手机端的广告业务,货币化是业务重点。然而,LinkedIn把用户体验放在首位来考量,努力寻找收入和互动的平衡点,避免用户被铺天盖地,或是不相干的广告影响。而寻找平衡点的关键在于对数据的应用,使有偿广告与自然信息合理地更新。但是多平台的特性,更增加了我们分析的复杂度。


图1 2014年10月,我和Parveen在纽约举办的Starta+Hadoop会议上一起做了分享 。

做好数据分析,必先做好数据点采集的工作。对于Sponsored Update来说,是网页和移动端同时采集,而且由于产品刚刚落地,对数据量和种类也有很多要求。那时候我们分析团队的广告数据分析经理单元明,将很多时间都花在配合产品经理和业务人员建立大量的页面标签,追踪代码以及核心的KPI定义上。大致分为几类思路:第一,维度需求:比如用户的地区,职业级别,职业功能,行业,技能,人脉数量等等;第二,行为数据:比如用户多少次登陆LinkedIn,互动级别,这些用户关注了哪些公司,访问了哪些公司的主页等等;第三,分群用户:根据一些维度区分用户,每个群组所看到的有偿广告更新与自然信息更新的频次是不一样的。这个部分,我们团队的元明带领整个LinkedIn广告数据分析组,每周7天在线将各种分析标签、数据采集的计划和商业分析KPI与整个的管理层,广告产品,移动端和工程部门进行各种分析结果的沟通。

然而,当时我负责整个商业分析部门的数据解决方案,按照query的时间、用户维度、用户行为维度、不同的群组维度估算了一下,如果要做任意时间范围内的任意维度组合的指标运算,用2000台左右的Hadoop集群,在有很重的Queue的基础上,即使跑一天的Hadoop脚本,也不能跑完所有的分析组和。而且,每天产品经理要对超过数十亿行的数据进行实时的分析,我们当时的BI解决方案刷新一次要滞后5分钟,速度很慢。而新产品对分析的要求就是不断提出假设,不断分析变量的过程,维度无法确定下来,如果分析师要增加分析维度的需求,那么我们商业数据分析部要跑更多的脚本。我们都知道,维度越多,要预先聚合运算的可能性是2的N次方增加。

Sponsored Update是LinkedIn首页上的产品,生成的数据量很大,而且每一条更新背后都有各种多维度的逻辑。这样的挑战,不能用传统的办法解决,这就是我们一直在寻找各种方案的原因。当时的Pinot是完全服务于线上交易型数据库的一种方案。在我们与LinkedIn的工程资深主管沟通后,我们决定在没有OLAP分析案例的情况下尝试Pinot。

为何使用Pinot

使用Pinot的原因。在LinkedIn和工程师团队保持良好的关系很关键(好像在哪里都一样啊),我最初在尝试senseidb,但是senseidb的主程已经去了Twitter。当时管理LinkedIn搜索的主管就向我介绍了Pinot开发团队,一共只有3个人的团队,还有一个工程师是新加入的。Pinot当时主要是支持LinkedIn线上的系统,每个QPS要求小于600毫秒,产品支持SQL的Rest API,数据源可以是kafka,可以是从Hadoop Avro format直接建segment导入Pinot,支持filter,group by。他们团队小,任务重,主要专注于线上服务,本来没有时间支持我们线下分析案例。好在他们团队主管与我们分析团队有很多合作,我们不断向他勾画Pinot的未来,可以支持OLAP查询,最终才得到4台机器,包括:16 core,48G,SSD的机器,于是我们开始尝试。


图2  Pinot能够满足的技术场景


图3  Pinot的Architecture


图4  Pinot用到的index,包括实现前面提到得到多值filter

很兴奋地装载了1天1B的数据,跑了些query后,查Log,发现扫描的数据越多,query就越容易断线,第一个结论就是小query多次发送没有问题,Concurrent很好,小任务,小步快跑没有问题,步子迈太大慢跑就不行,将timeout设置得很大也是这个问题。最终我们决定,前端先将大的query根据每次可以扫描的数据量将query拆成多个query,然后控制并发度,保证query能够在10秒内返回结果。这样的结果符合我的预期。如果放在Hadoop里面跑,我要等很久才有结果。

后台完成之后,我给产品经理和分析师迅速搭建起网页端界面,允许任意筛选和整合数据,保证新的数据从Hadoop到Pinot的导入。而在用户看来,是质的飞跃:从前要等一天才能看到结果,现在10几秒钟就解决了。这使我们的分析师可以在短时间内,对产品表现做出判断。

紧接着我们要求加了两个特性:支持count unique user和filter on tuple。刚开始的时候,我在准备avro format数据的时候,就将user分别存在不同的segment文件里面,而且要保证每次生成的segment文件里面都是consistent存放相同的KEY区间。这样就能将count unique变成count很多小query,然后做total merge的简单方法。其实还是count运算,只是保证每个segment文件没有重复的KEY。后来Pinot团队增加hyper loglog的功能。Filter on multiple value也是一个很好的特性,LinkedIn每个用户都有不同的技能,而且每个user的技能长度都不一样。而搜索变得十分简单:例如我们想要寻找有Java或Scala技能的人,只需要写skills in (Java或Scala)就可以得到了,而背后实现全靠bitmap index。

那时候只有3个人的Pinot团队做出这样优秀的产品,十分了不起。之后我们团队和Pinot团队开展了很多更深入的联合开发,也与Pinot的主程Praveen建立了非常好的关系。

作者:吴继业

作者简介:在数据仓库,数据分析和数据工程领域有13年工作经验,前LinkedIn商务分析部数据工程总监,现任Gorwoingio联合创始人。曾经就职于宝信软件,HP,eBay和Linkedin,2007年出国,于2015年回国和Simon Zhang一起创办GrowingIO。

0
0
  • CSDN官方微信
  • 扫描二维码,向CSDN吐槽
  • 微信号:CSDNnews
程序员移动端订阅下载

微博关注

相关热门文章