CN103139280A

CN103139280A - 在sns社区中获得好友动态的方法和系统

Info

Publication number: CN103139280A
Application number: CN2011104011336A
Authority: CN
Inventors: 黄耀华
Original assignee: Beijing Oak Pacific Interactive Technology Development Co Ltd
Current assignee: Beijing Oak Pacific Interactive Technology Development Co Ltd
Priority date: 2011-11-24
Filing date: 2011-11-24
Publication date: 2013-06-05

Abstract

本发明涉及一种在SNS社区中获得好友动态的方法和系统。所述方法包括第一映射步骤，用于对用户的好友进行映射Map；第二映射步骤，用于进一步对用户好友的动态进行映射Map；以及规约步骤，用于对上述两轮映射Map过程的结果进行规约Reduce。

Description

在SNS社区中获得好友动态的方法和系统

技术领域

本发明总体上涉及网络信息技术领域，更具体地，涉及在社交网络社区中获得好友动态的方法和系统。

背景技术

随着网络信息技术的不断发展，社交网络(也称为社交网站)SNS(Social Network Site)已经成为了现代网络的重要组成部分之一。在此使用的术语“社交网络”是指向对特定对象感兴趣或只是一起“闲逛”的人们提供虚拟社区的Web站点。成员通过语音、聊天、即时消息、视频会议和博客等进行通信，并且该服务通常向成员提供了联系其他成员的好友的方法。这种站点还可以用作亲自会面的媒介。

特别地，很多社交网络都以现实世界的实际生活中的社交为基础。换言之，尽管社交网络成员的关系和数据是虚拟化的，但是这些关系和数据之间的联系往往基于和反映现实生活中确实存在的社交关系。例如，社交网络中的“好友”在很多情况下都是真实世界中的朋友、同事、同学这样的关系。已知的是，此类社交网络通常在注册成员时要求进行实名制认证。

社交网络为其用户或成员提供与该社交网络的其他用户进行通信和交互的能力(注意，在与社交网络有关的描述中，“成员”和“用户”可互换使用)。在使用中，社交网络的用户可以首先执行登录操作，继而与其好友或者其他用户进行互动。在此使用的术语“好友”是指用户通过社交网络与之形成连接、关联或者关系的任何其他用户。社交网络中的连接通常是双向的(但这不是必须的)，因此术语“好友”可能依赖于参照系。用户之间的连接可以是直接连接；然而，社交网络的某些实施方式允许经由一级或者多级连接的间接连接。另外，术语“好友”并非必须要求用户在现实生活中实际上是朋友，它仅仅表示社交网络中的关系。

基于用户与“好友”之间的上述关系，可以认为用户很可能会关注或者希望了解“好友”的各种动态，从而用户可以基于该获得的“好友”动态进行后续的活动。一个简单的好友的动态的例子是“好友”开辟了一个新的聊天群。另一个好友动态的例子是“好友”分享了新的照片。在前一个例子中，用户可能基于该动态的获得而加入“好友”的聊天群。在后一个例子中，用户可能在获知“好友”分享了新的照片后，立即查看该分享的照片。

在传统的好友动态的获得方式中，往往是通过“广播”方式进行的。然而，通常用户会存在多个好友，每个好友可能会有数个动态、甚至数十个动态。在这种情况下，广播的数据量是非常大的。更进一步需要考虑的情况是，从全局角度看，某一特定用户的每个好友同时也可能是多个其他用户的好友，从而该好友的动态除了向该特定用户广播外，还会向该其他用户广播。这样，在用户量较大，且用户活跃度较高的情况下，往往会造出性能问题。

发明内容

为了克服现有技术中的上述缺陷，本发明将经典的Map-reduce这个分布式处理框架引入到SNS社区的好友动态获取中，不仅极大地实现了并行自动化，还可以快捷便利地获得好友的动态。

具体而言，根据本发明的第一方面，提供一种在SNS社区中获得好友动态的方法，包括：第一映射步骤，对用户的好友进行映射Map；第二映射步骤，进一步对用户好友的动态进行映射Map；以及规约步骤，对上述两轮映射Map过程的结果进行规约Reduce。

在本发明的可选实施方式中，所述方法进一步包括，在所述第一映射步骤之前，还包括下列建模步骤：第一建模步骤，记录用户好友列表为User：List[Friend]；第二建模步骤，记录用户动态为User：List[Tuple<Activity，Time>]；以及第三建模步骤，记录动态的用户使用状态为Activity：List[User]。

在本发明的可选实施方式中，所述第一映射步骤的key/value对为user_id/friendList；所述第二映射步骤的key/value对为<user_id，act_id>/use_time；所述规约步骤通过reduce获得的value为<user，List<app，friend，use_time>>。

