Pinot-LinkedIn如何将大数据做到实时与民主化
回国创业已经两个月了，最近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的主程已经去了推ter。当时管理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。