钛媒体注：美国知名科技博客GigaOM近日刊登了对LinkedIn几大数据构架工程师的访谈文章，试图探寻LinkedIn幕后数据挖掘技术的全景图。LinkedIn是社交网络数据挖掘领域的先行者，最简洁的功能和设计，幕后往往都有一个强大的技术团队才能支持运转。任何一个UGC的社交网络，都需要过硬的后台数据构架体系，以及精准的匹配算法，才能展现给用户良好的体验。钛媒体特综合编译如下：

【心语、赵赛坡/钛媒编译】LinkedIn最广为人知的功能，莫过于People You May Know （你可能认识的人）。该功能方便用户拓展人脉，找到想要认识的人。而这一切都依赖于强大的数据处理、管理技术，只有这样才能让LinkedIn可以让数据在不同的应用程序之间顺畅流通，并且保持准确。而实际上，当Jay Kreps（LinkedIn 首席工程师）五年前开始接手时，情况比现在棘手的多。

Kreps现在主要负责的事情，是为LinkedIn寻找合适的工程师，“我来的时候，那时还没开始架构数据。”最初，他是打算来LinkedIn做数据研究的，因为他认为这里的数据价值很高。后来才发现，他需要解决的是LinkedIn基本数据框架的构架问题。

问题有多严重？最初，People You May Know 是在一单独Oracle数据库实例里运行，主要通过几个脚本和贪婪算法来提供智能分析。于是就造成了更新一次数据大约要花六周时间的问题，如果更新过程中宕机，就要花更多时间。当然，这是理想状态下的情况，最严重的情况可能是系统六个月无法正常运转。

如果数据量超过服务器的负荷，服务器就无法应答，只能通过减少贪婪算法，来减轻计算压力。

所以，他的主要工作是在LinkedIn实现Hadoop基础构架，并建立一个叫Voldemort的分布式数据库，而不是为“你可能认识的人”写算法。

从那以后，他建立了一个叫做Azkaban的开源调度器来批量处理分布式计算，还建立了Kafka（相当于大数据消息代理的开源工具）。从更高的层面来说，Kafka是用来管理公司实时数据的，以便以最快的方式让成百上千的app订阅用户获得最新的数据。

有人要Espresso吗？

这些工作只是Kreps成为LinkedIn的董事后数据构架工作的一小部分。该工作的目的是在LinkedIn创建一个和其他互联网公司一样的创新型数据环境，这样公司里的应用程序开发员和科学家有更多的时间和精力放在创造他们梦想中的产品上。

LinkedIn的高级数据主管Bhaskar Ghosh在参加数据构架专家论坛时表示，他们用的是一种三级的数据构架，包括在线、离线、近线系统，他们是为不同性质的工作设计的。在线系统处理用户的即时交互；离线系统由 Hadoop 和Teradata数据库构成，主要负责批量处理和分析工作；近线系统处理People You May Know、搜索、以及LinkedIn的社交图谱，这些功能经常更新，但对延迟的要求没有在线系统高。

公司最重要的成就之一就是一个名为“Espresso”的新数据库系统。他和Voldmort不同，Voldemort继亚马逊的Dynamo之后的一款最终一致性的“键——值”储存模型的数据库，用来高速提供特定的数据。而Espresso是一款事务一致性的文件储存系统，用来替代公整个公司里网络运作时使用的Oracle数据库。Espresso最初是专门设计用来为InMail功能提供信息服务的，源代码会在今年晚些时候开放。

工程总监Bob Schulman表示，“我们的邮箱功能中，有个关于邮箱规模和信息处理灵活性的问题。”Expresso要存储大量的用户数据，还要和用户的操作保持同步。此外，邮箱还需要搜索功能，以便用户（尤其是往来信息很多的用户），可以迅速找到需要的邮件。

在原来的数据层保持不变的情况下，这个方案让开发者解决了扩展性和稳定性问题。