在本发明的可选实施方式中，在所述规约步骤中还根据使用时间对动态进行排序。

在本发明的可选实施方式中，所述动态包括发布/更新日志、进行新游戏以及向用户发送消息、建立新群以及共享照片。

根据本发明的第一方面，提供一种在SNS社区中获得好友动态的系统，包括：第一映射装置，配置用于对用户的好友进行映射Map；第二映射装置，配置用于进一步对用户好友的动态进行映射Map；以及规约装置，配置用于对上述两轮映射Map的结果进行规约Reduce。

在本发明的可选实施方式中，所述系统进一步包括：第一建模装置，记录用户好友列表为User：List[Friend]；第二建模装置，记录用户动态为User：List[Tuple<Activity，Time>]；以及第三建模装置，记录动态的用户使用状态为Activity：List[User]。

在本发明的可选实施方式中，所述第一映射装置中的key/value对为user_id/friendList；所述第二映射装置中的key/value对为<user_id，act_id>/use_time；所述规约装置通过reduce获得的value为<user，List<app，friend，use_time>>。

在本发明的可选实施方式中，在所述规约装置中还根据使用时间对动态进行排序。

在本发明的可选实施方式中，所述动态包括发布/更新日志、进行新游戏、向用户发送消息、建立新群以及共享照片。

附图说明

通过结合附图对所示出的实施方式进行详细说明，本发明的上述以及其他特征将变得明显。在附图中，相同的参考标号表示相同或相似的元素。

图1是示出了根据本发明第一实施方式的在SNS社区中获得好友动态的方法100的流程图。

图2示出了根据本发明的在SNS社区中获得好友动态的一个具体示例。

图3示出了根据本发明第二实施方式的在SNS社区中获得好友动态的系统300的框图。

图4示出了适于用来实践本发明实施方式的计算机系统的示意性框图。

应当注意，附图中的流程图和框图，图示了按照本发明各种实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，所述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

具体实施方式

下面将参考若干示例性实施方式来描述本发明的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本发明，而并非以任何方式限制本发明的范围。

图1是示出了根据本发明第一实施方式的在SNS社区中获得好友动态的方法100的流程图。应当理解，方法100中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。方法100还可以包括附加的步骤和/或省略执行示出的步骤。本发明的范围在此方面不受限制。

方法100开始之后，在步骤S102，基于SNS社区的用户进行第一轮映射(map)。这一轮映射是对SNS社区中的每个用户所拥有的好友进行的映射。

在本发明的可选实施方式中，可以将用户的好友列表记录为User：List[Friend]，其中key为user_id，value为friendList。

在实际过程中，为了更加方便快捷起见，优选进行两次map-reduce过程。在这种情况下，针对第一轮map的reduce过程实则为对每个好友进行下一轮map-reduce。也即方法进到步骤S104。

在第二轮map中(步骤S104)，对好友的动态信息进行map。

在本发明的可选实施方式中，可以将用户的动态记录为User：List[Tuple<Activity，Time>]，其中key为<user_id，act_id>，value为time。

在本发明的可选实施方式中，还可将动态的用户使用状态记录为Activity：List[User]。

第二轮map结束之后，方法100进到步骤S 106，即第一轮reduce步骤。在该reduce步骤中，以<user_id，act_id>为key进行规约，合并其动态历史。

最后进行第二轮reduce步骤。即以user_id为key，对动态历史进行合并，至此，方法100结束。

在本发明的可选实施方式中，合并过程中同时可以根据使用时间use_time进行排序。

在本发明的可选实施方式中，以上两轮map-reduce工作可以提交给大型分布式MapReduce平台进行对海量数据的计算。这里的大型分布式MapReduce平台包括现有的各种类型的分布式MapReduce平台。

为了具体说明本发明，图2示出了根据本发明具体实施方式的一个具体示例。例如在社交网络200中存在多个用户201，比如A，M，X，Q，……，以及a，b，c，d，……。这些用户中的每一个都有至少一个自己的好友。

为描述方便起见，如图2所示，假设用户A的好友为a和b，用户M的好友为a和c，用户X的好友为m，a和d，并且用户Q的好友为d。则根据本发明实施例，当这些好友有任何动态时，首先进行第一轮map202，即在202中对用户的好友进行映射。在该第一轮map202中，key例如可以是用户，而value例如可以是好友。从而得到例如下列结果：

用户A，a

用户A，b

用户M，a

用户M，c

……

用户X，m

用户X，a

用户X，d

用户Q，d

……

