移动互联网的接入使得传统PC端的数据收集已经不能满足目前业务的需求，移动大数据的收集处理分析也成为所有企业不可回避的问题。相比于终端较为统一的PC年代，移动终端的多样性、流量、网络、功能等诸多因素都限制着移动大数据的收集。如何在不影响用户体验的情况下做到准确、快速的收集？51CTO
【WOT2015"互联网＋"时代大数据技术峰会】特邀讲师阿里无线事业部基础架构线主管陈武分享手淘应对每天亿万级UV的数据采集手段。
陈武：花名 苍井，阿里巴巴集团无线事业部无线事业部基础架构线技术主管。曾就职于91无线，腾讯。13年加入阿里一直从事业务开发，深知业务线对埋点的痛点之后带团队参试手淘埋点监控体系建设。
以下是采访实录：
Q:手淘是如何进行数据收集的？
陈武:目前手淘通过客户端埋点的方式采集数据。埋点方案常见的有两种：一种是页面埋点，这种一般是在架构层理已经做好了。另外一种是一些控件点击和自定事件的埋点这种通常是开发手工埋的。
Q:移动大数据收集 VS PC大数据收集的有什么差异？
陈武：首先从设备维度看，中国有7亿的手机网民，而且一直保持着高速增长，手淘的日志量也基本是每年翻一翻，在DT时代的进程中，移动设备渐渐成为了主流的数据的生产者，移动互联网巨大的流量给的服务器的连接能力和计算能力提出了极大的挑战。另外，移动设备跟贴近用户，移动数据呈现出更多的用户属性：比如用户的位置信息，用户的性别，用户的语音信息，用户的健康情况，甚至是用户的喜怒哀乐在移动端都能被数据化，可见移动数据的私密性比PC数据要高很多，用户对数据安全的考虑要求我们在移动数据安全上比PC更加严格。移动设备比PC更具有多样性，中国的手机从几百元到几千元机型性参差不齐，再加上中国特色的山寨机市场，在方案设计上就需要考虑到不同机型，耗电，内存，cpu占用等性能指标。
其次是移动互联网的网络特性，PC的数据采集流量基本是不需要考虑的，而在手机端流量成本会直接影响到用户成本，也是需要重点考虑的。PC的网络相对稳定，而移动互联网要应对频繁的强弱网络切换的场景，弱网如何保障传输也是我们要考虑的点。
再次是交互层级，移动端的交互逻辑比PC端要复杂的多。手机的屏幕本身比较小，导致它的层级很深。而手淘非常重视整个交易的链路的，链路上下文参数的透传上也是比PC端复杂很多，比如手淘的详情页面我们需要记录这些页面的流量地图，在埋点的时候就必须track这些流量的来源作为不同业务方的结算依据。
还有技术框架问题，整个移动端的框架要比Web框架要复杂很多。在Web端有一些标准的Html标签，通过spm.webx框架很容易实现自动化埋点。但在手机端的框架内并没有一个特别标准的语义,以及Reactive Native框架，webApp框架，Native和H5嵌套，C和OC，C和java的各种语言混编，双十一的各种native到H5的降级方案灵活切换都给手淘的埋点增加了很多的复杂度。
总之，如何在数据量，数据质量，性能，成功率以及实时性上做权衡，是移动数据采集面临的最难题。
Q:手淘是如何解决移动端数据采集的难点的？
陈武:首先，性能问题我们的埋点sdk会有自身监控，这些监控会记录关键代码的性能指标和到达率指标，在服务端我们按版本建立监控的基线来保证我们的sdk自身的性能是不断优化的。具体到优化的方法也是很多的：比如我们在节约流量提升下行到达率方面做了配置增量更新方案，通过聚合埋点来提升计算性能，按照事件的优先级做了不同的上传策略来保证实时性，通过动态窗口调整的算法，保证***的带宽利用。其次，在交易链路方面问题我们会通过阿里的SPM（super position model）和TPK(transparent key)标志在框架层做透传。***，混合编程问题，我们在sdk提供了C层，JS层的埋点bridge确保下游业务方可以方便的调用我们的埋点代码。
Q:如何储存收集上来的数据？
陈武:这里就涉及到了后端架构，我们在***层是adash服务器，它负责数据流的接收和解码工作，解码之后按消费的业务场景拆分到不同的数据流。第二层是阿里的TT流，TT流负责消费adash的数据。TT的另外一端连接我们的实时计算galaxy系统和离线存储的ODPS云梯系统，最终将数据落地到我们的云服务器上。负责数据产品的业务系统可以分别从galaxy上产出实时监控报表，以及从ODPS上产出离线监控报表。
Q:如何处理处理异常数据？
陈武:异常数据我们会评估处理的成本，如果是低优先级的数据，我们可能会直接丢弃，如果是高优先级的数据（比如财报数据），我们会对这些数据做一些事后的清洗。
从以往的case看，通常遇到的是重复数据和脏数据两种情况，比如重复数据的清洗，简单来说我们会认为一台手机不会在同一毫秒产生2条相同的日志，所以就按照这个算法对ODPS中有问题的小时表，按照设备ID和时间做投影对数据库做一轮去重。这种清洗通常是需要耗费很大的计算成本。
还有一种是在客户端的清洗，举个例子详情业务存在一个自定义打点，后来版本升级改动将页面名称从shop变成了sp，那么在统计PV上就会出错，这时候我们可以通过下发配置在埋点sdk里面对数据做订正，在源头上纠正错误日志。这种情况节约了很多服务端的计算成本，但是要考虑配置到达率和时效性的问题。
日常工作中我们也会通过建立一些中间表来累积清理规则，对于符合这些表里的数据，我们可以选择清理或者是保留。
Q:如何保证SDK在性能与数据量上的平衡？
陈武:首先是数据【分级】，我们会把淘宝的数据按照业务划分，性能数据、业务数据，接着对这些数据设定优先级，像UV、GMV以及实时计算数据这些都享有非常高的优先级，我们会按优先级来传数据，优先级低的数据我们可以用更低级别的线程来处理。另外就是【采样】，我们的网络性能埋点一天有上百亿的点，这些点不涉及业务结算，只是用来监控网络成功率的，我们可以通过配置控制的采样率，对样本抽样做监控即可。***可以通过【聚合】来提升性能，以计数的点为例，我们只要把一段时间内的相同点的值做累加，最终把一段时间内的多个点聚合成一个点上报，可以很好的控制了日志的埋点频率。聚合的方式提升了性能，但是如果在聚合的过程中异常退出了，就可能损失一部分数据，所以我们只是针对低优先级的点位做了聚合处理。
Q:双十一，你最担心的问题是什么？
陈武:在双十一期间流量会暴涨，今年还有大型晚会，可以预见今年一定会出现流量极端暴涨的情况。因此在容灾方面我比较担心，流量上去了会不会把服务器打爆，会不会把网卡打爆？数据量暴增的时候下游的数据产出是否会延时？我们平时会模拟大流量的情况，做全链路压测，梳理各个节点性能瓶颈，为双十一保驾护航。
Q:在灾备方面手淘是如何做的？
陈武:容灾这块需要客户端和服务端一起做，客户端灾备无外乎控制数据量和请求数，但这二者是相对矛盾的。如果把请求数降低，那么就意味着只能把用户上传log时间调大，这样的好处就是服务器的qps降低了，然而客户端堆积的日志就变大了，服务器解码也变大了，下游产出时间变长了，所以需要按照顾下游服务器的计算能力合理的权衡上传间隔和数据量。我们在双十一的时候会对客户端做多级的降级预案，会根据服务器的水位推送不同级别的配置，保证客户端高级别的数据能够全量上传，低级别的数据能够尽可能的上传。
另外在服务器端容灾，我们核心业务都是异地多活， 在故障时可以快速迁引流量，保证服务的持续可用。在业务层按业务做集群隔离，像手淘、天猫、聚划算双十一相关的业务系统单独集群，其它业务会被放到另外集群。重要的数据会存多份，采集服务器如果丢失数据，可以根据一些日志流水进行部分数据恢复。
***还有系统的测压保障，我们已经在双十一之前做过多次全链路的流量放大压测，除此之外还会有各种下游业务的降级预案。
11月深圳WOT，我们聊大数据
