在此处输入标题

未分类

大致从2004年地图应用开始流行之时，很多人并不会了解到地图会成为未来各大互联网企业尤其O2O企业必备的基础能力之一，即使是大数据技术如此成熟的今天，诸如“导航”、“附近的人”等基础功能的背后大规模时空处理并不是容易的事情。

7月6-9日，ArchSummit全球架构师峰会将在深圳举行。本次大会设置了《大数据平台架构实践》专题来解读人工智能时代下大数据新思路及前沿实践，其中邀请了Facebook Tech Lead宾理涵前来分享《Facebook万亿级混合复杂时空数据的处理决策》。

我们借此机会采访了宾理涵老师，他为我们带来Facebook时空处理的相关细节，如果读者想了解更多Facebook的大规模数据的技术栈，欢迎报名参加ArchSummit深圳站并与宾理涵老师进一步交流。

受访嘉宾介绍

宾理涵，Facebook Software Engineer Tech Lead，毕业于美国佛罗里达大学硕士，就职于Facebook的GeoAPI组担任技术领导。带领团队开发了Geospatial Indexing平台，将地理大数据和实时数据流检索导入以提供实时的查询和计算，该平台已经用于多个面向用户的产品。他还参与了Facebook搜索引擎中的地理查询的设计和开发。

此前就职于Qualcomm，任Qualcomm在标准制定组织Khronos Group的代表，参与OpenCL标准制定。

Qualcomm与Facebook

Facebook最吸引我的文化是开放：大家共享同一代码库。公司鼓励员工自由地选择内部调动，做你最感兴趣的项目。一般工作年限满一年的员工会收到内部邮件鼓励参加hackamonth，即去别的组工作一个月，期满后工程师可自行决定是否留在新的团队。

另外，Facebook的软件工程师没有等级title，所有工程师统一叫做Software Engineer，这极大地降低了对话的门槛，你可以毫无压力地和业界最顶尖的程序员交流技术问题。

至于Qualcomm（下文统一使用“高通”），它的工程师文化相对而言更像传统的计算机公司，有严格的开发流程，毕竟硬件不像软件那样可以轻易的升级换代。

我曾在标准制定组织Khronos Group任高通公司的代表，参与了OpenCL标准制定。这段经历很有意思，你面临的不是公司内部的资深员工，而是业界巨头例如Intel，Google，NVIDIA等的资深架构师。他们是这个行业最顶尖的专家，对GPU软件和硬件的发展趋势都非常的熟悉。

作为公司代表，你的任务是代表公司的利益，根据公司长期的roadmap，提出新的软件、硬件功能的proposal，并试图让别的公司的代表通过你的提案。我们每周有电话会议，每季度有面对面会议。从草案到发布周期长达一年，甚至更久。

以OpenCL举例，整个过程简单来说分三步：

• 第一步是working group内部讨论

• 第二步是各公司内部审核

• 第三步是投票，如果投票通过，那么该方案将加入下一代的OpenCL标准

除了OpenCL，著名的OpenGL及其后续版本Vulkan都是Khronos Group旗下的标准，该组织非盈利，主席由各个公司轮番担任。

Facebook大规模时空数据处理

时空数据处理问题

我目前在Facebook的GeoAPI组担任tech lead，带领团队开发Geospatial Indexing平台，该平台能将地理大数据和实时数据流检索导入以提供实时的查询和计算。

这段期间我们在处理大规模空间数据除了有在规模上的挑战以外，还有一些独特的问题，举个例子：

作为一个没有做过空间数据的人，第一个常犯的错误就是两个坐标点的距离，如果你简单地计算了欧几里得距离，那么你最后在产品中看到计算出来的点肯定是错的。同样的，相同经纬度差在赤道和两级在距离上有很大区别。

第二个是空间数据的分布问题，大城市密度比小城市密度高，这在多个层面影响你的算法。从分布式的角度，你的数据怎么分布延时最小。从数据结构设计上，怎么处理地图zoom level问题。从产品的角度，计算多少米的半径才是用户愿意去的。

最后就是工具的缺失，传统大数据分析不是为空间数据优化的，通常要JOIN两个HIVE表格会花很长的时间而且答案不一定正确。

