统一数据管理下的敏捷分析

衡石科技

+ 关注

2022-07-29 19:46

494次阅读

导读

近期，衡石成功举办了 HENGSHI SENSE 4.1 线上分享会，分享会上衡石科技 CEO 刘诚忠，衡石科技联合创始人&首席架构师赖林华围绕整个数据分析市场、行业和衡石的创新为主题进行分享。上期的推文我们分享了衡石科技 CEO 刘诚忠带来的《企服市场新物种：何为数据分析 PaaS》。

本期推文我们来看看衡石科技联合创始人 & 首席架构师赖林华带来的《统一数据管理下的敏捷数据分析》分享。

数据分析典型架构

众所周知，数据分析的起点是业务系统原始数据。这其中包括 APP 数据、CRM 数据、订单数据、仓储数据、调查问卷等。这些数据在数据分析流中是分层存在的，如 ODS、DWD、DWM、DWS。ODS 是最原始的，业务系统里用户的每一个点击，每一次下单，ODS层都需要忠实地进行数据同步。

明细数据会通过不同的 ETL 任务进到数据仓库，每一层数仓聚合粒度是不一样的。DWD 进行数据的清洗与聚合。DWM 会按照天或者每小时进行轻度汇总。DWS则是按照业务线、产品、部门进行进一步的汇总。这些数据最终会通过 ETL 加工成不同的业务主题。这是数据分析的典型架构。

数据分析 ETL 过程

典型架构中有很多 ETL 的过程。这些过程通常需要开发工程师开发，但是需求方并不是开发工程师自己，它拥有特定的需求方。需求方本身不会写代码，所以大量需求沟通必不可少。沟通中的理解不到位会带来数据处理时的数据失真，口径不匹配，以至于最终交付结果不理想。

即使开发流程非常顺利，成功交付。但一次交付的完成并不代表整件事情的结束，而是下一个“噩梦”的开始。需求是会变更的，每一次变更意味着整个流程得再次重复执行。

传统 ETL 实现数据分析的痛点

ETL 架构下无法满足敏捷的分析需求：

1、传统的 ETL 数据管道每条都是定制的，计算前置、以空间换时间

敏捷性极差：新增数据源或更改数据模型逻辑时，难以及时响应、快速返回分析结果
难以复用性：提取与转换紧耦合，每条 ETL 管道都是一个复杂的定制方案，扩展非常困难

2、业务团队需求无法及时响应，IT 团队疲于奔命

统一数据管理下的敏捷分析(图3)

ETL 的趋势

传统的 ETL 具有历史积累的合理性。它的 pipeline 是高度定制化的，在前端生产数据的时候能够把数据量聚合到非常小，这样一来便可做到展示时的快速响应。但重点是，如果满足不了业务分析需求的话，前端展示的快与慢便失去了其意义与价值。

所以我们不能说 ETL 这个方式被完全取代了。但是可以说 ELT的趋势是在上升的，更多的厂商、企业正在尝试用 ELT去实现数据平台的规划。

ELT 趋势上升原因：

1、企业数字化转型：传统数仓针对小规模数据的存储和计算能力逐渐不能满足企业需求

2、新业务新应用快速迭代：传统数仓高度聚合的数据，不能满足更多针对用户维度行为的分析需求，针对明细数据的分析需求不断涌现

3、Lakehouse 数据湖性能的提升：随着分布式软硬件的发展，针对海量数据的批量、Adhoc 的查询技术成熟

衡石数据分析产品架构

ELT 和 ETL 架构在数据源多源异构方面差异不大。数据同步中 EL 方式下会弱化 T 的部分。

ETL 跟传统架构不一样的地方在于 ODS、DWD、DWS 数据不需要被分在不同的地方，比如 ODS 数据量比较大，面向的是顺序读写存储，所以会放在 Hive 或是 Spark 里面；DWD 放在 oracle 里面；DWS 放在 MySQL 里面。这是传统的做法。在新的方法论下这些分层可以统一在 Lakehouse 里面进行存储和管理。

模型指标层承载了 ELT 中 T 后置的任务。在数据源之后，我们可以直接对接模型指标层去做关键业务系统的模型关系构建，以及运算逻辑的确定。这些模型会形成主题数据包。数据包包含了模型和指标公式。我们最终可以基于已经构建好的数据包去支撑业务，比如基于数据包去做技术分析，做大屏或者做一些数据查询。当然也可以把它形成 data API 或者将数据同步到各种下游。

衡石定义的是标准化的模型，这样的模型能够下推到底层不同的 Lakehouse 里面，能够做到完全一致的行为和结果。技术选型时能够比较开放的去选择业务上面比较合适的架构进行落地，再也不需要绑定在某一种技术上面，这是未来的发展趋势。