数据与计算科学

主持人：

各位来宾，各位朋友，大家上午好。

金秋九月，欢迎大家来参加由 TalkingData主办的“T11全球移动大数据峰会”，我叫肖

文峰，由我主持技术专场。这里是技术专场，技术专场，技术专场，重要的事情重复三遍，

避免有朋友发现进错了会场。

TalkingData自 2011年成立以来，一直以技术为核心驱动力，在大数据领域努力耕耘，

我们希望用数据去改变企业做决定的方式，也希望用数据去帮助人们了解周围的环境。我们

一直坚信，数据和数据技术都应该是开放的、平等的、流动的，只有这样才更加有价值。因

此，数据行业的技术人员也应该具有开放、平等和分享的心态。回首 4 年大数据之路，

TalkingData 获得了很多朋友的帮助，我们也想在力所能及的范围内回馈曾经帮助我们的朋

友——分享，无疑是最好的回馈方式。

我们希望藉此机会，能够把 T11做成大数据行业一线研发人员每年一度的海天盛筵。在

本会场，我们 CEO要求一定讲干货，充分交流，要把话题讲透。本次大会作为第 1季，我们

请来了在硅谷的一些技术专家，他们会带来硅谷大数据领域的一些新的想法和实践经验。上

午我们将聚焦于大数据的分析系统和架构，下午将聚焦在算法模型和应用实践。

同时我们也有三次抽奖环节（上午一次，下午两次），准备了丰厚的奖品，也提前预祝大

家好运。

另外，为了方便大家交流，我们也创建了微信群“T11-大数据技术群-2015”：通过微信

“面对面加群”的功能，大家输入数字“2011”即可加入。

大家都知道，TalkingData覆盖 18亿智能设备，拥有非常大量级的数据，也有很多朋友

对支撑如此大量级数据的平台非常好奇。黄洋成，TalkingData 合伙人兼首席架构师，曾在

BEA、Oracle、尚邮等公司担任研发和架构师职位，专注于移动分析和数据挖据平台。接下来，

洋成将基于他对数据平台的思考，和大家探讨下一代数据平台的定义、挑战以及 TalkingData

在通往未来之路上的实践经验。有请黄洋成！

黄洋成：

首先欢迎大家在北京繁忙的周末、交通拥堵的情况下非常早就来到我们的会场，另外还

需要感谢一下多位不远万里从硅谷来的专家跟大家分享目前技术领域世界领先的前沿技术。

今天我给大家带来的题目是通往下一代数据平台的狂暴之路。TalkingData 从 2011年成

立以来，我们一直致力于怎么去发展数据的一些应用，以及发掘数据的价值。通过四年来的

实践，我们也得到一些经验教训，同时也有自己的心得。

我主要分享三部分，一是分享一下数据项的流程是怎样的，要支撑这样一个流程，大家

对数据平台有什么样的期望；二是从技术的角度，从技术团队来讲，要满足这样的期望会遇

到什么的挑战；三是 TalkingData 已经做以及正在做的一些事情，跟大家分享一下。

这是一个非常普通的流程，数据流程都是类似的，也没有什么特别的地方，没有特别的

地方往往也说明其实就是一个比较普适很基本的东西，很难改变这个流程。通常一个数据项

首先从一个问题开始，这个问题可能是你有某个业务上的问题需要解答，数据有疑问，需要

数据支撑。当业务提出疑问的时候，必须和相关团队来形成一个计划，说明这个问题到底分

析的是什么，怎么用数据的方法来解决或者验证这个问题。当这个方案已经初步形成以后，

接下来更多是技术团队的工作。技术团队首先要看看到底这个数据在哪里，怎么能得到它，

现在有没有，以及有什么样的特性。这个问题解决以后，往往会把这些数据根据业务数据处

理掉，传统来说就是做一些统计、某些规划，再有通过一些技术模型来看看这些数据到底隐

含什么样的信息。

这个数据流程跑完以后最终得到一个结果，这个结果有可能支撑你开始的想法，也可能

这个结果回过头来发现刚才某一步有问题，从这个结果跳到某一步，重新走一遍。这样往往

会对相关人员提交结果，比如说管理层，管理层根据你这个结果做出重要的决定。这也是一

个非常简单的数据流程。

通过这个流程，我们会发现做一个数据项，对于我们都是技术人员，我们首先需要考虑

能建一个数据平台，来支撑这个流程。

接下来看，要做一个数据平台，从流程反映出来，它到底应该提供什么？我用几个词来

描述这些需求。第一，协作；第二，迭代；第三，交互；第四，表现力；第五，智能。

协作，数据项涉及到非常多的部门，有很多人参与。从部门来讲，你的需求可能来自于

销售部门或者市场部门、产品部门，技术实施需要技术部门来做实施，最后你做决定可能是

CEO做最终的决定。整个流程跨了很多部门，而且这里面参与了很多的角色，得有人懂业务，

有人懂数据，有人懂技术，才能把这个流程做好。假如说你有一个理想的数据平台，首先必

须能保证所有的部门和各种角色非常好的协作出来，整个数据流都要跑通。

迭代，这是流程驱动环节，这就是迭代。大家都是做技术的，都知道软件模型也是一个

迭代模型。软件迭代往往是按月来计，对数据来讲，理想就是按天，甚至按小时迭代模式更

合适。为什么呢？对于软件来说，要做一个软件，电商系统要做一个订单系统，这个订单系

统只给了流程，业务人员是确定，技术人员也确定，不确定的就是小细节。数据迭代是不一

样的，你根本不知道这个数据最终给你带来什么样的信息，往往有可能给你带来惊喜，也可

能带来恶梦。数据项目本身就是解决不确定性的，正因为有了不确定性，对迭代的速度要求

就和开发软件不一样。另外数据本身有时效性，如果迭代速度太慢，数据早已经过期了，数

据已经成为垃圾。

交互，正是因为数据迭代才产生交互性，数据流动的过程充满不确定性，这个平台对交

互性提出更高的要求，交互是什么呢？作为一个平台，我预先不确定干什么，在一个平台有

一些结果，我还看看别的东西，这个平台有没有能力支撑，这个平台方便让人们表达新的需

求，然后实现出来，就可以说是交互性比较好，可以达到比较好的交互性。

当数据结果出来最终会有数据输出，最终的结果数据输出往往不是自己理解就可以了，

需要做的事儿是和流程中所有的人沟通，这就带来一个情况——流程中有一些人，尤其是管

理层，对这个事情怎么做根本不了解，如果这个结果不能很好的表达意图，对别人来说这个

数据也是非常难理解的。举例，以前我们有 Database 团队，我们给一些数据打上标签，这些

标签都是跟用户移动应用信息相关。我们非常感兴趣的就是这种标签对移动应用推广广告有

没有影响，把这个任务交给我们，我们看这个团队直接发一个邮件出来，这个邮件里面有几

十个数据，这些数据叫 ALC，这对于老大来说，根本不知道 ALC 到底是什么玩意儿，这些数

据都是小数，而不是整数，密密麻麻排在那儿，都不理解这个邮件到底想表达什么，结论是

什么，表现为更多对于数据项目肯定会产生结论，这个结论要通过一些数据做支撑，你根据

这个数据说这个结论是可靠的，如果不能把这两个东西说清楚，这个数据项肯定是失败的。

智能，智能非常容易理解，作为 SaaS平台，计算机存在以来，不干别的就是处理数据。

大家对数据平台尤其是大数据平台有一定的定义，这些数据平台肯定不是一些浅层次的知识，

希望这个平台能够展现出来数据背后隐含什么东西，人不能一眼识别和理解的东西。

智能化不仅仅是从数据上有作用，数据挖掘也有作用。数据之前肯定有大量的工作是做

数据清洗，数据清洗是通过各种人发现清洗规则。有没有可能通过一些机器的方法自动把这

些规则发现出来，不需要人繁琐的工作，假如做了，这个数据项 80%的工作就变成 20%的工作，

效率提高一倍。

我们都是做移动项目数据的，很多合作伙伴都是一些移动开发者，移动开发者非常关注

的就是日活和新增，现在一般每天都上系统看看相关数据，如果这个系统比较智能，能不能

自动发现一些模式，在新增异常的时候，你能自动智能通知他，这块可能有问题，需要查看

相关的东西，这样的平台可能更理想一点。

刚才更多是从业务的角度谈谈大家对数据平台有什么样的期望。接下来回到技术阶段，

作为一个技术团队，拿到这些需求和期望，我们会有什么样的挑战。要满足他们这些期望，

我们要做什么。还是选择几个词来描述。第一，跨界；第二，源信息；第三，混合；第四，

速度；第五，可视化，第六，效率；第七，运维。

跨界，大家很好理解，我们有些客户是房地产企业，有些需求是来自房地产开发商的，

他们想知道这块地是什么样的，在什么位置，周围住多少人，有什么需求，我们并不了解，

经过探讨一下，语言就是谎言，因为语言没有清晰描述一个事情的能力，很多信息也是错误

的。如果技术人员很专业，你可以不是房地产专家，但是你可以需要相关的地产，对于我们

这个项目来说很关键就是对地产不是很了解，对信息有很深的了解，对项目做成功也非常重

要。这不是一个很简单的事情，大家都知道基于位置会产生很多信息，产生经纬度。是不是

只是经纬度能代表位置信息呢，是不是还有其他的东西。你会探究到一些东西，很多信息都

是跟位置相关的，包括 IP。位置提供的精度是不一样的，你要理解这个项目，用户对位置需

求是怎样的，对精确度需求是怎样的。这就要求大数据人员不只是懂 hadoop等，还要懂业务。

源信息，这些数据怎么找到它，找到它怎么获取，它到底有多少，分布情况是怎样的，

以及这些数据不是原始的，这些数据是从哪儿来的，从哪儿转化过来的，这些信息非常关键。

而且这些信息需要项目初期了解，如果没有了解，就不能评估这个项目，有没有能力支撑这

个项目，这个项目能不能做。如果项目中期发现根本没有能力支撑这个项目，你可以换一个

项目，但是这个风险是非常高的，会造成非常大的浪费。

有了数据之后，我们要处理这些数据，处理数据有很多方式，涉及到更多各种各样的技

术，但都是不是成熟技术，都是新的技术。怎么能让这些技术在一个平台里相安无事，能够

用的好，这可以说是一个非常难的事情。但是这个需求确确实实存在。对于你来说，追踪的

项目是有非常高的要求，可能要求几秒钟的数据，数据平台需要平台 Elearning 的支持，

Elearning 的模式可能又有很大的区别。你后面需要对模式的区别的支持体系也有很大的不

同，怎么协调也是一个非常大的问题。

速度，数据跑的太慢也不行，不管怎么定义，大家都有一个公认的定义，有一个共同的，

就是数据体量不会太小。数据体量一起来，就发现这是一个技术难题。除了数据运行速度，

还有其他的速度，开发速度能不能进行快速开发，开发速度要大大提高。数据项有一个重要

的特性就是它是迭代的，而且对迭代速度有更高的要求，迭代速度也是衡量这个数据平台是

不是高效的一个重要因素。

可视化，作为技术人员，可视化太低，大家都会觉得你太 Low了，很多数据也需要可视

化进行展现。你会发现一个数据用合适的方式展现出来以后，很多结论就显而易见了。有些

数据是按小时看的，我能不能知道这个分布随着时间变化是怎样的，你业务高峰的时候，数

据分布和平时分布状态是不是不一样。我们做的用户使用时长目前也有分布，你会看它是不

是偏了，对比变化情况是怎样的。传统的分布是很难表现这种信息的。它首先把二维变成一

维的，再并列起来，变成一个二维，它的分布相应显而易见，非常清晰。

大数据意味着大量的计算资源，大量计算资源意味着非常高的成本，非常高的能耗。据

我们了解，现在国内像 IDC，按平均 CPU 使用来计，IDC 的 CPU 使用率是怎样的，如果达到

20%已经是做的非常不错了。这意味着有 80%的计算力没有利用上，消耗掉了。假如说结算成

机器，有 1000台机器，800台机器是没有用的，这可能是有一种夸张的说法，但是也是反映

现实。只有 20%的机器在干活，80%的能量消耗都是白白浪费掉了。这对于机器整个系统运行

效率也提出了非常高的要求。几十台机器不会在乎这些问题，但是如果是几百台、几千台的

时候，浪费是非常高的。对于大数据，现在还是探索阶段，对于一个数据平台，现在还没有

持续高效率产出一些高价值的东西。其实对于大数据平台，目前它的收益并不高，收益并不

高的情况下，对整个成本控制就是以后大数据平台能不能活下去的一个非常大的因素。

运维，对于软件来说，大家很不关心软件的运维，但是软件开发出来只完成 20%，80%的

工作都是软件上线，上线之后怎么维护，发生问题怎么恢复，有状态怎么发现，有大量的工

