作者介绍：
马扬，BBD研发平台大数据研发总监。曾就职于腾讯、微软，也曾自主创业。受聘复旦大学MSE客座讲师。技术控，原NOIPer，ACMer。擅长算法，建模、产品设计；喜欢关注新技术及发掘其在业务应用中的价值。
随着大数据行业的发展，大数据越来越多地被用到了各种行业，出现了各式各样的应用。“大数据”所处理的数据，也远非早期阶段单纯的日志采集分析这种间接服务于主营业务的方式，而是开始直接处理业务数据了。越来越多的数据类型，越来越复杂的业务场景，也对大数据应用的数据传输方式有了不一样的要求。今天我们就来探讨一下，如何在自己的大数据应用中选择合适的数据传输方式。
一个典型的大数据应用的数据流向如下图所示：
对于B流程，大都是大数据公司的核心业务，且已经有很多成熟的框架，出问题的可能不多。本文主要探讨A和C流程需要注意的问题。
1.常见的数据获取方式
常见的获取数据方式主要有以下三种：
1.1.自行爬取
也就是自己写爬虫了，简单点的直接拉下来，复杂点的还需要在客户端去模拟用户行为、构造浏览器、甚至破解验证码，但无论哪种方式，http请求是免不了的。这种情况下，一般大家对数据传输的着眼点也都在已经抓取到数据后的内部流程了，而不是从数据服务端到本地客户端这一段。
1.2.通过接口
接口可能的实现方式五花八门，但从调用方式上讲，主要就分为以下两类：
1.2.1.Pull方式（主动请求）
即客户端在需要数据时，向服务端做一次请求，从服务端的响应中获取数据。
由于客户端对服务端的数据变化无感知，一般都会采取轮询的方式，往往会造成大量的无效请求，因为轮询的频次无法做到恰好与服务端步调一致，频次太高会导致大量无效的冗余数据；频次过低会导致漏数据。有的服务在此基础上稍加改进，会单独提供一个轻量级接口供客户端判断当前是否需要请求数据，但也并不是一个根本方法。
另外，从某种意义上说，自行爬取也可以算是一种HTTP的pull方式实现，只不过没有得到数据所有方的同意罢了。
1.2.2.push方式（被动推送）
相比较pull方法来说，push的方式从逻辑上更符合自然规律一些。就好像大家都喜欢定个闹钟就不管了，没有人愿意每半小时起床看一眼几点。想想也确实是由知道变化的一方向不知道变化的一方做通知更合理，这符合信息的扩散原理，“知道变化”这一信息得到了更有效的利用。有了push方法，客户端再不用不停地向服务端请求了，只需要等着服务端判断在指定的条件满足时推送给客户端一份数据就好。
伴随着push方式出现的一个概念就是订阅，订阅是为了解决客户端如何告知服务端“我需要这份数据，请以后给我推送”以及“我不再需要这份数据了，请不要再给我推送了”，或者更高级的“以后请只给我每天最新的10条数据”这类修改订阅条件的事件。
1.3.底层访问方式
包括直接暴露内部消息队列/从库等方式，这种方式的好处是较灵活，尤其是需求经常发生变化的时候，可以由上层应用开发人员直接自由封装，自由操作数据。但与外部产生数据交互的场景（即使用方/应用开发方不是本公司同事）时应尽量避免这种方式，存在安全方面的隐患。
那么，我们应该怎么考虑数据传输的技术方案呢？
2.业务关系
首先我们要考虑的问题，就是数据的来源方式。数据的来源方式很大程度上取决于业务应用落地的方式，即在一个应用场景中，数据所有方与应用实施方（大数据公司）之间的关系。一般存在以下三种情况：
2.1.完全独立
比如，客户A要求大数据公司B为其提供舆情分析服务，舆情来源为各媒体站点，这里称数据来源公司为C。这时A跟B的合作与C是毫无关系的。我们称这种情况为“完全独立”，B想要拿到C的数据，只能通过自行爬取，或C提供的公开无差别第三方接口。即使在后者的情况下，C一般这种接口的目的都不是作为数据接口使用的，往往会对数据的获取增加种种限制，比如，只能拿到最新的条数/时间范围下的数据。同时，这类接口对于调用的频次/IP等都会有很高的限制，绕不开代理、IP池等，要想在此基础上做到目标数据获取，很大一部分工作其实跟自行实施爬虫是重叠的，也不排除开发人员在实施过程中，干脆放弃该方式走回自写爬虫的老路。
2.2.合作对接
比如，客户A要求你大数据公司B为其提供舆情分析服务，同时告诉B:“我们已经找C实施了一套数据采集方案，所有我们关注站点的新闻已经可以通过C的系统获取到了，你们只要跟C的系统对接，做好后面的流程就可以了。”这时C也会适时的丢给你一份接口文档：“我们的产品很成熟，按照这个文档对接就可以了”听起来是不是很贴心呢？这种情况的特点是，B想要拿C的数据，只能通过C给定的对接方式，我们称这种情况为“合作对接”。然而现实是，除非你跟C已经对接过，否则，这个过程至少有80%的概率不是一帆风顺的，总会在哪里出一些问题。这里最大的问题就是，C的质量是不可控的，千万不要盲目迷信大公司，笔者亲眼看过某C将一项实时性要求很高的数据接口客户端http轮询XML的方式提供出来。如果你实在无法忍受C提供的HTTP轮询的XML文档，向C提出了抗议，你得到的回答要么是“其他客户都这么用的，没什么问题啊”，要么是“我们在下一版会做这个改进”，至于下一版什么时候发布，你懂的。
当然，还有10%左右的机会，C是家很nice而且技术靠谱的小公司，他会告诉你“我们还没有数据对外的接口，你们看需要什么样的方式给出来，给我们需求，我们来开发”，那你就一边偷着乐,一边按自研的方式设计套合理的方案交给他们吧。
那么，是不是对于“合作对接”的情况，我们除了被动地按现实接口情况接受，就毫无能做的优化了呢？
也不是。
一种很经典的优化思路及常见做法即计算前置，即提前在数据进入网络流向前，在本地做一定的操作，如部分数据清洗，字段映射，做倒排重组数据，做cache合并数据等，能够将一个冗杂的XML转换为一个精简的二进制字节流再丢到公网传输至云服务器。由于第三方服务所在的服务器不一定具备可配置性，这项方法更多的呈现方式是一个前置的终端，尤其搭配在链接多种设备的网关上，能够简化非常多的业务逻辑，同时降低整体的方案成本。这个终端甚至可以是个路由器，可以是个机顶盒，尤其是最近两年intel的NUC经常扮演这个角色。
NUC甚至提供自定义贴图/激光打印的服务，让很多纠结于深圳山寨厂商贴牌服务及品牌机的高质量稳定性的公司有了新的选择。该做法似乎与云计算、SaaS等概念背道而驰，但这更说明了计算机技术对思想方法的重视，包括得到广泛认同的“反范式设计”等，重要的是如何解决问题，而非遵循某个固定的教条不变。其核心，即技术还是要为业务服务。
2.3.自食其力
比如，客户A要求你（大数据公司B）在其本地为其提供舆情分析服务，同时告诉你“听说你们公司已经有一套系统可以得到舆情结果了，只要把这个结果同步到我们服务器上就行。”这个时候，该数据的服务提供方和数据消费方都是你，我们把这种情况叫“自食其力”。其好处就是灵活，限制条件少，可以按自己思考最佳的方式设计实施；但缺点也有，一方面就是自己负责的范围扩大了直接带来的自然是工作量的增加，可能引起工时紧张或延期风险。还有需要注意的一点是不要陷入over design中不能自拔。
除了业务关系，还得考虑数据特点。包括数据的应用场景、数据的安全性、数据的实时性、数据的产生速度等。
比如，交易类数据应避免使用UDP 等不可靠协议；物联网类数据（传感器等）应优先使用mqtt/mqtt-sn协议。
那么，如果我们自己生产数据，应该使用什么样的数据出口呢？
跟数据入口一样，也得看业务关系和数据特点。
但与入口不一样的是，入口很大程度上由来源数据出口决定，没法自主选择；而出口，有一些点上，是有明显的优劣之分的，我们在设计时应该主动避免的。
比如，在数据同步/收集接口方面，应该尽量使用push而避免使用pull。
比如，在数据传输方面，XML确实没有任何可取之处，甚至完全逊色于json，更不用提protobuf、thrift、msgPack、自定义二进制流等方式。
说到protobuf，顺便提一下gRPC，是一款非常优秀的RPC框架。其底层使用HTTP2.0，大家千万不要闻HTTP色变，其性能并不比裸的TCP差多少，作为对内服务是非常好的选择。同时，也已经出现了类似grpc-gateway这样的开源项目，将内部RPC接口通过一层gateway自动映射为Restful API，同时应对多种应用场景，大大提高了工作效率。
另外，在protobuf之后，Google还于14年发布了flatbuffers，其号称专为游戏场景设计，本质上是空间换时间，在访问内容数据前不需要解析/拆包，在时空因素需要做trade off的场景可以考虑使用。
