“技术人员经常做的事情就是对功能进行抽象，以使代码更加整洁简单，这是天然的带有强迫症的一种行为。”TalkingData CTO肖文峰说。

在日前举办的TalkingData-T11全球移动大数据峰会上，肖文峰接受了记者的采访，全面介绍TalkingData研发团队构建高效的移动大数据处理能力的经验，包括功能模块服务化、采用Spark、去MongoDB、机器学习等。所有的技术选择，核心原则是两个词：简单、务实，为业务场景而变。

研发变革

肖文峰加入TalkingData是2014年，正好是大数据开始上升的时候，客户对数据的需求越来越强烈，对数据质量要求也越来越高，这就要求研发部能够很灵活地资源配置以应对业务需求。于是，肖文峰做的一件大事，就是产品研发思路的调整：从关注产品线，转向关注功能模块服务化。

在调整之前，研发团队按照产品线区分的，包括通用统计分析、游戏运营分析、广告监测以及数据的产品线等，配制相对独立的资源，鲜有共享。整个团队调整的目标，是从SDK、数据的收集到数据的可视化都成为服务模块，给前端的业务团队提供更灵活的业务支撑。

现在，TalkingData已经是有专门独立的数据采集、数据计算、数据存储、数据挖据、以及数据可视化的团队。与此同时，不到40人的研发团队，也扩充到了80多人。

肖文峰打算未来逐渐以这种模式组织研发资源表示。他表示，技术人员经常做的事情就是对功能进行抽象，以使代码更加整洁简单，这是天然的带有强迫症的一种行为，所以首先需要对不同产品线的公用模块进行梳理并抽象出来，比如登陆模块、数据的采集和清洗模块，未来都会做成公共的服务，做到基础服务框架中。

TalkingData的最终目标，是希望在数据的提取、加工、合规、价值评估、数据安全等环节，都能提供一个公共的框架，能够成为数据的“水库”，汇聚从各个不同的数据源流入的数据，并加工成不同质量的“水”，然后提供给不同行业不同需求的客户，改变他们的决策模式。

技术选择

TalkingData关注的是移动大数据，希望通过各种各样的数据把智能设备背后的人尽可能精细地刻画出来，为开发者创造价值。来自SDK和各种传感器的数据，具有显著的多样性和实时性，比如地理位置信息是不断变化的，这对数据处理性能和架构都有很高的要求。

那么，在当前如雨后春笋一般不断涌现的大数据技术之间如何选择？肖文峰认为，研发人员最重要的是务实，TalkingData技术团队是一个比较务实的团队，对于新技术，从来不会为了引进而引进。

务实与开放

肖文峰举了三个案例说明TalkingData技术团队的务实：

1. 最开始做分析系统的时候，采用 Hadoop 加 Hive，只有批处理，用户需要在第二天才能看到数据。后来用户有了实时分析的需求，TalkingData才增加了一个实时计算模块。
2. 计算方面，TalkingData开始都是通过Map-Reduce来实现的，处理算法逻辑效率比较低。2013年数据量急剧膨胀之后，体现出来的是处理速度非常慢，原先半个小时能完成的计算需要2个小时才能拿到结果，季度数据的计算有时候甚至一整天都出不来，于是TalkingData引入Spark计算框架（目前集群规模为上百节点），同时也改进了算法，减少迭代次数（没有采用Spark集成的MLlib，TalkingData认为它迭代次数过多，计算资源消耗之大难以接受）。
3. Kafka、bitmap计算引擎的引入，都是为了解决特定业务场景的问题。前者是因为Kestrel平行扩展能力差，多消费者支持也不是特别灵活；后者是因为需要跨很多纬度的多维数据交叉计算，以前的交叉计算效率很低。

同时支持实时计算和离线计算的架构，这和后来的Lambda很相似；而引入Spark的时候，这项技术也还不像现在这么流行。换言之，在务实的同时，TalkingData也是一个开放的团队。肖文峰介绍，他们用20%左右的时间做前沿技术的研究，也会定期去和技术社区以及硅谷的技术专家作交流和分享，确保能够充分理解新的技术，以准确判断新技术对业务的影响。

去MongoDB

