数仓开发面试题汇总-数据建模&数据治理

1. 如何建设数仓，如何构建主题域

        数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。
        可以这样理解：数据仓库对异构数据源进行集成，集成后按照主题进行了重组，并包含历史数据，且不再修改。
        如果对数据仓库还不够理解，可以先搞清楚关系型数据库与数据仓库的区别，OLTP和OLAP的区别等。
        如何建设数仓，技术方案选型上有很多选择：云服务/自建、流处理/批处理、MPP/Hadoop；数据建模方面可以参考阿里数据管理方法论OneData，该方法论是基于Kimball的维度建模理论并做了改进：包含统一的指标定义体系、模式设计体系以及配套工具。
        OneData实施过程（螺旋迭代）：
        (1) 数据调研：
                1 业务调研：业务线、业务模块、业务过程
                2 需求调研：找分析师、运营人员了解收集他们的报表需求，以及调研现有的报表。
        (2) 架构设计：
                1 数据域划分：

        数据域就是主题域。数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。
        1.业务过程可以概括为一个个不可拆分的行为事件，在业务过程之下，可以定义指标；
        2.维度是指度量的环境，如买家下单事件，买家就是维度。
        为保障整个体系的生命力，数据域是需要抽象提炼，并且长期维护和更新的，但不轻易变动。
        在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中和扩展新的数据域。
 

        常见的划分主题域的方法有：按分析需求、按产品功能、按业务系统、按业务线、按部门等等。

                2 构建总线矩阵：
                需要做两件事情：①每个数据域下有哪些业务过程；②业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。
        (3) 规范定义：主要定义指标体系、维度属性规范定义
        (4) 模型设计：主要包括维表设计和事实表设计
               


        

       

2. 缓慢变化维 几种处理方式

        SCD（Slowly Changing Dimensions）：数仓的特点之一就是反映历史变化，如何处理维度变化是维度设计的重要工作之一。与增长较快的事实表相比，维度变化相对缓慢。
        根据Kimball建模理论，简单讲有三种处理方式：
        方式1. 重写维度值：不保留历史数据，始终取最新数据；
        方式2. 插入新的维度行：维度变化前的事实与过去的维度值关联，维度值变化后的事实和当前的维度值关联；
        方式3. 添加维度列：采用方式2不能将变化前后记录的事实归一为变化前的维度或者变化后的维度。可以用增加一个属性列来解决。
        Kimball建模理论中完整的方式共8种类型（实际是7中，类型0不算，另外类型4、5、6、7不常用），如下：
        类型0：属性值不可能变，原样保留。
        类型1：重写，覆盖原值，类型1不能反映历史。
        慎用该类型，比如一个人改名了，覆盖原值说得通。如果一个人换城市了，那么他在以前的城市做的事情当然不能归到现在的城市。
        要想清楚，新值能否直接取代原值。比如一个人的性别从未知到男，当然就可以直接取代。
        类型2：增加新行（代理键会变化）。同时增加两个日期字段来表示有效期：①开始日期；②截止日期（当前有效值的截止日期可以设置一个很大的日期如9999-12-31）。另外事实表中使用维表的代理键，这样旧的事实关联旧的维表代理键值，新的关联新的代理键值。
        类型3： 增加新属性。比如增加一个“以前部门”。
        类型4： 增加微型维度。比如用户的几个属性变化很快，那么把它们拿出去单独建一张表，可以对这些属性做去重，数量会少很多；而且此维度是作为一个维度在事实表中去引用。通常使用的是这些维度值的笛卡尔积的组合来进行建表，同时创建代理键，没有自然键。
        类型5： 类型1+类型4。在微型维度做为用户维度的支架，维表中增加字段存储最新的微信维度的代理键值。
        类型6： 类型1+类型2+类型3。通过类型3区分当前和历史两个字段，然后通过类型2对历史字段进行多行处理，最后通过类型1对当前字段写入最新值。
        类型7：类型1+类型2。分为：双重外键、单外键，分出两张表（或者一张表和一个当前值的视图），一张类型2存历史值，一张类型1存当前值，实时表中通过两个外键关联这两张表叫双重外键，实时表中通过1个自然键或者代理键来关联为单外键。

参考：深入解析缓慢变化维 - 知乎

