数据仓库

数据为什么要分层 1.清洗数据结构，每一层都有其特定作用域 2.数据血缘追踪 ，数据出现问题，快速定位到源表。 3.减少重复开发 ，会有中间层数据。 4.复杂问题简单化，每一层具有特定的数据层功能。 5.屏蔽源数据的异常 来源： https://www.cnblogs.com/tangsonghuai/p/11443895.html

总线架构是数据仓库建设的总体规划，从整体视角描述了解决方案的维度模型，描述了各个子系统的功能以及关系，描述数据从源系统到决策系统的数据流程，提供建立企业数据仓库系统的增量式方法。业务需求回答了要做什么，总线架构就是回答怎么做的问题。 一、数据仓库整体解决方案架构 数据仓库的核心功能从源系统抽取数据，通过清洗、转换、标准化，将数据加载到BI平台，进而满足业务用户的数据分析和决策支持。数据仓库整体解决方案架构包含三个部分：源数据、 数据仓库、数据应用。 二、数据仓库分层架构： 数据仓库的数据来源于不同的源数据，并提供多样的数据应用，数据自下而上流入数据仓库后向上层开放应用，而数据仓库可以是数据中心管控平台。 源数据层（ODS）：此层数据无任何更改，直接沿用外围系统数据结构和数据，不对外开放；为临时存储层，是接口数据的临时存储区域，为后一步的数据处理做准备，一般只会进行数据筛选和异常处理。 数据转换层（DSA）：数据加工区域，主要涉及数据的转换数据，清洗数据，过滤数据等操作。 数据仓库层（EDW）：DW 层的数据应该是一致的、准确的、干净的数据，即对源系统数据进行了清洗（去除了杂质）后的数据。 数据应用层（DA 或 APP）：前端应用直接读取的数据仓库；根据报表、专题分析需求而计算生成的数据，数据仓库是数据处理的后台，业务用户并不关心后台怎么处理。数据应用是数据呈现的前台

第一阶段：目标解读 　　在建立用户画像前，首先需要明确用户画像服务于企业的对象，根据业务方需求，未来产品建设目标和用户画像分析之后预期效果； 第二阶段：任务分解与需求调研 　　经过第一阶段的需求调研和目标解读，我们已经明确了用户画像的服务对象与应用场景，接下来需要针对服务对象的需求侧重点，　　　　结合产品现有业务体系和“数据字典”规约实体和标签之间的关联关系，明确分析纬度； 第三阶段：需求场景讨论与明确 　　在本阶段，数据运营人员需要根据前面与需求方的沟通结果，输出《产品用户画像规划文档》，在该文档中明确画像应用场景、最终开发出的标签内容与应用方式 ，并就该份文档与需求方反复沟通确认无误。 第四阶段：应用场景与数据口径确认 　　经过第三个阶段明确了需求场景与最终实现的标签纬度、标签类型后，数据运营人员需要结合业务与数据仓库中已有的相关表，明确与各业务场景相关的数据口径。在该阶段中，数据运营方需要输出《产品用户画像实施文档》，该文档需要明确应用场景、标签开发的模型、涉及到的数据库与表，应用实施流程； 第五阶段：特征选取与模型数据落表 　　本阶段中数据分析挖掘人员需要根据前面明确的需求场景进行业务建模，写好HQL逻辑，将相应的模型逻辑写入临时表中，抽取数据校验是否符合业务场景需求。 第六阶段：线下模型数据验收与测试 　　数据仓库团队的人员将相关数据落表后，设置定时调度任务

ylbtech-DB-MDM：MDM/主数据管理 百科 主数据 管理（MDM Master Data Management） 描述了一组规程、技术和解决方案 ，这些规程、技术和解决方案用于 为所有利益相关方 （如 用户、应用程序、 数据仓库 、流程以及贸易伙伴 ）创建并维护业务数据的 一致性、完整性、相关性和精确性 。 1. 返回顶部 1、 中文名：主数据管理 外文名：MDM Master Data Management 关 键：管理 简 称：MDM 目录 1 概述 2 数据集成 3 管理 ▪ MDM应用程序法 ▪ MDM平台法 ▪ MDM应用程序法与MDM平台法的不同 ▪ 多领域数据管理 ▪ 主数据管理 4 降低成本 5 最佳实践 2、 2. 返回顶部 1、 概述 主数据 管理的关键就是“管理”。主数据管理不会创建新的数据或新的数据纵向结构。相反，它提供了一种方法， 使企业能够有效地管理存储在分布系统中的数据 。主数据管理使用现有的系统，它从这些系统中获取最新信息，并提供了先进的技术和流程，用于自动、准确、及时地分发和分析整个企业中的数据，并对数据进行验证。 主数据管理解决方案具有以下特性： ·在企业层面上整合了现有纵向结构中的客户信息以及其他知识和深层次信息 · 共享所有系统中的数据 ，使之成为一系列以客户为中心的业务流程和服务 ·实现对于客户、产品和供应商都通用的主数据形式