作都在后面。运维是一个非常吃力的工作，又没有太多成绩来讲，但是对一个工程来说非常

重要。

从技术的角度来讲，要做一个好的运维，基本上是一个好的开发。你做一个好的开发只

有非常低的可能性能做一个好的运维。

最后简单介绍一下 TalkingData做的一些工作，不会特别详细，大家感兴趣也可以线下

进行探讨，也欢迎大家平时到我们公司作客，进行交流。

最近我们推出了灵动分析的功能，这个功能是移动应用分析产品里面 Beta 的状态，内部

叫 codeless，产品或者运营人员需要搜集这个 APP运行的各种信息，首先需要想清楚，到底

要抓住什么点，接下来需要和 APP的开发者沟通，你把这些地方的数据收集上来，单一应用

都是放在 APPStore，应用上线周期几周甚至几个月，终于上线了，大家都到这个平台上看看，

这个数据是不是像我所期望的，它没有那么完善，可能想错了，就找开发的人。开发的人功

能迭代压力非常大，大家每天都需要加班加点干活，没人愿意干数据相关的破事儿，跟他主

要的目标没有关系。我的应用怎么更快一点，给用户交付更好，达到什么效果，和产品设计

出来一模一样，这是开发者的重点。

这里面有一个什么问题呢，首先是协作的问题，它需要和产品或者运营求着干事情，人

家爱干不干。还有一些数据的问题，很多东西预先没想清楚，原来这种模式要求你必须想清

楚，否则这个东西就可能是一年以后的事情了。

再就是沟通成本，从数据平台来看，目前最头疼的一个问题就是毫无意义的事件，都是

业务人员和技术人员沟通当中造成的，技术人员没有理解业务人员需要收集什么数据。为了

解决这个问题，我们要解决这个问题的方法，它的方法就是只要加一行代码，这行代码跟你

收集的数据没有什么关系，就是跟数字化有关系。

咱们收集数据呢？是根据所见即所得来实现的，跟你的上线流程没关系。新的流程下，

你要收集数据要跟移动应用谈判有什么关系，只要做一次就可以了，不需要知道收集什么数

据，收集什么数据可以在上线以后进行定义，或者发现什么地方定义错了，随时修改。任何

好的东西都是有局限性的，对于这个局限性在哪里呢？它只能跟踪界面上表现出来的东西，

如果你跟踪的东西不能在界面上表现出来，这时候是无能为力的。

再就是 DATA CATALOG，它是数据资产管理平台，可以让相关的人一目了然知道目前我们

到底有什么数据，这些数据都有什么含义。这些数据到底有多少，各种统一信息都可以很显

然看到。没有做这个之前，我们了解每个数据都需要找技术人员跑一遍，看看到底有多少数，

把业务放进来，看看有多少数据。这些数据并不是完全精确，但是也有一定的不确定性。

DATA CATALOG接下来就是需要把数据来龙去脉描述清楚，很多数据并不是源数据，都是

后期的，原始数据都很脏，你需要把原始数据清洗，还有很多数据散落在很多地方，原始数

据可能有很多 BUG或者问题，我们通过什么元素帮助你发现这个过程中有没有问题。不然你

得猜测到底是哪些地方、哪些环节出现了问题。

我们还做了一个 OLAP模型，这是我们内部用用的，没有其他那么有名，主要是做分析的

功能。具体细节，我们技术人员也做了很多分享，不细说了。这个模式就是非常结合的模式，

用结合的模式解决对性能有要求的需求，如果你能够迎合这种性能的需求，我可以通过多种

方式满足你，而不是预先定义的这几个。

SAMPLING，大家会觉得 SAMPLING和大数据有点冲突，大数据用的是全数据，而不是采样。

为什么采样呢，数据初期可能不会有完善的方案，而是通过数据探索不断完善方案。如果全

数据跑，是非常不经济的，速度很慢，也耗费资源。我们会利用采样，首先在采样数据上磨

炼你的方案，让你实现一个逐渐完善的方案，然后再用全数据测试，测试可以提高整个执行

效率。

MLASA SERVICE，传统的 Elearning模式都是一些 LAB的技术，对于技术人员对 Elearning

的模式不了解。这对于通常做 JAVA的人，都不是很直观或者很容易理解的，因为你刚毕业还

好，如果你从大学毕业已经五年十年，大学数学早已经换给老师了，Elearning 很多东西会

感觉非常抵触熟悉，很抵触，很难知道怎么去用。

从我们这边，我们有一个团队，这个团队分为两部分，两个团队对两边的技术都有一定

的了解。我们希望一个团队能把研发变成服务，别人只要把数据提交过来，就能证明结果，

然后由另外一个团队和业务团队进行沟通，把需求和数据返回到这边，给出结果，最后在业

务平台里面去跑。

DATA FLOW，数据流程非常复杂，每一步很容易出错，出错有各种各样的错，有你理解的

错，有数据本身有一些异常数据没有处理好等等引来的，这个数据流程怎么健康跑起来，这

些流的统计数据是不是你期望的，到底有多少数据是错的，把信息化平台展现出来，这样有

助于大家对数据流的诊断。实际中经常发现有些数据不符合预期，很多问题都是数据流程原

来没有注意到的问题带来的。

针对运维场景来说，我们现在暂时不到一千台机器，从可预见的情况来看，机器数目增

长接下来肯定非常快。这么多的机器，那么多的数据流程，那么多不同的数据在上面跑着，

首先对你系统怎么维护是很大的挑战，前面提到除了系统能跑，怎么高效跑，那是一个更大

的挑战。目前来说，我们初期主要还是系统能正常跑，更快的能够上线，上线之后能够更好

的运行，对于这个，我们还是很关注的。接下来我们关注的就是很多系统能不能自动随着压

力增大，自动调整部署机器。目前来说对我们还是非常大的挑战，还没有做到这一点。但是

我们也在往这个方面努力。

最后，我们也希望探索各种不同模式计算对资源消耗模式是不一样的，如果能够精细的

把这些不同运算安排一下，能够把隔离做好，相互之间不会有影响，有可能会把整个机器应

用效率提上去。有些地方做的是很好，他们把 CPU运营 40%、50%提高到 80%、90%，它里面还

有一个设置，对响应要求非常高的服务，同时保证数据不会破坏。目前我们能力有限，还做

不到那么好，我们在做这种实验，把不同的东西放到一起，同时提高应用效率，保证这些系

统能够正常工作。也希望大家祝我们好运。

今天给大家分享的就这些，谢谢。

主持人：

谢谢黄洋成，黄洋成是我们公司神技术的存在，如果有问题可以私下跟他讨论。

Pinot是出自 LinkedIn 的一套分布式 OLAP系统，为了解决大数据集的实时分析。Pinot

在 LinkedIn已经使用了有超过两年的时间，LinkedIn 有超过 25个分析产品使用 Pinot作为

后端的支撑，并且超过 30 个内部产品使用 Pinot。Greg Brandt 在 LinkedIn 数据分析架构

组任职高级软件工程师，负责 Pinot的聚合索引、分布式 OLAP数据库、以及 ThirdEye项目。

此前，他曾任职于 Espresso，也是 Apache Helix项目的贡献者之一。

下面，有请 Greg 来为大家剖析分布式 OLAP 引擎 Pinot 的聚合索引之道。Ladies and

gentlemen, now let me introduce Mr. Greg！

Greg Brandt：（英文）

主持人：

大家如果有问题，可以找 Greg Brandt问。大家也可以加群问。

如果说 Pinot 系出名门，那么 Druid 系统毫不逊色。Druid 系统应对的问题和 Pinot 相

似，都是大数据实时查询和分析，它能达成在秒级以内对十亿行级别的表进行任意的探索分

析。并且 Druid和 Pinot具有较为相似的技术架构。

仿今是 Druid开源项目的核心贡献者之一，也是旧金山大数据初创公司 Imply的联合创

始人。仿今毕业于加拿大 Waterloo大学，并先后在 Metamarkets和 Cisco公司任职高级工程

师。

接下来，请仿今为大家分享 Druid实时分析系统的架构设计思想科学。

杨仿今：谢谢大家来听我这个讲座。我开始以前和大家说一下，中文不是我的母语，我是在

外国长大的，所以我用英语讲。（英文）

主持人:谢谢仿今。下面是抽奖环节。（抽奖环节）上午的会议到此结束，下午一点半开始，

请大家准时过来。（结束）

主持人：

我是 TalkingData CTO 肖文峰。先讲一个故事，我加入 TalkingData 之前，是在 360

安全事业部负责手机卫士的，当时我们是做工具的，我们跟猎豹各自有几十个人的运营团队，

每天不干别的，就下载一些软件，安装在自己手机上，产生垃圾目录一个一个分析，运行的

后台进程也一个一个分析，进程名是什么，干什么用的，都要去分析。为什么要做这一点呢？

就是想帮客户清理更多的垃圾，清理更多的进程。如果有一个第三方服务能够告诉开发者，

用户现在正在干什么，那么这种清理的判断还能够更加智能，清理效果还能够更好些。比如，

微信一般不会被清理，但是在用户不登录的时候其实是可以清理的。又比如，正在走路的时

候，导航软件就应该保留，但是如果长时间在家没有动，那么导航软件就可以清理。其他还

有很多类似的案例，可见，什么样的人在什么时刻做什么，对工具类软件来说是很重要的信

息。对电商类软件来说更是如此，比如，我知道用户是在上班的路上，就会推送一杯咖啡提

神醒脑，是在下班回家的路上，那可能就会推送一束鲜花送给家人。

场景化包含三个核心要素：什么人、在什么时刻、做什么事情。大数据解决了“什么人”

的问题，TalkingData覆盖了 18亿智能设备，我们给这些人做画像，男女、年龄、职业等，

给他打上标签。位置和时间信息解决了“在什么时刻”的问题，比如“在回家的路上”。手机

上的各种传感器解决了“做什么”的问题，比如“走路”、“跑步”、“驾驶”、“游泳”等。大

家都知道手机上有很多的传感器，国外用手机电池电量定位，或者磁场定位，我们觉得是匪

夷所思的事情，说明我们对传感器了解还很少。

TalkingData基于此，投入了一些资源，做了一个场景感知 SDK，帮助开发者感知场景，

利用场景。上个月，我们也为此举办了一场黑客马拉松比赛，以让开发者的创意在场景化的

能力中得以绽放。

下面有请 TalkingData 研发总监卢健来为大家介绍一下 TalkingData 场景感知 SDK，同

时为我们揭晓黑客马拉松比赛结果。

卢健：

刚才 CTO把我好多要说的话都说完了，但是我还是要说一下场景感知 SDK。TalkingData

致力于为开发者提供专业的服务，这些服务的目的是让开发者能够专注于自己的业务，能够

结合我们的提供的服务开发出有创造性的应用，为用户提供更好的服务。

刚才 CTO讲的场景化，大家都知道 Apple 的 Core Motion框架上提供了简单的行为识别，

走、跑、驾车等行为识别，以及记步等功能。Google 的 GMS上也加入了地理围栏和行为感知

功能。我们看到没有第三方提供类似的技术支持，没有开发者有这样的技术能力，加上场景

感知技术，可以为用户提供更好的有创造、创新的服务。基于此，TalkingData 做了一个孵

化项目叫场景感知 SDK，为了让这个 SDK 快速得到反馈，更好为开发者提供支持，我们举办

了一个编程马拉松，历时 32小时，有很多对场景感知有兴趣的开发者，还有北邮和清华的许

多学生参加了，共 40多人，分成 9 个队伍，都提交了自己的产品。待会儿我会宣布评奖结果。

接下来介绍一下场景感知 SDK。这是我早上来的时候拍的照片，他讲的是谁在什么时候

做了一个什么事情。既然谈到感知，到底应该感知什么，结合现代手机应该有的能力，每个

人都有社交类的应用，应用多数都有推送功能，这已经成为一个基础服务。在这样一个形式

下，加一些感知，就会知道你的好友哪些也在会场，这样就提供了一个新交流的平台和机会，

这就是谁在什么时候做什么。我没有提到一个词，就是“位置”，场景感知实际上是对位置感

知的补充。LBS 已经火了很多年，LBS SDK 已经整合进多数应用的使用流程里面，场景感知

SDK有可能成为位置 SDK之后的强需求 SDK。

场景，怎么定义场景，我不考虑说怎么收集这样的场景数据，单从人的行为环境数据看，

到底什么是场景。信息类：人的特性，生活习惯、感情，你的生理条件、健康条件，这都是

信息类场景。社会环境类，就是生活在这个社会当中，人和人之间的关系，你所在的这个群

体，这是人的一个社会性。行为活动类，每天都在主动参与一些活动，被动邀请参加活动，

每个活动都有自己的活动目的。从信息到社会，到行为，不同人的行为数据都是一些场景，

