[版权声明] 本站所有资料由用户提供并上传，若内容存在侵权，请联系邮箱。资料中的图片、字体、音乐等需版权方额外授权，请谨慎使用。网站中党政主题相关内容(国旗、国徽、党徽)仅限个人学习分享使用，禁止广告使用和商用。

• 面向主题的 ：传统是面向应用。主题是信息系统中的数据综合、归类并进行分析利用的抽象；某一宏观分析领域所涉及的分析对象。（例如：销售分析就是分析领域，数据仓库主题就是“销售分析”）
• 集成的 ：数据仓库中的数据是为分析服务的，而分析需要多种广泛的不同数据源以便进行比较、鉴别，数据仓库的数据是从原有的分散的多个数据库、数据文件、用户日志中抽取来的，数据来源可能既有内部数据又有外部数据。(如：客户价值分析，需要存款业务、贷款业务、信用卡业务、理财业务等)

操作型数据与分析型数据之间差别很大：

• 数据仓库的每一个主题所对应的源数据，在原有的各分散数据库中有重复和不一致的地方，且来源于不同的联机系统的数据与不同的应用逻辑捆绑在一起.
• 数据仓库中的数据很难从原有数据库系统直接得到。数据在进入数据仓库之前，需要经过统一与综合

• 稳定的 ：数据仓库数据反映的是一段相当长的时间内历史数据的内容，是不同时点的数据库快照的集合，以及基于这些快照进行统计、综合和重组的导出数据。数据仓库的用户对数据的操作大多是数据查询或比较复杂的挖掘，一旦数据进入数据仓库以后，一般情况下被较长时间保留。数据经加工和集成进入数据仓库后是极少更新的，通常只需要定期的加载和更新。
• 反映历史变化的：数据仓库包含各种粒度的历史数据。数据仓库中的数据可能与某个特定日期、星期、月份、季度或者年份有关。虽然数据仓库不会修改数据，但并不是说数据仓库的数据是永远不变的。数据仓库的数据也需要更新，以适应决策的需要。数据仓库的数据随时间的变化表现在以下几个方面：
  1.数据仓库的数据时限一般要远远长于操作型数据的数据时限
  2.业务系统存储的是当前数据，而数据仓库中的数据是历史数据
  3.数据仓库中的数据是按照时间顺序追加的，都带有时间属性

• 整合企业业务数据，建立统一的数据中心；
• 产生业务报表，了解企业的经营状况；
• 为企业运营、决策提供数据支持；
• 可以作为各个业务的数据源，形成业务数据互相反馈的良性循环；
• 分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果；
• 开发数据产品，直接或间接地为企业盈利；

数据仓库与数据库的区别

数据库与数据仓库的区别实际讲的是 OLTP 与 OLAP 的区别。

• 数据仓库主要用于解决企业级的数据分析问题或者说管理和决策
• 数据仓库是为分析数据而设计，数据库是为捕获和存储数据而设计
• 数据仓库是面向分析，面向主题设计的，即信息是按主题进行组织的，属于分析型；数据库是面向事务设计的，属于操作型
  数据仓库在设计是有意引入数据冗余（目的是为了提高查询的效率），采用反范式的方式来设计；数据库设计是尽量避免冗余（第三范式），一般采用符合范式 的规则来设计
• 数据仓库较大，数据仓库中的数据来源于多个异构的数据源，而且保留了企业的 历史数据；数据库存储有限期限、单一领域的业务数据

数据仓库是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的大型数据库。

面向管理决策、面向分析（主题）
静态、不能直接更新；定时添加数据
高度结构化、满足第三范式	简单的、冗余的、满足分析的
访问量大；每次访问的数据量少	访问量小；每次访问的数据量大

数据集市（数据仓库子集）

数据仓库（DW）是一种反映主题的全局性数据组织。但全局性数据仓库往往太大，在实际应用中将它们按部门或业务分别建立反映各个子主题的局部性数据组织，即数据集市（Data Mart），有时也称它为部门数据仓库。

数据集市：可以按主体域组织划分，用于支持部门级的数据分析与决策。（如商品销售数仓：采购数据集、库存数据集和销售数据集市）

