数据仓库常见问题讨论
54 37最热 | 最新
- 一图讲清👉数据仓库的分层设计 1️⃣数据缓冲层 STG(Stage) 结构与源系统保持一致的增量数据，汇聚业务系统源头数据，也是ETL加工过程的缓冲区。 2️⃣数据引入层 ODS (Operational Data store) 将原始数据几平无处理地存放在数据仓库系统中，结构上与源系统基本保持一致，是数据仓库的数据准备区。这一层的主要职责是将基础数据同步、存储。 3️⃣数据公共层 CDM(Common Dimenions Model) 存放明细事实数据、维表数据及公共指标汇总数据。其中明细事实数据、维表数据一般根据 ODS 层数据加工生成。公共指标汇总数据一般根据维表数据和明细事实数据加工生成。CDM 层又细分为DIM 层、DWD 层和DWS 层。 🔸维度层 DIM(Dimension 以维度作为建模驱动，基于每个维度的业务含义，通过添加维度属性、关联维度等定义计算逻辑，完成属性定义的过程并建立一致的数据分析维表。为了避免在维度模型中冗余关联维度的属性，基于雪花模型构建维度表。 🔸明细数据层 DWD(Data warehouse Detail) 以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细事实表。可将某些重要属性字段做适当冗余，也即宽表化处理。 🔸汇总数据层 DWS(Data Warehouse Summary) 以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标表。以宽表化手段物理化模型，构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。 4️⃣应用数据层 ADS(Application Data Service) 存放数据产品个性化的统计指标数据，根据 CDM 层与ODS层加工生成。
- 数据表类型-数产必知知识点3 表是数据仓库建立各种数据模型的核心，了解表的类型是最基础的部分。 📖表分为两类，一类是【维度表】，一类是【事实表】。 🌟维度表存在的目的是为了丰富分析维度，能方便用数的人能从更多维度进行分析。维度表中记录的内容是某个对象的特性，比如商品属性表，记录了商品ID以及对应商品的品类，尺寸，生产商等属性。维度表有时候也被称为码表，比如某一个表中记录了每种特定状态所对应的编码，比如睡眠状态，对应编码为1，激活状态，对应编码为2等等这样的枚举。一般维表前缀为dim。 🌟事实表是数仓建模的核心，需要紧紧贴近业务过程来设计，一般前缀带有fact，事实表可以被分为三种类型： 1⃣️事务事实表：表里不断新增随着业务不断产生的数据，比如订单表，里面每天都会新增不断发生的订单记录，并且这些记录一旦产生，就不再发生变化。 2⃣️周期快照事实表：以一个周期为时间间隔，来统计事实，比如按天为周期，去统计【年累计消费金额】，每天这个字段都记录着不同的数，不同日期查询到的该字段都不同。 3⃣️累计快照事实表：不按特定周期，来记录事实，且随着事实变化，始终只保持着一条记录。比如某个订单状态表里有【支付时间】，【收货时间】，【评价时间】三个字段，当完成支付的时候填充上支付时间，而其他两个字段为空，一段时间后，用户完成收货动作，那么就会填充上收货时间，并且覆盖上一条记录，保持记录永远只有一条。
- 从结构化和非结构化入手了解技术 从业务价值角度理解数据的来源和应用场景
- 从 0 到 1 搭建数仓，首先要了解自己的情况，你去问一个数仓工程师怎么做，他很可能给你的回答就是怎么分层怎么清洗怎么转化，最终到指标提供给应用端，整个链路怎么建设，这并没有什么问题，但前提是自己有没有架构师对整个技术盏有一定规划，用什么样的技术能支撑数据的运行，之后再谈搭建数仓整体链路，其次要了解自己对数仓的要求，为什么要做数仓，是要统一数据做一些指标展示还是要做能一定程度上支持智能分析的数仓，对做数仓有一定自身的了解和追求之后，在谈找什么样的人来做，但无论怎样，前期做短平快都是最合适做法，至于后续的迭代需要根据需求而定
- 最主要的平台建设环节，实施开发先不讨论 1.架构与规范 根据公司业务数据特征，定义数仓分层架构，定义数据命名规范，定义数据字典规范，不要小看这些定义，这是后续产品化或数据应用中非常重要的环节，也是代码的质量验收标准。 2.ETL 与调度 数仓的 ETL 和调度关系到未来系统的实施成本，运维与开发人力的多少与这个环节的研发投入息息相关。如果公司需要对外做落地实施的，相信我，不要完全依赖开源工具，市场上所有的开源调度系统都是有各种缺陷的，Zeus，阿兹卡班，dolphin，都是需要二次开发才能完善的，具体有哪些坑可以私聊。ETL 环节就得看数据架构的设计了，常见的是开源工具和脚本结合，无论是 datax 还是 kettle 都需要设计一些模板来实现大部分工作的自动化代码落地。 3.血缘和元数据管理 这对于数仓而言不可或缺，业务系统的接口变化在当下非常的频繁，好的血缘管理能直接释放运维人员的工作，节约项目的人力实施成本。这里又要回到自研调度的重要性了，元数据管理配合 sql 解析的功能可以做到字段级血缘，这方面的人才市场并不多见，一般都是 10 年以上老玩家研究的东西。 3 指标管理和 BI 应用 其实可以分成两部分，因为同属数据应用平台范畴了，就合并着一起描述了，行业中最早的指标管理标杆产品是阿里 dataphin 里的指标定义功能，细节不了了，原理一般高工去看了都能明白，自研难点是部署的数据库的 sql 自动化生成功能，这块的研发很容易碰壁遇到瓶颈或者被迫放弃一些衍生指标的功能。BI 应用就不多说了，市场格局基本已经成型，主流工具就这么五六款，近年还都在转型 saas 服务，价格我觉得都贵了，这些报表工具研发不算太难，价格高了容易丢失用户，我劝各厂商要善良。最后提一下大家都在做数字化转型，大屏是各位企业转型的门面，个人用下来 BI 也可以大屏，但是要说炫酷大家可以试用下阿里云的 datav，无论菜鸟还是专业的设计师都有适合的工具界面。
- 数据埋点，实时场景，考虑 kafka 接入，如果数据字段固定，放入同个 topic 里，用字段做区分是那类数据。程序接入数据，达到数据自动同步的目的。 数仓入库，不同类的数据，入库到不同的表，上层再考虑业务做模型构建
- 很难弄，首先得领导懂行，上游系统有管控，下游应用有方向，这些外部环境对0-1很致命，是决定性因素。 然后才是建仓本身，怎么持续快速落地和产生效果是个难点。大部分数仓建设周期长，环节多链路长，可能等做出来就已经过时了，而且成本收益不成正比，而小快灵的开发方式后期数据一致性也是灾难性的执行效率也会越来越低。 另外尤其对于数字化转型的企业，需要整个业务部门也数字化转型，工作方式和业务模式的数字化转型，全面安全管理的支持，而不是仅靠IT部门本身加大投入，这点挺难的，有两个点，一个是IT部门自己往往都没有数字化管理的意识，另外如果涉及到业务部门的利益的或者让部门利益拿出来让公司层面共享，很多人是拒绝的，会人为制造很多壁垒和部门墙。 说到数仓本身，最重要的是入仓和数据质量的管理，这个也是占到整个数仓开发工作量的大头，尤其是多个数据源的接入，一定要自己建立一套体系，越依赖源系统建设的数仓后期越不能应付各种变化，其次就是要规划好数据服务的出口，没应用的数仓价值就体现不出来，最后才是根据上下游的情况做好数仓内部的一些建设，包括使用一些合适的平台和工具促进开发效率。
- 第一步，自动探源，发现变化； 第二步，自动生成新的列，用列数据库比较方便，例如 hbase。如果不是列库，可以考虑用 datavault 模型，但除非一次拓多个列，少量列就改原表吧； 第三步，自动或程序添加 atlas 元数据，如果是 hive 或 hbase，atlas 会自动识别，其他库自己程序增加； 以上工作交到一个 etl 过程做，那么有了 atlas 或者自建的元数据管理系统，自动修改元数据，发现，数据探查等就走原来功能路径就好了。如果没有元数据管理工具，那这个自动拓宽就很不友好，基本上不会有人愿意用的。
- 存个 json 字符串解决战斗，埋点上报时也是字符串，没必要都拆字段，原因是上报信息多埋点信息不一定属性一致。 其他场景真想动态扩充，做元数据对比就可以，问题是数据源有改字段类型的可能性，这玩意儿动态改不了，除非默认全存字符串，就不用改了
- 增强曝光率，评论区多留言，多点赞收藏。关注必回，大家一起加油!
- 记住，每一次面试都是一次学习和成长的机会 即使结果不尽如人意 你也在为 下一次更好的表现积累经验 你的坚持和毅力是你的最大财富
- 大数据岗位介绍之《数仓工程师》 数仓工程师 (全称：数据仓库工程师) 数仓工程师日常工作一般是不写代码的，主要以写 SQL 为主！ 数据仓库分为离线数仓和实时数仓，但是企业在招聘时大多要求两者都会，进入公司之后可能会专注于离线或实时其中之一。 就目前来说，大多数的企业还是以离线数仓为主，不过未来趋势肯定是实时数仓为主，所以学习时，为了现在能找到工作，需要学习离线数仓，为了以后的发展，需要学习实时数仓。所以，离线和实时都是我们重点掌握的！ 需要掌握的技能： 不管离线还是实时，重中之重就是：SQL SQL 语法及调优一定要掌握，这里说的 SQL 包括 mysql 中的 sql，hive中的 hive sql，spark 中的 spark sql，flink 中 的 flink sql。 在企业招聘的笔记及面试中，一般问的关于 sql 的问题主要是以 hive sql 为主，所以请重点关注！ 除 sql 外，还需要重点掌握以下技能，分为离线和实时 离线数仓需要重点掌握的技能： Hadoop（HDFS，MapReduce，YARN） Hive（重点，包括hive底层原理，hive SQL及调优） Spark（Spark 会用及了解底层原理） Oozie（调度工具，会用即可） 离线数仓建设（搭建数仓，数仓建模规范） 维度建模（建模方式常用的有范式建模和维度建模，重点关注维度建模） 实时数仓需要重点掌握的技能： Hadoop（这是大数据基础，不管离线和实时都必须掌握） Kafka（重点，大数据领域中算是唯一的消息队列） Flink（重中之重，这个不用说了，实时计算框架中绝对王者） HBase（会使用，了解底层原理） Druid（会用，了解底层原理） 实时数仓架构（两种数仓架构：Lambda架构和Kappa架构）
- 数据仓库概念-数产必知知识点1 数据产品最常对接的就是数据仓库的研发，同时数产也承载着数仓用于分析使用的主题表的设计，因此对于数据仓库的基本知识需要掌握。 📖为什么会出现数据仓库？ 为了降低业务数据库中数据存储的压力，数据仓库接入业务数据库中的数据并进行保存，同时也方便了企业使用数仓中的数据进行后续的数据分析。 📖数仓的定义是什么？ 数仓本质是一个数据集合，这个数据集合是面向主题的，集成的，非易失的且随时间变化的数据集合。 📖数仓的特点是什么？ 1⃣️面向主题：数仓中根据不同主题将数据进行集合，比如用户购买行为大宽表 2⃣️集成：数仓中的数据来自不同数据源，需要通过数据的抽取，清洗，转换后入仓 3⃣️非易失：从业务系统同步到数仓的数据是不允许修改的，只能查询和分析。 4⃣️时变性：数仓定期接收从业务数据库同步来的数据，从而反映出数据最新的变化。 📖数仓和数据库的区别是什么？ 可以认为数据库可以保存实时的业务上产生的数据，而数据仓库是后续从数据库中接入这些数据进行保存。数据库面向事务设计，属于OLTP系统，在设计时尽量避免冗余，符合数据库设计范式（原子性，独立性，唯一性）。而数据仓库面向主题设计，属于OLAP系统，关注数据的整合，分析，处理性能，在大宽表设计中常常会故意进行冗余，采用反范式设计。 🌟资源推荐 某鹅课程：数据仓库原理与实战（免费）