我们把这些合在一起，就是一个生活化场景。

我们看场景按照物理环境分类：位置，它是相对位置和绝对位置，这个很好理解，我们

时时刻刻都处在一个位置上。基础设施，就是我们周边的硬件设施，包括网络通信，还有眼

前很亮的灯，都是基础设施。灯是基础设施，那灯光是什么，灯光是物理条件，还有空气质

量，磁场，空气质量，大气压力等，我们能收集的数据还是很多的，现在很多传感器都被塞

到随身的手机里，有这样一个条件。TalkingData有能力收集这类数据，收集这些数据以后，

就可以通过对数据开放做一些基本的服务。当然，我们不可能把所有场景信息都收集到。

这是很早之前 Google讲的一个故事，他以时间为轴，从早上起床快速奔向一个车站，无

论是坐公交、火车，还是地铁，下车以后去上班的路上，你坐在公司椅子上开始工作。整个

行为过程中，有什么样的应用可以给我们提供服务呢？它可以知道我是不是可以打开一个音

乐，到车上以后是不是可以日历浏览、工作处理，工作的时候把邮件打开处理我一天的工作。

前面好理解，大家看第三排有很多的波浪线。我们如何感知场景，有很多传感器，传感器有

什么用，传感器里面的数据可以形成很多波形。你起来以后很快跑到车站，第一个线很密集，

你坐上车以后几乎有一段时间不动，一会儿又动，这就是开车停车了，你下车后的缓步，对

比第一个波形，你会发现它没有那么密集。你到了公司，手机一直在桌子上不动。波形也是

不动的。

Google是一个很超前的技术公司，那么他们现在通过场景识别在做什么。大家仔细观察

会发现，这几个图上都有一个手表，Google现在希望在可穿戴设备上实现场景感知，它用可

穿戴式设备中的手表来通知你。这些图表达什么场景？

左上角就是你的家，上面有 72度，希望当你接近或者进入到这样一个家的环境里面，空

调自动调节室温。

右上角是一个停车场，上面有一个车钥匙，当你到达停车场附近位置的时候，我们可以

打开车的空调，在开车之前让车内的温度变得舒适。

左下角的场景是机场，你进入机场以后，会给你一些介绍，你的目的是哪儿，还有多远，

已经到达什么地方。

右下角，一个孩子在动物园里，我带孩子去动物园最苦恼的事情，就是不知道动物园的

表演是什么时候，什么位置，我拿着地图看，进门之后看半个小时也记不住，这个场景的案

例离我的需求最近，手表提醒我之后，就可以知道什么时候该去哪看表演，接下来的路线应

该如何规划。

中间这个图是国内商家非常喜欢的，O2O，如果你对某些店感兴趣，给这些店家标签，手

表会告诉你，你是不是要喝咖啡，是不是要买糖果。

大家回到国内现实状况来看，所有能用在可穿戴式设备的传感器，都会在手机里，可穿

戴设备应用的第一落地点也应该是手机，我们先把手机的传感器做好，让这个应用成为可能。

这个圈有四个步骤，我们看看 TalkingData 能不能做这个事情，首先是数据收集。

TalkingData从 11年到现在四年时间内收集很多的数据，为开发者提供了除了业务以外的专

业服务，我们有专业收集能力，有数据分析，有强大后端团队，帮助我们做数据整理、分析、

挖掘。数据可视化，这不是要把这些数据整理之后展现出来。我们常说昨天、今天和明天，

场景感知是用昨天的数据和今天用户行为，预知你将来有可能的动作行为，是这样一种条件

反射。通过第四步循环迭代，让一个开发者更加准确的知道用户想要什么，基于这样的可能

性，为开发者提供了一个场景 SDK。这个项目提供的第一个服务就是实时用户行为识别，这

是我们跟着 Google和苹果的技术设计，在手机上利用传感器实现实时用户行为识别。

这些模型第一个是走的，第二个是跑的，第三个是驾车的，我们做一些算法处理以后，

它会更加可辨识，这里面也存在另外一个问题，大家都知道安卓手机厂商里面，所有元器件

都是非标准的，这就给我们带来很大的难题，非标准的元器件怎么做。我们一开始通过大量

数据收集和计算，找到一些普适性的，准确性大概在 95%，有可能在走，有可能在跑，换一

个手机还行吗？可能不行了。后来我们也没有办法，只能寻找其他的技术，想办法让它自学

习，希望它能够适应手机以及用户自身的行为，因为每个人也不一样，每个人都是一个个体，

运动过程中没有人知道他是走，还是跑，实际上它是感知这个频率变化过程。最后我们提供

SDK之前，应该是达到了几个状态中平均达到 90%以上的程度。

SDK 提供的第二个能力，获取访问频度最高的 POI，这是什么，这就是上午提到的

TalkingData 要做数据开放，这是我们数据开放的一个尝试，我们收集了很多用户数据，我

们不可能利用这些数据知道你是谁，以前我们宏观的行为分析，整体靠数据表现，现在是不

是可以告诉你，有这么一个人，他大概做哪些事情，经常出现在哪些 POI 点上。POI 是地图

里面专指的一个兴趣点。我截这个图想表达的就是奥体公园、儿童医院、北京南站，他经常

到北京南站，可能经常出差，常去奥体公园锻炼，而且有孩子，因为他也去儿童医院。我们

想让开发者创造出更好的功能，为客户提供更好的服务。

SDK 提供的第三个能力，基于 POI 信息的地理围栏，地理围栏是地图上的概念。这个概

念我原来一听，就想到游戏，很早在玩儿游戏的时候，攻防类游戏，敌人进入你的领地的时

候一定有声音提示，你被攻击了，敌人离开都会有。后来它不仅在虚拟世界里，在现实世界

中，也可以很精确知道你进入到某一个很小的区域，在这里停留了，从这里离开了，基于这

样几个行为的变化，我们用这样一个 POI点和地理围栏表示这个人下一步的行为。

整个场景感知最后讲的就是预测，预测的方法到底谁来实现，谁能实现的好，用户就会

喜欢谁的方案。

现在所有 SDK提供的就是这三个功能。结合这三个功能，之前举办的编程马拉松提到的

应用程序经过组委会的评定，下面我来宣布评奖结果。

第一个，最具商业价值奖，这是一个名为反应链的应用，它就是一个预测，要反应，要

循环，要持续做一些事情。开发者名字是李明亮和张惜金，获奖理由，就是结合位置信息为

用户提供智能服务，通过数据预测用户下一步的行为，结合一个很火的概念 O2O。

第二个，最高完成度奖，所有人都提交了程序，有的完成的更完整。他叫杨振中，使用

识别用户行为记录用户运动状态，它的整个功能，描述的事情，他自己已经做到了，所以我

给这个奖。获奖理由：使用实时行为识别进行健康数据统计，结合 POI 信息，为有共同兴趣

爱好的人提供互动，形成社交圈。提交的作品体现了功能设计目标。

第三个，最佳设计奖，iKnow，开发者是宁起和刘大伟。它的概念设计是可以用非常好的

数据可说话的图象表现力表达一个用户长时间数据，从而对这些用户进行分类，对用户更准

确的刻划。获奖理由，使用实时行为长期记录用户状态，分析用户行为特征，进行人群画像，

结合社交分享，提高客户黏性与参与度。

整个结果很奇怪，三个获奖 App，名字都是英文的，可能英文可以用很短的词更加明确

表达想表达的含义。这些应用很准确使用 SDK的功能，结合 SDK，要么是 O2O，要么是社交，

最终都是对人的行为进行预测。本来是发的一二三等奖，但是大家提交的程序，没有办法评

出谁是最好的，所以评出来这三个奖项。

TalkingData 希望提供更多像场景感知 SDK 这样的功能，更好的帮助开发者实现它的业

务，我们提供的只是工具，至于怎么使用，结合开发者自身的应用程序，为你的用户提供更

好的服务。希望应用开发者接下来给我们更多的反馈，告诉我们，你们更需要什么，当你不

想在一个应用中实现这样的功能，觉得不是一个应用程序应该干的事情，应该由第三方提供

更专业的支持，希望大家到我们公司做深入的交流。

谢谢大家。

主持人：

谢谢卢健，卢健负责我们公司整个 SDK的研发，SDK说起来简单，但是技术含量非常高，

如何做到一个轻、小、稳定，很多技术在里面。如果大家有兴趣了解如何开发一个 SDK，可

以随时找卢健，这么有颜值的设计师去做技术。

我们公司从成立到现在说有 18亿设备数据，这些数据能产生什么的价值。我们有一个非

常牛的数据科学家，张夏天，他加入我们之前曾在 IBM中国研究院，腾讯数据平台部，华为

诺亚方舟实验室任职。他是我见过的数学科学家施展能力最强的，在我心目中科学家是不食

烟火的，夏天直接上来就写 Code，基本上几分钟就完事了，我们心目中跟 SDK完全并列神存

在的人。他的演讲将聚焦于基于大数据的人群定向实践，从 18亿设备中去发现相似之处。有

请张夏天先生！

张夏天：

文峰给我的演讲取了一个很炫的名字，但是我换成简单了，因为不想写那么长。

大家看题目，就知道和广告相关的最近计算广告专家刘鹏写了个《广告技术公司十大装

逼姿势》的系列文章，我今天讲的这些就撞在他的枪口上了。 但是我首先还是要声明一下，

TalkingData 是大数据公司，不是广告技术公司。我们在广告生态里面有两个角色，一是我

们推出了 Ad Tracking产品，在广告主，广告网络和媒体之间裁判者；二是作为数据提供者，

我们收集了 18亿设备数据，我们希望把数据能力开放出来，提高广告投放的效率，提高整体

广告投放的 ROI。我们不会做具体的投放。我们之前做了很多的工作，做人群标签的 DMP，很

多类似的事情。但是我们实践中也发现很多的合作伙伴或者客户需要 Lookalike 的支持，我

们在这方面做了一些探索。

什么是 Lookalike，对广告行业熟悉的应知道，一个广告主如果想扩大客户群，可以基

于现有的客户，然后通过数据分析，找到这一批现有客户最类似的客户，转化为一个潜在的

客户，再想各种各样的办法转化，这样可以提高转化的效率，这也是受众定向技术之一，只

是不同于以往简单的规则，就是要男的，还是女性的，还是 18岁，这是一种简单的规则，这

种规则也是有效果的，但是基于主观判断会出现一些问题。

我之前听过一个小故事，真假我没考证。腾讯最开始上朋友圈广告的时候，上了一个宝

马的广告。张小龙发现这个广告没有推送给他，他就问为什么他没有被标记为宝马的受众群

体。后来一查发现，因为人群定向的时候，年龄要求是 35岁以下。所以基于规则的定向，不

一定是最理想的。到底谁是你的潜在用户?Lookalike 提供了一种通过数据挖掘的方式来回答

这个问题。怎么来做 Lookalike？做任何事情，我都是倾向于先从简单的方法来入手，不会

一上来就用 Deep Learning 这样的大杀器。最简单的想法是，用一组种子用户，他可能是你

的客户，也可以是某一次广告投放转化的客户， 我们把计算出一个“平均种子客户”。然后

在候选受众里面选择跟这个“平均用户”最相似的一群人。这个方法和思想应该是非常简单

的最近邻法。后面我们发现我们数据的情况，并不能很好的支持这种方法，我们后面会提到。

我们的 Lookalike 场景有两种，首先基于用户的也就是基于设备的，我们会拿到合作伙

伴或者客户给我们的一批设备号。他们希望我们从 18亿设备池子里面找出一批相似的设备。

另外我们碰到很多推广的朋友都是做 APP推广。他们希望知道到底哪些 APP和他的 APP关系

很紧密， 需要做 APP Lookalike。这有两个意义，一是知道用户群体是什么样的，使用你的

应用以外，还会使用其他的应用。二是应用里面本身有一些媒体，我们找出了跟你的 APP关

系更紧密的媒体。如果去投放，效果更好。

我们接下来看一下 TalkingData有哪些数据，这是 TalkingData目前直接收集到的数据。

第一部分是 Device Information，这是手机硬件信息和手机操作系统信息。这个信息只要装

了 SDK的设备，都是可以拿得到。从我们经验来讲，这部分数据对人群兴趣爱好区分度差一

点，相对是一个弱信息。比较重要的是第二部分 APP Information，也就是一个设备安装和

使用哪些应用的信息，这个信息反映用户兴趣爱好非常强的信息。第三部分是 Location

Information，包括了室外的 GPS定位数据和室内的 WIFI定位数据。今天讲的内容主要是面

向 App推广的 Lookalike, 所以仅使用第二部分数据。

简单介绍一下我们数据的特征，APP 安装和使用的数据是服从长尾分布的，而且是头部

非常重的长尾分布。这两个图是我 TalkingData官网的移动观象台的应用排行中截取的。可