3. 什么是维度建模，星型模型与雪花模型的区别

        维度建模是一种将大量数据结构化的逻辑设计手段，包含维度和指标，它不像ER模型目的是消除冗余数据，维度建模是面向分析，最终目的是提高查询性能，所以会增加数据冗余，并且违反三范式。
        维度建模也是重点关注让用户快速完成需求分析且对于复杂查询及时响应，根据事实表和维度表的关系，可将常见的模型分为：①星型模型；②雪花模型；③星座模型。其中最常用的其实是星型模型。
        建模原则：
        1.高内聚和低辑合：将业务相近或者相关、粒度相同的数据设计为一个逻辑或者物理模型：将高概率同 时访问的数据放一起 ，将低概率同时访问的数据分开存储。
        2.核心模型与扩展模型分离：建立核心模型与扩展模型体系，核心模型包括的宇段支持常用的核心业务，扩展模型包括的字段支持个性化或少量应用的需要 ，不能让扩展模型的宇段过度侵人核心模型，以免破坏核心模型的架构简洁性与可维护性。
        3.公共处理逻辑下沉及单一：越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用层实现，不要让公共逻辑多处同时存在。
        4.成本与性能平衡：适当的数据冗余可换取查询和刷新性能，不宜过度冗余与数据复制。
        5.数据可回滚：不改变处理逻辑，不修改代码的情况下重跑任务结果不变
        6.一致性：字段命名及定义必须一致
        7.命名清晰、可理解：表命名需清晰、一致，表名需易于使用方理解
        维度模型设计步骤：
        1. 选择需要进行分析决策的业务过程，。比如下单
        2. 选择粒度。在事件分析中，我们要预判所有分析需要细分的程度，从而决定选择的粒度。比如订单粒度，粒度是维度的一个组合。
        3. 识别维表。选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选。
        4. 选择事实。确定分析需要衡量的指标。
        事实表（Fact Table），指存储有事实记录的表，如系统日志、销售记录等；事实表的记录在不断地动态增长，所以它的体积通常远大于其他表。事实表作为数据仓库建模的核心，需要根据业务过程来设计，包含了引用的维度和业务过程有关的度量。作为度量业务过程的事实，一般为整型或浮点型的十进制数值，有可加性，半可加性和不可加性三种类型。
        1.可加：最灵活最有用的事实是完全可加，可加性度量可以按照与事实表关联的任意维度汇总。比如订单总金额。
        2.半可加：半可加度量可以对某些维度汇总，但不能对所有维度汇总。余额是常见的半可加事实，按时间维度相加没有意义，比如每天的余额加起来毫无意义，但是同一个人不同账户的余额加起来是有意义的。
        3.不可加：一些度量是完全不可加的，例如：比率。对非可加事实，一种好的方法是，分解为可加的组件来实现聚集。
        维度表（Dimension Table）或维表，有时也称查找表（Lookup Table），是与事实表相对应的一种表；它保存了维度的属性值，可以跟事实表做关联；相当于将事实表上经常重复出现的属性抽取、规范出来用一张表进行管理。常见的维度表有：日期表（存储与日期对应的周、月、季度等的属性）、地点表（包含国家、省／州、城市等属性）等。维度是维度建模的基础和灵魂。
        星型模型：星形模型中有一张事实表，以及零个或多个维度表，事实表与维度表通过主键外键相关联，维度表之间没有关联，当所有维表都直接连接到“ 事实表”上时，整个图解就像星星一样，故将该模型称为星型模型。星形模型是最简单，也是最常用的模型。由于星形模型只有一张大表，因此它相比于其他模型更适合于大数据处理。其他模型可以通过一定的转换，变为星形模型。
        雪花模型：当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的维度表，形成一些局部的 " 层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。如图，将地域维表又分解为国家，省份，城市等维表。它的优点是 : 通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。
        星座模型：星座模型是由星型模型延伸而来，星型模型是基于一张事实表而星座模式是基于多张事实表，并且共享维度表信息，这种模型往往应用于数据关系比星型模型和雪花模型更复杂的场合。星座模型需要多个事实表共享维度表，因而可以视为星形模型的集合，故亦被称为星系模型。
        总结：星型模型对OLAP的分析引擎支持比较友好，而雪花模型在关系型数据库中如MySQL，Oracle中非常常见，尤其像电商的数据库表。在数据仓库中雪花模型和星座模型的应用场景比较少，但也不是没有，所以在具体设计的时候，可以考虑是不是能结合两者的优点参与设计，以此达到设计的最优化目的。

