will001449的博客

每个企业都哟两个层次的决策：企业决策和个人决策。企业决策是在一种正式的规范环境下完成的，而个人决策是一种即兴的、个体的非正式的决策。个人分析师可以通过面向个人分析环境的各种工具查看企业数据或个人数据，在做个人分析时并没有时间限制。个人决策是动态的，而个人的分析环境一般是个人的电脑，常使用EXCEL进行。EXCEL有很多优点：提供自主性：分析师可以自由的利用任何公式录入任何数据并且随时进行更改 速成：公式化和结构化处理，不需要学习工具使用的技术 功能灵活：便于修改，适合所有类型的分析 成本低廉：没有

分析可以贯穿整个计算环境使用，企业计算中最重要的环境之一就是作业环境。作业环境是进行详细、即时决策的场所之一。作业环境主要由办公人员使用，作业环境有而是处理企业业务的场所。大多数企业都有两种基本的环境：既有作业化境也有管理决策环境。有一些标准能促使作业环境取得成功，其中一些标准涵盖了以下功能：创建、更新和删除单个事务 访问数据 具备事务处理的完整性 处理大量的数据 系统性的处理数据 快速执行由于这些因素，在作业系统中快速访问和处理数据的能力是最为重要的。事务处理响应事件是作业环境中最重要的要

大数据分为重复型数据和非重复型数据，重复型数据的处理相对容易，而非重复型环境中的每一个数据单元都需要单独进行解释，因此处理相对复杂。大数据环境中的非重复型数据的例子包括：电子邮件数据 呼叫中心数据 企业合同 质保索赔 保险索赔当有文本进入大数据环境时，大数据中存储的数据单元是非重复型的。采用搜索技术是处理非重复型数据的方式之一。搜索技术可以用于完成扫描数据的任务，而搜索技术存在的缺陷在于一方面，搜索技术只是搜索数据，并不能产生一个可以随后用于分析的数据库；另一方面，搜索技术不能查找或者

分析的基础概念和实践都是通用的，这些概念和实践可以应用于重复型分析。分析有两种不同的类型：开放式连续分析和基于项目的分析。开放式连续分析常用于企业的结构化数据领域，但是在重复型数据领域很少使用。在开放式连续分析中，分析是从数据的收集开始，对数据进行提炼和分析，当完成数据分析后就会根据分析结果做出决策，通过决策的使用收集更多的原始数据重复分析过程。另一种类型的分析系统是基于项目的分析，对于基于项目的分析而言，其目的是仅做一次分析。一个调查究竟 应该进行一次还是经常进行却决于围绕着该调查的基础设施。对于

数据既是信息技术的产物，又是支撑。经过多年的信息技术的发展，数据已经形成了自己特有的科学领域，包括数据治理、数据分析、数据架构等。由于数据非常复杂，数据架构包含了很多方面，其中以下四个方面最有意义：数据的物理表现形式 数据的逻辑联系 数据的内部格式 数据的文件结构数据架构在各自具有意义的特点上不断演化：大数据给组织带来了新的信息和决策机会，同时也具有着巨大的潜力。大数据和已有系统的整体流程如下：原始大数据分为重复型和非重复型，这两种数据的处理方式和接口完全不同。重复型原始大数据的

计算机信息技术

DataVault是一个BI系统，包括建模、方法论、架构和实施四个方面。DataVault的组件包括以下四个：DataVault建模（对模型性能和可扩展性的更改） DataVault方法论（遵循Scrum和敏捷最佳实践） DataVault架构（包含NoSQL系统和大数据系统） DataVault实施（基于模式、自动化生成能力成熟度模型集成——CMMI第五层及）DataVault有很多特殊之处，在面向企业数据仓库建模方法中吸收了软件开发最佳实践中的一些经验常识，包括CMMI、六西格玛管理、全面质

数据仓库的发展是由最早的管理主文件的磁带文件系统发展而来的。从磁盘存储取代了磁带存储之后出现了DBMS，再之后出现了OLTP，伴随着第四代编程语言的出现和PC的跨越性升级，为了保证数据的完整性，数据仓库应运而生。...