数据集市仅仅是数据仓库的某一部分，实施难度大大降低，并且能够满足企业内部部分业务部门的迫切需求，在初期获得了较大成功。但随着数据集市的不断增多，这种架构的缺陷也逐步显现。企业内部独立建设的数据集市由于遵循不同的标准和建设原则，以致多个数据集市的数据混乱和不一致，形成众多的数据孤岛。
企业发展到一定阶段，出现多个事业部，每个事业部都有各自数据，事业部之间的数据往往都各自存储，各自定义。每个事业部的数据就像一个个孤岛一样无法(或者极其困难)和企业内部的其他数据进行连接互动。这样的情况称为数据孤岛，简单说就是数据间缺乏关联性，彼此无法兼容。

• 性能：良好的数据模型能帮助我们快速查询所需要的数据，减少数据的I/O吞吐
• 成本：良好的数据模型能极大地减少不必要的数据冗余，也能实现计算结果复 用，极大地降低大数据系统中的存储和计算成本
• 效率：良好的数据模型能极大地改善用户使用数据的体验，提高使用数据的效率
• 质量：良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性

需要全面了解整个企业业务和数据 ； 实施周期非常长 ； 对建模人员的能力要求非常高。
釆用ER模型建设数据仓库模型的出发点是整合数据，将各个系统中的数据以整个企业角度按主题进行相似性组合和合并，并进行一致性处理，为数据分析决策服务，但是并不能直接用于分析决策。其建模步骤分为三个阶段：

• 高层模型：一个高度抽象的模型，描述主要的主题以及主题间的关系，用于描述 企业的业务总体概况
• 中层模型：在高层模型的基础上，细化主题的数据项
• 物理模型(也叫底层模型)：在中层模型的基础上，考虑物理存储，同时基于性能 和平台特点进行物理属性的设计，也可能做一些表的合并、分区的设计等。

维度模型（小型、敏捷）

维度建模从分析决策的需求出发构建模型，为分析需求服务，重点关注用户如何更快速地完成需求分析，同时具有较好的大规模复杂查询的响应性能。代表星型模型、雪花模型。设计分为以下步骤：

• 选择需要进行分析决策的业务过程。业务过程可以是：单个业务事件（支付、退款）；某个事件的状态（当前账户余额）；一系列相关业务事件组成的业务流程。
• 选择数据的粒度。分析需要细分的程度
• 识别维表。选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选
• 选择事实。确定分析需要衡量的指标

大多数企业实施数据仓库的经验说明：在不太成熟、快速变化的业务面前，构建ER模型的风险非常大，不太适合去构建ER模型。而维度建模对技术要求不高，快速上手，敏捷迭代，快速交付；更快速完成分析需求，较好的大规模复杂查询的响应性能。

数据仓库更多代表的是一种对数据的管理和使用的方式，它是一整套包括了数据建模、ETL（数据抽取、转换、加载）、作用调度等在内的完整的理论体系流程。

分层的主要原因是在管理数据的时候，能对数据有一个更加清晰的掌控

• 清晰的数据结构：作用域
• 将复杂的问题简单化：任务分解成多个步骤完成，每层只处理单一问题，比较容易理解和维护。
• 减少重复开发：开发一些通用的中间层数据，能减少极大的重复计算。
• 屏蔽原始数据的异常：不必改一次业务就需要重新接入数据。
• 数据血缘的追踪：一个业务表来源很多，如果一张来源出问题，借助血缘最终能快速准确定位问题，并清楚它的危害范围。

ADS (DM)：汇总得到业务相关的指标或数据
DWS 层：数据服务层。对DWD层的数据操做轻度的汇总，得到业务汇总表或宽表
DWD 层：数据明细层。对ODS层的数据做一定的数据清洗和转换。
ODS 层：离线或准实时数据接入（业务数据、日志数据、第三方数据）

ODS层数据的主要来源包括：

• 业务数据库。可使用DataX、Sqoop等工具来抽取，每天定时抽取一次；在实时 应用中，可用Canal监听MySQL的 Binlog，实时接入变更的数据；
• 埋点日志。线上系统会打入各种日志，这些日志一般以文件的形式保存，可以用 Flume 定时抽取；
• 其他数据源。从第三方购买的数据、或是网络爬虫抓取的数据；

• 业务相对简单和独立，可以将DWD、DWS进行合并
• 公共维度层（DIM）：基于维度建模理念思想，建立一致性维度；(贯穿DWD和DWS)
• TMP层 ：临时层，存放计算过程中临时产生的数据；(贯穿DWD和DWS)