然而，主要的软件架构师Das指出，仅仅尝试用代码来解决问题并不是长远之计。因为这会很快的消耗团队和用户的精力，此外你不知道下次挑战将会在什么时候出现。

Schulman认为，在灵活易变的环境下，最重要的是如何能在不破坏已有的情况下做出调整。当然，另外一条途径就是打到一切重新来，不过“想让一切停下运转，你根本无法找到合适的时间。”

下一步战略：改进Hadoop系统

迄今为止，LinkedIn的最大成功表现在优化近线和在线系统（Ghosh说：我们已经做的很棒了），下一个改进目标就是离线系统——特别是Hadoop。目前他们已经使用Hadoop来运行公司的整个常规业务，比如ETL（提取、转换、加载数据）、构建模型、数据分析以及近线系统的程序数据的预处理。而Ghosh希望有更大的改进。

他提出了一项方案，方案的重点在于对Hadoop集群和关系型数据库进行高度整合。他们希望实现的目标有：更好的ETL框架、随机查询、可选择的存储模式以及被Ghosh称之为“圣杯”的整合式元数据框架——该框架可以极大的方便不同分析系统互相共享数据。他表示，有些事Linkedin已经完成了一半，在年底之前将完成全部工作。

Ghosh说：“Hadoop上的SQL还需要两年才能投入应用，我们还能怎样呢？我们不能抛弃它。”

Das表示，实际上，LinkedIn数据工程的重心是构建一系列可以方便协作的服务。像Espresso API，就使得开发者可以连接到多栏存储引擎，然后从事务数据库里做一些有限的在线分析。

良好的基础设施让数据科学家快乐工作

Yael Garten是一位LinkedIn的高级数据科学家，她坦言公司越来越好的底层架构让她的工作变得更容易。和Kreps一样，她被吸引到LinkedIn（她上一份工作是在斯坦福大学的生物信息研究所）的原因也是这里拥有大量有趣的数据分析工作，只是她有幸错过了当年由于底层架构不完善导致连1000万用户信息都无法处理的困难日子，如今LinkedIn要面对2亿用户的信息处理任务。Garten表示她还没有遇到因为公司基础架构不完善而无法解决的数据问题。

数据分析团队和产品团队并肩作战，有时产品经理主导产品走向，而有时则是围绕数据科学家的结论进行开发。Garten表示在2013年，开发者希望基础架构能让他们实时开发产品原型并进行测试。而且那些业务经理们也需要尽可能实时的看到产品分析报告，以便于他们可以了解产品运行情况。

Garten认为：“基础架构并不仅仅是要将所有的工作加速，有时一些想法是无法实现的。“她没有介绍基础架构中某个神奇部分的细节，我猜想这可能涉及到公司机密的分布式图谱系统。Ghosh在公司其他方面毫不讳言，但在这个问题上却拒绝透露更多。

“仓鼠滚轮”式的良性循环

无论是Ghosh还是Kreps认为LinkedIn以及其他领先的互联网公司，任何时候都不会放弃创新。一方面是由于业务决策需要，Ghosh觉得这源于公司文化和招聘的积极影响。Kreps则指出公司决策层在计算运营成本时所面临的苦难，主要反映在到底是购买软件证书、雇佣开源项目权限拥有者还是进行内部建设的权衡比较方面。

Kreps将公司构建新系统的循环比作“一种仓鼠滚轮”，但公司也提供了足够多的基于特殊需求而开发新产品的机会。比如最初他设想为用Hadoop解决两种用例，但现在公司大约有300种用例由Hadoop处理。它也从之前的两次实时反馈发展到了现在的650次。

他说：“公司现在所做的这些的目的就是一个，解决问题。”

Ghosh否认了公司过度依赖商业授权技术或开源项目的说法，他说：“我们认真思考过我们应该在哪里做些复杂的工作。”但他马上补充说：“你并不想让你的系统变成一个系统整合商场”。

他表示，今年会有更多基于LinkedIn的开发工程和开源项目。“我已经在想接下来的两个或三个重头戏了”。■