大数据的发展时间线如下图：大数据的发展从3个V到4个V再到现在有人提出5个V，人们不断的在扩展大数据的定义。但是目前普遍的大数据技术人员都认定大数据4个V的概念：以非常大的数据量存储的数据（Volume） 数据的增长速度和处理速度很快（Volecity） 数据具有多源、多渠道、多平台和多架构的多样化（Variety） 数据价值具有低密度化（Value）大数据的定义决定了大数据的特征：以非常大的数据量存储的数据；存储在廉价的存储器中的数据；通过分布式方法管理的数据；以非结构化格式存储和管.

企业数据包括企业中的所有数据，企业的全体数据分为两大类：结构化数据和非结构化数据。结构化数据就是指存在数据库表中的数据，一般由DBMS进行管理；非结构化数据则包括文本、音视频等不方便访问的数据。下表对结构化数据和非结构化数据进行了对比：结构化数据与非结构化数据 结构化数据 非结构化数据 定义良好 没有被计算机识别的结构 可预测的 不可预见的 方便访问 不方便访问 快速定位 解析查找 非结构化数据又可以进一步的划分成两种基

建立实时ETL数据仓库的解决方案需要理解不同的整合技术，这个领域体现了具有新技术、新方法、新词汇的全新理念。通过选择合适的实时ETL技术、特征、方法来指导专业实验数据仓库构建实时ETL的四个过程：调研：实时数仓技术的状态、历史以及业务情况 描述：区分组织的实时需求的方式、方法 评估：针对实时报告以及整合服务机制，对每一个方法提供最合适的技术并进行分析 判定：按需求分类，通过选择技术途径以及方法论上指导ETL工作组对于快速执行的垂直系统，数据仓库要完成决策任务，要给操作系统反馈丰富的信息，使这个系

书中本章主要介绍的是ETL的人员组织架构，而非技术内容，各企业和团队由于自身原因并不能做到书中这样的组织架构，但是相关的职责要明确。当数据仓库团队建立的时候，通常需要3个专家，下列角色为数仓项目初始阶段所需要的角色，其中次要角色用括号表示：数据模型师（项目经理）：必须受过维度数据模型建模的专门训练，学习过维度模型的理论 ETL架构师/程序员（DW架构师）：ETL程序员以及ETL架构师通常是SQL和数据库的专家，这个人负责建立ETL系统、数据仓库环境的技术架构并负责涉及物理的ETL流程 应用专家（业务

由于ETL是数据仓库得核心，时常承担着管理和存储数据仓库大量元数据得职责。在数据仓库中ETL处理程序是元数据最重要得创建者——数据沿袭。数据沿袭追踪数据从源系统和文件中得请确位置直到最终被装载之前。数据血统包括数据库系统的数据定义和在数据参考古中最终静止状态。元数据分为后台元数据和前端元数据，后台元数据是与处理相关的，指导抽取清洗装载工作；前端元数据更偏向描述性和使我们的查询工具和报表工具更加稳定。后台将数据加载到数据仓库，同时指明数据来源，而前端元数据主要是为终端用户服务的，可以作为描述所有数据的业务数据

ETL开发完成后，主要工作是执行ETL开发的这些过程

本篇主要介绍ETL工具包、数据评估系统、数据清洗系统和可用的脚本语言。书中介绍的一些厂商的工具包比较早，不太符合目前的主流市场，因此我们只是简单介绍一下，并不推荐大家使用。书中介绍的ETL工具包的产品如下：Ab Initio Ascential DataStage BusinessObjects Data Integrator Cognos DecisionStream Computer Associates Advantage Data Transformation CrossAcces

装载数据新表的首次加载需要处理一次加载极大量数据的情况，在ETL系统中通常进行以下处理：单独处理数据插入 利用批量加载工具 并行加载 最小化物理更新 在数据库外进行聚合ETL过程应该最小化那些通过数据库批量加载所完成的更新和插入操作。如果需要大量的更新，应该通过批量加载工具截断和重新加载整个事实表。当更新量很小时，分离那些需要更新的记录，对其单独的处理。在数据仓库中，数据量不大时采用全量的快照装载，当数据量过大时一般使用增量装载，这也是在数仓中最常用的装载方式。增量加载用于周期性的加载

