关于Instgram的搜索架构简要分析

Instagram的优势在于：虽然公司规模小，却拥有相对大得多的基础设施架构，在恰当的时候还能利用资源以借助Facebook十年来积累的经验。Facebook的“Unicorn”搜索架构是一款以社交图谱为基础的搜索引擎，可扩展至包含上万亿个文档的索引。2015年初，Instagram将所有的搜索架构从Elasticsearch转到Unicorn。同一时期，Instagram的搜索流量增加了65%，这不仅是用户群数量增加的结果，也是忠实用户数（每次使用搜索引擎时都会使用Instagram）增长了12%的结果。
　　这样的成果部分得益于Unicorn通过社交功能及二阶连接执行查询排序的能力。在7.0升级后，通过对图谱的各个部分编制索引，Instagram的搜索能力更强，可以更迅速、更便捷地搜索任何想要查找的信息，包括人、地点、标签与媒体。
　　什么是搜索？
　　Instagram的搜索架构包含了所有兴趣实体，如：标签、位置、用户及媒体，这些内容以非规范化的形式储存，通常被称为文档——它们被分组归类到集合中，可通过高效的集合运算（如AND、OR与NOT）来查询，在实际操作中Instagram对运算结果高效地排序筛选，只留下与指定查询最相关的文档。当用户查询时，服务器后端会将查询转换成编码，进行集合运算后筛出最佳匹配结合的有序集合。
　　数据录入
　　Instagram每秒可处理数百万个搜索请求，其中很多如注册、点赞和上传在内的请求需要修改现有记录，并向主PostSQL数据库增加新行。为了确保可搜索文件的集合正确，我们需要将这些变更告知搜索架构。此外，在PostgreSQL数据库中，搜索时一般需要不只一行的信息，例如在照片上传后，该用户帐号的历史信息也会用在搜索中。
　　为了解决非规范化的问题，Instagram引入了Slipstream系统，该系统会对Instagram上的event进行编码，再录入包含更多信息的Thrift架构中。这些event以二进制序列化格式存储，通过异步发送-订阅频道（Firehose）来发送。譬如“搜索”功能之类的消费者订阅到Firehose，过滤掉不相干的event，再对其余event作出反应。Firehose在Facebook的Scribe顶端实现，让消息传输可以异步实现。
　　下图展示了该架构：
　　
　　自系统化之后，Thrift中跨请求对象再次复用；同时无需自定义反序列化，消费者便可直接消费所传递的信息。Slipstream架构中与照片对应的子集如下所示：
　　struct User { 1： required i64 id; 2： string username; 3： string fullname; 4： bool is_private; 。..} struct Media { 1： required i64 id; 2： required i64 owner_id; 3： required MediaContentType content_type; 。..} struct LikeEvent { 1： required i64 liker_id; 2： required i64 media_id; 3： required i64 media_owner_id; 4： Media media; 5： User liker; 6： User media_owner; 。..8： bool is_following_media_owner; } union InstagramEvent { 。..2： LikeEvent like; 。..} struct FirehoseEvent { 1： required i64 server_time_millis; 2： required InstagramEvent event; }
　　Firehose频道的信息作为best-effort delivery，在消息传递中预计只有很小比例的数据丢失。在搜索时，我们通过数据核对进程或base build建立起最终一致性：每天晚上都会对Instagram连接到Hive的所有PostgreSQL数据库进行截图存档，并定期在这些Hive表格与结构中查询每个垂直搜索的所有文档；将base build与从Slipstream中获取的数据相合并，以确保在数据丢失的情况下，系统也保持最终一致性。
　　数据输出
　　处理查询
　　如果数据正确接收，则搜索架构可在一定的约束下高效提取相关的文档，我们称之为“约束查询（constraint a query）”，一般是根据用户提供的文字（例如：用户输入“Justin”，实际想搜索Justin Bieber）所衍生。在Unicorn中，查询被重写为明确表达目的的S-Expressions，比如：
　　（anduser:maxime（applyfollowed_by： followed_by:me））
　　以上代码翻译过来就是：查找我关注、名叫maxime的人所关注的人。在搜索架构中，这个过程分两步处理：
　　生成候选集：找出一组与给定查询匹配的文档，Instagram的服务器后端使用反向索引（reverse index）结构，即通过关键词索引找到多组文档。举例来说，输入关键词“name:justin”就会出现包含“justin”的用户名集合。
　　排序：从所有候选集中选出最佳文档。获取候选文档后，从文档的元数据编码中找出特征，例如：用户Justin Bieber的特征之一是关注者多达3.23千万。系统会将这些特征用于计算“拟合度值（goodness）”，以便对候选子集进行排序。拟合度可通过机器学习或手动调整而生成——在机器学习案例中，针对特定候选者，我们可以设计点击或关注有所差异的特征。
　　通过这两个步骤，最终得出指定查询的最佳文档有序列表。
　　社交图谱搜索
　　在优化搜索功能时，为了提供更具个性化的搜索结果，Instagram现在会将用户关注的人以及他们所关注的人都纳入搜索范围。这样一来，基于用户所关注的人再来查找某人会更容易。
　　使用Unicorn后，我们能够对Instagram上的所有帐号、媒体、标签和地址，还有其间各类关系生成索引。举例来说，通过对某个用户的关注者编辑索引，Unicorn可以回答这类问题：
　　“用户X与用户Y同时关注的账号有哪些？”
　　同样的，通过对媒体中的位置进行索引，Unicorn能得出如下信息：
　　“我关注的帐号所发布的媒体是在纽约拍摄的”。
　　优化帐号搜索功能
　　单独使用Instagram的图谱的话体验不佳，不足以找到想要查找的帐号，必须结合Unicorn的搜索排序架构使用才能奏效。
　　完成这一目标的方法之一是在Instagram上为现有连接建立模型。在Facebook上，账号间的基本关系是非定向的（通常会互加好友），而在Instagram上却不一定要回粉。我们的团队必须对搜索排序算法进行修改，以存储并检索Instagram关注图谱中的帐号信息。对Instagram来说，要使用Unicorn按照混合的方式来检索帐号：“你关注的人所关注的人”和“关注你的人所关注的其他人”。
　　此外，Instagram的用户关注彼此的原因各种各样，某位用户无需与他所关注的用户保持完全一致的兴趣点。我们的团队构建了一个模型，针对每个用户所关注的帐号进行排序，因此在搜索时，与搜索者关系更为密切的用户所关注的对象会优先显示。