以看到安装覆盖率，Top1的微信超过 80%，是最高的，到了 100的应用就已经掉到 4%以下，

100 名以后的覆盖率更加低。这还是安装覆盖率，使用率的长尾分布头部更重。因为越是前

面的应用使用频率在后台驻留的时间越长，使用率的自然更高。如果我们计算平均值，会出

现什么问题呢？我算这个人群最常使用的应用，会出现什么情况？招商银行 APP 和京东 APP

用户，最常使用的 TOP10应用都是一样的, 都是微信，手 Q，电话这些。，排名有些差别，但

使用频率也就差几个百分点。这种情况下，这样算出来的平均种子用户根本没有办法体现一

个群体的特征。， 我们还有一个办法，用来突出这个群体内使用率相对较高的应用，就是

提升值的方法。我们用一个应用在这个群体里的使用概率除以整体人群中的使用概率，就得

到了提升值。然而提升值排在 TOP的应用都是一些非常小众的应用， 在整体人群上只有 1，

2 次使用。这是因为这些小众应用恰好随机出现这样一个人群里面，就被凸显出来了。实际

上这样的提升值值没有意义。当然，在这两个极端里面可以用参数、公式调整，用各种方法

做一些平衡。但以我们的经验来看很难调整到一个理想的状态。

因为数据分布的情况促使我们不可能直接用非常简单直接的方法去做这个事情。我们就

考虑使用 Supervised Learning的方法，学出一个群体的特征应用，排除掉流行度很大的应

用和随机出现的小众应用的影响。我们想到两个场景，一是 Device Lookalike。我们把 APP

作为特征，如果一个设备安装或者使用个一个 APP, 那么这个 APP代表的维度的值就为 1， 否

则就是 0。我们把种子设备作为正样本，其他设备作为负样本。我们训练一个分类模型，这

个模型可以给所有设备打一个分，打分以后排序，挑出分值比较高的那些设备，作为相似也

就是 Lookalike 设备。再来看 APP Lookalike，其实思想是一样的，我们把使用过或者安装

过这个 APP作为正样本，其他作为负样本，训练一个模型，这个模型本身就是每个 APP和目

标 APP相关程度和紧密程度的系数值，我们找出那些分数比较高的 APP出来就可以做相似也

就是 Lookalike 的 APP。这个方法还是很简单的，思想也不复杂。但是这里面要做好这个事

情有很多挑战。

我们已经把 Lookalike 的问题它转变为一个经典的机器学习学习问题。基于数据的情况，

存在四大挑战。首先我们的数据级别是 Billion级别的，数量非常大，这是一个大规模的问

题。其次，我们把每个 APP 作为一个 Feature，而我们收录到 APP 是超过 300 万左右。这就

意味着 APP的特征空间也是超过 300万的。再者，虽然 APP很多，但是每个人安装使用的应

用就是十几个、几十个，不可能用几万个，几十万个。因此这个数据又是一个非常稀疏的数

据。最后还有一个重大的挑战就是 Class Imbalance。通常我们拿到的种子设备，也就是正

样本的数量也就是几千到几十万，而我们的负样本是 billion级别的。在正负样本比例如此

悬殊的情况下要做好学习也是一个很大的挑战。为了解决这些问题，我们做了一系列的工作，

首先要做机器学习，要选择计算平台，我们最终选择了 Spark作为机器学习的平台，为什么

选择 Spark，两个原因，一是 Spark速度效率特别高，它和 Hadoop比能快一到两个数量级；

二是 Scala 语言更适合处理数据，能够提高编成开发效率。从算法选择上，我们选择了

Logistic Regression。LR也是在工业界用得很多的算法，主要是因为它的形式上比较简单，

可解释性相对较强。另外相比于其他的 SVM等其他的分类算法，计算开销是相对较小的。Spark

的 MLLIB包里面本身就有 LR的实现，但我们经过测试，发现它的效率还是达不到我们的要求，

主要是因为需要迭代的次数较多，而且对 Class Imblance 的问题处理不好。因此我们对 LR

做了很多优化工作，实现了自己的 LR算法。这个算法，数据只要过一遍，因此使得我们这么

大规模的问题里面，机器资源相对有限的情况下，10 分钟以内完成这样一个训练过程。同时

对前面几个问题，稀疏问题，高维度问题和 Class Imblance问题都不敏感。 虽然我们把时

间做到 10分钟之内解决这么大的一个问题，但是仍然不满足，因为我们有时候碰到要做几百

甚至几千个的 Lookalike任务的情况。虽然每个都可以 10分钟完成，但是五百个，一千个，

消耗的时间仍然是非常可观的。我们就想，是不是还有进一步提高效率的办法。我们发现，

我们做 Lookalike的时候，不管是哪个种子，哪个不同的应用，我们实际上都是在同一个数

据上做计算。我们每次单独跑一个任务，就需要重新读一遍数据。，因此我们就做了一个 Batch

LR的算法，这个和单任务的算法是一致的，我们把几百个任务合在一起，数据过一遍就可以

了。我们现在做 500 个 Lookalike 任务，50 多分钟就能完成，平均一分钟可以训练 8，9 个

任务，一个任务平均不到 10秒钟。

下面举一些例子，讲一下我们做出来的 Lookalike 结果是什么样的。今天上午首席架构

师批评我做出来的结果老是拿一些大家看不懂的指标，所以后面的例子一个数字都没有了，

就看图说话。

招商银行和平安银行也是我们的老客户了，他们两个手机客户端做出来的 Lookalike结

果是什么。招行的用户除了使用招行的 APP，还使用很多不同家银行的 APP，而且也可以看到，

招行用户使用脉脉名片全能王,是商务人士的可能性比较高。招行的用户还喜欢使用航旅纵横

和酒店类的 APP, 可能出差也比较多。平安银行情况比较不同，平安用户首先客户忠诚度高

一些，基本上理财、金融类都使用平安，不会使用其他的。从出行跟招行的不同，比较喜欢

坐高铁（使用高铁管家）。这是两个银行案例的结果。

淘宝和京东，最大的 C2C 和 B2C电商平台。显然淘宝用户对折扣感兴趣，对价格敏感性

更强，，而且女性倾向比较强。京东的用户更喜欢使用 B2C的平台，还喜欢看中关村在线，明

显是 3C类有需求和很关注的人群。明显看到淘宝和京东客户群在手机端还是有很大的区别。

出行类的，滴滴打车和优步，这里面看不出太多的规律，用户偏好相对比较接近，可能

只是在地域上略微有差别。滴滴打车在北方比较强势，优步的用户使用杭州、深圳、广州等

地方应用比较多。

我们再看两个游戏的例子，全民反恐、花千骨，全民反恐的用户男性玩家属性更重，喜

欢玩战斗类的游戏比较多，而且使用比较重度的游戏玩家才用的应用。花千骨用户群相对男

性化倾向没有那么强，卡哇伊的比较多，休闲类也比较多。说明这两个用户群是不同的。

我们看完 APP，再看一个不同地理位位置的人群 Lookalike结果对比。

北京 CBD人群，他们 Lookalike Apps出现脉脉、职场应用和差旅的这类应用较多，整体

来看人群比较高端，但是再高端还是上班免不了挤公交和地铁（公交，地铁类应用）。清华大

学那边有自己比较明显的特点，，这里面可以看到高校学生比较关心的，上知乎，喜欢背单词，

还有运动类的。

讲完 Lookalike之后，看最后一个例子，这个例子和前面有很大的不同，这是某个广告

主投放的汽车广告。做这个 Lookalike 之前，我相信大家看到前面的结果肯定会想象

Lookalike Apps应该是这样的，都是汽车相关的 App，这样才正常。但是出来的结果让我们

比较吃惊，为了这个结果还检查很多遍，是不是程序上出了问题。什么结果？实际是这样一

种结果，不知道大家知不知道像易赚，马上赚钱，省钱助手，点点冲，是干什么的。这类应

用都是做任务点广告赚话费的应用。实际从这个投放结果看，都投到刷量的应用上面去了。

基于这个结果，我们也在想，Lookalike 这个方法是否也能用在防欺诈上面。我们应该有办

法 目前我们用到的数据是 App Information，覆盖的设备大约为 1个 Billion。我们

下一步就要引入 Device Information，虽然是比较弱的信息，但是比较广，我们能把覆盖量

扩充到 1.8Billion。我们还会把 Location 方面的信息加进来，你平常在什么地方工作，喜

欢在什么地方买衣服，这对我们 Lookalike都有很大的帮助。我们目前最多的是 APP推广，

我们整个移动端广告不限于 APP 推广，还有房产、汽车、金融的广告都可以尝试。仅仅 APP

Information 相对弱，我们把其他信息加入以后有更多的帮助，可以做的更广一些。线上线

下结合，不只是能把人找出来，还把找人的条件选出来. 。这就是我们未来 Lookalike想做

的一些事情。

我今天讲的内容就是这样，谢谢大家。

主持人：

谢谢夏天。夏天讲的非常精彩。做数据的时候，大家用数据针对行为找人很有意思。数

据就是为人亿憔悴，终不悔（音）的工作。

刚才夏天讲的是我们公司在大数据算法方面的一些经验、一些实践，真正大数据中心都

在硅谷，接下来是硅谷方面专家演讲。

第一个演讲的专家是王俊，硅谷社交网络数据科学家，拥有十多年的大数据分析从业经

验，主要方向是大数据在广告营销方向上的应用。曾在汇丰银行和谷歌带领数据分析师团队。

2012年加盟互联网金融创业公司 Freemonee任产品和分析总监。

演讲将会基于王俊的多年经验，探讨开发一款大数据产品的经验，这个经验价值 5千万

美金，大家千万坐好了。有请王俊先生！

王俊：

刚才说五千万这个事儿，其实这五千万更多应该是教训，我先剧透，我前头创业的公司

最后的结果还是以关门大吉的结果。我后面说的就是怎么把一个大数据的产品进行产品化过

程中的思考，关于商业模式的想法，会在后半段篇幅更多一些。

我在硅谷好几年了，在汇丰银行做了几年，后来 Google想做一个支付钱包，我就去了，

也在 Google做了广告相关的东西，做的很复杂，主要是大数据或者大数据的技术，由数据带

来的做产品的新道。11年我加入了一个创业公司，这也是今天故事的主题，在那个公司失败

而告终，我现在在 Twitter 做广告相关的东西。我们和夏天刚才讲的事情殊途同归，有很多

相似的地方，有很多技术跨行业交流对我来说也是一个很好的学习过程。

我现在也做一些小的 Startup，以我的经验教训帮助中期和早期的公司避免我们走过的

一些弯路，少烧一点钱，教训也算值了。这可能也是希望我能够帮助大家的一个方向。我前

面做了一个一家公司被收购了，对我而言也是很有收获的一件事。

Startup融了三轮融资，第一轮就 500万，第二轮就 1000万，一共三千万，除了结局不

是很美满，但是过程还是很近人意的。我们主要的卖点和技术创新的地方就是我们可以做到

消费行为预测，我们通过发放精准营销的促销广告，帮助五百强排名靠前的企业做，获得目

标和客户群体。

数据方面，我们以过亿的估值拿到这么多钱的原因，就是我们解决了数据来源。美国前

八大银行六家，我们都拿到他们的数据分享协议。我们流量太大，花费不是太大，这样一个

共赢的模式快速能拿到一些商业合作伙伴，大家一起做这个事儿。我们和银行间的合作，主

要是把他们的信用卡和借记卡的数据传给我们，基本上每一笔数据，每刷一次卡，在哪里，

多少钱，什么时候，消费地点，这些信息都是通过银行分享给我们。我们集成了很多家银行，

跟 TalkingData做的很相似，我们是金融数据，他们是 App数据。

我们很注重隐私，美国这方面管理也特别严格一些。所以我们绝大部分数据都是我们不

知道是谁，我们知道是这张卡产生的相关交易，但是我们并不知道银行的信息，你的姓名，

信用卡信息等等。我们唯一知道就是你张卡发生的交易。这些数据是别人不会有的。我们也

花了很多的精力，去拿到能买到的数据。我们的目标是五百强企业，他们网站都有地址，每

家门店的地址和联系电话，门店号，麦当劳 802号在密西根哪些地方，我们把这些数据拿过

来对我们很有帮助。

想想如果你得到这样的数据会那来干什么？我在这家公司做产品和数据，做的比较杂，

我拿到这些数据干什么。这在中早期的公司也是很重要的一件事。我当时想到两件事情比较

感兴趣，首先是对冲基金，美国前八家银行有六家银行消费数据都在这儿。我们基本上可以

预测美国 GDP 增速，我们能够看到美国消费额除了买房之外的 70%，这还是消费卡的数据，

基本上能够看到整个经济的增速。在这个大框架下，我们可以做到每家公司比如说麦当劳去

