双11背后的大规模数据处理.PDFVIP

6.2 双 11背后的大规模数据处理 作者 ：惠岸 朋春 谦乐 1. 实时数据总线服务-TT TimeTunne （TT ）在阿里 巴巴集团内部是一个有着超过6年历史的实时数据总线服务 ，它是前台在线业务和后端异步数 据处理之间的桥梁。从宏观方面来看 ，开源界非常著名的Kafka+F ume的组合在一定程度上能够提供和TT类似的基础功 能 ；不同的是 ，在阿里 巴巴的业务体量和诉求下 ，我们有比较多的配置管控、资源调度、轨迹校验和血缘识别等方面的 工作。 TimeTunne 产品架构 1.1 Pub/Sub服务 通过上图我们清楚地看到 ，TT的核心部分是一个基于HBase做中间存储的Pub/Sub服务 ，它提供了一个能支撑高读写 比、大吞吐量和数据不丢的队列服务。除此之外 ，基于 日常运维考虑 ，我们还支持了按时间seek和弹性伸缩的能力。 数据需要在 Pub/Sub “落地”的需求一方面来 自于业务上对热点数据多份消费的考虑 ，另一方面一些在线算法方面的应 用需要经常性地对数据进行回放训练 ，数据 “落地”能够比较好地对前后台进行解耦。事实上 ，TT里最热门的数据 （例 如天猫交易相关 ）有超过100倍的读写比 ；而从整体来看 ，仅双11当天流出TT的数据也比流入的数据多了3倍以上。 选择HBase作为中间存储的原因是能够成本较低地复用基于HDFS的多副本存储能力 ，以及HBase自身在提供读写服务时 对于热点数据的内存管理能力。图 8是写入TT的数据在 HBase中的存储模型 ，我们在broker层面通过构造合理的row key 来使得同一个分 区下的数据可按row key顺序scan ；同时 ，因为在生成row key的时候我们使用了broker上的时间戳作为 高位变量 ，因此能很方便地提供按时间seek的能力。 数据在 HBase中的存储模型 1.2数据采集 上图左侧黄色部分是TT的数据采集方案。我们通过以下途径来准实时地收集前台业务产生的增量数据 ： 1. 依赖DRC实现对MySQL、OceanBase以及Orac e等前台业务数据库的增量变更进行捕捉解析 ； 2. 自研的 日志Agent部署在数十万台的应用服务器上 ，准实时地捕捉应用 日志的变化 ； 3. 和其他一些内部主流存储例如OTS进行打通 ； 4. 用户采用TT提供的SDK主动写入。 随着集团内重要业务异地多活架构和全球化的发展 ，数据采集分散在跨越数千甚至上万公里的多个IDC中 ；而与此相反 ， 以Ga axy、ODPS为代表的大数据计算服务则需要考虑充分地利用大集中的架构来提升吞吐能力。因此 ，不可避免地在 数据采集过程中需要对数据进行缓冲和压缩以尽可能降低长途链路对于吞吐量的负面影响。 矛盾的是 ，缓冲意味着前端产生的数据需要在采集端 “等待” ，也就意味着消费方看到的数据是延迟的。这对于像阿里 妈妈这样依赖TT做反作弊和实时计费的业务来讲是很难接受的 ，数据延迟意味着资损 ，意味着用户体验的显著下降。同 样地 ，压缩也是要消耗采集端的服务器资源的 ，尤其在双11这样的场景下 ，前台业务对于采集端的功耗尤其敏感。 遗憾的是 ，世界上从来没有一个只带来好处而没有任何弊端的事物 ，软件和产品的设计中处处都是折衷和取舍。除了在 技术层面将实现细节做到尽可能极致 ，TT为了服务这些不同的场景 ，也提供了一些可配置的参数例如buffersize、 sendthreads、compressLeve 等用来匹配用户对延时、性能以及功耗的不同需求。 1.3 轨迹校验 TT区别于其他类似产品的最大之处 ，是我们通过技术埋点实现了一套完整的数据轨迹校验的方案——我们称之为 “门 将”。轨迹校验的 目的在于通过监控的手段来保证 “数据不丢” ，设计得好 ，甚至可以识别出数据的重复、乱序等情 况。 几乎所有类似的产品都宣称 自己能做到 “数据不丢” ，当然也包括配备了 “门将”之前的TT。有意思的是 ，几乎所有类 似的产品都会被 “丢数据”这个问题困扰 ，同样包括TT。因为我相信我们一定有能力在软件设计以及编码实现方面做 到 “数据不丢”的承诺 ，但往往会在一些预期外的异常case、版本升级或者系统耦合的地方出现这样那样的纰漏 ，从而 导致下游消费方看起来缺失了部分数据。 以 日志采集为例 ，我们碰到过因为操作系统的限制 （请参阅max_user_watches相关的说明 ），inotif