事实数据表的主要特点是包含数字数据（事实），并且这些数字信息可以汇总，以提供有关单位作为历史的数据。事实表的粒度决定了数据仓库中数据的详细程度。
事实表根据数据粒度分为：

• 事务事实表：事务事实表记录的事务层面的事实，保存的是最原子的数据，也称“原子事实表”。数据的粒度通常是每个事务一条记录。数据插入就不再进行更改，其更新方式为增量更新（类似Binlog）。如订单表，通过事务事实表，还可以建立聚集事实表，为用户提供高性能的分析。
• 周期快照事实表：以具有规律性的、可预见的时间间隔来记录事实，时间间隔如每天、每月、每年等等。每个时间段一条记录（是在事务表上建立聚集表）。如销售日快照表(无论当天是否有销售发生，都记录一条)，历史至今、自然年至今、季度至今等。
• 累计快照事实表：周期快照事实表记录的确定的周期的数据，而累积快照事实表记录的不确定的周期的数据。累积快照事实表代表的是完全覆盖一个事务或产品的生命周期的时间跨度，它通常具有多个日期字段，用来记录整个生命周期中的关键时间点。另外，它还会有一个用于指示最后更新日期的附加日期字段。由于事实表中许多日期在首次加载时是不知道的，所以必须使用代理关键字来处理未定义的日期，而且这类事实表在数据加载完后，是可以对它进行更新的，来补充随后知道的日期信息。如本周，本月，本年累计销售表

维度表（维表）可以看作是用来分析数据的角度，纬度表中包含事实数据表中事实记录的特性。有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分析者提供有用的信息。时间、地域、物体维度。

事实是关注内容（销售额、量）；维度表是观察事务的角度（时间、地区）
人物、地点、时间（维度）发生什么事情（事实内容）。

星型模是一种多维的数据关系，它由一个事实表和一组维表组成。事实表中包含了大量数据，没有数据冗余；
维表是逆规范化的，包含一定的数据冗余。

雪花模式是星型模型的变种，维表是规范化的，模型类似雪花的形状。如地区维度存的是省市的ID，关联地理基本表。

星型模型存在数据冗余，所以在查询统计时只需要做少量的表连接，查询效率高；在数据冗余可接受的情况下，实际使用星型模型比较多。

数据仓库由多个主题构成，包含多个事实表，而维表是公共的，可以共享，这种模式可以看做星型模式的汇集，因而称作星系模式或者事实星座模式。

元数据（Metadata）是关于数据的数据。元数据打通了源数据、数据仓库、数据应用，记录了数据从产生到消费的全过程。元数据就相当于所有数据的地图，有了这张地图就能知道数据仓库中：

• 哪些数据经常被使用，哪些数据很少有人光顾

业内通常把元数据分为以下类型：

• 技术元数据：库表结构、数据模型、ETL程序、SQL程序等
• 业务元数据：业务指标、业务代码、业务术语等
• 管理元数据：数据所有者、数据质量、数据安全等

电商行业技术特点：技术新；技术范围广；分布式；高并发、集群、负载均衡；海量数据；业务复杂；系统安全。

• 网站前台。网站首页、商家首页、商品详细页、搜索页、会员中心、订单与支付相关页面、秒杀频道等；
• 运营商后台。运营人员的管理平台， 主要功能包括：商家审核、品牌管理、规格管理、模板管理、商品分类管理、商品审核、广告类型管理、广告管理、订单查询、商家结算等；
• 商家管理后台。入驻的商家进行管理的平台，主要功能包括：商品管理、订单查询统计、资金结算等功能；

数据仓库项目主要分析以下数据：

• 日志数据：启动日志、点击日志（广告点击日志）
• 业务数据库的交易数据：用户下单、提交订单、支付、退款等核心交易数据的分析

数据仓库项目分析任务：

每日新增会员数；每日、周、月活跃会员数；留存会员数、留存会员率 广告点击次数、广告点击购买率、广告曝光次数 订单数、成交商品数、支付金额

数据埋点，将用户的浏览、点击事件采集上报的一套数据采集的方法。

通过这套方法，能够记录到用户在App、网页的一些行为，用来跟踪应用使用的状况，后续用来进一步优化产品或是提供运营的数据支撑，包括访问数、访客数、停留时长、浏览数、跳出率。这样的信息收集可以大致分为两种：页面统计、统计操作行为。

主流的埋点实现方法如下，主要区别是前端开发的工作量：

