阿里巴巴大数据实践｜实时技术篇流式技术架构（二）

前言

大家好,我是ChinaManor,直译过来就是中国码农的意思,我希望自己能成为国家复兴道路的铺路人,大数据领域的耕耘者,平凡但不甘于平庸的人。

以上是实时技术篇的思维导图 ～ 接下来几篇 manor将更新正在阅读的《阿里巴巴大数据实践》的第五章实时技术

2 流式技术架构

在流式计算技术中，需要各个子系统之间相互依赖形成一条数据处 理链路，才能产出结果最终对外提供实时数据服务。 在实际技术选型 可选的开源技术方案非常多，但是各个方案的整体架构是类似的 只是 各个子系统的实现原理不太一样。另外，流式技术架构中的系统跟离线 处理是有交叉的，两套技术方案并不是完全独立的，并且在业界中有合 并的趋势。 各个子系统按功能划分的话，主要分为以下几部分。 1 数据采集

数据的源头，一般来自于各个业务的日志服务器（例如网站的浏览 行为日志、订单的修改日志等），这些数据被实 采集到数据中间件中， 供下游实时订阅使用。

2 数据处理

数据被采集到中间件中后，需要下游实时订阅数据，并拉取到流式 计算系统的任务中进行加工处理。这里需要提供流计算引擎以支持流式 任务的执行。

3 数据存储

数据被实时加工处理（比如聚合、清洗等）后，会写到某个在线服 务的存储系统中，供下游调用方使用。这里的写操作是增量操作，并且 是源源不断的。

4 数据服务

在存储系统上会架设一层统一的数据服务层（比如提供 HSF 接口、 HTTP 服务 ），用于获取实时计算结果。

从图 5.2 可以看出，在数据采集和数据服务部分实时和离线是公用 的，因为在这两层中都不需要关心数据的时效性。这样才能做到数据源 的统一，避免流式处理和离线处理的不一致。

2.1 数据采集

数据采集是整个数据处理链路的源头，是所有数据处理链路的根节 点，既然需要做到实时计算，那么自然就需要做到实时采集了。所采集 的数据都来自于业务服务器，从所采集的数据种类来看，主要可以划分 为两种： 数据库变更日志，比如 MySQL binlog 志、 HBase hlog 志、 Ocean Base 的变更日志、 Oracle 的变更日志等。 引擎访问日志，比如用户访问网站产生的 pache 擎日志、搜 索引擎的接口查询日志等。 不管是数据库变更日志还是引擎访问日志，都会在业务服务器上落 地成文件，所以只要监控文件的内容发生变化，采集工具就可以把最新 的数据采集下来 。一般情况下，出于吞吐量以及系统压力上的考虑，并 是新增一条↓己录就采集 次，而是基于下面的原则，按批次对数据进 采集 数据大小限制：当达到限制条件时，把目前采集到的新数据作为 批（例如 512KB 批）。 时间阐值限制：当时间达到 定条件时，也会把目前采集到的新 数据作为 批，避免在数据量少的情况下一直不采集（例如 30 秒写 批）。 只要上面的其中一个条件达到了，就会被作为 批新数据采集到数 据中间件中 这两个条件的参数需要根据业务的需求来设定，当批次采 频繁时，可以降低延时，但必然会导致吞吐量下降。 对于采集到的数据需要 个数据交换平台分发给下游，这个平台就 数据中间件。数据中间件系统有很多实现方式，比如开源的系统有 Kafka ，而阿里巴巴集团内部用得比较多的是 TimeTunnel （原理和 Kafka 似），还有 MetaQ Notify 等消息系统。 从图 .3 可以看出，消息系统是数据库变更节点的上游，所以它的 时比数据中间件低很多，但是其支持的吞吐量有限。因此，消息系统 般会用作业务数据库变更的消息中转，比如订单下单、支付等消息。 对于其他较大的业务数据（每天几十 容量）， 般会通过数据中 间件系统来中转，虽然它的延时在秒级，但是其支持的吞吐量高。消息 统和数据中间件的性能对比如表 5.1 所示。 另外，在一些情况下，有些业务并没有通过消息系统来对数据库进 行更新（比如有些子业务的订单数据是通过同步方式导人 MySQL 的） 也就是说，从消息系统中获取的数据并不是最全的，而通过数据库变 日志拿到的业务变更过程数据肯定是全的。因此，为了和离线数据源 致， 般都是通过数据中间件来采集数据库变更数据这种形式来获 取实时数据的（这需要在数据处理层对业务主键进行 merge 处理，比如 一笔订单可能会被变更多次，会有多条变更记录 ，这时就需要进行 merge 拿到最新的数据）。 时效性和吞吐量是数据处理中的两个矛盾体 ，很多时候需要从业务 的角度来权衡使用什么样的系统来做数据中转

2.2 数据处理