参考：数据模型建设-维度建模详解 - 知乎

4. 数仓的好处

建设数仓的意义

        避免数据烟囱和不一致，通过建模避免通用逻辑的重复计算，通过维度退化等手段空间换时间提升查询效率。通过数仓建设可以构建统一、规范、可共享的数据管理体系。通过数仓可以控制数据规模增长趋势，通过集中建设降低整体数据研发管理维护成本，利于进一步的性能优化节约软硬件资源等。具体也可以从数仓的定义和特征进行详细说明：①面向主题的、②集成的、③相对稳定的、④反映历史变化、⑤支持管理决策。

数据建模的好处

        数据仓库采集进来的原始数据是杂乱无章的，只有通过构建数据模型，将数据有序的组织和存储起来之后（即模型），才能为上层应用提供高效灵活的支撑，优秀的数据仓库模型对应用的价值主要体现在数据质量、响应速度、成本消耗及健壮水平四个方面：

 参考：数据仓库建设意义 - 知乎

5. 分层的好处

ODS层：把业务系统数据几乎无处理地存放在数据仓库系统中。
CDM公共维度模型层：存放明细事实数据、维表数据及公共指标汇总数据，其中明细事实数据、维表数据一般根据ODS层数据加工生成；公共指标汇总数据一般根据维表数据和明细事实数据加工生成。 CMD层又细分为DWD层和DWS层，分别是明细数据层和汇总数据层。
ADS数据应用层：存放数据产品个性化的统计指标数据，根据CDM与ODS层加工生成。

数仓分层的好处

• 清晰数据结构：每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。
• 数据血缘追踪：简单来讲可以这样理解，我们最终给业务呈现的是一张能直接使用的张业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围。
• 减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。
• 把复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
• 屏蔽原始数据的异常：屏蔽业务的影响，不必改一次业务就需要重新接入数据。

参考：数据仓库系列（三）数仓分层的意义价值及如何设计数据分层-阿里云开发者社区