• 手动埋点：开发需要手动写代码实现埋点，比如页面ID、区域ID、按钮ID、按钮位置、事件类型（曝光、浏览、点击）等，一般需要公司自主研发的一套埋点框架
  • 优点：埋点数据更加精准
  • 缺点：工作量大，容易出错
• 无痕埋点：不用开发写代码实现的，自动将设备号、浏览器型号、设备类型等数据采集。主要使用第三方统计工具，如友盟、百度移动、魔方等
• 缺点：埋点数据统一，不够个性化和精准

指标：对数据的统计值。如：会员数、活跃会员数、会员留存数；广告点击量；订单金额、订单数都是指标。指标构成：基础指标（不可拆分） + [ 修饰词 ] + 时间段

指标体系：将各种指标系统的组织起来，按照业务模型、标准对指标进行分类和分层；

没有数据指标体系的团队内数据需求经常表现为需求膨胀以及非常多的需求变更。每个人都有看数据的视角和诉求，然后以非专业的方式创造维度/指标的数据口径。最终滚雪球似的搭建难以维护的数据仓库

在建立指标体系时，要注重三个选取原则：准确、可解释、结构性

• 准确：核心数据一定要理解到位和准确，不能选错；
• 可解释：所有指标都要配上明确、详细的业务解释。如日活的定义是什么，是使用了App、还是在App中停留了一段时间、或是收藏或购买购买了商品；
• 结构性：能够充分对业务进行解读。如新增用户只是一个大数，还需要知道每个渠道的新增用户，每个渠道的新增转化率，每个渠道的新增用户价值等。

1.理清业务阶段及需求

创业期、上升期、成熟发展期，不同阶段关注的核心指标也是不同的。

• 业务前期：最关注用户量，此时指标体系应该紧密围绕用户量的提升来做各种维度拆解
• 业务中期：除了用户量走势，更重要是优化当前的用户量结构，如用户留存。
• 业务后期：关注产品变现能力和市场份额，关注收入指标、各种商业化模式的收入，同时做好市场份额和竞品的监控。

核心指标的波动必然是某种维度的波动引起，要监控核心指标，本质上还是要监控维度核心指标。

在分析“进入APP用户数”指标时，要关注渠道转化率，分析用户从哪里来；同时用户通过哪种方式打开的，如通过点击桌面图标、点击通知栏、点击Push等。停留时长不同用户特征和行为特性。

漏斗模型：每一个环节的关键指标都可以通过公式的形式进行拆解，在根据拆解公式逐个分析对应的影响因素。

4.指标宣贯、存档、落地

宣贯：告知所有相关业务人员。一是为下一步工作做铺垫；二是以防甩锅。
存档：对指标口径的业务逻辑进行详细的描述并存档，只有明确、清晰的定义才能明白指标的具体含义。建立核心指标的相关报表，实际工作中，报表会在埋点前建好的，这样的话一旦版本上线就能立刻看到数据，而且也比较容易发现问题。
落地：搭建主要是由产品经理主导完成的，业务人员需要配合产品经理选择并确认指标，这也是在建立之初最重要的一点。

Apache：完全开源免费；社区活跃；文档、资料详实。

第三方发行版（CDH / HDP / Fusion Insight华为）：版本管理清晰；兼容性、安全性、稳定性上有增强；提供了部署、安装、配置工具，大大提高了集群部署的效率；运维简单。提供了管理、监控、诊断、配置修改的工具。

• CDH：最成型的发行版本，拥有最多的部署案例。
• HDP：100%开源，可以进行二次开发，但没有CDH稳定。
• Fusion Insight：华为基于hadoop2.7.2版开发的，坚持分层，解耦，开放的原则，得益于高可靠性，在全国各地政府、运营商、金融系统有较多案例。

框架、软件尽量不要选择最新的版本，选择半年前左右稳定的版本

• 元数据管理：Atlas

• 机器成本考虑：物理机的价格 > 云主机的价格
• 运维成本考虑：物理机需要有专业的运维人员；云主机的运维工作由供应商完成，运维相对容易，成本相对较低

可以从计算能力(CPU、 内存)、存储量等方面着手考虑集群规模（假设：每台服务器20T硬盘，128G内存）。
假如：日活500w，每人每天100条日志，每条日志1K，不考虑历史数据以及半年不扩容，3个副本。

