1 实时数据总线服务-TT
TimeTunnel（TT）在阿里巴巴集团内部是一个有着超过6年历史的实时数 据总线服务，它是前台在线业务和后端异步数据处理之间的桥梁。从宏观方面来 看，开源界非常著名的 Kafka+Flume 的组合在一定程度上能够提供和 TT 类似 的基础功能；不同的是，在阿里巴巴的业务体量和诉求下，我们有比较多的配置 管控、资源调度、轨迹校验和血缘识别等方面的工作（图 1）。
Paste_Image.png
图 1 TimeTunnel产品架构
1.1 Pub/Sub 服务
通过 图 1 我们清楚地看到，TT 的核心部分是一个 基于 HBase 做中间存储的 Pub/Sub 服务，它提供了一个能支撑高读写比、大 吞吐量和数据不丢的队列服务。除此之外，基于日常运维考虑，我们还支持了按 时间seek和弹性伸缩的能力。
不一样的技术创新
数据需要在 Pub/Sub“落地”的需求一方面来自于业务上对热点数据多份 消费的考虑，另一方面一些在线算法方面的应用需要经常性地对数据进行回放训 练，数据“落地”能够比较好地对前后台进行解耦。事实上，TT 里热门的数 据（例如天猫交易相关）有超过100倍的读写比；而从整体来看，仅双11当天 流出TT的数据也比流入的数据多了3倍以上。 选择HBase作为中间存储的原因是能够成本较低地复用基于HDFS的多副 本存储能力，以及HBase自身在提供读写服务时对于热点数据的内存管理能力。 图 2是写入TT的数据在HBase中的存储模型，我们在broker层面通过构造 合理的rowkey来使得同一个分区下的数据可按rowkey顺序scan；同时，因 为在生成rowkey的时候我们使用了broker上的时间戳作为高位变量，因此能 很方便地提供按时间seek的能力。
Paste_Image.png
图 2 数据在HBase中的存储模型
1.2 数据采集
图1左侧黄色部分是TT的数据采集方案。我们通过以下途径来准实时地收 集前台业务产生的增量数据： 1. 依赖 DRC 实现对 MySQL、OceanBase 以及 Oracle 等前台业务数据
不一样的技术创新
库的增量变更进行捕捉解析； 2. 自研的日志 Agent 部署在数十万台的应用服务器上，准实时地捕捉应 用日志的变化； 3. 和其他一些内部主流存储例如OTS进行打通； 4. 用户采用TT提供的SDK主动写入。 随着集团内重要业务异地多活架构和全球化的发展，数据采集分散在跨越数 千甚至上万公里的多个IDC中；而与此相反，以Galaxy、ODPS为代表的大数 据计算服务则需要考虑充分地利用大集中的架构来提升吞吐能力。因此，不可避 免地在数据采集过程中需要对数据进行缓冲和压缩以尽可能降低长途链路对于 吞吐量的负面影响。 矛盾的是，缓冲意味着前端产生的数据需要在采集端“等待”，也就意味着 消费方看到的数据是延迟的。这对于像阿里妈妈这样依赖TT做反作弊和实时计 费的业务来讲是很难接受的，数据延迟意味着资损，意味着用户体验的显著下降。 同样地，压缩也是要消耗采集端的服务器资源的，尤其在双 11 这样的场景下， 前台业务对于采集端的功耗尤其敏感。 遗憾的是，世界上从来没有一个只带来好处而没有任何弊端的事物，软件和 产品的设计中处处都是折衷和取舍。除了在技术层面将实现细节做到尽可能极致， TT 为了服务这些不同的场景，也提供了一些可配置的参数例如 buffersize、 sendthreads、compressLevel 等用来匹配用户对延时、性能以及功耗的不同 需求。
1.3 轨迹校验
TT 区别于其他类似产品的大之处，是我们通过技术埋点实现了一套完整 的数据轨迹校验的方案——我们称之为“门将”。轨迹校验的目的在于通过监控 的手段来保证“数据不丢”，设计得好，甚至可以识别出数据的重复、乱序等情 况。 几乎所有类似的产品都宣称自己能做到“数据不丢”，当然也包括配备了“门 将”之前的 TT。有意思的是，几乎所有类似的产品都会被“丢数据”这个问题 困扰，同样包括 TT。因为我相信我们一定有能力在软件设计以及编码实现方面 做到“数据不丢”的承诺，但往往会在一些预期外的异常 case、版本升级或者 系统耦合的地方出现这样那样的纰漏，从而导致下游消费方看起来缺失了部分数
不一样的技术创新
据。 以日志采集为例，我们碰到过因为操作系统的限制（请参阅 max_user_watches相关的说明），inotify没有通知到新文件的产生而发生整个 文件漏采集；也碰到过因为软件的 bug 在递归创建子目录的情况下出现了时序 问题导致文件漏采集；还碰到过保存在应用服务器上的checkpoint文件被意外 损坏导致的“丢数据”。这样的案例实在太多，而且防不胜防。 所以，工业界真正的“数据不丢”我认为是有完备的机制能够快速地发现数 据丢失，考验的是系统的监控能力。 上文提到过，TT 支撑着阿里妈妈的实时反作弊和点击计费业务；同样地， 蚂蚁金服大量涉及资金核对和商户对账的业务也将身家性命托付在TT上。这样 的业务不允许有任何原因导致的数据正确性问题。 “门将”的核心思路是在采集端往TT写入数据的同时，构造恰当的meta， 将数据“链表化”，从而能够在“门将”的校验服务里对数据轨迹进行还原，进 而和源头进行校验（图 2）。 仍然以日志采集为例。在采集过程中，我们以ip+dev+inode+sign来唯一 识别内网上的一个文件，在构造 meta 时记录下当前数据包在原始文件中的 offset 和当前数据包的大小 size，那么对于同一个文件的多个数据包，通过 offset 和 size 就能快速地识别出文件内有没有被重复采集或者遗漏采集。如果 在恰当的时间内与这台机器上 ls 命令得到的结果进行比对，就很容易发现有没 有文件被漏采集。
1.4 小结
所有的技术实现都是业务需求的抽象，这些需求有可能来自于大多数用户需 要用到的功能，更有可能来自对上下游业务架构和场景的理解。数据总线服务是 一个和业务架构耦合非常密切的基础组件，阿里巴巴集团独特的技术架构、多样 性的存储方案和横向平台化的研发模式赋予了TT探究更复杂问题的原动力。 在2016年双11这样一个万众瞩目的时间点，TT通过前期的软件性能和机 房规划上的努力，高峰期单一集群承担了15GB/s的写入和50GB/s的读取流量， 首次做到了对所有业务进行不降级服务。这对于我们、对于搭建在TT上的众多 业务，都是极大的鼓舞。
网友评论