事实表装有企业的度量数据，每一个度量都是被模型化到事实表中的一条记录。度量是指：通过工具或比例等级可以测量观察的数量值。事实表包含度量，维度表包含关于度量的上下文，这种关于事务的简单试图是最终用户直观理解数据仓库的方式。每一个事实表通过表的粒度来定义。事实表的粒度是事件度量的定义。粒度的定义必须按照现实的，物理的度量意义来定义，然后才考虑维度和事实表中的其它字段等其它因素。所有的事实表包含了一组关联到维表的外键，而这些维表提供了事实表度量的上下文。大多数的事实表还包括了一个或者多个称为事实的数值型的度量

小维度和大维度数据仓库中许多记录都是在小表中，表中记录很少，字段只有一两个。创建这些表时应当保留最初的源表，经常会有新的记录添加。小维度可能出现在很多数据集市中，

维表是数据仓库的核心，它提供了事实表的上下文，是查看数据的入口。维表的基础结构如下图：物理上所有的维度都应该是上表的子集。维表的字段所连接的事实表的字段即为事实表的外键。维表和事实表通过单一字段连接的性能是最高的，当外键为数字类型时事实表是最为紧凑的。谈到这里我们要介绍两个概念，代理键和自然键。代理键是指无意义的主键，它是维表中一条数据的唯一标识；自然键是维表中的字段，可以是一个字段也可以是多个字段，它通常是源系统中有意义的主键。当维表是静态的并且不随时间而变化的，则代理键和自然键是一一对应的；如.

过滤器及其度量在数据体系中，总会有一些数据看起来没什么问题，一旦联系了上下文或者和其它数据放在一起就会发现数据存在问题，我们称这样的数据为异常数据。在监测数据异常时，通常采用一下方式：数据采样：对有问题的列进行分组，计算该表的行数，可以使用数据评估工具约束类型：把各种不同类型的数据质量检查分为四大类型 √ 列属性约束：保证由源系统输入的数据包含系统的期望值，列属性约束检查的过滤器包括：检查列的空值、超出期望的最高和最低范围的数值、长度超长和超短的列、包含有效值列表之外的数值、匹配所...

在ETL系统中，数据的抽取和加载只是改变了数据的格式和数据的位置，而真正改变数据价值的恰恰是清洗和规范化的步骤，这对于数据能否用于预期目标起了决定性的作用。清洗和规范化包含三个重要的可提交内容：数据评估报告 错误事件事实表 审计维关于数据评估报告主要针对的是数据质量，数据质量应该保证数据的精确性，精确的数据意味着：正确的：数据的值正确 明确的：数据值的描述清晰 一致的：固定标识，相同值的描述方式相同 完整的：数据值不为空，数据总数完整设计目标数据质量子系统为了完成初始化的目标需要支

时光荏苒，岁月穿梭，转眼间已经停更了好几天了，原因是因为笔者最近遇到了悲催的数据库问题，关于问题和解决我们到时候单开一个模块，今天这篇接着聊数仓ETL的数据抽取。从不同平台进行抽取每一个数据源可能是不同的DBMS甚至不同的系统平台。在企业级的数据仓库建设中，要做好连接到限定系统的准备。如果ETL工具为了连接到源系统而使用特别庞杂的语言，应该将源系统的数据导成平面文件形式。在实际生产中，经常使用ODBC来连接不同的DBMS：书中花了一定的篇幅介绍了主机系统（小机）作为数据源时的一些注意事.

源数据抽取是数据流主线的第一步，在数据抽取时应抽取什么样的数据、利用什么工具抽取、抽取的指标是什么、抽取的数据如何交给下游等将在本篇详细说明。逻辑数据映射的设计在物理设计之前必须进行ETL的逻辑映射来确保无法跟踪数据的情况产生，逻辑数据映射的设计包括一下几方面：有一个逻辑数据映射的规划 确定候选的数据源 使用数据评估工具来分析源系统 接收数据线和业务规则的遍历 充分理解数据仓库的数据模型 验证计算和公式的有效性逻辑数据的映射文档通常用EXCEL或者一张关系型表来表示，其中的内容包括：