• 表命名（数据库表命名规则）： * ODS层： 命名规则：ods_{业务线|业务项目}[数据来源类型]{业务} ；* DWD层： 命名规则：dwd_{业务线|业务项目}{主题域}{子业务}； * DWS层： 命名规则：dws_{业务线|业务项目}{主题域}{汇总相关粒度}{汇总时间周 期} ；* ADS层： 命名规则：ads{业务线|业务项目}{统计业务}{报表form|热门排序topN} ；* DIM层： 命名规则：dim_{业务线|业务项目|pub公共}_{维度}

会员：以设备判断标准，每个独立设备认为一个会员（IMEI号/OpenUDID）；或手机号码等。
新增会员：每日新增会员数。第一次使用应用的用户。
活跃会员：每日，每周，每月的活跃会员数。每天打开，自然周启动过应用的会员。
会员留存：1日，2日，3日会员留存数、1日，2日，3日会员留存率。某段时间的新增会员，经过一段时间后，仍然继续使用应用是留存会员；这部分会员占当时新增会员的比例为留存率。

• 使用正则表达式匹配目录中的文件名
• 监控的文件中，一旦有数据写入，Flume就会将信息写入到指定的Sink
• 不会对跟踪文件有任何处理，不会重命名也不会删除
• 不支持Windows，不能读二进制文件。支持按行读取文本文件

• 根据日志数据量的大小，Jvm堆一般要设置为4G或更高
• -Xms -Xmx 最好设置一致，减少内存抖动带来的性能影响
• 存在的问题：Flume放数据时，使用本地时间；不理会日志的时间戳

前面 Flume Agent 的配置使用了本地时间，可能导致数据存放的路径不正确。要解决以上问题需要使用自定义拦截器.

采集启动日志(使用自定义拦截器)

• 给source增加自定义拦截器

采集启动日志和事件日志

本系统中要采集两种日志：启动日志、事件日志，不同的日志放置在不同的目录下。要想一次拿到全部日志需要监控多个目录。
2、修改自定义拦截器，不同来源的数据加上不同标志

自定义拦截器：编码完成后打包上传服务器，放置在$FLUME_HOME/lib 下。

• nohup，该命令允许用户退出帐户/关闭终端之后继续运行相应的进程
• /dev/null，代表linux的空设备文件，所有往这个文件里面写入的内容都会丢失，俗称黑洞
• ->/dev/null 标准输出1重定向到 /dev/null 中，此时标准输出不存在，没有任何地方能够找到输出的内容
• 2>&1 错误输出将会和标准输出输出到同一个地方

• 使用taildir source 监控指定的多个目录，可以给不同目录的日志加上不同header
• 在每个目录中可以使用正则匹配多个文件
• 使用自定义拦截器，主要功能是从json串中获取时间戳，加到event的header中
• hdfs文件的滚动方式（基于文件大小、基于event数量、基于时间）

3.ODS建表和数据加载

ODS层数据与源数据的格式基本相同。

数据文件中每行必须是一个完整的 json 串，一个 json串 不能跨越多行。
Hive 处理json数据总体来说有三个办法：

自定义UDF处理json串中的数组。自定义UDF函数：输入json串、数组的key；输出字符串数组。

 

 序列化是对象转换为字节序列的过程；反序列化是字节序列恢复为对象的过程；
对象的序列化主要有两种用途：
 
 

• 对象的持久化，即把对象转换成字节序列后保存到文件中

5.DWD层建表和数据加载

 
 

 json数据解析，丢弃无用数据（数据清洗），保留有效信息，并将数据展开，形成每日启动明细表。（ETL）
 
 

下一步任务：DWD（会员的每日启动信息明细） => DWS（如何建表，如何加载数据）

活跃会员指标需求：每日、每周（自然周）、每月（自然月）的活跃会员数

第一次使用应用的用户，定义为新增会员；卸载再次安装的设备，不会被算作一次新增。

某段时间的新增会员，经过一段时间后，仍继续使用应用认为是留存会员；这部分会员占当时新增会员的比例为留存率。

互联网平台通行的商业模式是利用免费的基础服务吸引凝聚大量用户，并利用这些用户资源开展广告或其他增值业务实现盈利从而反哺支撑免费服务的生存和发展。广告收入不仅成为互联网平台的重要收入之一，更决定了互联网平台的发展程度。