实时计算任务部署在流式计算系统上，通过数据中间件获取到实时 源数据后进行实时加工处理。在各大互联网公司中，有各种开源的和非 开源的流计算引擎系统在使用。在业界使用比较广泛的是 Twitter 开源 Storm 系统、雅虎开源的 S4 系统、 Apache park Streaming ，以及 最近几年兴起的 Flink 。这些系统的整体架构大同小异，但是很多细节 上的实现方式不太一样，适用于不同的应用场景。 在阿里巴巴集团内使用比较多的是 阿里云提供的 StreamCompute 系统，作为业界首创的全链路流计算开发平台，涵盖了从数据采集到数 据生产各个环节，力保流计算开发严谨、可靠。其提供的 SQL 语义的 流式数据分析能力（ StreamSQL ），让流数据分析门槛不再存在。它在 Storm 的基础上包装了一层 SQL 语义，方便开发人员通过写 SQL 就可 以实现实时计算，不需要关心其中的计算状态细节，大大提高了开发效 ，降低了流计算的门槛。当然，它也支持传统模式的开发，就像 Hadoop 中的 Hive MapReduce 关系一样，根据不同的应用场景选择不同的 方式。另 StreamCompute 还提供了流计算开发平台，在这个平台上 就可以完成应用的相关运维工作，不需要登录服务器操作 ，极大地提 了运维效率。 下面以 Stor 为例，简单讲一下流数据处理的原理。实时应用的整 个拓扑结构是 个有向无环图（详情可参考 Apache Storm 的官网： http :// storm.apache.org index.html ），如图 5.4 所示。 • pou ：拓扑的输人，从数据中间件中读取数据，并且根据自定 义的分发规则发送给下游的 bolt ，可以有多个输人源。 • bolt ：业务处理单元，可以根据处理逻辑分为多个步骤，其相互 之间的数据分发规则也是自定义的。 时数据处理应用出于性能考虑，计算任务往往是多线程的。 会根据业务主键进行分桶处理，并且大部分计算过程需要的数据都会放 在内存中，这样会大大提高应用的吞吐量。当然，为了避免内存溢出， 内存中过期的数据需要定时清理，可以按照 LRU （最近最少使用）算 法或者业务时间集合归类清理（比如业务时间属于 T- 的，会在今天凌 晨进行清理 ）。 下面就实时任务遇到的几个典型问题进行讲解。 1 .去重指标 BI （商业智能）统计类实时任务中 ，对于资源的消耗有一类指 标是非常高的，那就是去重指标。由于实时任务为了追求处理性能，计 算逻辑一般都是在内存中完成的，中间结果数据也会缓存在内存中，这 就带来了内存消耗过多的问题。在计算去重时，势必要把去重的明细数 据保存下来，当去重的明细数据达到上亿甚至几十亿时，内存中放不下 了，怎么办？这时需要分两种情况去看 精确去重。在这种情况下，明细数据是必须要保存下来的，当遇 到内存问题时，可以通过数据倾斜来进行处理，把一个节点的内 存压力分到多个节点上。 ·模糊去重。在去重的明细数据量非常大，而业务的精度要求不 的情况下，可以使用相关的去重算法，把内存的使用 量降到千分 之一甚至万分之一 ，以提高内存的利用率。 ( I ）布隆过滤器 该算法是位数组算法的应用 不保存真实的明细数据，只保存明细 数据对应哈希值的标记位。当然，会出现哈希值碰撞的情况，但是误差 率可以控制，计算出来的去重值比真实值小。采用这个算法存储 亿条 数据只需要 100 MB 空间。 适用场景 统计精度要求不高，统计维度值非常多的情况。比如统 计全网各个商家的 UV 数据，结果记录数达到上千万条。因为在各个维 度之间，布隆过滤器是可以共用的。 (2 ）基数估计 该算法也是利用哈希的原理，按照数据的分散程度来估算现有数集 的边界，从而得出大概的去重值总和。这里估算的去重值可能比真实值 大，也可能比真实值小。采用这个算法存储 亿条数据只需要几 KB 内存。 适用场景：统计精度要求不高，统计维度非常粗的情况。比如整个 大盘的 UV 数据，每天的结果只有一条记录。基数估计在各个维度值之 间不能共用，比如统计全天小时的 UV 数据，就需要有 个基数估计 对象，因此不适合细粒度统计的场景。 这两个算法可以在网上搜索到具体的实现细节，这里就不细讲了。