为什么要介绍ETL中的数据结构？前面我们说过了什么是数据集结，不同的数据结构在集结区里的意义和作用不尽相同，我们应该根据不同的数据结构来规划和设计集结区，从而来支持所需的元数据。元数据是个大话题，就连本书的作者在书中也都是围绕着元数据来谈数仓的。数据应该存在哪？数据的存储要么在内存，要么在硬盘。两者的利弊大家都很清楚，前者访问速度快但数据已丢失，后者虽能保证数据安全但是I/O成本太高，如何在二者中均衡是针对业务的所有架构设计的挑战，无论在关系型数据库还是在数仓中，我们的目标都应该是：将数据以最快

本来这一篇是要详细写写ETL的需求部分，比如业务需求、合规需求等。但是码了一百多字发现大部分内容和上一篇都是重复的，因此决定本篇详细讲讲数据仓库的架构。架构中关于元数据、质量控制等我们不多做介绍了，还是详细说说后台和前台。先来看一张图数据后台主要是负责数据管理的，也是ETL工具集的工作空间。数据后台是不允许用户访问的，所有的抽取、清洗、规格化和提交的动作都是在数据后台进行的；而数据前台是数据的展示区，是提供给最终用户访问的。数据前台中有一个非常重要的部分——数据集市。 数据集市是为了满足业务流.

上一篇简单介绍了一下阿里大神团队研发的数据抽取的工具——DataX，还是那句话，DataX的强大远远比介绍的多得多，有时间大家自己搭建一下、使用一下就了解了。本篇我们来介绍ETL的另一条主线，规划与设计主线。规划与设计主线规划与设计主线的第一步是描述所有需求和现状，需要强调的是所有！应为需求不细致、现状不明确、不贴合业务的数仓搭建的失败案例比比皆是，历来需求分析都是项目中最耗时也是最重要的一步。需求包括如下几方面：业务需求 数据评估和数据源现状 监察需求 安全需求 数据集成 数据.

昨天硬着头皮写了篇数据流的说明，本来今天想写规划与设计主线的说明。但是！早上坐地铁的时候看了B站讲的大数据数仓工具数据抽取的部分，想了想应该详细介绍一下ODS层的抽取工具，主流工具有很多，本篇选用DataX 3.0进行讲解，一下简称DataX。什么是DataXDataX 是阿里巴巴集团内被广泛使用的离线数据同步工具/平台，实现包括 MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、D

上篇说到ETL的设计需要同时考虑两条主线，一条是数据流主线，一条是规划与设计主线。二者其一是数据为主导，从数据的抽取、清洗、规格化到加载给“最终用户”；其二是以业务为主导，从需求现状、架构、开发实现到测试发布。两者相辅相成缺一不可啊。下面我们来详细说说数据流主线每一步的含义。数据流主线抽取数据抽取是ETL工具的第一步。企业中存在许多业务系统，包括财务系统、ERP系统、CRM系统、OA系统等。每个系统都有支撑业务的独立数据库，即使为了系统间的交互有些场景共用同一套数据库，大部分也是由不同的实例

上文书我们说到，大英雄ETL手持两把钢鞭，一条上刻着：需求/现状 -> 架构 -> 实现 -> 测试/发布；另一条隐约闪现着：抽取 -> 清洗 -> 规格化 -> 提交 的字样。大英雄闷闷不乐，因为这俩家伙事儿不一样长。。。。。。为什么是两条线？为什么ETL设计时是这两条线并存。其一我们从名字上就能看出，“E”（抽取）、“T”（转换）、“L”（加载），说的就是数据流的处理，这条线也是ETL的功能主线；而ETL的设计使用是要针对不同企业的不同场景，因此没有一种ETL

最近在看Ralph Kimball写的数据仓库ETL工具箱，虽说这本书距今看历史悠久，有些架构和设计可能也不符合现在互联网公司的架构要求，但是就我自己来说技术这东西我还是喜欢从头看起。一种技术的从无到有再到“家喻户晓，没他不行”的状态，定经历了需求——实现——问题——解决问题——越来越多的问题——颠覆性变革——主流产品，这么个过程。凡事知其因才能晓其果。当让，就职场而言，一种技术只要你会运用能掌握，面试的时候人本家问你的时候能遮过去，干活的时候能对付上就够了。再不济能根据公司的业务场景修修改改，弄个开源放到