在此基础上，进行第二轮map，即对用户好友的动态信息进行map。在该示例中，动态信息例如包括用户的活动和进行该活动的时间。在该第二轮map中，key例如可以是好友(其同时也是用户)id以及动态活动id，value例如可以是进行动态活动的时间。在第二轮map之后，得到下列结果：

a，新建群 10:14 10月1日

a，更新日志 21:19 9月28日

b，共享照片 16:40 9月30日

c，加入群 19:51 9月30日

……

m，推荐新游戏 8:11 9月29日

d，更新日志 16:40 9月30日

d，推荐电影 21:19 10月2日

d，更新日志 19:51 10月2日

……

至此，可以开始进行reduce过程。如图2所示，第一轮的reduce204实际上针对的是第二轮map的结果，在这轮reduce204结束之后，得到例如如下输出：

a，更新日志 21:19 9月28日

a，新建群 10:14 10月1日

b，共享照片 16:40 9月30日

c，加入群 19:51 9月30日

……

d，更新日志 16:40 9月30日

d，更新日志 19:51 10月2日

d，推荐电影 21:19 10月2日

m，推荐新游戏 8:1 19月29日

……

随后，继续进行第二轮reduce206，该reduce实际上对应于第一轮map。在这轮reduce结束之后，得到例如如下输出：

A，a，更新日志 21:19 9月28日

A，a，新建群 10:14 10月1日

A，b，共享照片 16:40 9月30日

M，a，更新日志 21:19 9月28日

M，a，新建群 10:14 10月1日

M，c，加入群 19:51 9月30日

……

X，m，推荐新游戏 8:11 9月29日

X，a，更新日志 21:19 9月28日

X，a，新建群 10:14 10月1日

X，d，更新日志 16:40 9月30日

X，d，更新日志 19:51 10月2日

X，d，推荐电影 21:19 10月2日

Q，d，更新日志 16:40 9月30日

Q，d，更新日志 19:51 10月2日

Q，d，推荐电影 21:19 10月2日

……

在本发明的可选实施方式中，在reduce步骤中还根据使用时间对动态进行排序。例如将先发生的动态在前显示。

在本发明的可选实施方式中，动态包括发布/更新日志、进行新游戏以及向用户发送消息、建立新群、共享照片等等。

图3示出了根据本发明第二实施方式的在SNS社区中获得好友动态的系统300的框图。。

如图所示，系统300包括第一映射装置301，配置用于对用户的好友进行映射Map；第二映射装置，配置用于进一步对用户好友的动态进行映射Map；以及规约装置，配置用于对上述两轮映射Map的结果进行规约Reduce。

在本发明的可选实施方式中，系统300进一步包括：第一建模装置304，配置用于记录用户好友列表为User：List[Friend]；第二建模装置305，配置用于记录用户动态为User：List[Tuple<Activity，Time>]；以及第三建模装置，配置用于记录动态的用户使用状态为Activity：List[User]。

在本发明的可选实施方式中，第一映射装置中的key/value对为user_id/friendList；第二映射装置中的key/value对为<user_id，act_id>/use_time；规约装置通过reduce获得的value为<user，List<app，friend，use_time>>。

在本发明的可选实施方式中，动态包括发布/更新日志、进行新游戏、向用户发送消息、建立新群以及共享照片。

从上述示例可以看出，通过MapReduce这个分布式处理框架，不仅能用于处理大规模的用户动态，而且能将很多繁琐的细节隐藏起来，比如，自动并行化、负载均衡等。因而能够快速便捷地向用户提供其好友的动态。

图4示出了适于用来实践本发明实施方式的计算机系统的示意性框图。如图4所示，计算机系统可以包括：CPU(中央处理单元)401、RAM(随机存取存储器)402、ROM(只读存储器)403、系统总线404、硬盘控制器405、键盘控制器406、串行接口控制器407、并行接口控制器408、显示控制器409、硬盘410、键盘411、串行外部设备412、并行外部设备413和显示器414。在这些设备中，与系统总线404耦合的有CPU 401、RAM 402、ROM 403、硬盘控制器405、键盘控制器406、串行控制器407、并行控制器408和显示控制器409。硬盘410与硬盘控制器405耦合，键盘411与键盘控制器406耦合，串行外部设备412与串行接口控制器407耦合，并行外部设备413与并行接口控制器408耦合，以及显示器414与显示控制器409耦合。

应当理解，图4所述的结构框图仅仅为了示例的目的而示出的，而不是对本发明范围的限制。在某些情况下，可以根据具体情况而增加或者减少某些设备。