6. 怎么做数据质量，怎么保证及时性和准确性

        阿里从四个方面评估数据质量：①完整性、②准确性、③一致性、④及时性
        完整性：指数据的记录和信息是否完整，是否存在缺失的情况。数据的缺失主要包括记录的缺失和记录中某个字段信息的缺失，两者都会造成统计结果不准确，所以说完整性是数据质量最基础的保障。
        准确性：指数据中记录的信息和数据是否准确，是否存在异常或错误的信息。
        一致性：一般体现在跨度很大的数据仓库体系中，对于同一份数据，必须保证一致性。
        及时性：保障数据能及时产出，才能最终体现数据的价值。

        阿里数据质量管理方法：
        1.消费场景知晓：主要通过数据资产等级和基于元数据的应用链路分析来解决消费场景知晓的问题。根据应用的影响程度，确定资产等级；根据数据链路血缘，将资产等级上推至各数据生成加工的各个环节，确保链路上所涉及数据的资产等级和在各加工环节上根据资产等级的不同采取不同的处理方式。
        2.数据生产加工各个环节卡点校验：包括在线系统(OLTP)和离线系统(OLAP)数据生产加工各个环节的卡点校验。OLTP方面包括：根据资产等级的不同，当对应的业务系统变更时，决定是否将变更通知下游；对于高资产等级的业务，当出现新业务数据时，是否纳入统计中，需要卡点审批。OLAP方面主要包括代码开发、测试、发布和历史或错误数据回刷等环节的卡点校验，针对数据资产等级的不同，对校验的要求有所不同。
        离线卡点工具，①代码提交时：代码扫描工具SQLSCAN，针对每一次提交上线的代码进行扫描，将风险点提示出来。②任务发布上线时：每一次变更都需要线下完成测试后再发布到线上环境中，线上测试通过才算发布成功。发布上线前的测试主要包括Code Review和回归测试，对应资产等级高的任务变更发布，强制阻塞必须通过在彼岸完成回归测试后才允许发布。③最后是是节点变更或数据重刷时的变更通知。下游对变更没有异议后，约定时间发布变更，将影响将至最低。
        3.风险点监控：主要是真的数据在日常运行过程中可能出现的数据质量和时效等问题进行监控，包括在线数据和离线数据的风险点监控两方面。在线数据的风险点监控主要是针对在线系统日常运行产出的数据进行业务规则的校验，以保障数据质量，主要使用实时业务检测平台BCP(Biz Check Platform)；离线数据的风险点监控主要是针对离线系统日常运行产出的数据进行业数据质量监控和时效性监控，其中数据质量监控主要使用DQC，时效性监控主要使用萨摩德。
        离线数据风险点监控主要包括数据准确性和数据产出及时性的监控。
        准确性：DQC检查其实也是运行SQL任务，只是这个任务是嵌套在主任务中的，一旦检测点太多自然就会影响整体的性能，因此还要依赖数据资产等级来确定规则的配置情况。比如A1、A2类数据监控率要达到90%以上，规则类型需要三种及以上，而不重要的数据资产则不强制要求。
        及时性：需要进行一系列的告警和优先级设置，使得重要的任务优先且正确产出。任务优先级和告警设置在叶子节点上并通过叶子节点传递到上游节点。强保障监控是摩萨德的核心功能，包括：
        监控范围：强保障业务的任务及其上游所有任务都会被监控；
        监控的异常：任务出差、任务变慢、预警业务延迟；
        告警对象：默认是任务的Owner；
        何时告警：根据业务设置的预警时间判断何时告警；
        告警方式：根据任务的重要紧急程度，支持电话、短信、邮件等告警。
        除了强保障监控还有轻量级的自定义监控，主要包括：
        出错告警、完成告警、未完成告警、周期性告警、超时告警。
        摩萨德还提供甘特图的服务，可以查看完成业务的最慢任务链路图。
        4.质量衡量：对质量的衡量既有事前的衡量，有DQC覆盖率；又有事后的衡量，主要是用于跟进质量问题，确定质量问题原因、负责人、解决情况等，并用于数据质量的复盘，避免类似事件再次发生。根据数据质量问题对不同等级资产的影响程度，确定其是属于低影响的事件还是具有较大影响的故障。质量分则是综合事前事后的衡量数据进行打分。
        度量指标：
        ①数据质量起夜率：每个月的起夜数是衡量质量建设完善度的一个关键指标；
        ②数据质量事件：先止血，再归因分析，最后查缺补漏+制定预案；
        ③数据质量故障体系：故障定义、故障等级（P1~P4）、故障处理、故障Review。
        5.质量配套工具：针对数据质量的各个方面，都有相关的工具进行保证，以提高效能。

数据资产等级：A1毁灭性质、A2全局性质、A3局部性质、A4一般性质、Ax未知性质

参考：【精选】一文搞懂数据质量怎么做，很接地气！_数据社的博客-CSDN博客

7. 什么是维度，什么是度量

维度：描述事实发生时的环境信息，或者是分析的类别和角度
度量：描述事实的具体数值，一般为整型或浮点型的十进制数值，有可加性，半可加性和不可加性三种类型。
        1.可加：最灵活最有用的事实是完全可加，可加性度量可以按照与事实表关联的任意维度汇总。比如订单总金额。
        2.半可加：半可加度量可以对某些维度汇总，但不能对所有维度汇总。余额是常见的半可加事实，按时间维度相加没有意义，比如每天的余额加起来毫无意义，但是同一个人不同账户的余额加起来是有意义的。
        3.不可加：一些度量是完全不可加的，例如：比率。对非可加事实，一种好的方法是，分解为可加的组件来实现聚集。

8. 如何数据治理？

        从0开始进行数据治理，分四步走：①定标准；②建模型；③沉数据；④促开放。
        主要遵循的理论有：①DAMA DMBOK（数据管理知识体系指南）、②DMM（数据管理成熟的模型）、③DCMM（数据管理能力成熟度评估模型）。
        数据治理主要包含以下几个方案：①数据标准管理；②数据架构管理；③元数据管理；④数据质量管理；⑤数据安全管理；⑥数据生命周期管理；其他方面：数据服务管理。