本次讨论的主题是：对于数据产品经理的突出能力，你更看重哪一方面？ 问题描述： 现在有两个产品可能会和你合作： 1、 一个产品，不懂技术细节，但是能给你带来业务价值，能帮你把数仓推广到全公司，帮你在老板前露脸 2、另一个产品，对数仓很了解，甚至能帮你设计一套数据仓库，可能比你设计的还好，但是其他方面一般般，比较偏研发 这两个产品，你会选哪个做你们的合作伙伴？请说出你的理由！ 分析： 本话题是一个发散性的话题，并没有限制太多的内容，主要是想跟大家讨论一下在实际工作中我们会更希望产品经理具有哪一方面的能力，又是为什么这么选。 对于这个问题，我感觉还是应该分情况来讨论。毕竟是“你”想要的伙伴，那么选择哪一种其实是由“你”现在所处的位置、“你”的能力、“你”想要获得的收益、“你”想要实现的目标等多种主观跟客观的因素共同决定的。所以在讨论中才会出现各种两种不同的声音。而对于我来说，我想我会在以下三种情况下进行不同的衡量与选择： 我自身的开发能力很强，不需要产品为我解决技术上的问题。那我会选择第一种，技术问题我来搞定，但是我需要产品为我打通老板及各个部门间的关系，说服他们支持我们的数仓建设，能让我们引入数据并将数据打通。也需要产品能很好地理解业务场景，让我少花时间在业务理解上的同时也让技术能实实在在地落实于业务中。 我自身开发能力较差，又希望能有个懂业务也懂技术的人带一下我，那我会选择第二种

1.整理 sql的where各种条件 2.整理 sql的group 3.整理 sql的join 4. 04txt文件的案例 9句sql 5.整理刚才分享的小知识点 6.补充资料文件夹 去看看执行 7.彩蛋 视频 sql 1.整理 sql 的 where 各种条件 where 子句 　　如需有条件地从表中选取数据，可将 where 子句添加到 SELECT 语句。 语法 SELECT 列名称 FROM 表名称 WHERE 列 运算符 值 下面的运算符可在 where 子句中使用： 操作符 描述 = 等于 <> 不等于 > 大于 < 小于 >= 大于等于 <= 小于等于 BETWEEN 在某个范围内 LIKE 搜索某种模式 2.整理 sql 的group 聚合函数 (比如 SUM) 常常需要添加 group by语句。 group by语句 　　group by语句用于结合聚合函数，根据一个或多个列对结果集进行分组。 语法 SELECT column_name, aggregate_function(column_name) FROM table_name where column_name operator value group bycolumn_name 3.整理 sql 的 join join分为inner join、left join、right join，分别表示内联结

　　最近在看《Pentaho Kettle 解决方案》，看到 ETL子系统，发现信息量比较大，用简短的语句做一下笔记。 　　ETL子系统有34种子系统，被分成4个部分：抽取、清洗和更正、发布、管理。 一、抽取 　子系统1：数据剖析系统 　　指从不同源系统中搜集数据的统计信息或其他相关信息的过程，目的是分析不同数据源的结构和内容。 　子系统2：增量数据捕获系统 　　目的是捕获系统里的数据的变化。由于数据量大以及网络的延迟，数据完成初始加载后，不应再把数据重新加载一边，为了识别出有变化或更新的数据，增加时间戳或快照的方式。 　子系统3：抽取系统 　　从不同数据源抽取数据，并输入到ETL流程里。 二、清洗和更正 　　几乎没有什么数据是不存在问题的，因此数据加载到数据仓库之前要增加一些步骤来清洗和更正这些数据。另外，每个系统存储数据得方式不同，比如有些数据源里，性别表示为 0，1；有些数据源里用“男”，“女”表示，存进数据仓库里面应该有统一的规范。 　子系统4：数据清洗和质量处理系统 　　这个过程主要是修改和整理进入到 ETL 流程的脏数据，提高数据的质量。 　子系统5：错误事件处理 　　错误事件处理的目的是记录下 ETL 过程中的每一个错误。这样便于管理员定期监控和分析错误。 　子系统6：审计纬度 　　审计维度表是一类特殊的维度表，数据仓库里的所有事实表都和审计纬度表关联