电商平台本身就汇聚了海量的商品、店铺的信息，天然适合进行商品的推广。对于电商和广告主来说，广告投放的目的无非就是吸引更多的用户，最终实现营销转化。因此非常关注不同位置广告的曝光量、点击量、购买量、点击率、购买率。

1、点击次数统计(分时统计)：曝光次数、点击次数、购买次数。
2、转化率-漏斗分析：点击率=点击次数/曝光次数；购买率=购买次数/点击次数
3、活动曝光效果评估：行为(曝光、点击、购买)、时间段、广告位、产品，统计对应的次数。时间段、广告位、商品，曝光次数最多的前N个

3.ODS层建表和数据加载

4.DWD层建表和数据加载

• action。用户行为；0 曝光；1 曝光后点击；2 购买
• place。广告位置；首页=1，左侧=2，右侧=3，列表页=4

6.漏斗分析(点击率购买率)

小结：分析简单，没有DWS层

执行命令，使用json配置文件；测试

编写执行脚本shell

1000W左右日活用户；按 30条日志 / 人天，合计3亿条事件日志；每条日志 650字节 左右；总数据量大概在180G；采集数据时间约2.5小时。

日志文件很大，可以将hdfs文件滚动设置为10G甚至更大

本主题是电商系统业务中最关键的业务，电商的运营活动都是围绕这个主题展开。

选取的指标包括：订单数、商品数、支付金额。对这些指标按销售区域、商品类型进行分析。

商家店铺表（shops）

业务数据保存在MySQL中，每日凌晨导入上一天的表数据。

• 表数据量少，采用全量方式导出MySQL
• 表数据量大，而且根据字段能区分出每天新增数据，采用增量方式导出MySQL

订单表、订单产品表、产品信息表

4.ODS层建表与数据加载

ODS层的表结构与源数据基本类似（列名及数据类型）。

DataX仅仅是将数据导入到了 HDFS ，数据并没有与Hive表建立关联。执行脚本使数据迁移、数据加载到ODS层。对于增量加载数据而言：初始数据加载；该任务仅执行一次，不在脚本中。

5.缓慢变化维与周期性事实表

缓慢变化维（SCD；Slowly Changing Dimensions）。在现实世界中，维度的属性随着时间的流失发生缓慢的变化（缓慢是相对事实表而言，事实表数据变化的速度比维度表快）。【修改历史记录】

维度属性值不做更改，保留原始值。

修改维度属性为最新值，直接覆盖，不保留历史信息。

在维度表中增加新的一列，原先属性列存放上一版本的属性值，当前属性列存放当前版本的属性值，还可以增加一列记录变化的时间。

缺点：只能记录最后一次变化的信息。

每天保留一份全量数据。
简单、高效。缺点是信息重复，浪费磁盘空间。
适用范围：维表不能太大

拉链表适合于：表的数据量大，而且数据会发生新增和变化，但是大部分是不变的（数据发生变化的百分比不大），且是缓慢变化的（如电商中用户信息表中的某些用户基本属性不可能每天都变化）。主要目的是节省存储空间。

数据量大、部分字段更新、记录修改比例不高、需要保留历史信息。（log操作日志表） 创建临时表

方案二：保存一段时间的增量数据(userinfo)，定期对拉链表做备份（如一个月做一次备份）；如需回滚，直接在备份的拉链表上重跑增量数据。处理简单

订单状态可以采用拉链表保存历史状态数据。

6.DIM层建表加载数据

DIM贯穿DWD和DWS，公共维度层。

把多层级变成单层级（递归变成for循环）宽表。

将商家店铺表、商家地域组织表组织成一张表，并拉宽。在一行数据中体现：商家信息、城市信息、地域信息。信息中包括 id 和 name ；

对ODS中表的信息做了裁剪，只保留了必要的信息（paymentId、paymentName）。

使用拉链表对商品信息进行处理：
1、历史数据 => 初始化拉链表(开始日期：当日；结束日期：)【只执行一
2、拉链表的每日处理【每次加载数据时处理】

• 新增数据。每日新增数据(ODS) => 开始日期：当日；结束日期：
• 历史数据。拉链表(DIM) 与 每日新增数据(ODS) 做左连接
  • 连接上数据。数据有变化，结束日期：当日；
  • 未连接上数据。数据无变化，结束日期保持不变；

7. DWD层建表加载数据

要处理的表有两张：订单表、订单产品表。