数据标准管理：数据标准是组织建立的一套符合自身实际，涵盖定义、操作、应用多层次数据的标准化体系。 数据治理对标准的需求可以划分为三类，即基础类数据标准、指标类数据标准和专有类数据标 准。基础类数据是指组织日常业务开展过程中所产生的具有共同业务特性的基础性数据。 基础数据可分为客户、资产、协议、地域、产品、交易、渠道、机构、财务、营销等主题。 指标类数据是指为满足组织内部管理需要及外部监管要求，在基础性数据基础上按一定统计、 分析规则加工后的可定量化的数据。专有类数据标准是指公司架构下子公司在业务经营及 管理分析中所涉及的特有数据。
数据架构管理：数据模型是数据构架中重要一部分，包括概念数据模型、逻辑数据模型和物理数据模型， 是数据治理的关键、重点。理想的数据模型应该具有非冗余、稳定、一致、易用等特征。 逻辑数据模型能涵盖整个组织的业务范围，以一种清晰的表达方式记录跟踪组织的重要数据元素及其变动，并利用它们之间各种可能的限制条件和关系来表达重要的业务规则。 数据模型必须在设计过程中保持统一的业务定义。为了满足将来不同的应用分析需要，逻辑数据模型的设计应该能够支持最小粒度的详细数据的存储，以支持各种可能的分析查询。同时保障逻辑数据模型能够最大程度上减少冗余，并保障结构具有足够的灵活性和扩展性。物理数据模型是逻辑数据模型在数据库中的具体实现，是数据库系统中实际数据的定义或主机文件系统中的文件结构定义，内容包括数据库内所有的表、视图、字段及其相关主键和外键的定义，以及系统内数据流向及系统间的数据交换关系。
元数据管理：元数据是关于数据的数据，描述了数据定义和属性。主要包括业务元数据、技术元数据和管理元数据。元数据管理的目的是厘清元数据之间的关系与脉络，规范元数据设计、 实现和运维的全生命周期过程。有效的元数据管理为技术与业务之间搭建了桥梁， 为系统建设、运维、业务操作、管理分析和数据管控等工作的开展提供重要指导。 元数据管理的内容主要包括元数据获取、元数据存储、元数据维护（变更维护、 版本维护）、元数据分析（血缘分析、影响分析、 实体差异分析、实体关联分析、 指标一致性分析、数据地图展示）、元数据质量管理与考核等内容。元数据管理的工具有：Atlas、Datahub等
数据生命周期管理：大数据业务系统，在运行过程中会产生大量历史数据，这些历史数据日积月累下来，除了增加集群的存储成本，也会影响大数据集群之上的应用系统的运行效率（因为整个大数据集群的hdfs, hive, hbase等存储引擎随着负担越来越大，其响应效率会有所降低）。
        所以数据治理会强调对数据进行全生命周期的管理，既要考虑数据的采集获取，也要考虑数据的备份归档。我们不能因为大数据集群本身具有可横向扩展，容量大，单位存储成本低这些特点，就对数据 “只进不出”。因为缺少了治理的数据集合，再多也不能称为“数据湖泊”，而是“数据沼泽”，是不利于数据价值的分析挖掘的。
        在大数据业界，对于数据的生命周期管理，普遍的做法是，根据业务特点，分析数据使用状况，将数据分为冷数据与热数据（更细致的还有温数据），然后对冷热数据采取不同的管理策略。常见的数据管理策略有：

• 利用云对象存储的力量：将热数据保存在当前大数据集群中支撑当前的业务系统，而将冷数据备份到云对象存储如oss, s3上；
• 冷热数据分集群存储：将热数据保存在当前大数据集群中支撑当前的业务系统，并搭建专门的冷数据集群，将冷数据转存到冷集群中；（冷集群更侧重存储能力，热集群更侧重计算能力，在集群底层服务器选型上各有侧重，从而均衡成本）；
• 利用hdfs本身提供的分级存储的策略：hdfs新版本本身（其实也不新了，从3.0开始就逐步完善这块了，详情见jira hdfs-2832,）也是支持tiered storage即分级存储的，可以对不同的目录，根据其数据冷热程度不同，动态配置不同的存储策略，从而存储到不同的底层存储介质上。可以使用的存储类型 storage types 有 archive, disk, ssd 和 ram_disk，可以配置的存储策略 storage policies 有 hot, warm, cold, All_SSD, One_SSD, Lazy_Persist and Provided。
• 直接删除冷数据：当前的大数据集群只保存业务需要的数据，而将业务不需要的历史数据，定期通过脚本进行删除。这种方式，因为需要删除数据，所有只有在业务方确认数据确实不需要了，而且公司真个成本又有限的情况下，才会使用。