年一共刷卡消费多少，今天刷卡消费多少，能够在金融市场有所作为，但是法律法规各方面

的规律这事儿不能做，至少不能以公司的形式能做，如果各位在国内有这样的机会，我会很

鼓励你们做这条路。我们拥有很多作业公司看不到的数据，但是跟你的目标消费用户特别是

相关的数据，是客户看不到的数据，这也是很有价值的。后来我们做了一个能够让销售把门

敲门的方式，是一种以促销为主的市场推广模式。

我们一句话总结，帮助线上线下的商家做超级惊人的营销，找到对他们的产品最感兴趣

的客户。营销的优惠券十天之内过期的，你十天之内到我酒店某个地方花钱，花了多少，多

少钱是白送一样的，有买一百送一百，我们跟团购的竞争对手相比最大的优势，团购是撒网，

我们是精准的，我们有海量数据支持的精准营销。

从消费者的角度来说，消费者使用的经历就是你每天到各个地方刷卡，吃饭用它，加油

也用它，我发现你可能是某一个客户的目标用户，你会收到一个消息，这个消息取决于你的

使用，有的时候会是邮件，你愿意接受促销的电子邮件的话，也可以在网上登录网上银行，

我们跟银行是合作伙伴，登录网上银行查看你这个月花了多少，收入多少，会有一个广告一

样的东西，有两百免费赠十，手机上也有 App，如果是线下来不及用，也不浪费，当你的手

机走过一家星巴克的时候，突然弹出一个消息出来，效果也非常好，当然有技术挑战在里面，

这也是我们尝试过的东西。

在美国比较传统的团购形式，我们促销广告基本上非常确定的说根据我们的预测，你很

快到我们那儿消费，再给你一个额外的小刺激。我们做销售的时候，跟很多五百强的企业合

作，类似团购公司最大的主力就是需要跟所有柜员也好，销售也好，让客户扫一下，减十块，

我们是完全透明的，要跟商家说你刷完了之后，我们在后端可以查到，你是我们目标消费，

你消费一百，我们自动送十块，这是全部透明的，可以做到的。这也是我们很快拿到 Sales

的方式。

从数据的角度来讲，我们核心的数据是来源于银行，把那块数据拿进来，还有各个地方

的第三方数据，主要就是刻划商家和客户是什么样的。有很多的区别，线上和线下，我刚才

提到线下门店，如果你在线上，有一些目标客户买一单，看看那一单在自己的信用卡上显示

是什么样子，回到他的网站上看看有没有蛛丝马迹，把这些做得更好一些。我们这个做的是

三四年前，是稍微传统的，基于 LBS 的一个 Startup，把比较原始的数据做到一个比较能够

放到数据库里面的量级。在公司管理角度来讲，如果你有一个很能用的数据基础，放在那儿

不管是分析数据，还是什么，开发成本会降低很多，可以把这些放到你的模型上面。

数据处理很重要就是地理信息数据，你的 Location 经纬度，你的客户经纬度，如果我们

真的是银行，知道你的帐单和位置，客户的内容就是消费者的位置不知道，我们有两步方法，

第一步尽量把精确把刷卡数据覆盖到门店，每个门店有经纬度，这是比较繁琐的事儿。你把

门店经纬度拿下之后，第二步就可以把每个消费者线下消费点的经纬度 全部画下来，然后

在上面选择什么样的算法去算折扣，分成州的级别、省的级别，预测他大概什么时候去消费，

怎么把他精确定位到每笔交易都是在哪个店发生的。还有那个消费是哪一个行业内的，吃饭

也好，银行 ATM取款机费用也是在帐单上，还有各种各样的会员卡，衣服类的，小孩类的，

这种分类也是没有一个明确的，都是摸索的过程，把一些现有的分类的东西拿过来，每个店

去看一下。这个给我们 Sales很多有帮助的机会，我们可以把一家店分到不同门类，看到不

同门类的竞争对手和合作。还有所谓打电话，这些都是数据处理的部分。这是一个排除在应

用电话买东西时代的客户，你发现那个信息本身给你带来很多预测时候不同的方式很难做到

的一些沟通成本。

还有银行法律管制的问题，这也是我们为什么做对冲基金的原因，银行给这些数据有很

多限制，有些事儿可以做，有些事儿不可以做，他们不会给你帐单地址。我们可以预测到，

但是经费很高的，我们也有很多限制，银行允许你做，不允许做，这也是中美之间的差异。

我们是媒体，消息是可以拿到的，但是我们并不需要知道每一笔精确到分的消费模式，

所以预测的时候，把数据量降低一到两个数据量级，可能对我们整个运营会有比较大的帮助，

我们也花了一些时间在衡量，到底在什么水平上拿到数据。

这是一个 Mdel，跟夏天讲的很像。我们会把所有消费者拿出来，所有的商家拿出来，消

费者是千万到亿级，商家就是百万级。协同过滤就是每个用户在商家消费的时候，你也可以

看得出来，他会展现出他的消费模式。我们希望能够预测 M号消费者在 3号商家有多大的可

能性去做这样一个交易的概率，在概念上是一个两层的挖掘，我需要看到什么样的人在这样

的商家里面购买，这种情况下 M号消费者应该在 2号商家做，所有打勾的人都有可能，那些

人在 3号商家里面消费意愿有多强烈，公式写出来，大概就是 2号和 3号在 Lookalike层面

上有很大的相似性，我们会给一个概念上稍微高的概率，这是我们先尝试的一些模型，希望

预测给定的一个消费者在商家多大的概率去买。我们发现效果不是很好。但是活儿也干了，

我们希望能够把它用起来，虽然它的预测效果不是很好，但是它给我们销售市场部门一个很

好的工具，这个工具很类似刚才夏天说的，结合我前面提到的，我们希望能够敲开客户的门，

利用这种方式敲门，我给你一个相当于免费的消息，谁在你这儿刷卡之后还在哪儿刷卡，有

可能是你的竞争对手，有可能是你的合作伙伴，这个效果也是不错的。这给我们销售团队一

个很好的指引。我们有了一个客户，跟这个类似的客户效果很好，你的效果也会很好。

如果你是一个商家，也可以看出来每个门店的情况。我们有一个小故事，如果你在麦当

劳买了东西，就会给你推送一个肯德基的促销广告。有一个客户叫汉堡王，在汉堡王里面非

快餐领域内，跟它相关度非常高的是谁，当时出现一个品牌，是做一家超大号女装的店。这

可能有一些产生 PR纠纷。如果我们当时不仔细，就会发现整天在汉堡王买东西的，就给你超

大号女装的优惠券，买一百送三十，好象是一个问题一样。后来我们发现还需要做一些事儿，

这里面的敏感度，一是女装，我们不希望把男装去掉，男女预设还是要去做，二是不是需要

黑名单，有些不给比较好。有些东西不能明说，这也是很重要的事儿。数据挖掘在实际生活

当中应用有很多很细的坑，这也是需要专家团队去做的，而不是扔出一些数据结果，很容易

有一些纠纷发生。

我们输入的变量就是你的地点，在类似的区域，你历史上消费总量，在什么样的行业内

愿意买服装，买小孩产品的，还是线上，还是加油油卡，会有各种各样的输入变量。输出主

要是你会在一个指定的店里消费的概率，这就是一个巨大的矩阵，作为每一个用户和客户都

需要多大的概率去刷卡。我们每周做同样的事儿，时间也是很重要的。 每一个用户信息配

对，每个礼拜都要运行的模型。

这里面有一些需要调整的东西，我们花了很长多少把这样一个东西做更精细。我们很精

确的预测到，某一个群体在某个商家消费的概率是 2.38，我们一周之后去看这个概率，确实

是 2.38。还有你的优惠券是多大的，是一百送二十，还是多少，如果给一个小额的，他们买

的量比较小，如果一百送二十，他们买的量比较大。还有就是线上和线下，取决于我们地理

信息，几块钱的快餐店和几百块的家居店，线上和线下的差异比较大，线上下单，线下提货。

你在这个行业消费过，和没有消费过，信息也是不一样的，还有时间上的调整。我们一

定程度上预测他的生日在某一天，会有什么样的消费。如果在那个地方用了我们的优惠券，

我们怎么确认把这个钱打到他的帐号上面去，这也需要在操作过程中做一些调整，也需要做

一个模型，使用我们这个模型，没有任何刺激的消费行为，有刺激之后的消费行为进行统计。

如果你能够预测到他们消费的概率，花多少。看他们历史消费，你的历史消费记录，如

果这家店消费过，以前消费记录是怎样的，如果没有在这家店消费过，在其他高端餐厅消费

过，消费模式是怎样的，给我们一个排序的参考，我们需要一个百分比。我们能够看到在本

商家、本行业内的消费，你的排名大约是多少，用那个作为一个参考，如果是排名比较高的，

我们预测的时候会把你作为一个 Macth放在客户那边去。

比较有意思的是我们把所有的预测做好之后，需要做一个全网络的优化，我们毕竟有一

百多家客户、上千万、接近上亿的用户，我们每个人每个礼拜只会花一个优惠券，这是很经

典的一个教课书上优化大规模规划或者二次优化的问题。这其实就是第二次规划的问题。这

个问题的设计就是所谓促销的概念，用户的反馈度非常高，我们也需要从 Sales 角度跟商家

谈，他能够接受怎样的损失，销售里面有多少利润，假设我们预测非常准确的，我们可以计

算出来，在一个预测消费额度和消费频率的综合平衡基础之上，什么样的人是不能发优惠券，

发了就亏了。

我们主要注重的是两件事，一是赚多少钱，二是多少人使用这个券，这是让合作伙伴开

心的，他希望能够给银行客户的服务机制更加有关联度。这是一个公式，基本上我们有一个

预测，能赚多少钱，花多少钱，给什么样的折扣，差价就是花完了之后，就是商家能赚到的

钱，还有盈利，还有多少人使用优惠券，剩下就是商家能赚到的钱。我们预测这样一个优惠

券发出去之后，有多少人会使用。

这是比较有意思的目标优化，我们一方面想要能够赚那么多的钱，另一方面也希望我们

Response rate 不会太低。目标函数是怎样的，你的目标函数有可能是两个函数加权平均的

过程，有可能你的限制是你不希望赚的钱低于多少程度。我们最后用了一个行业标杆企业的

公式做了一个模型，试图做比较好的目标函数优化的过程。

当我们把优化模型建立完了之后，遇到了一个挑战，就是花很长的时间才弄下来，并且

半天一天算，这也罢了，我们经常遇到一件事，在优化模型的时候，有可能大家比较希望赚

很多的钱，就是目标函数和现实函数之间平衡，我们做运营的那几个人先算，算完了之后过

几天发现无解，又调整指数，挺费事。我们先把线上函数空间算出来，那个东西一般可以算

出来，确认有解之后再找结果，效果更好一些。

当然我们把这个事儿做完了，我们有一个预测的模型，有多少人用了这些优惠券，我们

会发现把这些数据拿进来需要重新改。我们模型一开始的时候并没有用户使用的过程，在我

们不断积累用户使用数据过程，也是不断改造我们自己的过程，这也是一个非常感性的过程。

最终是 2点几概率，然后给他一些优惠券，会提到多少，然后把这些数据比较快的放进去。

我这边主要的经验就是在你设计预算模型或者数据处理，能够包容计划好，没有计划好

的一些额外的东西，需要有一些宽容度。最终结果是纯粹数据产品有一个非常精确的，能够

预测消费者的消费行为，不光是他在正常情况下没有外部因素影响下，消费概率、消费花多

少钱，还能知道给他一个什么样的促销广告，促销信息得到之后，对他的消费信息有什么样

的改变，这块已经解决掉了，我们当时很开心，然后发现不赚钱。

我们在中间有一行作为我们很重要的手段，让他们愿意用我们的优惠券，愿意购买我们

的产品。每一块都可能出错，每一块出错了之后，你从工程逻辑上进行一些改良工作，我一

个个再过一下。

银行最大的挑战就是银行自己有很多法律法规规定什么能做，什么不能做，这是一个很

难逾越的沟。举例，我们是若干家银行，我们希望知道你是 A银行的一个会员卡，同时也是

B 银行的一个会员卡，这个东西能够链接起来，其实很简单，因为大家有一个身份证号，但

是银行不可能给我们的，我们把这个东西加密一下之后进行沟通，这个过程经常一谈谈几个

月，而银行大部分情况以不出错为他们主要目的的，而不是以多收一些钱为他们主要目的，

他们速度也很慢。如果产品有合作，把他们下个礼拜消费数据拿过来，或者实时的管道，给

用户发卡之后，你收到一个优惠券，这个过程也是非常慢，数据分享的过程也是一个挑战。

另外一个挑战，就是银行大部分情况下只愿意给我们几月几号在什么地方花了多少钱，

有时候他们有，有时候他们也不知道购买了什么东西。其实购买什么东西的信息量特别大，

