有赞数据仓库实践之路.docxVIP

有赞数据仓库实践之路 2.1.1 背景 在有赞大数据的初期，严格来说是没有数仓概念的：没有分层，没有主题域，也没有规范。 当整个 Hive 里就只要一个 st 库，并且不做规范性命名的时候，便会消灭两个同名的 mysql 表先后导入同一个库，后者把前者的表结构和数据都掩盖了。 只要一个 st 库的混沌期 没有 ETL 工具，没有工作流的概念（或者说全部任务就是一个工作流），没有调度平台，当然更不会有数据字典和血缘关系了。 全部的数据处理任务都是用 python 写的，SQL 自然也就都作为字符串写在 python 文件里了。在一个大 python 项目里，任务之间的依靠关系，则是维护在一个配置文件里的。 2.1.2 痛点 可以说在缺乏方法论的混沌期，数仓在稳定性和可用性方面都是存在问题的。 业务方单方面修改了表结构，我们凌晨收到告警；业务方修改枚举值未通知到位，我们凌晨收到告警；集群资源安排不合理，我们凌晨也会收到告警……频繁的凌晨告警、延迟的数据产出、不精确?????的数据结果、分析人员对数据的吐槽……各类问题交错着，令我们焦头烂额。 2.1.3 Action 随着有赞业务的快速进展，这种烟囱式的开发模式已经支撑不了每天增长的各式各样的数据需求了。 虽然没有用 Informatica 这类商业化的 ETL 工具，但是调度 scheduler 和监控 monitor 的力量却是数据仓库任务必不行少的。于是，在2021年的最终一个季度，有赞开头了基于 airflow 二次开发的数据平台建设，随之也开启了数据仓库的规范之路。 2.2 建设期 2021年初，有赞正式踏上了数据仓库规范之路。伴随着 有赞大数据开发平台的内测，数据仓库首当其冲成为新平台第一个吃螃蟹的人。 2021年6月，我们开头将之前由一堆 Python 文件维护的数据任务开头往大数据平台迁移。迁移持续到了2021年8月，而数据仓库的规范直到今日还在演进…… 数据仓库规范首先要考虑的是分层问题以及随之而来的主题域划分。伴随着数据仓库的不断建设，数据权限、数据字典，任务资源安排等需求都浮出水面。 2.2.1 数仓的分层 分层是为了处理 ETL 任务及工作流的组织、数据的流向、读写权限的把握、不同需求的满足等各类问题。 总体来说，我们将数仓划分为了数据落地层、数据仓库层和数据集市层三部分。作为历史遗迹的 st 层，在迁移过程中被保留了下来——有太多芜杂的任务无法清除，最终在2021年底，被快刀斩乱麻式的一刀切掉了。 数据仓库分层架构图 （1）ODS 落地层 落地层 (Staging Area) 最后是作为介于业务源数据和数据仓库 ETL 之间的缓冲区而存在的。在 Hive 里它表现为一个独立的库，全部来自业务方的表都会先落到这个库里。 有赞的 ODS 落地层处理了两个问题：1）导表的冲突，2）落后的数据仓库两头层建设和日益增长的业务需求之间的冲突。 导表的冲突 由于数据源有各种各样的库，源表表名反复是很正常的情况。因而我们需要给每个表加上主题域前缀，从而避开来自不同主题域的同名表之间的冲突。当同一主题域下消灭同名表时，我们辅以额外的表后缀来区分。 落地层处理了统一导表的落地问题，也担当着全局 ETL 中的第一轮 Extract。我们的准绳是使落地层里的数据和业务数据保持全都，这也是为了便利将来数据问题的排查与核对。 数仓建设和业务需求之间的冲突 当时我们的人力完全无法满足众多需求方对数据的需求——数据两头层的建设赶不上飞速奔跑的业务需求。于是，一个折中的方法是让业务方直接使用落地层，自行处理一些不跨主题域的需求。 这里有业务方格外生疏的原始表，他们能格外快速地获得所需要的数据。这也有利于快速、低成本地进行一些数据方面的探究和尝试。 （2）DW 数仓层 数据仓库层在 Kimball 的数据仓库架构中应当映射的是数据呈现层 (Presentation Area)，它承载了最简单的 ETL 规律和建模，也是维度建模集中体现的一层。 分层的误区 Kimball 并没有对它做更细的层级划分。我们则依样画葫芦，依据当时业界较为通行的做法将整个数仓层又划分成了 dwd、dwb 和 dws 三层。然而我们却一直说不清楚这三层之间清楚的界限是什么，或者说我们能说清楚它们之间的界限，简单的业务场景却令我们无法真正落地执行。 由于缺乏维度层，我们的维表显得无处安放；由于缺乏临时层，我们的两头结果和对外发布的表混在了一起。最终，三级分层只完成了我们的数据流向规范——从 dwd 到 dwb 再到 dws，层级之间不行逆向依靠。 宽表的误区 带着大数据环境下维度建模能否照旧适用的怀疑，我们和很多人一样，在数仓层开头引入了宽表。所谓宽表，迄今为止并没有一个明确的定义。通常做法是把很多的维度关联到现实