参考：数据资产化的前提-浅谈数据治理体系的建设-阿里云开发者社区

治理经验

主要问题：

1. 公共层表复用度不高，ADS层共性未下沉
2. ADS层重复建设，跨应用/集市依赖
3. 命名规范、流程规范，公共层和应用层开发协作方式不明确

面临的挑战：

1. 治理成本高，价值不明显
2. 协作复杂，涉及ADS、CDM层多人协作
3. 维护成本高，难根治，容易出现新模型依赖有问题的模型

治理策略：①盘点存量、②规范增量、③日常化：通过数据化驱动，比如模型分等方式

从业务角度保障四点：①交付效率、②产出时效、③质量可靠、④成本可控

• 应用层核心是专注支持业务，需要考虑研发效率、交付数据口径一致性和稳定性。
• 通过集市规范来控制复杂度，通过轻度聚合的中间层确保口径统一，通过扁平化设计确保稳定。

  • 集市划分的原则有以下两点：

    • 原则一：以业务场景或者服务对象作为划分原则，对相似数据业务场景内聚抽象进行分类。

    • 原则二：集市划分需要统一标准，尽量符合MECE原则（"相互独立、完全穷尽"，即所谓的 "无重复、无遗漏"）。

• 公共层的核心是抽象复用来提升效率，需要考虑易用性和稳定性。通过规范和冗余宽表提升复用性，通过解耦来确保稳定性（比如划分主模型和扩展模型）。
• ODS 层的核心是合规高效，需要考虑接入效率和性能稳定。通过工具化提升效率、优化治理确保性能的稳定。特别是在数据达到一定量之后要考虑采用merge 的方式接入数据。

数据治理实践参考：大淘系数据模型治理最佳实践-CSDN博客

9. 三范式

第一范式-1NF：遵循原子性。即，表中字段的数据，不可以再拆分。
第二范式-2NF：在满足第一范式的情况下，遵循唯一性，消除部分依赖。比如出现只依赖联合主键其中一个的情况。通俗讲：一个表只能描述一件事情。
第三范式-3NF：在满足第二范式的情况下，消除传递依赖。即不能存在：A依赖B，B有依赖C这种情况

参考：什么是数据库三大范式,通俗讲解 一讲就懂_数据库三范式-CSDN博客

10. 数据仓库vs数据中台vs数据湖

数据中台

        数据中台是一套可持续“让企业数据用起来”的机制，是一种战略选择和组织形式，是依据企业特有的业务模式和组织架构，以有形的产品和实施方法论为支撑，构建的一套持续不断把数据变成资产并服务于业务的机制。
        从架构角度看，数据中台上承业务数据积累，通过自己的数据平台工具，将原始数据加工成数据资产，并通过数据资产服务化下起数据应用场景，帮助业务端或管理端降本增效。数据中台不止是一套生产加工的流程，它对企业的战略定位、组织保障、基础设施等方面都产生了深远影响。
        从实施角度看，数据中台是以数据资产为核心，以实现数据资产可见、可懂、可用、可运营的系列目的，配以平台工具、流程规范、应用建设等必要环节，最终落地的数据解决方案。
        在数据中台内部，具体又细分出开发工具层、数据资产层、资产管理层、数据服务层、数据运营体系、数据安全体系等模块。

数据湖

数据湖（Data Lake）是一种用于存储、管理和分析大量不同类型和格式的数据的集中式存储库。

数据湖是一种存储和管理数据的技术，它与数据仓库不同，数据湖储的是所有的原始数据、半结构化数据和非结构化数据，包括文本、图像、音频和视频等，这些数据通常不会进行处理和转换。数据湖是一种高度扩展解决方案，可以快速处理大量数据，提供了一种数据增长的架构化解决方案。因此，数据湖是一种灵活的数据存储系统，适合存储大量的半结构化数据。