尤其是在美国垂直商家非常多，对他们来说没有太大的影响，其实这是一个很好的事儿。但

是在现有信用卡和借记卡比较多的框架下也是很好解决的问题，只是速度非常慢。

再就是银行之间的竞争，美国汇通银行就想签一个排他协议，我们也不希望有排他性协

议，要不然我们就成为一个银行的独资子公司的感觉了，他们银行自己做了一个东西，挺烂

了，但是宣传已经有了这样的产品。

公司的挑战，美国法律规定任何一家卖烟酒的公司要有证，这个东西不允许打折，给你

发了一个水果超市的券，严格意义上法律规定不允许的，这个事情发生概率很低，也不是很

重要的事儿，但是银行还是以不出错为主要的思维方式，也会导致我们销售时间非常长，风

险和收益比起来是微乎其微的，我们在产品开发上会把这些东西跳过，烟柜台的 Pos机也给

我们产品开发产生一些额外的负担。

银行不给我们用户买了什么的信息，商家说需要把清仓的东西卖掉，另外一些东西不想

打折扣。这是一个双刃剑，收银员本身不知道你优惠券存在，你刷银行卡，我们在背后绕过

去，把优惠给你，客户理论上可以有两个优惠券，一张能看到，一张看不到，有很多商家提

出这个问题。我们其实可以识别这样的用户，把这些用户作为我们销售过程当中一个重点之

一。

这毕竟是一个新生事物，跟这些银行经常一谈谈几个月才有进展。

用户，我们要让用户有这样的东西存在，刷卡之后可以直接得到一些折扣，你有多少钱

可以买想买的东西。如果在游戏界，大客户是各大商家争夺的重点，我们需要能够尽量好的

优化，让一些有钱去消费的用户得到对他来说相关的、愿意去买的产品。如果他买了这个，

发现这个钱没有到帐，我们作为初创企业，在客服方面怎么让客户满意。我们有两层客服，

一是银行，二是我们自己的。这些用户会不会有一些人纯粹为消费而消费，我们可不可以区

分清楚，我预测出错了，但是并没有把这些人当做单独的用户来做，这也是我们需要解决的

一个问题。

这是最后总结的一些思考，我认为我们从技术上、开发上、数据挖掘上做了世界一流的

预测和数据管理的过程，都是非常好的。理想遇到现实的时候，我们很快做了改进，把这个

事儿做完。但是在商业模式上的一些东西不是我们能够控制的，是我们希望影响的。还有一

把双刃剑，就是我们设计的时候有很多隐私相关的思考，用户的性别、年龄，住在哪里，这

个反过来也成为我们能够做一些事儿的壁垒，这个看具体的环境，一开始有些东西设计的时

候不需要那么细。

我自己挺感谢的一件事，就是这个钱花了三年就烧完了，第三年作为公司级做这个事儿

不是太好，但是作为一个产品开发，这是值得思考的事情，你自己有一个预期，什么样会成

功，什么样会失败。

有一个技术是很好的，但是还是服务一个商业模式为目的，有一个好的商业模式，看到

钱进来，才能让我们继续去开发。

这是我的联系方式，Twitter就是王俊，大家可以上微博，妙手空空。

主持人：大家有问题吗？

提问：我们是否有很强的商业模式设计的能力，让这个事情可控，当时是怎样考虑的？

王俊：

商业是一个很大的话题，我们融资三千多万，大家都认为可以做这个事儿，但是出现问

题的时候，销售团队建设的时候没有考虑这是一个新的产品。我当时给他们说了一个事儿，

如果我们是一个卖车的企业，招聘一群卖车的人，我们车比宝马开的快，又便宜。我们在实

际销售领域遇到的挑战，我需要和银行交流，这个东西有四个轮子，怎么走，这是一条路，

比他自己走的快。在销售层面，我作为产品管理、分析的人去做销售，你需要知道一些细节。

这样做起来很顺畅一些。

主持人：谢谢王俊。进入第二次抽奖环节。（抽奖）

主持人：

说到数据，每个数据都是一个点，各个点连在一起就是图，下一位嘉奖就是图分析的专

家，在这方面非常有造诣的专家靳若明博士。靳若明博士，GraphSQL 的首席技术官和合作创

办人。他于 2005年获得美国俄亥俄州大学计算机科学与工程博士学位，也是肯特州立大学授

予终身教授。他是图分析和大数据分析领域的国际权威专家（在国际顶级计算机会议和期刊

上发表了近100篇技术论文）。他于2010年赢得美国国家自然科学基金会杰出青年教授奖（NSF

CAREER）。

有请靳若明博士，为大家带来基于图分析数据技术的实时客户智能的研究和讨论。

靳若明：

首先了解一下，大家有多少人知道图分析概念，有多少人知道 SQL 的？有多少人实现

Hadoo和 NoSQL呢。

GraphSQL就是用数据大脑解决数据实时的问题。我今天的报告分为四个部分。

1、简单介绍我们自己发现的一个互联网公司的特性，尤其这些特性带来的就是很多互联

网企业对于实时商业智能和客户智能的需求。

2、大家听了很多大数据，这几年国内国外都非常流行的一个题目。但是大数据主要遇到

的问题和困境。

3、以图技术为核心的大数据分析。

4、实践中的一些解决方案，尤其对于客户智能。

我今天的报告很大程度比较极端，我们公司现在还处于一个 Sasmol（音），很多介绍都

是和客户讨论出来、实践出来的一些观点。

在这两年跟硅谷、北京、上海、杭州一些互联网企业交流过程中发现一个非常有意思的

问题，我们把它总结成互联网三大定律。一是对于大多数互联网公司来讲，大家做的工作是

非常类似的，我们可以认为互联网企业实际上相当于一个实时匹配引擎，这个比较好理解，

任何一个互联网企业都可能有上亿或者上十亿的客户，真正想解决的问题就是怎么帮助那些

客户完成某一方面的需求，或者是商品方面的购买需求，或者是一种其他方面的需求。实际

上我们看到所有的这些创业公司和很成功的互联网企业，他们对不同行业、不同需求类的，

不同垂直领域，完成特定实时的 Macthing，Macthing 问题是数据量特别大，百万级对上十亿

的用户 Macthing，这带来很大的挑战。为了完成这个挑战，任何一个企业要完成这个

Macthing，用机器学习也好，用数据挖掘也好，要完成智能匹配。二是怎么智能匹配呢？通

过推荐、搜索或者广告，对人群定性。你可以怎么对用户找到更合适的用户和商品，在商家

那边怎么找到所对应的客户群。三是任何互联网企业创业开始的时候都会有一个欺诈的过程，

无论对商业本身，还是用户本身都会造成很大的伤害。这三类问题就是现在互联网企业最关

心的核心问题。

大家在传统行业做过，我在学校跟很多公司谈过之后发现，无论是从小到大，还是从传

统行业到互联网行业，所有客户都关心的一个问题，是他们客户问题，你怎么能够找到客户，

当你找到客户之后，客户到你网站上，你怎么留住他，实现变现。希望你的客户在你的网站

消费，购买更多的东西。你希望留住客户，客户其实有很多的欺诈问题，你怎么有效保护你

的客户，防止你有效的客户不被欺诈。Uber前一段受到很多的损失。对于任何企业来讲，这

是不可缺少的，可能是 No1的问题。

对于企业来说，尤其是移动互联网企业来讲，用户的注意力非常有限，任何一个互联网

App 需要解决的问题，就是怎么在非常快时间内理解客户的需求，理解用户的兴趣，这能够

对用户作出一个非常好的对用户的推荐。除了实时，还要做的快，我们要需要对客户有非常

全景的描述，对用户历史数据、历史行为的，其他方面的了解，客户传统意义上的 CRM所记

录的信息，也包括对于跟这个客户肯定是类似其他用户的行为，刚才 Lookalike 就是讲这个

事儿。简单来讲，这是一个对于客户实时全景的数据分析需求。这是我们接触市场大概一年

左右总结出来的一些规律。

大家都意识到，为了解决移动互联网客户的问题，我们需要大数据。在这里面 No1因素

是什么呢？我们总结出来，大数据里面有一个非常有意思的问题，在传统数据分析利并没有

得到很好的解决，我们总结成 Global VS.Local，大数据可以收集到各种渠道的数据，我们

有非常非常多的数据，有几十亿个设备和用户使用的行为数据，都可以积累下来。这是一个

非常非常大的数据。

与此同时，对于用户需求来讲，尤其对于客户智能来讲，我们怎么能够利用这些数据对

其他企业或者对企业用户产生帮助，需要非常精准的一种分析。这种分析的能力实际上是一

种非常 Local的分析能力。当任何一个用户出现 AppS 的时候希望了解当前这个用户做什么，

周围的用户有什么类似的行为，用这些可以做最有效的推荐服务。刚才讲的所有例子，某种

意义上都是在完成这样一种运算。

总结起来有一句话，所有的数据要为每一个用户服务，同时每个用户的数据也要聚合起

来能够为其他整体用户需求做服务。但是这件事情不是很容易。

从历史上来讲，从数据库的发展来讲，大部分数据是在做 BI，BI就是商业智能，商业智

能起源于 80年代，到 90年代开始进入一个比较成熟的阶段。到七八年 Hadoop出现之后，大

量研究开发工作都研究一个问题，就是如何解决商业智能。大家讲的都是解决商业智能的问

题。

商业智能主要群体是为一个企业的决策者或者商业分析师服务的。对于企业来讲，有的

项目是亏钱，有的项目是赚钱的，某些情况下商业分析师要有这个判断能力，它使用的频率

相对是比较好的。我们刚才讲的计算，总结叫客户智能，客户智能受众群体、服务的群体不

是企业老板，而是企业真正的客户。任何一个很小的 apps客户群体可能就是几百万，每一分

钟服务的客户可能几千人。当前一刻发生的数据对用户需求有很强的反映。用户在计算过程

中需要完成的时间也有非常强的及时性。这类需求实际是客户智能 2.0对已有的数据分析技

术带来了非常大的挑战。

传统的技术，在座大家都用过关系型数据库，关系型数据库解决商业智能有非常大的局

限性，做过搜索广告的都会有这个体会。为什么关系型数据库不是一个很好解决这类问题很

好的平台。我们的数据并不是表，大多数数据是一种自然的关系型数据。关系型数据并不是

真正能够对关系产生很好描述的。

在座的同学来到这个会议室，每个人是节点，人和人的关系可以通过图的节点，位置是

中国大饭店，也可以记录下来，来到这边参加什么会议。关系型数据库并没有很自然使用这

种关系，要变成很多的表。更复杂的问题就是做数据分析的时候很多操作需要重新在图上描

述和解释、执行它。如果关系型数据库去做，会非常难写，执行效率也非常低。现在我们公

司解决的问题，也是我们存在价值所在，我们会用一些 Open-Source去解决一些问题。

里面有两个问题，如果这类平台本身不是实时的，当我们在做这件事情过程中，要使用

非常多的工具，Open-Source 每一个工具并不是为了这个事情而设计的，没有其他工具的情

况下，使用这些工具把它组合在一起。如果是这种情况，你一定会遇到很多问题，从商业角

度来讲，他们真的是实时的，如果你做一些实时的东西，用到一些额外的工具，实时的工具

和后台传统历史数据不能很好的 Macth，有很多的问题。

由于我们做客户智能分析的时候，它是非常复杂的一件事情。这种计算或者分析的复杂

的东西，我们没法很好的在这种工具上完成，其实很多解决方案不是最终的。

作为工程师来讲，我们做数据分析的过程中，基本上以 Task Cuntered为主的，我每个

开发使用不同的工具，产生不同的结果，周期也是非常多，我们 Task为主的。一二十年面向

对象过程中，我们需要所有是以数据为中心，而不是一个 Task为中心，要不然会遇到很多的

问题。

Open-Source 是一个工具，我们认为跟很多客户交流过程中，所有东西觉得拿到的是一

个免费的，你可以做很多，但是实际上带来的代价是非常巨大的。因为这个 Open-Source有

各种各样的问题。对于工程师来讲，这里面有一个问题，我是教 CS计算机学科的。我们为了

培养工程师，这些 Open-Source库往往不是我们教给学生的一些基本的东西，如果工程师能

够很好的使用这些工具，需要很长的学习和经验积累的过程，这使得我们工程师的成本非常

昂贵，越来越多的工具产生出来，他们去做这个东西，因为没有一个很好的工具完成这个任

务，所以人的经验越来越重要，工程师越来越昂贵，我们并不是说工程师昂贵不好，但是对

于一个生态系统来讲，这里面确实有问题的，这不是能够持续增长的东西。当一个工程师在

硅谷 50万美元，甚至 100万美元，对于生态系统来讲这是一个问题。

关于大数据，首先我想强调一点，大家都在说大数据，所谓数据大了就有用，实际上我

