响应式网站建设代理商,设计培训网页班,北京网站建设公司如何选,网站蓝色和红色搭配数据仓库是公司数据发展到一定规模后必然需要提供的一种基础服务#xff0c;也是“数据智能”建设的基础环节。迅速获取数据反馈不仅有利于改善产品及用户体验#xff0c;更有利于公司的科学决策#xff0c;因此获取数据的实时性尤为重要。 目前企业的数仓建设大多是离线一套… 数据仓库是公司数据发展到一定规模后必然需要提供的一种基础服务也是“数据智能”建设的基础环节。迅速获取数据反馈不仅有利于改善产品及用户体验更有利于公司的科学决策因此获取数据的实时性尤为重要。 目前企业的数仓建设大多是离线一套实时一套。业务要求低延时的使用实时数仓业务复杂的使用离线数仓。架构十分复杂需要使用很多系统和计算框架这就要求企业储备多方面的人才导致人才成本较高且出了问题难以排查终端用户也需要熟悉多种语法。本文分析目前的数仓架构探索离线和实时数仓是否能放在一起考虑探索Flink的统一架构是否能解决大部分问题。 文末有福利可下载电子书。 数仓架构 数据仓库可以分为三层ODS原始数据层、DW数据仓库层、ADS应用数据层。 1. ODS (Operation Data Store) 层 从日志或者业务DB传输过来的原始数据传统的离线数仓做法也有直接用CDC (Change Data Capture) 工具周期同步到数仓里面。用一套统一的Kafka来承接这个角色可以让数据更实时的落入数仓也可以在这一层统一实时和离线的。 2. DW (Data warehouse) 层 DW层一般也分为DWD层和DWS层 DWD (Data warehouse detail) 层明细数据层这一层的数据应该是经过清洗的干净的、准确的数据它包含的信息和ODS层相同但是它遵循数仓和数据库的标准Schema定义。DWS (Data warehouse service) 层汇总数据层这一层可能经过了轻度的聚合可能是星型或雪花模型的结构数据这一层已经做了一些业务层的计算用户可以基于这一层计算出数据服务所需数据。3. ADS (Application Data Store) 层 和DWS不同的是这一层直接面向用户的数据服务不需要再次计算已经是最终需要的数据。 主要分为两条链路 业务DB和日志 - Kafka - 实时数仓 (Kafka Dim维表) - BI DB - 数据服务业务DB和日志 - Kafka - 离线数仓 (Hive metastore HDFS) - BI DB - 数据服务主流的数仓架构仍然是Lambda架构Lambda架构虽然复杂但是它能覆盖业务上需要的场景对业务来说是最灵活的方式。 Lambda架构分为两条链路 传统离线数据具有稳定、计算复杂、灵活的优点运行批计算保证T1的报表产生和灵活的Ad-hoc查询。实时数仓提供低延时的数据服务传统的离线数仓往往都是T1的延时这导致分析人员没法做一些实时化的决策而实时数仓整条链路的延迟最低甚至可以做到秒级这不但加快了分析和决策而且也给更多的业务带来了可能比如实时化的监控报警。Flink的强项是实时计算、流计算而Kafka是实时数仓存储的核心。上图标出了1-9条边每条边代表数据的转换就是大数据的计算本文后续将分析这些边探索Flink在其中可以发挥的作用。 Flink一栈式计算 元数据 先说下元数据的管理离线数仓有Hive metastore来管理元数据但是单纯的Kafka不具备元数据管理的能力这里推荐两种做法 1. Confluent schema registry 搭建起schema registry服务后通过confluent的url即可获取到表的schema信息对于上百个字段的表它可以省编写Flink作业时的很多事后续Flink也正在把它的schema推断功能结合Confluent schema registry。但是它仍然省不掉创建表的过程用户也需要填写Confluent对应的URL。 2. Catalog 目前Flink内置已提供了HiveCatalogKafka的表可以直接集成到Hive metastore中用户在SQL中可以直接使用这些表。但是Kafka的start-offset一些场景需要灵活的配置为此Flink也正在提供 LIKE [1] 和 Table Hints [2] 等手段来解决。 Flink中离线数仓和实时数仓都使用Hive Catalog use catalog my_hive;
-- build streaming database and tables;
create database stream_db;
use stream_db;
create table order_table (id long,amount double,user_id long,status string,ts timestamp,… -- 可能还有几十个字段ts_day string,ts_hour string
) with (‘connector.type’ ‘kafka’,… -- Kafka table相关配置
);
-- build batch database and tables;
create database batch_db;
use batch_db;
create table order_table like stream_db.order_table (excluding options)
partitioned by (ts_day, ts_hour)
with (‘connector.type’ ‘hive’,… -- Hive table相关配置
); 使用Catalog后续的计算可以完全复用批和流提供相同的体验。 数仓导入 计算①和⑤分别是实时数仓的导入和离线数仓的导入近来更加实时的离线数仓导入越来越成为数据仓库的常规做法Flink的导入可以让离线数仓的数据更实时化。 以前主要通过DataStream StreamingFileSink的方式进行导入但是不支持ORC和无法更新HMS。 Flink streaming integrate Hive后提供Hive的streaming sink [3]用SQL的方式会更方便灵活使用SQL的内置函数和UDF而且流和批可以复用运行两个流计算作业。 insert into [stream_db.|batch_db.]order_table select … from log_table; 数据处理 计算②和⑥分别是实时数仓和离线数仓的中间数据处理这里面主要有三种计算 ETL和数据导入一样批流没有区别。维表Join维表补字段是很常见的数仓操作离线数仓中基本都是直接Join Hive表即可但是Streaming作业却有些不同下文将详细描述。AggregationStreaming作业在这些有状态的计算中产生的不是一次确定的值而可能是不断变化的值。维表Join 与离线计算不同离线计算只用关心某个时间点的维表数据而Streaming的作业持续运行所以它关注的不能只是静态数据需要是动态的维表。 另外为了Join的效率streaming作业往往是join一个数据库表而不仅仅是Hive表。 例子 -- stream 维表
use stream_db;
create table user_info (user_id long,age int,address,primary key(user_id)
) with (‘connector.type’ ‘jdbc’,...
);-- 将离线数仓的维表导入实时数仓中
insert into user_info select * from batch_db.user_info;-- 维表JoinSQL批流复用
insert into order_with_user_age select * from order_table join user_info for system_time as of order_table.proctime on user_info.user_id user_info.user_id; 这里有个非常麻烦的事情那就是在实时数仓中需要按时周期调度更新维表到实时维表数据库中那能不能直接Join离线数仓的Hive维表呢目前社区也正在开发Hive维表它有哪些挑战 Hive维表太大放不进Cache中考虑Shuffle by key分布式的维表Join减少单并发Cache的数据量考虑将维表数据放入State中维表更新问题简单的方案是TTL过期复杂一些的方案是实现Hive streaming source并结合Flink的watermark机制有状态计算和数据导出 例子 select age, avg(amount) from order_with_user_age group by age; 一句简单的聚合SQL它在批计算和流计算的执行模式是完全不同的。 Streaming的聚合和离线计算的聚合最大的不同在于它是一个动态表[4]它的输出是在持续变化的。动态表的概念简单来说一个streaming的count它的输出是由输入来驱动的而不是像batch一样获取全部输入后才会输出所以它的结果是动态变化的 如果在SQL内部Flink内部的retract机制会保证SQL 的结果的与批一样。如果是外部的存储这给sink带来了挑战。有状态计算后的输出 如果sink是一个可更新的数据库比如HBase/Redis/JDBC那这看起来不是问题我们只需要不断的去更新就好了。但是如果是不可更新的存储呢我们没有办法去更新原本的数据。为此Flink提出了Changelog的支持[5]想内置支持这种sink输出特定Schema的数据让下游消费者也能很好的work起来。例子 -- batch计算完成后一次性输出到mysql中同key只有一个数据
-- streamingmysql里面的数据不断更新不断变化
insert into mysql_table select age, avg(amount) from order_with_user_age group by age;
-- batch: 同key只有一个数据append即可
insert into hive_table select age, avg(amount) from order_with_user_age group by age;
-- streaming: kafka里面的数据不断append并且多出一列来表示这是upsert的消息后续的Flink消费会自动做出机制来处理upsert
insert into kafka_table select age, avg(amount) from order_with_user_age group by age; AD-HOC与OLAP 离线数仓可以进行计算⑨对明细数据或者汇总数据都可以进行ad-hoc的查询可以让数据分析师进行灵活的查询。 目前实时数仓一个比较大的缺点是不能Ad-hoc查询因为它本身没有保存历史数据Kafka可能可以保存3天以上的数据但是一是存储成本高、二是查询效率也不好。 一个思路是提供OLAP数据库的批流统一Sink组件 Druid sinkDoris sinkClickhouse sinkHBase/Phoenix sink总结 本文从目前的Lambda架构出发分析了Flink一栈式数仓计算方案的能力本文中一些Flink新功能还在快速迭代演进中随着不断的探索和实践希望朝着计算一体化的方向逐渐推进将来的数仓架构希望能真正统一用户的离线和实时提供统一的体验 统一元数据统一SQL开发统一数据导入与导出将来考虑统一存储参考 [1]https://cwiki.apache.org/confluence/display/FLINK/FLIP-110%3ASupportLIKEclauseinCREATETABLE [2]https://cwiki.apache.org/confluence/display/FLINK/FLIP-113%3ASupportsTableHints [3]https://cwiki.apache.org/confluence/display/FLINK/FLIP-115%3AFilesystemconnectorinTable [4]https://ci.apache.org/projects/flink/flink-docs-master/dev/table/streaming/dynamic_tables.html [5]https://cwiki.apache.org/confluence/display/FLINK/FLIP-105%3ASupporttoInterpretandEmitChangeloginFlinkSQL 福利来了 从容应对生产环境中的技术难题,《Apache Flink 十大技术难点实战》电子书免费下载! 点击免费下载 《Apache Flink 电子书合辑》 深度解读 102万行代码1270个问题Flink 1.10 发布了什么从开发到生产上线如何确定集群规划大小?Demo基于 Flink SQL 构建流式应用Flink Checkpoint 问题排查实用指南如何分析及处理 Flink 反压Flink on YARN上一张图轻松掌握基础架构与启动流程Flink on YARN下常见问题与排查思路Apache Flink与Apache Hive的集成Flink Batch SQL 1.10 实践如何在 PyFlink 1.10 中自定义 Python UDFFlink 1.10 Native Kubernetes 原理与实践 本书由 Apache Flink 核心贡献者及一线大厂生产环境使用者总结分享内容全面丰富涵盖原理解析、应用实践、demo演示、生产环境常见问题排查与解法、Flink 1.10 生态应用原理与实践助力大数据开发者真正解决Flink生产应用难题 原文链接 本文为云栖社区原创内容未经允许不得转载。