与数据仓库不同，数据湖不需要在导入数据之前定义特定模式或具有特定数据结构。这意味着在数据湖中数据可以作为大型数据结构存储下来，并且基于事实进行分析。数据湖还支持实时数据处理，可以接收和处理来自多个源的数据，并进行分析。这使得数据湖比数据仓库更适合需要快速访问实时数据的应用。

通过使用数据湖，企业可以轻松访问所有的原始数据、半结构化数据和非结构化数据，并基于事实进行分析。数据湖也可以用于开发机器学习模型、处理大数据、流式数据分析等应用。

总之，数据湖提供了存储和处理海量数据的灵活解决方案，可以为企业数据驱动决策和应用程序提供更大的价值。

数据湖与数据仓库有什么区别？

总体来说，数据仓库适用于结构化数据存储和分析，主要用于支持企业的决策制定和战略规划BI；而数据湖适用于非结构化和半结构化数据存储和分析，主要用于大数据分析、机器学习等领域AI。

数据仓库是结构化的，而数据湖是半结构化或非结构化的。

数据仓库是经过处理和清洗的数据，存储在规范化的表格中，以便于查询和报表生成。而数据湖存储的是所有的原始数据、半结构化数据和非结构化数据，包括文本、图像、音频和视频等，这些数据通常不会进行处理和转换。

数据仓库是基于批处理技术的，而数据湖支持实时数据处理。

数据仓库通常将数据存储在一个预定义的结构中，数据也会按照定期批处理的方式进行处理和转化，以保证数据的准确性和一致性。而数据湖支持实时数据处理，能够接收和处理来自多个源的数据并进行分析。这使得数据湖比数据仓库更加适合需要快速访问实时数据的应用。

数据仓库中的数据是有所限制的，而数据湖中则没有。

因为数据仓库需要预定义表格，可能会在数据加载时发生截断，丢失由于规范化和转换过程造成的一些详细信息。但是，在数据湖中，数据可以存储在原始格式中，并且不需要事先定义表格，因此，数据可以作为一个大型数据结构存储下来并基于事实进行分析。

参考：什么是数据湖_数据湖简介_数据湖的优势以及应用场景-腾讯云开发者社区
参考：数据平台发展史-从数据仓库数据湖到数据湖仓 1-阿里云开发者社区
参考：数据平台发展史-从数据仓库数据湖到数据湖仓 2-阿里云开发者社区

11. 做过实时数仓吗

Flink和Spark Streaming的区别

12. OneData相关

OneData实施流程

