实时数仓在广告业务的应用

本文主要介绍本人在公司广告业务的实时数仓建设方案和迭代过程。
第一版，flume + kafka + flink + apache druid + redis
此时还没有分层的概念，广告数据主要分为两部分，一部分为dsp,ssp,adx,daq等服务器产生的日志数据，会通过flume采集到kafka中.另一部分是业务数据库的数据，包括广告投放业务数据和维度表数据。这部分数据是用canal采集binlog日志到kafka.
那么现在数据都已经在kafka中，在kafka和druid之间是流式处理引擎FLink，flink程序做的主要是对日志数据和业务数据进行清洗和维度关联，并没有做聚合操作，维度数据在redis中维护了一份，flink程序在关联维度时会去redis读取数据。flink处理完并不是直接写到druid，而是先写往kafka,这么做一是因为druid对kafka摄入数据性能比较好，其次flink和kafka对接容易保证数据的一致性。至此，在druid中形成了十几张宽表，代表了整个广告投放过程各个环节的业务，包括订单，投放，sspb曝光，adx竞价，dsp曝光，dsp点击，用户留资等表。此时只有druid会对数据按照维度字段进行预聚合，粒度基本上比较细，数据量较大，因此除留资数据外，其它表只保存最近30天的数据。
分析和展示工具使用superset，和druid集成的还可以，做olap分析性能很不错，图表功能也可满足产品和分析人员使用。

第二版，flume + kafka + flink + doris+hbase+redis
第一版虽然性能不错，但是缺点也比较明显：
1.druid中的数据量较大，内存和磁盘资源成本较高
2.由于数据每日TB级的增长，只能保存近30天的数据，无法保存更多的历史数据
3.druid架构复杂，运维也是个麻烦。
根据产品和分析人员沉淀下来的常用需求，常用指标，结合大厂的实时数仓构建方法，实时数仓改建方案也基本清晰了。
首先采用了ods-dwd-dim-dws-ads的类似离线数仓的分层架构。
其次用最近比较火的Doris替换了Apache Druid。
第三，使用hbase+redis存储维度层数据
ods:通过flume采集的日志数据和canal采集的业务数据库的数据存储到kafka中。
dwd:依然是对ods的数据进行过滤清洗，分流后写到kafka中,dwd层就是按业务环节分的kafka中的topic，保存的是事实明细数据。
dim:维度层做了一些优化，使用hbase+redis缓存+异步IO的方式。减少了redis的内存压力，同时提升了关联的性能。
dws:根据产品和分析人员提供的指标，做了轻度聚合层，使用flink程序对dwd和dim层进行聚合，维度关联，写入doris中的表。
ads:采用公司自研的报表展示系统，对接Doris，支持sql查询，灵活方便。