聊聊Facebook的大规模时空数据处理技术栈

会员服务 ·

聊聊Facebook的大规模时空数据处理技术栈

2018 年 4 月 16 日 聊聊架构 宾理涵

作者｜David

嘉宾 | 宾理涵

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

以 Facebook 为例，2017 年 Facebook 已经覆盖全球 130 多个国家和地区，直逼 20 亿用户，在地理位置数据处理方面的技术（包括轨迹追踪、定向圈人、GEO 相关研究）Facebook 在全球名列前茅。

万亿级数据处理背后，Facebook 是如何设计数据库索引结构、查询优化、数仓建模等难题的，聊聊架构采访了 Facebook 的 GEO 组 Tech Lead 的宾理涵，本文根据采访整理而成。

聊聊架构：你曾在 Qualcomm（下译为高通）工作过，在你看来高通与 Facebook 的工程师文化有哪些异同？Facebook 的哪些特性吸引您加入的？参与 OpenCL 标准制定有哪些不一样的体验？

宾理涵：目前我在 Facebook 担任 GeoAPI 组的 Tech Lead，以前曾在标准制定组织 Khronos Group 任高通的代表。

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

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

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

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

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

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

第一步是 working group 内部讨论
第二步是各公司内部审核
第三步是投票，如果投票通过，那么该方案将加入下一代的 OpenCL 标准

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

聊聊架构：Facebook 大规模时空数据处理中，有哪些 quirks 问题？为什么需要解决这些问题？

宾理涵：我目前在带领团队开发 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 平台的用户越来越多，我们开始针对一个又一个的产品需求进行优化，最终演变到了现在产品的样子。

聊聊架构：时空数据相比其他类型的数据，在处理方法上是否有异同？在任职 GeoAPI Leader 期间有什么技术挑战和非技术挑战？

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

我们有两个选择，要么继续打补丁，让友组在我们的 codebase 里面继续开发，要么直接开发下一代架构，当时我们从几个方面去研究了这个问题：

第一，由于我们初期版本架构瓶颈，虽然一系列代码优化减少了内存消耗，最终（一年以后）无法满足像 Marketplace 这样高速发展的产品的需求。

第二，我们组初期成员数量和 Marketplace 这样的大型部门成员数量相差悬殊，如果不开发新系统做平台化，把 Business Logic 尽快从我们的系统剥离，是无法满足多倍于我们组人数的各个 Marketplace 产品组的需求的。

第三，平台化有利于接受更多的产品组基于地理平台做产品开发。事实证明平台化后我们的平台用户增长数量比以前大一个数量级。

虽然诸多好处，最大的问题在于新系统开发周期比旧系统打补丁时间长很多。所以我们和 Marketplace 部门合作把内存占用最高的模块 ML model 临时移到了另外一个简单的 KV index。以延时 (higher latency) 换取我们的开发时间。

考虑上述诸多因素后，我们最后直接开发新系统。新系统在 PHP 层提供了类似 SQL 的语法来替代以前类似于插件模式（客户代码和我们系统一起编译发布）。这个决定从根本上定义了清晰的架构界线，从而让两个组都可以各自高效的向前推进。

聊聊架构：关于大规模空间数据，你们是如何考虑降维或特征选取的？

宾理涵：通常空间数据只是高位数据的其中一维。怎么整合空间数据到多维数据处理是我们常遇到的问题。例如我们的图搜索引擎把多个根据 social graph 连接的文档用 inverted index 来保存，怎么把空间信息也加入到这个图中就是一个有趣的挑战。

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

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

聊聊架构：万亿级别的数据是如何进行存储和传输的？谈到开源，如何看待 Oracle 与 Google 的 Java 诉讼？

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

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

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

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

我们不便做出评论 Oracle 与 Google 的 Java 诉讼，但是这不会影响我们选择开源产品。Facebook 也会继续拥抱开源社区，把更多优秀的内部孵化的平台系统开源。

聊聊架构：技术更新迭代速度之快，你们是如何获取与工作相关的前沿技术的呢？如何看待近期的人工智能？是否有考虑引入相关的技术来解决问题？

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

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

受访嘉宾介绍

宾理涵，Facebook Software Engineer Tech Lead，毕业于美国佛罗里达大学硕士，就职于 Facebook 的 GeoAPI 组担任技术领导。

带领团队开发了 Geospatial Indexing 平台，将地理大数据和实时数据流检索导入以提供实时的查询和计算，该平台已经用于多个面向用户的产品。他还参与了 Facebook 搜索引擎中的地理查询的设计和开发。

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

除《Facebook 万亿级混合复杂时空数据的处理决策》之外，ArchSummit 深圳站还有诸多人工智能 / 区块链的前沿架构实践及培训与大家分享，例如：