们跟很多企业交流之后，认为数据大是一方面的问题，更关键的就是数据复杂的问题，你有

各种各样的数据，怎么把各种复杂的数据结合在一起，完成有效的应用，完成数据分析，这

才是企业当前面临的最核心的问题。

数据不是一个静态的，它是动态的，这也是传统上 Hadoop是有历史原因，完成一类任务，

它的任务是完成后台数据，而不是实时数据。

大数据真正解决的问题就是非常深的，非常有聚焦力的洞察力。这种洞察力真正对客户

产生帮助，帮助他解决问题，带来便利。

为了解决这些问题，图是一个非常有效工具，大数据真正带来的创新是图分析在大数据

技术当中的应用。图的历史不用说了，图是有界限和边的。

图有什么优势呢？我稍微总结一下。图是最自然的代表数据、描述数据的方式，任何一

个东西用图，当你把数据本源用图表示出来，基本上代表所有的事实。这里面有各种例子，

但是最关键就是关系是数据最核心的价值，而这个关系描述是用图上面的节点和边描述最有

效的。

图是能够让你的数据变活，图的数据能看到的数据就是使用的数据，你不需要一个关系

型数据库非把数据变成一种格式，在另外一个格式上做处理。另一方面图可以支持快速更新，

你可以理解这个图实际上永远是动态、变化的一个东西。

对于企业来讲，这就意味着图能够支持的，无论你的数据源是什么，还是用户行为数据，

还是文本数据等等，这些都是可以有效的描述在图的表示下。

当有了图的描述之后，你可以对图进行非常有针对性的，针对个人的一种快速分析。实

际上你可以理解，当你可以很快找到图上的节点，是你想分析的目标，你可以在图上向外做

很快的扩张，能够找到它周围的信息，收集上来信息，在这个过程完成你想做的计算和想做

的分析。

我主要从高层次上有一个直接理解，我后面会有更详细的例子。

图实际上一个大数据非常重要的技术支撑点，它是最自然，最有效的数据描述的方式，

我们比较极端，所有的数据都是图数据，所有数据分析都是用图分析来完成的。图可以完成

全局数据，面向个人的数据分析，它有很大帮助在里面。

前面讲所有的都是理论，理论上这些东西都是可行的，但是实践中实际上有很多的问题，

如果学过数据库，大家知道 60 年代、70 年代最常用的数据库就是网络数据库，这是图数据

的前身。我们并不是第一家做图数据库的，但是用图做大数据，GraphSQL是第一家，也是最

独特的一家公司。

GraphSQL给客户带来的，最底层是以图为基准的，为核心的一种实时数据分析平台，我

们有一个平台可以帮助客户做数据描述、存储、计算和分析。在这之上，我们会帮助客户搭

建所谓数据大，数据非常有效的，非常有关联的，复杂数据用图的方式描述出来。这相当于

是一个企业数据大。我后面会举几个例子。

在之上，我们现在还在开发一些解决方案，或者一些平台性的，帮助用户在商业智能方

面推荐客户反欺诈方面，提供比较直接的服务，或者提供客户在我们平台上迅速完成针对应

用的开发。

这是三层比较详细的 Layer，最底层既有图的存储、计算、查询语言，还有图的管理，

还有图的可视化。这是比较完整的从底到上的结构。第二层是帮助企业完成数据大脑的构造，

我们有比较好的工具，帮助用户构建西玛，上载数据、更新数据，可以非常有效的完成。第

三层是有些产品能够帮助客户更好的完成他们对客户智能解决方案的搭建，包括推介广告类

的，以及反欺诈、反洗钱之类的应用。

我们现在的客户主要集中在互联网企业，前面我也讲了原因。这些客户分为两类，一是

电商、社交、媒体，这类客户数据量一般来说十亿级到百亿左右；二是超过千亿级的数据，

我们现在的客户比较多的是金融方面，比如说第三方支付方面，最大的客户达到将近 5000

亿节点和边的数据。

GP平台的一些参数是什么呢？GraphSQL是以图为基准的实时数据分析平台，我们可以支

持从上千亿阶段到上万亿阶段边界非常大的图的计算。现在每秒钟做到的更新是 50万左右。

同时在这么大的图上，我们查询和很多运算可以达到几十个毫秒到上百个毫秒。

从这点来说，我们分析的平台在 Breaking The Speed Barrier 是一个核心。Hadoop 都

是分钟级、小时级的运算，现在随着 GraphSQL的发展，可以支持秒级的运算。这不光是一个

简单的处理，而是在处理的时候是不是能够处理非常复杂的数据，而且数据还在动态变化。

你数据处理复杂度不是找到这个东西就完了，而是把一些数据分析在这么短的时间内完成。

我们这个平台现在已经有十多个客户，已经有上千个系统，就列举了几家，我们最大的

风控系统，节点可以达到 1500 亿节点，3000 多亿条的边，每天事件和交易量达到十亿。反

洗钱的量也是 100亿节点和边左右。

我们做了一家社交网络，它现在有一百万。我们帮这家公司做的 15亿节点和边，大部分

都是亿级的。我们可以达到 20到 50个毫秒的服务查询。

我们开发过程中，是有很多的技术和工具，细节不多说了，基本上在开发过程中，还有

平台有很多专业技术，这是一个图的存储平台，怎么对图进行压缩，怎么对图进行划分，另

外在图上我们预算是并行式的复杂运算。我们也提供开发语言。

举例，我们怎么利用图帮助企业搭建数据大脑，帮助他们实现比较复杂的应用。

国内非常有名的图片社交公司，他们去年跟我们接触的时候他们有非常好的客户，现在

已经达到 3000万客户，每天日活量有将近 300万。相信这个图，大家能理解，这个 APP，图

上的数据都是节点，这是用户和用户的关系。这个图片上还有一些标签，图片和图片之间有

关系，图片和人之间可能还有地点的关系，我们都是用一张完整的图，虽然这张图有将近 10

亿节点和 100亿条边来表述它最有效的信息。图能干什么呢？可以完成用户的推荐。我们希

望完成从用户推荐到其他的用户。我们在上面开发二十多个主要推荐的 API，这都是在图上

完成的。

我们的平台已经被多家第三方支付公司采用。我们有两类问题可以很好得用图解决，这

是支付行业最终面临的。某一个支付是不是可能是一个欺诈，这时候很多时候需要数据算出

来欺诈可行是多少，你要打一个分。当有一个交易觉得有问题，你是不是找到其他的因素，

是不是这个帐户被盗了，其他帐户受不受影响，就是类似这种分析。

在这里面，这个图的结构相对来说简单，但是实际上非常巨大，这里面任何一个用户的

帐户，用户所有所能接触电子的设备都可以联系在一起，电子标签，电话号码，邮件地址，

IP地址，所有能想到的，你在电子上能够电子化的信号都会记录下来，同时用户任何一个动

作都是一个节点。

在这里面，用图可以非常有效的解决一些我们认为非常棘手的问题，比如说我们有一个

交易发生了，T3是一个新的交易，我们怎么知道这个交易可能是有问题的交易呢，T3涉及的

设备是怎样的，这些设备和之前信息发生了什么交易，如果交易有问题，我们会算一个分数

出来的，这个交易可能有问题的分数是什么。

你们很多时候打电话，我的帐户被盗用了，帐户有问题的，他们在后台使用我们的系统。

当业务分析师认为到这个 IP地址或者交易是有问题的，他们要做什么，并不是 IP地址被封

掉就可以了，而是找到其他 IP地址或者其他帐户是不是受影响，这是非常复杂的分析逻辑。

他是通过什么样的动作涉及到这个 IP地址，涉及到什么帐户，这个帐户做了什么样的动作，

是不是最终会影响到其他哪个 IP 地址，这是非常复杂的逻辑。我相信可能 50%、60%的用户

使用某种支付就是在用这种技术保护你们。

理论上来讲，用图可以帮助解决 global/Local dilemma，它可以同时处理非常复杂的数

据，可以解决客户定点分析的问题。

现在由于跟很多客户合作，发现客户智能很多典型的问题可以有更好的数据，在客户方

面怎么推荐更好的服务。

这是我们三个产品线，构造最有效的推荐引擎，客户 360度分析，反欺诈、反洗钱。

在推荐的时候我想讲一点，大部分推荐是做 Engine 算法，第三方有很多算法，我们又往

前走了一步，我们可以记录下用户的行为，帮助用户去判断它各种推荐算法是不是有效。同

时完成一个自我学习的过程，能够帮助工程师更快做产品迭代。我们平台可以支持把各种各

样的数据集成在图的平台上，平台的解法提供最简单的支持，包括客户 360度的搜索，指定

一个用户之后可以看到它周边各种情况是怎样的，消费的情况怎么都能表述出来，还有一些

原始数据，这些都是可交互的，非常快，给用户做分类，以及之前提到的，我们的平台是可

以给用户做非常有效的支持

Anti-Fraud，通过产品开发界面描述，如果一个交易发生了，一个有问题的交易，在一

个图的环境下可以非常有效帮助客户分析原因，这是一个反洗钱可视化的表示。

我今天讲几个主要的，首先给大家介绍一个 Three Laws of Internts，在实时分析上

完成对每个客户精准分析。然后介绍一下图数据对数据分析的优势和特点，最后介绍一下

GraphSQL对客户智能帮助的解法。

GraphSQL提供世界上第一个以图为基础的实时数据分析平台，我们相信所有数据分析都

是图数据分析。公司成立在 2012年，我们也是非常专业，有很多专业人士。这是我们公司的

总部，我们还有两个分公司。

这是我们的客户。

我准备这个 PPT 的时候，我们讲的这些用电影表述更准确，X 战警里面有一个机器，查

尔斯会带着他老婆去，他可以感知到这个世界上所有的人，当他迅速感知到这个人的历史和

当时的情况，在媒体上介绍非常有意思，这个设备可以极大的提高你的感知能力，你可以理

解为提高对数据分析的能力，这个数据是这么大，当我们用大数据分析的时候，是不是能够

把大数据交给一个专业团队来解决，否则就会出现各种各样的问题。

我就讲这些。谢谢。

主持人：

感谢靳若明博士的演讲，未来设计是数据大脑的时代，未来谁都离不开数据。我认为地

理位置数据是非常有价值的，如何把地理位置数据商业化还是非常有挑战性的。

接下来演讲的嘉宾是胥森，来自美国硅谷，北京大学本科，宾州州立大学计算机科学/

地理科学硕博。曾就职于美国 GeoVista实验室, 美国 Inome公司高级数据科学家；现任美国

推特公司高级工程师，曾主管地理组精准广告投放。曾获 NGA(美国地理情报局)，NSF(美国

国家科学基金)科研基金；拥有两项高速计算服务技术专利, 2012－2015ACM SIGSPATIAL 会

议委员会成员，LBSN（基于地理信息的社交网络）workshop 组织者，多个科技期刊／书籍审

稿人。

下面有请 Alex为大家讲述地理位置数据的商业化应用创新。

胥森：

大家好，感谢主持人做了介绍，我在这个基础上稍微简单介绍一下，我叫胥森，我之前

北京大学毕业之后读了宾州州立大学地理科学硕博，这更方便地理方面的理解。因为我爱折

腾，在波士顿、纽约、三番、东西海岸住了一两年，对各地人文地理有了解，对各地地理数

据也有更深的理解。

今天时间比较晚了，所以我会挑着有意思的讲，我跟郭德纲一样，说点电视上不让播的。

我的题目是如何提前 20年事前财务自由。第一条起一个显眼的标题，把人拉过来，我们

做广告，做很多事情，都容易做的，提一个显眼的标题，不让大家打磕睡。

首先要讲的是地理位置数据的商业化应用创新。NFLKoff，只要你有流量，大家可以实时

看你的直播。我们公司今年的财报就是通过这个直播的，也算是一个创新。

这是 Twitter的一些官方数据，我们每次报告都是经过审批的，美国也是需要审批的。

这个报告是我在美国 ACM计算机协会和地理相关的地理空间专场的演讲，很多数据已经过期

了，但是也是希望大家看到的，Twitter有超过有三个百万的 August，这里面没有僵尸粉，

我们有小一百人的团队做僵尸粉激活。

一个平台活跃程度跟你上面的 Sam（音）多少是成反比的，这是维持活跃度的事情。

我们都是技术出身的，对于大数据，或者非常高流量的要求比较爽。TPS2013年每秒 14

万的数据，80%是手机上看的，40%是只看不发，这些内部一些数据，但是 TalkingData 做的

一件事情，就是把这些数据给每个开发者提供，这也是一个非常强需求的事情。

这是我今天演讲的一个概要，先讲跟地理数据相关的，其实是产品相关的，如何让用户

把自己的数据放在你的平台上，这是一个很哲学的问题，你想让用户把自己的数据分享给你，

