mvc5网站开发之美电子版,搭建网站的企业,东营网站seo,北京注册工作室代理公司目前比较流行的实时数仓架构有两类#xff0c;其中一类是以FlinkDoris为核心的实时数仓架构方案#xff1b;另一类是以湖仓一体架构为核心的实时数仓架构方案。本文针对FlinkHudi湖仓一体架构进行介绍#xff0c;这套架构的特点是可以基于一套数据完全实现Lambda架构。实时数… 目前比较流行的实时数仓架构有两类其中一类是以FlinkDoris为核心的实时数仓架构方案另一类是以湖仓一体架构为核心的实时数仓架构方案。本文针对FlinkHudi湖仓一体架构进行介绍这套架构的特点是可以基于一套数据完全实现Lambda架构。实时数仓架构图如下 技术框架 Kafka用于接入数据源 Flink CDC如果直接接入业务数据源可以考虑CDC方式如果通过Kafka缓冲接入业务数据可以忽略; Flink用于数据ETL包括接入数据、处理数据及输出数据全链路数据计算任务 Spark用于数据ETL包括处理数据及输出数据全链路数据计算任务 Hudi湖仓一体数据管理框架用来管理模型数据包括ODS/DWD/DWS/DIM/ADS等 DorisOLAP引擎同步数仓结果模型对外提供数据服务支持 Hbase用来存储维表信息维表数据来源一部分有Flink加工实时写入另一部分是从Spark任务生产其主要作用用来支持Flink ETL处理过程中的Lookup Join功能。这里选用Hbase原因主要因为Table的Hbase Connector支持异步IO功能。 Hera调度系统用来调度离线Spark任务 StreamXFlink任务管理工具用于部署管理以及监控Flink实时任务 数仓架构 采用维度模型标准三层架构ODS/DWD/DWS/DIM/ADS分层架构符合Kimball维度模型建仓指导原则。 ODS层增量方式接入业务数据和日志数据ODS层分区保留当日增量结果包含备份和支持下游数据源功能 DIM层维表加工分为几种情况 静态维表/转码表/字典表这些日常不怎么变化的直接加载到Hudi即可用于flink数据处理如果应用端需要依赖这类表Doris也得同步存储一份 普通维表数据由Flink完成实时任务加工由Spark任务完成离线数据修复同时为了维表Join维表还需要同步hbase一份(原因可以参考笔者另外一篇博客《Flink基于Hudi维表Join缺陷分析及解决方案》)同时结果同步Doris供终端引用。 DWD层维度模型设计采用事务表建模目的尽量将单表数据设计关系降低到最低、易于ETL实现实时数据装载由Flink驱动通过对ODS流进行Join、聚合和转行操作、以及对外部表以Lookup Join方式清洗数据(切记不能过分冗余维度数据底层对数据做分离是核心设计思想冗余越是过分、维护成本越高)结果保存Hudi离线任务修复由Spark实现操作同一份数据ETL要做好时间限制条件避免离线任务影响实时任务同时结果数据同步Doris供终端引用 DWS层非必要不要轻易跨业务过程合并数据其他参考DWD设计思路。 ADS层面向业务场景编程一套数据产品对应自己的一套数据这里一般有两种实现思路可以参考 Flink/Spark驱动读取DWD/DWS/DIM数据加工ADS结果表数据写入Hudi同步Doris供下游引用 StarRocks高版本支持物化视图功能可以借助物化视图实现ADS层 总结无论是实时数仓还是离线数仓建设问题根源一般来自于模型设计的不合理要知道数据模型才是维度建模的灵魂Kimball老爷子写了几百万字的著作主要描述的是数据建模的思想。 FlinkHudi实时数仓架构缺点 基于Hudi湖仓一体架构虽然实时性比离线数仓要高很多但是对比纯实时数仓而言其延迟性一般在分钟级(到终端引用可能要延迟10~15分钟时间)对于某些实时性要求较高场景并不适合。 常见问题 数据源保序任务一般来说接入数据源很难完全避免乱序场景发生这种情况有两种方案可以参考 事实表按照业务过程建设一般业务过程数据不存在更新所以单个key也不存在重复发射的情况即使存在数据重发也可以通过ETL规则提前规避掉这种思路对于下游数据任务加工都比较友好。 针对接入数据按照update_time保序由于接入Append-Only流数据通过保序任务会变成Retract流这样后续依赖也要考虑回撤场景带来的问题。具体可以参考作者关于乱序场景的几篇文章。 实时UV/PV计算去重计数指标一直依赖都是数据仓库设计领域的难题由于本架构采用了doris所以这部分指标加工如果没有特殊要求可以通过doris的bitmap实现另一种实现思路是借助redis hyperloglog(由于改架构避免不了Spark修复数据情况所以一定场景下是可以接受实时数据差异的)能力通过自定义UDF函数实现UV计算。这两种思路是实时UV常用的解决思路。 历史实时数据对齐如果底层面向业务过程设计那么根据合理的时间戳属性是可以严格区分历史数据和实时数据区别的这种情况可以考虑通过离线数据补全缺失数据。这也侧面说明了模型设计的能力才是数据仓库的核心技能其他方面的技能对于数仓建设的正面影响加到一起也不及模型设计能力的一部分。 Flink基于Hudi维表Join存在陷阱详情请参看笔者另一篇博客《Flink基于Hudi维表Join缺陷分析及解决方案》。 总结 Flink和Hudi组合实现湖仓一体架构目前也是业界讨论比较多的一套架构方案这也得益于Flink和Hudi社区的快速发展对于组件的特性支持越来越丰富。对于文中涉及到的一些技术点并没有展开发挥这部分内容陆续会在博客的其他文章中继续讨论。如果你对实时数仓架构有独到的见解欢迎留言讨论。
