一、前言数据仓库具有面向主题的特性,那么就会有主题的概念,数仓建设是遵循纵向分层开发,横向划分主题域设计,数仓分层就不在这次谈了,这次我会结合本人数仓工作实践总结的经验来聊聊数仓主题域划分,同时会引申出主题划分 这个对于数仓工程师来说是必备的能力,比如当你面临着一个新业务的开启,需要从0到1开始搭建数据仓库或者数据集市,这时候就要考虑到主题域和主题的合理划分。二、数仓建设的步骤1. 业务调研数仓开发侧是承上对接业务研发侧&承下对接数据分析侧,在数仓建设前期要对上游业务过程和对下游数据分析指标体系有所了解和熟知,然后拉齐上下游沟通数据口径和数仓搭建。2. 主题域划分3. 数仓分层设计模型表6. 数仓公共层表迭代升级三、主题和主题域下面结合本人对搬家业务的数仓建设,进行主题域划分和主题划分实践,当然项目的大小决定着这是一个小型的数据集市 还是 企业级的数据仓库。1. :「数仓建设篇」数仓主题域划分 另外,公众号有海量大数据领域资料 欢迎领取。同时也欢迎大家加我微信,拉你进大数据技术交流群,一同成长。图片
ads_alarm_stat_last_month为例: { "job": { "setting": { "speed": { "channel": 1 // DataX 作业的并发通道数,
因此,数仓建设的基石就是对于业务的把控,数仓建设者即是技术专家,也应该是“大半个”业务专家。 规范 模型是整个数仓建设基石,规范是数仓建设的保障。为了避免出现指标重复建设和数据质量差的情况,我们统一按照最详细、可落地的方法进行规范建设。 统一归口策略包含业务归口统一、设计归口统一和应用归口统一,从底层保证了数仓建设的三特性和三效果。 统一数据出口 数仓建设不仅仅是为了数据内容而建设,同时也为了提高交付的数据质量与数据使用的便利性。 图14 数仓管理流程 数仓全景图 基于OneData主题建设,我们采用面向业务、面向分析的建设策略,形成数仓全景图,如下图所示: ? 图15 数仓全景图 资产管理列表 基于起源数据平台形成的资产管理体系,如下图所示: ?
大家好,不管是离线数仓与实时数仓,建设的时候都少不了架构设计,今天来学习一下常见的架构及发展演变过程。 一、离线数仓大数据架构 1.数仓架构 下面详细说明图中的各个组件及其所起的作用。 图中显示的整个数据仓库环境包括操作型系统和数据仓库系统两大部分。 二、实时数仓Lambda 架构 Lambda 架构总共由三层系统组成:批处理层(Batch Layer),速度处理层(Speed Layer),以及用于响应查询的服务层(Serving Layer (2)资源占用增多:同样的逻辑计算两次,整体资源占用会增多(多出实时计算这部分) 三、实时数仓Kappa 架构 Kappa 架构可以认为是 Lambda 架构的简化版(只要移除 lambda 在实时数仓架构设计时,主要是思考“是否数据集成流批一体、“是否存储层流批一体”、“是否 ETL 逻辑流批一体”、“是否 ETL 计算引擎流批一体”;权衡这几个一体带来问题,而设计出符合业务场景的实时数仓架构
数据加工层:使用 Spark、Hive 构建离线数仓、使用 Storm、 Flink 实时数仓。 02 数仓建设 1. 数据仓库V1.0 ? 2016 年之前。 2.1 数仓规范 ① 数据仓库建模规范 ? 2.2 数仓 V2.0 的缺点 ? 前面几小节对数仓 2.0 做了详细的介绍,在数仓 2.0 版本的建设过程中我们也遇到了一些问题。 面对这个问题,我们在 2019 年对数仓进行了新的迭代,即数仓 V3.0,下面将对此做详细介绍。 3. 数据仓库V3.0 ? 总体愿景:数仓 3.0 优化思路主要是使用建模工具替代人工开发。
前段时间给大家分享了阿里的数仓建设《阿里数据仓库研发规范》,本文主要讲解下创业型公司是如何建设数仓的。 本文将重点探讨数据处理层中数据仓库的建设,有提到早期的数据服务中存在不少问题,虽然在做运营Dashboard系统时,对后台数据服务进行了梳理,构建了数据处理的底层公共库等,但是仍然存在一些问题: 中间数据流失 于是,我们考虑建设一个适于分析的数据存储系统,该系统的工作应该包含两部分:第一,根据需求抽象出数据模型;第二,按照数据模型的定义,从各个数据源抽取数据,进行清洗、处理后存储下来。 下图所示,为现阶段我们的数据仓库建设方案。 数据建模 根据数据分析的需求抽象出合适的数据模型,是数据仓库建设的一个重要环节。
做数仓最重要的是什么?一是模型易用性,二是数据质量。模型易用性我们可以通过建模规范、指标管理等方式去实现。而对于数据质量呢? 本篇将以严选数仓为例,从建设目标、保障措施、效果评价等几方面探讨数仓质量建设。 及时性 及时性指业务需要看数时,要有数可看,具体落实下来就是数仓的FLOW要能稳定按时产出。 3 数据质量实施策略 针对前面提到的建设目标,目前主要有以下策略。 数仓的数据来自于上游业务系统,上游系统的逻辑变更必然对数仓造成影响。 frc-99a461f37ea45bc42ed991586fec24bd.jpg 5 未来展望 关于数仓质量这块可能继续建设的方向包括以下几块: DQC结果订阅机制,这个需求已经提给了有数;
数仓建设 到这才真正到数仓建设,为什么前面要占那么大篇幅去介绍公司业务及所使用的数据中台系统,因为下面的数仓建设是根据公司的业务发展及现有的数据中台进行,数仓的建设离不开公司的业务。 ? 智能数仓规划 数仓建设核心思想:从设计、开发、部署和使用层面,避免重复建设和指标冗余建设,从而保障数据口径的规范和统一,最终实现数据资产全链路关联、提供标准数据输出以及建立统一的数据公共层。 有了核心思想,那怎么开始数仓建设,有句话说数仓建设者即是技术专家,也是大半个业务专家,所以采用的方式就是需求推动数据建设,并且因为数据中台,所以各业务知识体系比较集中,各业务数据不再分散,加快了数仓建设速度 数仓建设主要从两个方面进行,模型和规范,所有业务进行统一化 模型 所有业务采用统一的模型体系,从而降低研发成本,增强指标复用,并且能保证数据口径的统一 模型分层 结合公司业务,后期新增需求较多,所以分层不宜过多 数据应用层 数据应用层的表就是提供给用户使用的,数仓建设到此就接近尾声了,接下来就根据不同的需求进行不同的取数,如直接进行报表展示,或提供给数据分析的同事所需的数据,或其他的业务支撑。
1 背景介绍 1.1 概述 本案例基于腾讯云一站式开发治理平台Wedata、私有网络VPC、云数据库Mysql和弹性Mapreduce构建了全流程的离线数仓建设流程。 进行数据清洗,分层规划如下: ODS:原始数据层,数据采集,同步,统一结构化; DWD:数据明细层,数据预处理,格式化; DWB:数据中间层,指标汇总,公共指标加工; ADS:数据服务层,主要存储个性化指标; 数仓架构图 3.2 数仓分层任务编排 本demo采用先编排后开发的敏捷开发模式,实际使用中,也可以使用先开发后编排的模式。 SQL和Spark SQL完成dwd层和dwb层开发,包括任务节点有:dwd_user、dwd_item、dwb_user、dwb_item 3-新建Shell脚本,用于标记每一个逻辑的完成,并触发下一层数仓任务的运行 image.png 点击任务运维,可以跳转到任务流和具体任务的运维界面,进行任务的预警、周期补数和基本信息查看等操作 image.png 5 总结 以上流程的展现了从mysql抽取业务数据,对数据进行分层建设
最近在和几个做数据仓库的朋友聊天时,大家讨论到一个有意思的问题:建数仓是不是一定要用ETL工具?这个问题其实没有标准答案,得根据具体情况来定。 我在这个行当摸爬滚打这么些年,经历过大大小小十几个数仓项目,今天就和大家分享下我的一些看法。先说说用ETL工具的好处。ETL工具能给我们带来不少便利:1. 开发效率高。 (常用数仓构建流程)但是,ETL工具也不是万能的。有时候不用ETL工具,照样把活干得漂亮:1. 直接写SQL。如果数据源和目标都是关系型数据库,用SQL也能搞定大部分ETL工作。2. 用编程语言。 这才是建好数仓的关键。
做数据开发不能绕过数据仓库的建设,数仓是数据分析/数据挖掘的基础料仓,更是描述一个企业蓝图的智库。 如何打造出一个反映企业全局的数仓视图是“路漫漫其修远兮”的任重远道; 在数据公众号“数据指象”的上一篇推文《数仓矛盾的演进之旅》中,描述了数仓由简入繁的其中道理。今天我们接着了解数仓的名义。 数据集成性:集成是数仓最重要的特点之一,也是突出与传统数据库的特性之一;没有集成数仓就没有价值;只有将:同义不同名、同名不同义、多数据源、码值分解等等杂乱无章的数据,以集成就行统一、进行归一、进行编排形成一致性统一的的数仓 非易失性:不易丢失数据是仓的基本属性,数仓承接经年累月的数据输入,保存历史的数据细节,在时间的作用慢慢地聚沙成塔,让微小的数据也能发出耀眼的光芒。 具体数仓中粒度如何选择,后续将分享如何构建双粒度数仓 周末快乐
作为数仓对接上层应用的统一出入口,数据服务将数仓当作一个统一的 DB 来访问,提供统一的 API 接口控制数据的流入及流出,能够满足用户对不同类型数据的访问需求。 01 背景介绍 在统一数仓数据服务之前,数仓提供的访问接入方式往往存在效率问题低、数据指标难统一等问题,具体而言有以下几个比较突出的情况: 广告人群 USP、DMP 系统每天需要通过 HiveServer 以流的方式从数仓导出数据到本地,每个人群的数据量从几十万到几个亿,人群数量 2w+,每个人群运行时间在 30min +,部分大人群的运行直接超过 1h,在资源紧张的情况下,人群延迟情况严重。 数仓的数据在被数据产品使用时,需要为每个表新生成一个单独的接口,应用端需要为每一种访问方式(如 Presto、ClickHouse)区分使用不同的接口,导致数据产品接口暴涨,不方便维护,影响开发及维护效率 通过唯一的 ID 标识,数据产品可通过 ID 查阅数据,而非直接访问对应的数仓表。一方面,指标服务统一了指标的口径,同时也支持快速构建新的数据产品。
原创内容 No.781 杂谈 | 聊聊数仓建设中那些屎山代码 最近工作在忙着重构前人的屎山代码,分享一点心得。 图片由夸克AI绘制 最近没怎么更新,在忙别的事情,外加偷懒去了。 数仓迭代本身就是一个会逐渐变成屎山的过程。 数仓的搭建和传统软件开发还是有很大的区别的,逻辑上有太多的细节问题,比如对于某一种特殊情况我们做了取高的处理,为什么要这么处理,基于什么样的考虑等信息,没有相应的记录就会导致后人不敢动前人的代码——我觉得逻辑有点不合理
而伴随着大数据技术的不断发展和成熟,B站也对公司内部基础数据的治理和管控进行了大量尝试和实践,最终建设了一体化运维数仓,来支撑满足内部业务/基础架构/工程效率/SRE团队对于数据的强烈需求。 本文整理自SACC 2022中国系统架构师大会上嘉宾演讲,内容将围绕B站运维数仓的建设,分别从引擎侧、平台侧和业务侧展开介绍,分享在落地实践中面临的挑战和问题。本文主要包括以下部分: 1. B站运维数仓建设的整体思路 4. 关注数据质量 5. 围绕应用建设的运维数仓,本身从设计上没有考虑应用变动所带来的消费场景,周边平台对接完,发现应用改动后,缺乏感知。 B站运维数仓建设的整体思路 B站建设运维数仓的目标和准则是什么?
随着公司业务的扩展,数据处理需求日益增多,业务快速迭代和发展的情况下,不仅缺少数据仓库的标准化规范设计,而且缺少一款集实时离线为一体的数仓统一解决方案,鉴于此情况,我们对数仓进行了统一规划和建设。 数仓建设规范 数据分层 数据引入层 ODS (Operational Data Store) :存放未经处理的原始数据,包括埋点上报日志数据,数据库抽取的结构化数据。 像平均点击价格(CPC)、每千次展示成本(eCPM)、平均单次访问页面数(Pageview per Session)这样的复合指标是平均值类型的复合指标。 技术选型 通过数仓建设,我们需要解决以下问题: 数据存储的规范性 数据模型的复用性 数据模型的耦合性 数据的完整性 数据查询效率 数据成本可控 在标准测试数据集上,我们选取了一些常见的低基数聚合场景。 建设成果 公司数仓建设过程分为四个阶段: 是数据仓库规范建立和技术调研选型。
在谈数仓之前,先来看下面几个问题: 数仓为什么要分层? 维度建模怎么建: 在实际业务中,给了我们一堆数据,我们怎么拿这些数据进行数仓建设呢,数仓工具箱作者根据自身60多年的实际业务经验,给我们总结了如下四步。 数仓工具箱中的维度建模四步走: ? 数据应用层 数据应用层的表就是提供给用户使用的,数仓建设到此就接近尾声了,接下来就根据不同的需求进行不同的取数,如直接进行报表展示,或提供给数据分析的同事所需的数据,或其他的业务支撑。 数仓整体流程 数据治理 数仓建设真正的难点不在于数仓设计,而在于后续业务发展起来,业务线变的庞大之后的数据治理,包括资产治理、数据质量监控、数据指标体系的建设等。 规范治理 规范是数仓建设的保障。为了避免出现指标重复建设和数据质量差的情况,统一按照最详细、可落地的方法进行规范建设。
本文目录: 一、数据流向 二、应用示例 三、何为数仓DW 四、为何要分层 五、数据分层 六、数据集市 七、问题总结 导读 数仓在建设过程中,对数据的组织管理上,不仅要根据业务进行纵向的主题域划分 ,还需要横向的数仓分层规范。 本文作者围绕企业数仓分层展开分析,希望对你有帮助。 因文章太长,本文不是完结版,文末可获取完整PDF版 从事数仓相关工作的人员都知道数仓模型设计的首要工作之一就是进行模型分层,可见模型分层在模型设计过程中的重要性,确实优秀的分层设计是一个数仓项目能否建设成功的核心要素 这些表可以在 Hive 中,也可以是从 Hive 导入 Redis 或者 ES 这种查询性能比较好的系统中 数仓建设完整版教程PDF文档 发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn
整体架构图解直接看数仓分层的整体层级图各层级详解ODS层-操作数据层定义:数据仓库的“缓冲区”或“贴源层”。 核心作用:隔离风险:避免复杂的清洗逻辑直接影响源系统,也避免源系统变更直接击穿数仓。历史回溯:源系统通常只保留近期数据或覆盖更新,ODS层通过全量或增量快照保留历史状态。 它是数仓的字典中心,确保全公司对于用户、商品、城市的定义是统一的。核心作用:统一口径:避免不同报表中“北京市”和“北京”被算作两个城市。 DWD层-明细数据层定义:数仓的核心层。基于ODS数据进行清洗、规范化、脱敏、维度关联后生成的明细事实表。核心作用:数据清洗:去除脏数据、统一枚举值(如性别统一为0/1)、空值填充。 设计原则:按主题建设:如交易主题、流量主题、用户主题。时间粒度:最常见的是天粒度(日汇总),也有小时粒度或周/月粒度。维度组合:通常包含日期+核心维度(如用户、商品、地区)。
若从企业级数据仓库模型着手,走的就是一条自顶向下的建设途径:先建企业级数据仓库,再在其上开发具体的应用。 在缺乏足够的技术力量和数据仓库建设经验的情况下,按照这种模型设计的系统建设过程长,周期长,难度大,风险大,容易失败。 这种模型的优点是信息全面、系统灵活、数据冗余少。 2. 数据仓库的分层 基于数据仓库模型理论指导,以数据分析,统计指标为导向,为了能够记录数据的历史,便于处理业务变化,把复杂问题简单化,通过空间换时间提高数据访问效率,数据集成考虑,在数仓实际开发过程中进行分层处理 从上往下看对应数据仓库分层如下: image.png 从分层开发来看: 数仓流程.png 附:阿里数据仓库分层 1.分层和作用 image.png 2.数据分层架构 分层架构.png 3.网易数据架构
构建设备会话维表 需求说明 本需求继续针对dwd.event_log_detail表深度开发,完成对dws.mall_app_session_agr表(设备会话维表)的构建。