特别地，除硬件实施方式之外，本发明的实施方式可以通过计算机程序产品的形式实现。例如，参考图1描述的方法100可以通过计算机程序产品来实现。该计算机程序产品可以存储在例如图4所示的RAM 404、ROM 404、硬盘410和/或任何适当的存储介质中，或者通过网络从适当的位置下载到计算机系统400上。计算机程序产品可以包括计算机代码部分，其包括可由适当的处理设备(例如，图4中示出的CPU 401)执行的程序指令。所述程序指令至少可以包括：用于基于与所述用户相关联的至少一个图像来确定候选好友的指令，所述候选好友是所述社交网络的成员、但不是所述用户的直接好友；以及用于将所述候选好友中的一个或多个推荐给所述用户的指令。

上文已经结合若干具体实施方式阐释了本发明的精神和原理。根据本发明的实施方式，可以基于用户的移动终端通讯录来向用户进行推荐。这种推荐突破了传统推荐方式在同一类型的好友之间进行推荐的局限，使得推荐可以更加灵活、更贴合用户的需求。

应当注意，本发明的实施方式可以通过硬件、软件或者软件和硬件的结合来实现。硬件部分可以利用专用逻辑来实现；软件部分可以存储在存储器中，由适当的指令执行系统，例如微处理器或者专用设计硬件来执行。本领域的普通技术人员可以理解上述的设备和方法可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、CD或DVD-ROM的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本发明的设备及其模块可以由诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用由各种类型的处理器执行的软件实现，也可以由上述硬件电路和软件的结合例如固件来实现。

说明书中提及的网络可以包括各类网络，包括但不限于局域网(“LAN”)，广域网(“WAN”)，根据IP协议的网络(例如，因特网)以及端对端网络(例如，ad hoc对等网络)。

应当注意，尽管在上文详细描述中提及了设备的若干装置或子装置，但是这种划分仅仅并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多装置的特征和功能可以在一个装置中具体化。反之，上文描述的一个装置的特征和功能可以进一步划分为由多个装置来具体化。

此外，尽管在附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。相反，流程图中描绘的步骤可以改变执行顺序。附加地或备选地，可以省略某些步骤，将多个步骤规约为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

虽然已经参考若干具体实施方式描述了本发明，但是应该理解，本发明并不限于所公开的具体实施方式。本发明旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。所附权利要求的范围符合最宽泛的解释，从而包含所有这样的修改及等同结构和功能。

Claims

1.一种在SNS社区中获得好友动态的方法，包括：

第一映射步骤，用于对用户的好友进行映射Map；

第二映射步骤，用于进一步对用户好友的动态进行映射Map；以及

规约步骤，用于对上述两轮映射Map过程的结果进行规约Reduce。

2.根据权利要求1所述的方法，进一步包括，在所述第一映射步骤之前，还包括下列建模步骤：

第一建模步骤，用于记录用户好友列表为User：List[Friend]；

第二建模步骤，用于记录用户动态为User：List[Tuple<Activity，Time>]；以及

第三建模步骤，用于记录动态的用户使用状态为Activity：List[User]。

3.根据权利要求2所述的方法，其中，

所述第一映射步骤的key/value对为user_id/friendList；

所述第二映射步骤的key/value对为<user_id，act_id>/use_time；

所述规约步骤通过reduce获得的value为<user，List<app，friend，use_time>>。

4.根据权利要求1所述的方法，其中，

在所述规约步骤中还根据使用时间对动态进行排序。

5.根据权利要求1所述的方法，其中，

所述动态包括发布/更新日志、进行新游戏以及向用户发送消息、建立新群以及共享照片。

6.一种在SNS社区中获得好友动态的系统，包括：

第一映射装置，配置用于对用户的好友进行映射Map；

第二映射装置，配置用于进一步对用户好友的动态进行映射Map；以及

规约装置，配置用于对上述两轮映射Map的结果进行规约Reduce。

7.根据权利要求6所述的系统，进一步包括：

第一建模装置，记录用户好友列表为User：List[Friend]；

第二建模装置，记录用户动态为User：List[Tuple<Activity，Time>]；以及

第三建模装置，记录动态的用户使用状态为Activity：List[User]。

8.根据权利要求7所述的系统，其中，

所述第一映射装置中的key/value对为user_id/friendList；

所述第二映射装置中的key/value对为<user_id，act_id>/use_time；

所述规约装置通过reduce获得的value为<user，List<app，friend，use_time>>。

9.根据权利要求6所述的系统，其中，

在所述规约装置中还根据使用时间对动态进行排序。

10.根据权利要求6所述的系统，其中，

所述动态包括发布/更新日志、进行新游戏、向用户发送消息、建立新群以及共享照片。