• 订单表是周期性事实表；为保留订单状态，可以使用拉链表进行处理；
• 订单产品表普通的事实表，用常规的方法进行处理；
  • 如果有数据清洗、数据转换的业务需求，ODS => DWD
  • 如果没有数据清洗、数据转换的业务需求，保留在ODS，不做任何变化。这个是本项目的处理方式

订单从创建到最终完成，是有时间限制的；业务上也不允许订单在一个月之后，状态仍然在发生变化.

8.DWS层建表及数据加载

• 全国、一级商品分类订单信息
• 全国、二级商品分类订单信息
• 大区、一级商品分类订单信息
• 大区、二级商品分类订单信息
• 城市、一级商品分类订单信息
• 城市、二级商品分类订单信息

需要的信息：订单表、订单商品表、商品信息维表、商品分类维表、商家地域维表
订单表 => 订单id、订单状态
订单商品表 => 订单id、商品id、商家id、单价、数量
商品信息维表 => 商品id、三级分类id
商品分类维表 => 一级名称、一级分类id、二级名称、二级分类id、三级名称、三级分类id
商家地域维表 => 商家id、区域名称、区域id、城市名称、城市id

订单表、订单商品表、商品信息维表 => 订单id、商品id、商家id、三级分类id、单价、数量（订单明细表）
订单明细表、商品分类维表、商家地域维表 => 订单id、商品id、商家id、三级分类名称、三级分类名称、三级分类名称、单价、数量、区域、城市 => 订单明细宽表

• 拉链表。创建、使用与回滚；商品信息表、订单表（周期性事实表；分区表+拉链表）
• 宽表（逆规范化）：商品分类表、商品地域组织表、订单明细及订单明细宽表（轻度汇总的事实表）

Airflow将一个工作流制定为一组任务的有向无环图（DAG），并指派到一组计算节点上，根据相互之间的依赖关系，有序执行。Airflow 有以下优势：

• 功能强大。支持多种不同类型的作业，可自定义不同类型的作业。如 Shell、Python、Mysql、Oracle、Hive等；
• 简洁优雅。作业的定义简单明了；
• 易扩展。提供各种基类供扩展，有多种执行器可供选择

Webserver 守护进程。接受 HTTP 请求，通过 Python Flask Web 应用程序与airflow 进行交互。Webserver 提供功能的功能包括：中止、恢复、触发任务；监控正在运行的任务，断点续跑任务；查询任务的状态，日志等详细信息。

Scheduler 守护进程。周期性地轮询任务的调度计划，以确定是否触发任务执行。

元数据（MetaData）狭义的解释是用来描述数据的数据。广义的来看，除了业务逻辑直接读写处理的那些业务数据，所有其它用来维持整个系统运转所需的信息／数据都可以叫作元数据。如数据库中表的Schema信息，任务的血缘关系，用户和脚本／任务的权限映射关系信息等。

管理元数据的目的，是为了让用户能够更高效的使用数据，也是为了让平台管理人员能更加有效的做好数据的维护管理工作。

血缘信息或者叫做Lineage的血统信息是什么，简单的说就是数据之间的上下游来源去向关系，数据从哪里来到哪里去。如果一个数据有问题，可以根据血缘关系往上游排查，看看到底在哪个环节出了问题。此外也可以通过数据的血缘关系，建立起生产这些数据的任务之间的依赖关系，进而辅助调度系统的工作调度，或者用来判断一个失败或错误的任务可能对哪些下游数据造成影响等等。

分析数据的血缘关系看起来简单，但真的要做起来，并不容易，因为数据的来源多种多样，加工数据的手段，所使用的计算框架可能也各不相同，此外也不是所有的系统天生都具备获取相关信息的能力。而针对不同的系统，血缘关系具体能够分析到的粒度可能也不一样，有些能做到表级别，有些甚至可以做到字段级别。

业务属性信息都有哪些呢？如一张数据表的统计口径信息，这张表干什么用的，各个字段的具体统计方式，业务描述，业务标签，脚本逻辑的历史变迁记录，变迁原因等，此外还包括对应的数据表格是由谁负责开发的，具体数据的业务部门归属等。数据的业务属性信息，首先是为业务服务的，它的采集和展示也就需要尽可能的和业务环境相融合，只有这样才能真正发挥这部分元数据信息的作用。

为什么要做数据质量监控