Facebook技术栈

7月6-9日，我会在ArchSummit深圳站分享《Facebook万亿级混合复杂时空数据的处理决策》中详细介绍我们Location Infrastructure团队的技术栈，这里简单介绍概括一下。

• 数据来源于HIVE和Scribe；

• 离线查询使用Presto加上专门的spatial join的支持，在线查询通过indexer建立索引提供低延时实时查询；

• 在线系统基于Facebook的Thrift框架提供高性能高并发来实现海量查询；

• 实时流数据我们采用Facebook开发的Stylus平台。

我们大多数系统采用C++开发。算法上RTree，QuadTree用的比较多。我们使用开源的Google S2做坐标编码。我们的在线index系统经历了一系列的架构升级，从最简单的静态In-memory到现在的分布式，多存储形式，支持实时数据更新。

在整套体系的建设过程中，我们在内部技术和开源技术之间采取了折中而务实的办法。因为Facebook推崇hacker文化，我们的项目来源于hackathon，即几个程序员聚在一起hack好几天，来验证一个项目构想。

我们第一个项目的产生完全是因为一个产品组需要高性能的circle index，而现成的系统虽然功能非常强大但是对几何图形支持却非常有限。所有我们用boost rtree写了一个原始版本没想到性能居然超过了别的所有方案。

一般程序设计初期，我们先制定MVP，不会过度设计。随着我们index平台的用户越来越多，我们开始针对一个又一个的产品需求进行优化，最终演变到了现在产品的样子。

挑战

常见挑战

任职tech lead期间，遇到最大的挑战是帮助Facebook Marketplace的全球发布。当时正值我们一个版本的架构遇到了scale的瓶颈，加之产品组的Business Logic嵌入我们的代码太深导致我们不能很快的迭代，影响別组的进程。

当时我们有两个选择，要么继续打补丁，让友组在我们的codebase里面继续开发，要么直接开发下一代架构。

最后我们决定直接开发新系统。新系统在PHP层提供了类似SQL的语法来替代以前类似于插件模式，我们允许我们客户的插件代码。这个决定从根本上定义了清晰的架构界线，从而让两个组都可以各自高效的向前推进。

关于大规模空间数据如何考虑降维或特征选取，通常空间数据只是高位数据的其中一维。怎么整合空间数据到多维数据处理是我们常遇到的问题。例如我们的图搜索引擎把多个根据social graph连接的文档用inverted index来保存，怎么把空间信息也加入到这个图中就是一个有趣的挑战。

从大数据分析上，Spatial join也是我们处理高纬度数据需要解决的问题，例如多个HIVE表格要根据空间数据进行连接，怎么通过优化建立空间索引让JOIN更高效。

从ML层面上，时空数据怎么表达，怎么用现成的Caffe2 library来挖掘时空数据的价值都是我们遇到的问题。

万亿级别的数据的存储和传输

Facebook的data warehouse使用了很多开源系统，例如Hadoop，HIVE，presto，spark，有些是我们自己开发，然后开源的，有些是来自于开源社区，然后我们自己进行修改。

大部分Facebook的数据产生于我们的图数据库TAO，以及一些实时的log，TAO数据存储于MySQL，然后定期发布到HIVE，log数据通过我们自己的流平台Scribe做数据发行，下游系统例如PUMA可以做实时计算，FBETL可以将其倒入HIVE。

数据存储层Facebook有使用ORC格式对HIVE表格进行压缩优化。

传输层使用最多的是thrift系统， 该系统提供序列化和反序列化。Thrift可以很好的支持数据schema的变化。

技术前沿

我很幸运Facebook遇到的挑战都是独一无二，同事们研究的话题也是业界最前沿的。作为Location Infra，我们有跟各个组整合的机会，例如location在AR/VR中的应用，location在ML中的应用等等。

关于近期火热的人工智能技术，我们公司内部的FBLearner ML系统被高达一半的员工使用，ML已经在我们工作的方方面面了，从GBDT，到Logistic Regression到CNN，这些算法帮助Facebook的员工开发更智能的产品。时空数据和ML的整合是我们组现在正在研究的课题。