元数据（Meta Data），主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及 ETL 的任务运行状态。一般会通过元数据资料库（Metadata Repository）来统一地存储和管理元数据，其主要目的是使数据仓库的设计、部署、操作和管理能达成协同和一致。元数据是数据仓库管理系统的重要组成部分，元数据管理是企业级数据仓库中的关键组件，贯穿了数据仓库的整个生命周期，使用元数据驱动数据仓库的开发，使数据仓库自动化，可视化。 　　构建数据仓库的主要步骤之一是 ETL。这时元数据将发挥重要的作用，它定义了源数据系统到数据仓库的映射、数据转换的规则、数据仓库的逻辑结构、数据更新的规则、数据导入历史记录以及装载周期等相关内容。数据抽取和转换的专家以及数据仓库管理员正是通过元数据高效地构建数据仓库。 用户在使用数据仓库时，通过元数据访问数据，明确数据项的含义以及定制报表。数据仓库的规模及其复杂性离不开正确的元数据管理，包括增加或移除外部数据源，改变数据清洗方法，控制出错的查询以及安排备份等。 一、元数据类型 ​　　元数据可分为技术元数据、业务元数据和管理过程元数据。 　　1、 技术元数据为开发和管理数据仓库的 IT 人员使用，它描述了与数据仓库开发、管理和维护相关的数据，包括数据源信息、数据转换描述、数据仓库模型、数据清洗与更新规则、数据映射和访问权限等。 　　2、

本文源自于 Rebooting Web of Trust 组织在 RWOT IX — Prague, 2019 会议上的论文《 Encrypted Data Vaults 》的第二部分。继上一部分介绍了当前加密数据仓库的方法和体系结构、派生的要求、设计目标以及开发者在实现数据存储时应意识到的风险之后，本部分将主要讲述 数据存储系统的常见用例 、 需求分析 以及 建设加密数据仓库的一些指导原则和设计目标 。下一期我们将带来《Encrypted Data Vaults》的最后一部分，探讨加密数据仓库的架构及一些安全和隐私方面的考虑等问题。 原文： https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/encrypted-data-vaults.md 作者（按字母顺序）：Amy Guy、David Lamers、Tobias Looker、Manu Sporny 和 Dmitri Zagidulin 贡献者（按字母顺序）：Daniel Bluhm 和 Kim Hamilton Duffy 一、核心用例 以下四个用例是数据存储系统常见的应用模式，但绝不是唯一的用例。 1. 存储和使用数据 用户希望将数据存储在安全的位置，但不希望存储服务提供商能够看到他存储的任何数据

本文源自于 Rebooting Web of Trust 组织在 RWOT IX — Prague, 2019 会议上的论文《 Encrypted Data Vaults 》的最后一部分。继上一部分介绍了数据存储系统的常见用例、需求分析以及建设加密数据仓库的一些指导原则和设计目标，本部分我们将探讨 加密数据仓库的架构及一些安全和隐私方面 的问题。 原文： https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/encrypted-data-vaults.md 作者（按字母顺序）：Amy Guy、David Lamers、Tobias Looker、Manu Sporny 和 Dmitri Zagidulin 贡献者（按字母顺序）：Daniel Bluhm 和 Kim Hamilton Duff 一、体系结构 本节介绍了加密数据仓库协议的体系结构。在本文中，将数据仓库视为服务器，而客户端则是数据仓库进行交互的接口。 加密数据仓库协议的体系结构是自然分层的，基础层由具有最少功能的业务系统组成，而更高级的功能则位于其上。在实现的时候，既可以选择仅实现基础层，也可以选择实现由更丰富功能集组成的其它层，以实现更高级的用例。 图 | 网络 1.1 部署拓扑 根据用例，我们考虑以下部署拓扑： 仅移动设备