企业早期没有进行统一规划设计，大部分信息系统是逐步迭代建设的，系统建设时间长短各异，各系统数据标准也不同。企业业务系统更关注业务层面，各个业务系统均有不同的侧重点，各类数据的属性信息设置和要求不统一。另外，由于各系统的相互独立使用，无法及时同步更新相关信息等各种原因造成各系统间的数据不一致，严重影响了各系统间的数据交互和统一识别，基础数据难以共享利用，数据的深层价值也难以体现。
由于企业信息系统的孤立使用，各个业务系统或模块按照各自的需要录入数据，没有统一的录入工具和数据出口，业务系统不需要的信息就不录，造成同样的数据在不同的系统有不同的属性信息，数据完整性无法得到保障。
没有统一的数据管理平台和数据源头，数据全生命周期管理不完整，同时企业各信息系统的数据录入环节过于简单且手工参与较多，就数据本身而言，缺少是否重复、合法、对错等校验环节，导致各个信息系统的数据不够准确，格式混乱，各类数据难以集成和统一，没有质量控制导致海量数据因质量过低而难以被利用，且没有相应的数管理流程。
海量数据多头管理，缺少专门对数据管理进行监督和控制的组织。企业各单位和部门关注数据的角度不一样，缺少一个组织从全局的视角对数据进行管理，导致无法建立统一的数据管理标准、流程等，相应的数据管理制度、办法等无法得到落实。同时，企业基础数据质量考核体系也尚未建立，无法保障一系列数据标准、规范、制度、流程得到长效执行。
各个信息系统针对数据的标准规范不一、编码规则不一、校验标准不一，且部分业务系统针对数据的验证标准严重缺失，造成了企业顶层视角的数据出现“一物多码”、“一码多物”等现象。

数据质量监控的设计要分为4个模块：数据，规则，告警和反馈
①数据：需要被监控的数据，可能存放在不同的存储引擎中
②规则：值如何设计发现异常的规则，一般而言主要是数值的异常和环比等异常监控方式。也会有一些通过算法来发掘异常数据的方法
③告警：告警是指发告警的动作，这里可以通过微信消息，电话或者短信，邮件
④反馈：反馈是指对告警内容的反馈，比如说收到的告警内容，要有人员回应该告警消息是否是真的异常，是否需要忽略该异常，是否已经处理了该异常。有了反馈机制，整个数据监控才能形成闭环

• 最开始可以先关注核心要监控的内容，比如说准确性，那么就对核心的一些指标做监控即可
• 监控平台尽量不要做太复杂的规则逻辑，尽量只对结果数据进行监控。比如要监控日质量是否波动过大，那么把该计算流程提前，先计算好结果表，最后监控平台只监控结果表是否异常即可
• 多数据源。多数据源的监控有两种方式：针对每个数据源定制实现一部分计算逻辑，也可以通过额外的任务将多数据源中的数据结果通过任务写入一个数据源中，再对该数据源进行监控
• 实时数据监控：区别在于扫描周期的不同，因此在设计的时候可以先以离线为主，但是尽量预留好实时监控的设计

• 作用：任务（命令）定时调度（如：定时备份，实时备份）

分钟 小时 日期 月份 星期 需要执行命令

• *代表所有的取值范围内的数字。如月份字段为*，则表示1到12个月；
• / 代表每一定时间间隔的意思。如分钟字段为*/10，表示每10分钟执行1次；
• - 代表从某个区间范围，是闭区间。如2-5表示2,3,4,5，小时字段中0-23/2表示在0~23点范围内每2个小时执行一次；

注：由于各个地方每周第一天不一样，因此Sunday=0（第1天）或Sunday=7（最后1天）。

数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。

数据仓库建模：维度建模、ER建模

Flume采集日志数据、DataX采集业务数据（数据的全量或增量）.

会员活跃度分析、广告业务分析、核心交易分析；
Json数据的处理、动态分区、拉链表、宽表(逆规范化)、Tez引擎（缺点：对资源要求高）

椭圆的定义和标准方程（一）

掌握椭圆的定义，会用定义解题；

掌握椭圆的标准方程及其简单的几何性质，熟练地进行基本量间

掌握求椭圆的标准方程的基本步骤——①定型（确定它是椭圆）；②定位（判断它

的中心在原点、焦点在哪条坐标轴上）；③定量（建立关于基本量的方程或方程组，解基

，焦点到相应准线的距离（焦准距）等于