维度设计

        维度建模中，将度量称为“事实”，将环境描述为“维度”，维度是用于分析事实所需要的多样环境。维度所包含的表示维度的列，称为维度属性。维度使用主键标识其唯一性，分两种：代理键和自然键，代理键是不具有业务含义的键，一般用于处理缓慢变化维；自然键是具有业务含义的键。
        维度的设计过程就是确定维度属性的过程，如何生成维度属性，以及所生成的维度属性的优劣，决定了维度使用的方便性，成为数据仓库易用性的关键。
        第一步：选择维度或新建维度。需保证维度的唯一性。
        第二步：确定主维表。此处的主维表一般是ODS表，直接与业务系统同步。
        第三步：确定相关维表。根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。比如商品表，与类目、SPU、卖家、店铺等维度存在关联关系。
        第四步：确定维度属性。第一阶段从主维表中选择维度属性或生成新的维度属性，第二阶段是从相关维表中选择维度属性或者生成新的维度属性。确定维度属性的几点提示：
        （1）尽可能生成丰富的维度属性。例如淘宝商品维度有近百个维度属性；
        （2）尽可能多地给出包括一些富有意义的文字性描述。尽量不要用编码，而是用真正的文字，在阿里维度建模中一般是编码和文字同时存在，如商品ID和商品名称，类目ID和类目名称。ID用于不同表之间的关联，名称一般用于报表标签；
        （3）区分数值型属性和事实。数值型的字段是作为事实还是维度属性，可以参考字段的一般用途。如果通常用于查询约束条件或分组统计，则是作为维度属性；如果通常用于参与度量的计算，则是作为事实。比如商品价格，可以用于查询约束条件或者统计价格区间的商品数量，此时是作为维度属性使用的；也可以用于统计某类目下商品的平均价格，此时是作为事实使用的。另外，如果数值型字段是离散值，则作为维度属性存在的可能性较大；如果数值型字段是连续的，则作为度量存在的可能性较大，但不绝对，需要同时参考字段的具体用途。
        （4）尽可能沉淀出通用的维度属性。有些维度属性获取需要进行比较复杂的逻辑处理，有些需要通过多表关联得到，或者通过单表的不同字段混合处理得到，或者通过对表单的某个字段进行解析得到。此时，需要将尽可能多的通用的维度属性进行沉淀。一方面，可以提高下游使用的方便性，减少复杂度；另一方面，可以避免下游使用解析时由于各自逻辑不同而导致口径不一致。比如淘宝商品的property字段，使用key:value方式存储多个商品属性。商品品牌就存储在此字段中。
        规范化与反规范化：将维度的属性层次合并到单个维度中的操作称为反规范化。处于易用性和性能的考虑，维表一般是很不规范化的。
        一致性维度和交叉探查：为解决独立型数据集市导致的严重不一致性问题，Kimball的“数据仓库总线架构”提供了一种分解企业级数据仓库规划任务的合理方法，通过构建企业范围内一致性维度和事实来构建总线架构。在进行交叉探查（不同数据域的事实合并在一起进行数据探查，如计算转化率等）时如果使用的维度不一致，将导致交叉探查存在问题。不一致的情况基本可以划分为维度格式和内容不一致两种类型。
        维度整合：将面向应用的数据转换为面向主题的数据仓库数据，本身就是一种集成。具体系在：
        1）命名规范的统一。
        2）字段类型的统一。
        3）公共代码及代码值的统一。
        4）业务含义相同的表的统一。主要依据高内聚低耦合的理念，将业务关系大、源系统影响差异小的表进行整合；将业务关系小、源系统影响差异大的表进行分而治之。通常有如下几种集成方式：
        （1）采用主从表的设计方式，将两个表或多个表都有的字段放在主表中（主要基本信息），从属信息分别放在各自的从表中。对于主表中的主键，要么采用复合主键、源主键和系统或表区别标志；要么采用唯一主键、“源主键和系统或表区别标志”生成新的主键。通常建议采用复合主键的方式。
         （2）直接合并，共有信息和个性信息都放在同一个表中。如果表字段的重合度较低，则会出现大量空值，对于存储或易用性会有影响，需谨慎选择。
         （3）不合并，因为源表的表结构及主键等差异很大，无法合并，使用数据仓库里的多个表存放各自的数据。
        此外，维表表级别的整合，有两种表现形式。
        一种是垂直整合，即不同的来源表包含相同的数据集，只是存储的信息不同。将其整合到一个维度模型中，丰富维度属性。比如淘宝会议源系统中有会员基础信息表、会员扩展信息表、淘宝会员等级信息表。
        第二种是水平整合，即不同的来源表包含不同的数据集，不同数据集之间无交叉，也可以存在部分交叉。如蚂蚁金服的会员数据有淘宝会员、1688会员、支付呢宝会员等。如何整合？如果存在交叉，则需要去重；如果不存在交叉，则需要考虑不同子集的自然键是否存在冲突，如果不冲突，则可以考虑将各子集的自然键作为整合后的表的自然键；另一种方式是设置超自然键，将来源表各子集的自然键作为联合主键的方式，并且在物理实现时将来源字段作为分区字段。
        维表拆分：基于①扩展性（高内聚低耦合，保持核心模型相对稳定性）、②效能（性能和成本）、③易用性三个原则进行考虑
        水平拆分：方案1主子维度，定义一个主维度存放公共属性，同时定义多个子维度；方案2是维护单一维度，包含所有可能的属性。
        垂直拆分：出于扩展性、产出时间、易用性等方面的考虑，设计主从维度。主维表存放稳定、产出时间早、热度高的属性；从维表存放变化较快、产出时间晚、热度低的属性。如阿里数仓中，设计了商品主维度（1:30产出）和商品扩展维度（3:00产出）。
        历史归档：在数据仓库中，可以借用前台数据库的归档策略，定期将历史数据归档至历史维表。阿里数仓中设计了商品维表和历史商品维表，每天将历史数据归档至历史商品维表。通过解析binlog日志，对物理删除映射为归档操作。