采集的数据种类，主要可以划分为两种：
数据库变更日志，比如mysql的binlog日志，hbase的hlog，oceanbase的变更日志，oracle的变更日志等。
引擎访问日志，比如用户访问网站产生的apache引擎日志，搜索引擎的接口查询日志。
一般情况，出于吞吐量以及系统压力上的考虑，并不是新增一条记录就采集一次，而是基于下面的原则，按批次对数据进行采集。
数据大小限制：当达到限制条件时，把目前采集到的新数据作为一批。（例如512K写一批）
时间阈值限制：当时间达到一定条件时，也会把目前采集到的新数据作为一批，避免在数据量少的情况下一直不采集。（例如30秒写一批）
数据中间件系统有很多实现方式，比如开源的系统有kafka。
为了和离线数据源保持一致，一般都是通过数据中间件来采集数据库变更数据这种形式来获取实时数据的（这需要在数据处理层对业务主键进行merge处理，比如一笔订单可能会被变更多次，会有多条变更记录，这时就需要进行merge拿到最新的数据）
时效性和吞吐量是数据处理中的两个矛盾体，很多时候需要从业务的角度来权衡使用什么样的系统来做数据中转。
二、数据处理
1.去重指标：精确去重。在这种情况下，明细数据是必须要保存下来的，当遇到内存问题时，可以通过数据倾斜来进行处理，把一个节点的内存压力分到多个节点上。
模糊去重，去重的明细数据量非常大，而业务的精度要求不高的情况下，可以使用相关的去重算法，把内存的使用量降到千分之一甚至万分之一，以提高内存的利用率。
（1）布隆过滤器
改算法是位数组算法的应用，不保存真是的明细数据，只保存明细数据对应的哈希值的标记位。当然，会出现哈希值碰撞的情况，但是误差率可以控制，计算出来的去重值比真实值小。采用这个算法存储1亿条数据只需要100多MB的空间。
适用场景：统计精度要求不高，统计维度值非常多的情况。比如统计全网各个商家的UV数据，结果记录数达到上千万条。因为在各个维度之间，布隆过滤器是可以共用的。
（2）基数估计
改算法也是利用哈希的原理，按照数据的分散程度来估算现有数据集的边界，从而得出大概的去重值总和。这里估算的去重值可能比真实值大，也可能比真实值小。采用这个算法存储1亿条数据只需要几KB的内存。
适用场景：统计精度要求不高，统计维度非常粗的情况。比如整个大盘的UV数据，每天的结果只有一条记录。基数估计在各个维度值之间不能共用，比如统计全天小时的UV数据，就需要有24个基数估计对象，因此不适合细粒度统计的场景。
2数据倾斜
数据倾斜是ETL中经常遇到的问题，比如计算一天中全网访客数或者成交额时，最终的结果只有一个，通常应该时在一个节点上完成相应的计算任务。在数据量非常大的时候，单个节点的处理能力是有限的，必然会遇到性能瓶颈。这时就需要对数据进行分桶处理，分桶处理和离线处理的思路是一样的。
（1）去重指标分桶
通过对去重值进行分桶hash，相同的值一定会被放在同一个桶中去重，最后再把每个桶里面的值进行加和就得到总值，这里利用了每个桶的CPU和内存资源。
（2）非去重指标分桶
数据随机分发到每个桶中，最后再把每个桶的值汇总，主要利用的是各个桶的CPU能力。
3.事务处理
超时时间：由于数据处理是按照批次来进行的，当一批数据处理超时时，会从拓扑的spout端重发数据。另外，批次处理的数据量不宜过大，应该增加一个限流的功能（限定一批数据的记录数或者容量等），避免数据处理超时。
事务信息：每批数据都会附带一个事务ID信息，在重发的情况下，让开发者自己根基事务信息去判断数据第一次到达和重发时不同的处理逻辑。
备份机制：开发人员需要保证内存数据可以通过外部存储恢复，因此在计算中用到的中间结果数据需要备份到外部存储中。
以上机制都是为了保证数据的幂等性。