现在就是直接要，不知道为什么要，就直接要，其实这不是很合理的。我讲两个案例，如何

做出一个用户非常理解的，你让我的地理数据，你要生日，你要性别，这些信息我愿意分享

给你，因为你给了我想要的东西。

说到地理数据，实际上是有两个部分，一是用户的数据，二是地理相关数据的基准数据，

这些数据就是百度地图、高德地图做的事情，非常繁杂。经过我过去长时间的经验，这里面

水很深，要做好非常难。今天点一下题，我们做大数据分析，里面也有不做地理数据分析，

就缺失了很大一块，相当于你的大脑只用了 5%，地理数据无处不在，就跟时间数据一样，时

空数据要分析很重要，你要分析用户数据就很重要。如果有一个很基本的数据做得很好，这

也是一个很重要的问题。

下面会讲一些关于数据的正确性，为什么会有数据正确性的问题，这是很有意思的事情，

如果我不做就不知道。每个做地理相关的程序开发者都希望世界和平，具体我待会儿解释一

下。

如何实现盈利，相信在座有很多创业者或者即将创业的人，烧掉五千万都可能失败，如

何做一个很好的商业模式，2B 的模式已经被证实了，比 2C 好做很多，而且更有价值。现在

美国有很多其他的公司也在做类似的尝试，有两个公司就是做面向企业服务的，关于软件的，

把这个作为一个平台，过去七个月增加了 10倍。我们怎么做可以让我们的项目实现可盈利。

最后我会讲一些干货，我会讲做的两个案例。

开始正题之前讲一下我最近想到的三个原则，还是属于电视不能播的内容。如果要做一

个企业或者做一个产品，有很多地理相关的产品，比如说街旁，从我过去看了这么多企业和

项目来讲，我觉得纯从一个技术上来讲，或者纯从一个地理数据分析上来讲，你想做一款产

品，非常复杂，不靠谱，很难有一个为你这个产品付费。如果你要做大数据分析，我借用我

大师兄的话，你会把很大的信息丢失掉，你会花很大的费用，地理信息很贵，你需要很多人

做这个事儿，但是它的回报很大。不管你是一个创业公司，还是上市公司，技术很重要，如

果没有一个盈利模式，这个事儿很难做长久。

接下来讲正题，如何作出让用户想使用的产品，这个产品能让用户使用起来非常酸爽，

如果你不是付费用户，你就是产品，就是被卖的，如何能把产品做得更好，如何让你的用户

把更多的信息交给你。

现在没有一款社交软件，不管国内还是国外的，能让用户把所有方面集中在一起，这也

是 Twitter新做的。一个用户可能是一个开发者，同时会有他的校内，微博、微信，如果他

是一个摄影者，会有他的作品，设计师也有他的作品，他是一个做音乐的，会有他的专辑，

这些资源没有一个地方完全整合在一起。这是我们做的一个项目，就是在用户把他的生日提

交给我们平台的时候，我们会在他生日的时候放这么一个气球，当别人点你生日的时候，别

人也会看到，别人看到的时候这就是一个雪球效应，我也挺想要的，也会把我的生日放上去。

大家觉得很有意思，很好玩，不管什么目的，会把生日放上去，达到我们的目的。广告投放

针对年龄投放是最准确的，15岁和 35岁的消费能力完全不一样。

针对地理，当允许用户 Check in的时候，比如说我在北京，如果没有这个数据，别人不

会用，有这个数据的时候，你可以 Check in，你可以看到身边的机会，身边的人，身边的人

都说了什么，发了什么样的图片，发了什么样的视频，这对用户来讲是有用的，这是一个原

则，你必须给用户提供价值，他才会给你提供价值。

Twitter这种社交网络包括 Facebook90%以上的收入都是来自广告，我们做的功能一方面

是针对终端用户，另一方面是针对给我们钱的用户，就是广告商，我们需要做什么呢？一是

做更多的区分，地理、年龄、性别，二是谁关注我，我关注了谁，我关注了一个足球明星，

就很喜欢足球。地理有很多本地化的东西，把某些地名翻译成某一个语言，我说的本地化是

这个，这是美国最大的一个广告商谬森，国内没有直接对比的竞品，它是做电视广告的，它

所拥有的数据就是这一块的数据，每一个就是一块，这一块既不是州，也不是城市，也不是

任何官方的定义，它和美国 BS、US政府部门完全没有关系，它定义的是上下班有多少人都在

这一个区域内。不知道北京上下班延展到第几环，在美国纽约会有很多人从新泽西州到纽约

上班，如果用州的定义或者城市的定义都不能把这个涵盖在一起。这是一个很同质化的东西，

我住在这个城市附近，我基本上在这附近活动，这一堆人同质化非常强，你需要做的就是找

到这种数据，这种数据对广告商非常重要。把你的数据、客户的数据和这些结合在一起，给

广告商以比较好的形式呈现。这个已经过时了，我们比这个做的功能更齐全，花消是多少，

成本是什么，做广告的名词都在里面，这个我同事王俊比我更了解一些。

我想说的是下面这些功能，你可以有多种方式来选择精准定位，精准定位的意思就是我

要定位到中国，很精准吗？我要定位在纽约市，算精准吗？如果定义到某一个小区，算精准

吗？定义到小区难度非常大，而且非常精准了。最大的广告商是可口可乐、耐克，他们不在

乎通过你这个平台多多少用户，他们市场已经饱和了，他是想通过你这个平台到达更多的用

户。你精准程度、数据精准程度直接涉及到你的市场战略。

如何处理第三方数据，这是一个非常痛苦的数据。首先是选择，你选择的数据源直接影

响到很多东西，影响到数据质量，影响到做的是什么东西。你从谬森那里做数据，就可以做

广告投放，包括电视相关的，如果从美国政府拿过来的数据，就不能做这个东西。非常难的

一个话题就是数据整合，一般会有两家数据提供商，他们人生观、世界观是不一样的，他们

对世界的定义是不一样的。待会儿我会举一个详细的例子。

Service 是指我们的程序如何把第三方数据供给广告商，供给用户，都是比较大的课题

了。

首先这是新加坡的一个地图，不知道大家对新加坡地理了解不了解，它既是一个国家，

又是一个城市，又是一个 Town，这两个是没有什么区别的，但是你定义了一个 PlaceType，

它占了两个不同的涂层，如果做广告投放，用户应该选择这个，还是选择这个，理论上这个

比较小。你要给你的数据提供商很多的提问。

这是美国的 Zipcode，这个是没有精准的，大家用邮政编码做广告投放已经有 N多年了，

沿用广告商的习惯。但是到墨西哥，这个就不一样了，墨西哥最好的数据源只能提供点数据，

你只能切，那样比较麻烦。或者你可以通过不同的技术手段解决，这些都不是非常精准的，

你从更高层面的角度需要考量，就是你到底需要不需要这个数据。

这是数据准确性的问题，我们做的不是特别好，现在也可以看到一些数据不正确的东西

在上面。比如说 Territory，乌克兰的一个区，前段时间有争端，有争端之前已经是一个国

家了。基本上所有地理数据都会遇到这样一个问题，正确不正确的问题就不提了，没人知道

该如何处理这个问题，是该写台湾中国，还是中国台湾，没人能做这个决定，这个问题一直

往上反馈，直接反馈到拉里佩齐，最后就是不显示，这是没有办法的办法，这个问题就算解

决了。做地理的人都希望世界和平，别到处打来打去，就不需要考虑这些问题。

这是我们内部逻辑上一些偏学术的阐述，或者是我们是怎么建地理数据的，首先我们要

定义，然后是清洗，这是一个非常脏的活儿，把数据整合在一起，这是我们终端用户靠内部

的服务，把第三方数据弄到我们服务里面。

这是清晰的定义，第一是分类学的东西，第二是本体论，我们需要对世界有一个定义，

地理数据很多东西就是对世界上所有的东西进行一个定义。首先什么叫 Place，有一个定义，

可能有一个或者多个名字，每个名字可能有一个或多个语言，有一堆 POI，还有很多 Pitney

Bowes，还有地理数据核心真正点线面。

我们谈到地理数据，基本上大部分和兴趣点有关，所有兴趣点并不是这个兴趣点和兴趣

点价值对你来讲完全不同，一个垃圾处理厂的兴趣点和大家都喜欢吃的饭店兴趣点，对于终

端用户的价值是不一样的。你需要在这些方面进行一些权重的考量。

这是我们做的从数据到服务，服务主要有三块，一是地理编码，地理编码的意思是从文

字到经纬度，二是法定编码，就是从数字到经纬度，这个对大家比较有价值，基本上每个不

同数据源都有侧重，很难说一个数据源提供所有的东西，这不现实，这就会面临数据整合的

问题。三是 IP，如果用户不通过 GPS，他是有 IP，你在比较宽泛的范围来讲，有的到城市，

有的到省，甚至到国家，知道他来自哪儿。

牵涉到多个数据源就会牵涉到历史数据，我们建 Twitter数据库之前也一些数据在里面，

我们花了很大精力去尝试把它清洗掉，如果地理数据之间有 Overlaps，你把这点属于哪个地

理位置定位，这也是一个比较大的难题。

这是我们一个基本的流程图，从原始数据和新的 Vnedor为数据，第一步是同步，第二是

定义到我们定义的一个世界观里面，它有它们的价值观，最后我们把两个整合在一起。

有谁知道这两个人在做什么？这是西雅图有一个名字叫橡华蝥（音），它是一种贝类，长

的比较奇怪，他们要尝这种美味，需要花很多的工夫，味道比较鲜，你需要做这种工作才能

把它挖出来，这实际上跟地理数据挺类似的，你需要做非常脏的，非常难的工作，才能尝到

比较高的回报。

我给你一个点，你告诉我它属于哪一个街道，我们要做的就是告诉我它属于哪个多媒体，

如果你做过这块，这就是一个 ON Log N，这是世界上最优的解决方案，多媒体越多，它已经

通过空间索引进行了 log，ON Log N就是最好的东西。

还有一个叫 Geohash，我把世界分成 N多块，Geohash 有很多类似的东西，它是 2008年

提出的定义，Google提出的 S2跟它类似，它是方形的，S2是六边形的。它把世界分成三块，

每次分是 32块，这是 d，dr，d5，每个层级进行细分，这个属性就是 dr，把 r去掉，它肯定

属于比它少一位的场所，这样看的更明显一些。

我们做的一个事儿就是把 Geohash先翻译成一堆数据，当用户的点引入来，它可以直接

翻译成 Geohash，我们就把这个问题进行匹配，这个就是 O1，这是 O9，我们翻译成 Geohash

之后，建立了一个树状的结构。

这是一个优化，我们后来发现，如果整个世界所有的点，所有的点都变成了 9位，这样

你的数就有九层深，最后一层都填满，这个数据是非常大，我算了一下大概是 60G，想存也

行，比较贵，有没有什么办法把它简化掉，我们想非常直接用 Twitter的客户进行翻译，左

边是英国，右边是日本，我们设了一个点，红色的格子里面走的更深，60G也可以放在内存，

但是我们缩短到 2G，这样内存非常轻松，省了很多钱，因为当你考虑你的服务峰值是 10 万

请求每秒，你需要 N多台服务器，我们地理相关的服务器大概是 30多台，两个数据中心，60G

的内存乘 300，实际乘 600，省了很多钱。

这是我的微信，如果大家有兴趣交流，我之前也算在国内联系比较多，知道现在创业比

较火，大家如果有兴趣想交流一下，欢迎线下交流。有什么问题可以提问。

提问：数据怎么能到街道？

胥森：

刚才说当你有多边形的时候，这个点是不是在这个多边形里，是非常清晰的，如果你只

有街道，街道是一个线，点在线上的概率也有，但是非常小。这个要分几步，首先要找到最

近的街道，现在街道地理编码有几种方式，一是你有线数据，线数据怎么存储呢？这一个点，

这有一个点，这是中关村大街 100号，这是中关村大街 200号，我的点在中间，弄一个垂直，

测量一下，中间就是 150号，比较靠近 1%的时候就是 101号，同时需要考虑这个街道的城市

规划，是单号还是双号，这不是特别准确，是推测出去，如果这个街道只有这样一个现状，

然后你的点在外面，有可能需要到外面去，这就更不准了，这个号就存在了，206 号可能就

不存在了。你在高德上点一个图，并不是说高德地图不好，高德地图是在国内做得更好，你

点一个点，基本上给你一个数字状，301 号到 310 号，不是特别点。二是混合的方法，同时

有街道的数据，同时还有点的数据，你知道这个点，离这个点非常近。

主持人：谢谢胥森。下面进入抽奖环节。（抽奖）

今天技术专场所有内容都结束了，欢迎大家在群里多沟通，明年我们会在群里征求大家

的意见，大家需要哪些技术专题，我们会邀请这些专家过来。谢谢大家。（结束）