“每一项技术，引入都很容易，但是一旦深度使用，就会发现各种各样的坑，这些都需要对这项技术有很深的了解才可能解决。”肖文峰解释了务实的必要性，从MongoDB到Redis，从Hadoop到Kafka，甚至是硬件，在较大的数据量级的压力下，TalkingData都遇到了各种各样的问题，需要投入资源去应对。而最近在做的，是“去MongoDB”的重构。

去MongoDB的主因是主从备份，以及一些引擎上的问题。有的引擎效率不高，无法满足需求；能满足需求的引擎，又有较大的坑，比如有时候会崩溃以至于数据无法恢复，有时候会有内存泄露。MongoDB解决这些问题的迭代速度跟不上TalkingData业务发展，所以只能通过重构来解决问题。

TalkingData数据库重构的选择是MySQL和HBase，没有采用其他的KV数据库。原因如下：

1. 肖文峰强调，一个研发团队需要根据自己最熟悉最有把握的技术方向来解决现有的问题，否则一定会遇到新的坑，导致后面接手的人会有很多很多的问题，因为真正精通各种更大数据技术的人才还是比较稀缺的。
2. TalkingData目前还是有很多结构化的数据要处理。

根据肖文峰的介绍，TalkingData搜集数据的主要来源和构成如下：

1. 来自于TalkingData的SDK。TalkingData有三条为开发者服务的产品线，这些SDK植入到开发者APP里面（TalkingData支持超过8万款应用和 6万多的开发者），开发者在接受运营分析服务的同时，也会和TalkingData共享一些数据。这些数据包含最基本的事实数据（ground truth），包括：1.位置信息，比如GPS的信息；2.应用安装列表；3.手机的环境信息（机型、品牌等）。
2. 在线下跟第三方数据提供商交换的数据。

机器学习

TalkingData最近发布的一个SDK，是一个场景感知的SDK，把用户拿智能手机时的步态数据，比如静止、走路、跑步或驾车等，通过API的方式提供给App访问，同时也提供地理围栏的触发功能，让开发者判断用户地理位置相关的场景。

了解用户周围环境，做到场景化，能够帮助开发者应用做得更加智能，判断用户当前的状态和目的，从而很容易地触发一些有针对性的功能、服务和内容。但这需要对手机传感器进行研究，包括处理传感器数据的算法。

肖文峰表示，传感器的数据分析和处理存在很高的门槛。比如基于加速传感器去研究步态判断的算法，TalkingData尝试好几种算法，包括K均值、SVM、决策树等等，也包含综合一些算法进行投票的方法。经过了很多实验，发现这里面水很深。主要是因为智能设备的碎片化非常严重，手机传感器的元器件来自不同的厂商，良莠不齐，数据特征也有较大差别，成为巨大的坑。

数据脏其实也是TalkingData数据处理工作中面临的最大问题。TalkingData通过结合大数据和机器学习，来提高数据处理加工的效率。例如，TalkingData记录了超过两万款整理好的机型信息，数据超过百万量级，还有大量的长尾机型样本，这些样本的匹配，靠一些人工去编辑头部的机型数据，是一个很头疼的问题。但后来加入机器学习的算法，能够对原始机型数据进行一些过滤和初加工，工作量可以小很多。TalkingData目前很多数据的清洗工作，都是通过人工加上部分机器学习的方式进行的。

对于深度学习，TalkingData虽然有尝试，但还没有大量的使用。肖文峰认为，深度学习为提高精度付出的成本太高，有时候甚至会有数量级的成本增加。而分析系统对于计算的效率比较敏感，所以TalkingData在大部分时候偏向于选择一些更加简单同时迭代次数更少的算法，来在精度和算法计算效率之间做一些折中。

而对于人工智能，肖文峰表示，在基础理论没有根本性突破的前提下，基于目前的计算机科学的理论和技术，人工智能在落地上面存在一些困难。

雅虎发布Omid更新 旨在为HBase提供事务处理支持

雅虎工作人员表示希望Hadoop和HBase生态系统能够开始使用Omid。雅虎公司希望Omid跟随雅虎走出的Hadoop的轨迹并最终成为Apache的官方项目。

HBase,雅虎Omid