数据倾斜 数据倾斜是 ETL 中经常遇到的问题，比如计算一天中全网访客数 或者成交额时，最终的结果只有一个，通常应该是在一个节点上完成相 关的计算任务。在数据量非常大的时候，单个节点的处理能力是有限的， 必然会遇到性能瓶颈。这时就需要对数据进行分桶处理 分桶处理和离 线处理的思路是一样的。 ( 1 ）去重指标分桶 通过对去重值进行分桶 Has ，相同 值一定会被放在同一个桶 去重，最后再把每个桶里面的值进行加和就得到总值，这里 用了每个 桶的 PU 和内存资源。 (2 ）非去重指标分桶 数据随机分发到每个桶中，最后再把每个桶的值汇总，主要利用的 是各个桶的 能力。 事务处理 由于实时计算是分布式处理的，系统的不稳定性必然会导致数据的 处理有可能出现失败的情况。比如网络的抖动导致数据发送不成功、机器重启导致数据丢失等。在这些情况下，怎么做到数据的精确处理呢？ 上面提到的几个流计算系统几乎都提供了数据自动 ACK 、失败重发以 及事务信息等机制。 超时时间 由于数据处理是按照批次来进行的，当 批数据处理 超时时，会从拓扑的 端重发数据。另外，批次处理的数据 量不宜过大，应该增加一个限流的功能（限定一批数据的记录数 或者容量等），避免数据处理超时。 事务信息 每批数据都会附带 个事务 ID 的信息，在重发的情 况下，让开发者自己根据事务信息去判断数据第一次到达和重发 时不同的处理逻辑。 备份机制 开发人员需要保证内存数据可以通过外部存储恢复， 因此在计算中用到的中间结果数据需要备份到外部存储中。 上面的这些机制都是为了保证数据的幕等性。

2.3 数据存储

实时任务在运行过程中，会计算很多维度和指标，这些数据需要放 在一个存储系统中作为恢复或者关联使用。其中会涉及三种类型的数据： ·中间计算结果一一在实时应用处理过程中，会有一些状态的保存 （比如去重指标的明细数据），用于在发生故障时，使用数据库 中的数据恢复内存现场。 ·最终结果数据一一指的是通过 ETL 处理后的实时结果数据，这些 数据是实时更新的，写的频率非常高，可以被下游直接使用。 维表数据一一在离线计算系统中，通过同步工具导人到在线存储 系统中，供实时任务来关联实时流数据。后面章节中会讲到维表 的使用方式。 数据库分为很多种类型，比如关系型数据库、列式数据库、文档数 据库等 那么在选择实时任务所使用的数据库时应该注意哪些特征呢？ 前面提到实时任务是多线程处理的，这就意味着数据存储系统必须 能够比较好地支持多并发读写，并且延时需要在毫秒级才能满足实时的 性能要求。在实践中，一般使用 Base Tair MongoDB 等列式存储系 统。由于这些系统在写数据时是先写内存再落磁盘，因此写延时在毫秒 级：读请求也有缓存机制，重要的是多并发读时也可以达到毫秒级延时。 但是这些系统的缺点也是比较明显的，以 HBase 为例， 一张表 须要有 row key ，而 rowkey 是按照 ASCII 码来排序的，这就像关系型数 据库的索引一样， row key 的规则限制了读取数据的方式。如果业务方 需要使用另一种读取数据的方式，就必须重新输出 row key 。从这个角 度来看， HBase 没有关系型数据库方便。但是 Base 张表能够存储 TB 甚至几十 TB 的数据，而关系型数据库必须要分库分表才能实现 这个量级的数据存储。因此，对于海量数据的实时计算，一般会采用非 关系型数据库，以应对大量的多并发读写。 下面介绍在数据统计中表名设计和 rowkey 设计的 些实践经验。 表名设计 设计规则：汇总层标识＋数据域＋主维度＋时间维度 例如： dws trd _s lr dtr ，表示汇总层交易数据，根据卖家（ sir ）主维度 +O 点截至当日（ dtr 进行统计汇总。 这样做的好处是，所有主维度相同的数据都放在一张物理表中，避 免表数量过多，难以维护。另外，可以从表名上直观地看到存储的是什 么数据内容，方便排查问题。 rowkey 设计 设计规则： MD5 ＋主维度＋维度标识＋子维度 ＋时间维度＋ 子维度 例如：卖家 ID MD5 前四位＋卖家 ID+ app 级类目 ID+ ddd ＋二级类目 ID D5 前四位作为 row key 的第 部分，可以把数据散列，让服 务器整体负载是均衡的，避免热点问题。在上面的例子中，卖家 ID 于主维度 ，在查数据时是必传的。每个统计维度都会生成一个维度标识，以便在 rowkey 上做区分。

2.4 数据服务

实时数据落地到存储系统中后，使用方就可以通过统一的数据服务 获取到实时数据。比如下一章将要讲到的 OneService ，其好处是： 不需要直连数据库，数据源等信息在数据服务层维护，这样当存 储系统迁移时，对下游是透明的。 调用方只需要使用服务层暴露的接口，不需要关心底层取数逻辑 的实现。 屏蔽存储系统间的差异，统一的调用日志输出，便于分析和监控 下游使用情况。

总结

以上便是阿里巴巴大数据实践｜实时技术篇流式技术架构（二） 下一篇讲阿里巴巴的流式数据模型

愿你读过之后有自己的收获,如果有收获不妨一键三连，我们下篇再见👋·