实时数仓建设背景

• 业务需求的变化：随着互联网和移动互联网的快速发展，企业的业务需求变得越来越复杂和多样化，对数据处理的速度和质量要求也越来越高。传统的T+1数据处理模式已经无法满足企业的需求，实时数据处理成为了一种必要的需求。

• 数据时效性的重要性：在当今数据驱动的时代，数据的时效性对于企业的决策和运营至关重要。实时数仓能够提供实时的数据分析和数据挖掘，帮助企业快速发现市场变化、调整业务策略、优化产品设计和提高客户满意度。

• 技术的进步和发展：随着大数据技术的不断进步和发展，分布式计算、流处理、数据缓存等技术的成熟为实时数仓的建设提供了技术基础。这些技术的应用使得大规模数据的实时处理成为可能，提高了数据处理的速度和效率。

• 竞争压力的增大：随着市场竞争的加剧，企业需要更加精准地了解市场和客户需求，快速响应变化和抓住商机。实时数仓能够帮助企业快速获取实时的市场和客户数据，提供精准的分析和决策支持，提高企业的竞争力和市场地位。

实时数仓和离线数仓对比

• 架构选择：离线数仓采用传统大数据框架模式搭建，而实时数仓则采用Kappa架构方式搭建。

• 建设方法：两者都采用传统数仓建模方法论。

• 准确性：离线数仓的准确性较高，而随着技术的发展，实时数仓的准确性也在逐步提高。

• 实时性：离线数仓统计数据结果通常在T+1，而实时数仓的统计结果通常在分钟级别或秒级别，这显示出实时数仓的实时性更强。

• 稳定性：离线数仓的稳定性好，方便重算，而实时数仓对数据波动较为敏感，数据重新计算时相对麻烦。

• 数据吞吐量：离线数仓的吞吐量都很高，而随着实时技术的进步，实时数仓的吞吐量也得到了提高。

• 数据存储：离线数仓一般将数据存储在HDFS、Hive中，而实时数仓则将数据存储在Kafka、Hbase、Redis、ClickHouse中。

应用场景

• 实时数据分析：实时数仓可以提供实时的数据分析和数据挖掘，包括客户行为分析、销售分析、运营分析等。这可以帮助企业快速了解市场和客户需求，发现商机，调整业务策略，优化产品设计和提高客户满意度。

• 实时风险控制：实时数仓可以用于实时监测和预警各种风险，如保险欺诈监测、信用风险预警等。这可以帮助企业及时发现和应对风险，保障业务的稳定运行。

• 实时决策支持：实时数仓可以提供实时的销售策略调整、产品开发优化、市场推广效果评估等支持，帮助企业快速响应市场变化和抓住商机。

• 实时客户体验优化：实时数仓可以用于实时监测和优化客户体验，如客户服务快速响应、个性化推荐与定制服务等。这可以帮助企业提高客户满意度和忠诚度，增加客户留存和转化。

实时数仓的架构设计和技术选型

• 离线大数据架构：HDFS存储，hive、mr、spark进行离线计算；

• Lambda架构：在离线大数据架构的基础上增加新链路用于实时数据处理，需要维护离线处理和实时处理两套代码；

• Kappa架构：批流合一，离线处理和实时处理整合成一套代码，运维成本小，这就是现今flink之所以火的原因。Kappa架构已成为数据仓库架构的新趋势；

• 计算框架选型：flink等实时计算框架，强烈推荐flink，其『批量合一』的特性及活跃的开源社区，有逐渐替代spark的趋势；

• 数据存储选型：首要考虑查询效率，其次是插入、更新等问题，可选择apache druid，不过在数据更新上存在缺陷，选型时注意该问题频繁更新的数据建议不要采用该方案。当然存储这块需要具体问题具体分析，不同场景下hbase、redis等都是可选项；

• 实时数仓分层：为更好的统一管理数据，实时数仓可采用离线数仓的数据模型进行分层处理，可以分为实时明细层写入druid、Doris等查询效率高的存储方便下游使用；轻度汇总层对数据进行汇总分析后供下游使用。数据流转方案：实时数仓的数据来源可以为kafka消息队列，这样可以做到队列中的数据即可以写入数据湖用于批量分析，也可以实时处理，下游可以写入数据集市供业务使用。

实时数仓主要解决数据时效性问题，结合机器学习框架可以处理实时推荐、实时获取广告投放效果等智能化业务场景。实时数仓的建设应早日提上日程，未来企业对数据时效性的要求会越来越高，实时数仓会很好的解决该问题。

• 数据收集层：这一层负责实时数据，包括 Binlog、Service Log， Tracking Service Log，经过 Real-time Ingestion 团队数据将会被收集到 Kafka 、Hbase 中。Auto-Ingestion 团队负责数据库数离线日常收集到 HDFS。

• 存储层：这层主要是 Kafka 保存实时消息，加上 HDFS 保存 Hive 数据存储等，HBase 保存维度数据。
  在存储层上面是 Spark， Flink 计算引擎, Presto SQL 查询引擎。

• 调度管理层： 各种资源管理，任务管理，任务调度，管理各种 Spark，Flink 任务。

• OLAP数据存储层：Druid 用于存储时间序列数据，Phoenix(HBase)存储聚合报表数据、维度表数据、标签数据，Doris；Elastic Search 存储需要多维度字段索引的数据如广告数据、用户画像等。

• 应用层：数据报表，数据业务服务，用户画像等。

实时数仓各层级的技术选型

• 数据源：直接配置为kafka实时消息传输；

• 数据明细层：一般也会选择kafka作为数据存储，如果是这层做成大宽表的话，可以选择druid/Doris/hbase/

• 数据汇总层：对数据进行高度汇总后的数据，这层一般也会选择kafka作为数据存储，这样需要保证各层级的数据通过kafka能够产生依赖。

• 应用层：应用层根据不同的业务类型选用不同的数据存储，如果结果需要能够快速搜索，可以选用es，如果结果需要进行多维数据统计分析，可以选用druid，Doris;如果结果数据量不是很大的话，最好选用mysql，相对来说，mysql的稳定性要好一点。

• 维度存储：维度如果是稳定并且数据量不大的情况下可以选择mysql，但是如果维度经常变动或者字段经常增加的话，最好选用hbase进行存储redis。

本期分享就到这里了，感谢大家的阅读。如果你喜欢今天的内容，那么请不要错过我们下期更精彩的【实时数仓（下）】。