普通的操作型数据库主要面向事务性处理，而数据仓库中的所有数据一般按照主题进行划分。主题是对业务数据的一种抽象，是从较高层次上对信息系统中的数据进行归纳和整理。
面向主题的数据可以划分成两部分----根据原系统业务数据的特点进行主题的抽取和确定每个主题所包含的数据内容。例如客户主题、产品主题、财务主题等；而客户主题包括客户基本信息、客户信用信息、客户资源信息等内容。分析数据仓库主题的时候，一般方法是先确定几个基本的主题，然后再将范围扩大，最后再逐步求精
面向操作型的数据库通常是异构的、并且相互独立，所以无法对信息进行概括和反映信
息的本质。而数据仓库中的数据是经过数据的抽取、清洗、切换、加载得到的，所以为了保证数据不存在二义性，必须对数据进行编码统一和必要的汇总，以保证数据仓库内数据的一致性。数据仓库在经历数据集成阶段后，使数据仓库中的数据都遵守统一的编码规则，并且消除许多冗余数据。
·
数据仓库中的数据反映的都是一段历史时期的数据内容，它的主要操作是查询、分析而
不进行一般意义上的更新（数据集成前的操作型数据库主要完成数据的增加、修改、删除、查询），一旦某个数据进入到数据仓库后，一般情况下数据会被长期保留，当超过规定的期限才会被删除。通常数据仓库需要做的工作就是加载、查询和分析，一般不进行任何修改操作，是为了企业高层人员决策分析之用。
数据仓库不断从操作型数据库或其他数据源获取变化的数据，从而分析和预测需
数据仓库的发展大致经历了这样的三个过程：
通过数据仓库建设的发展阶段，我们能够看出，数据仓库的建设和数据集市的建设的重要区别就在于数据模型的支持。因此，数据模型的建设，对于我们数据仓库的建设，有着决定性的意义。
是一种逻辑概念，用来存放数据的仓库，通过数据库软件来实现，数据库由许多表组成，表是二维的，一张表里面可以有很多字段，数据库的表，在与能够用二维表现多维关系。
是数据库概念的升级。从逻辑上理解，数据库和数据仓库没有区别，都是通过数据库软件实现的存放数据的地方，只不过从数据量来说，数据仓库要比数据库更庞大得多。数据仓库主要用于数据挖掘和数据分析，辅助领导做决策。
数据库与数据仓库的区别实际讲的是OLTP与OLAP的区别。
分析型处理，叫联机分析处理OLAP（On-LineAnalyticalProcessing）一般针对某些主题的历史数据进行分析，支持管理决策。
数据仓库是要涵盖所有业务领域，还是各个业务领域独自建设，业务领域内的业务线也同样面临着这个问题。所以要构建大数据数据仓库，就需要了解各个业务领域、业务线的业务有什么共同点和不同点，以及各个业务线可以细分为哪几个业务模块，每个业务模块具体的业务流程又是怎样的。业务调研是否充分，将会直接决定数据仓库建设是否成功。
了解业务系统的业务后不等于说就可以实施数仓建设了，还需要收集数据使用者的需求，及找分析师、运营人员、产品人员等了解他们对数据的诉求。通常需求调研分下面两种途径：
1.根据与分析师、运营人员、产品人员的沟通获取需求。
2.对现有报表、数据进行研究分析获取数据建设需求。
(h5,web,app)
accountstring,appIdstring,appVersionstring,carrierstring,deviceIdstring,deviceTypestring,eventIdstring,ipstring,latitudedouble,longitudedouble,netTypestring,osNamestring,osVersionstring,propertiesmap
ETL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据
主要是从业务库把数据抽取到数据仓库或者把日志采集到数据仓库
sqoop和datax作为2款优秀的数据同步工具，备受数据开发人员喜爱，如何选择也是件非常头疼的事，下面就这两种工具来分析分析吧...
sqoop是apache旗下一款“Hadoop中的各种存储系统（HDFS、HIVE、HBASE）和关系数据库（mysql、oracle、sqlserver等）服务器之间传送数据”的工具。
导入数据：MySQL，Oracle导入数据到Hadoop的HDFS、HIVE、HBASE等数据存储系统
导出数据：从Hadoop的文件系统中导出数据到关系数据库mysql等Sqoop的本质还是一个命令行工具。
底层工作机制
将导入或导出命令翻译成MapReduce程序来实现
在翻译出的MapReduce中主要是对InputFormat和
OutputFormat进行定制
DataX是一个异构数据源离线同步工具，致力于实现包括关系型数据库(MySQL、Oracle等)、HDFS、Hive、ODPS、HBase、FTP等各种异构数据源之间稳定高效的数据同步功能。
核心架构
DataX本身作为离线数据同步框架，采用Framework+plugin架构构建。将数据源读取和写入抽象成为Reader/Writer插件，纳入到整个同步框架中。
核心模块介绍
DataX完成单个数据同步的作业，我们称之为Job，DataX接受到一个Job之后，将启动一个进程来完成整个作业同步过程。DataXJob模块是单个作业的中枢管理节点，承担了数据清理、子任务切分(将单一作业计算转化为多个子Task)、TaskGroup管理等功能。
DataXJob启动后，会根据不同的源端切分策略，将Job切分成多个小的Task(子任务)，以便于并发执行。Task便是DataX作业的最小单元，每一个Task都会负责一部分数据的同步工作。
切分多个Task之后，DataXJob会调用Scheduler模块，根据配置的并发数据量，将拆分成的Task重新组合，组装成TaskGroup(任务组)。每一个TaskGroup负责以一定的并发运行完毕分配好的所有Task，默认单个任务组的并发数量为5。
每一个Task都由TaskGroup负责启动，Task启动后，会固定启动Reader—>Channel—>Writer的线程来完成任务同步工作。
DataX作业运行起来之后，Job监控并等待多个TaskGroup模块任务完成，等待所有TaskGroup任务完成后Job成功退出。否则，异常退出，进程退出值非0
DataX调度流程：
举例来说，用户提交了一个DataX作业，并且配置了20个并发，目的是将一个100张分表的mysql数据同步到odps里面。DataX的调度决策思路是：
DataXJob根据分库分表切分成了100个Task。
根据20个并发，DataX计算共需要分配4个TaskGroup。
4个TaskGroup平分切分好的100个Task，每一个TaskGroup负责以5个并发共计运行25个Task。
下面以datax抽取mysql数据写入hdfs为例：
功能
datax
sqoop
运行模式
单进程多线程
mr
hive读写
单机压力大
扩展性好
分布式
不支持
支持
运行信息
流量控制
社区
开源不久，不太活跃
活跃
对于sqoop和datax，如果只是单纯的数据同步，其实两者都是ok的，但是如果需要集成在大数据平台，还是比较推荐使用datax，原因就是支持流量控制，支持运行信息收集，及时跟踪数据同步情况。
大数据私房菜提了一个问题
那么你们公司使用的是sqoop还是datax呢？是怎么考虑的？
附：
（有很多朋友私信问datax能操作哪些数据库或者文件，以下把datax各子工程贴出来了，下面有的就是支持的，否则就需要二次开发了）
ApacheFlume是一个从可以收集例如日志，事件等数据资源，并将这些数量庞大的数据从各项数据资源中集中起来存储的工具/服务。flume具有高可用，分布式和丰富的配置工具，其结构如下图所示：
Flume：是一个数据采集工具；可以从各种各样的数据源（服务器）上采集数据传输（汇聚）到大数据生态的各种存储系统中（Hdfs、hbase、hive、kafka）；
开箱即用！（安装部署、修改配置文件）
Flume是一个分布式、可靠、和高可用的海量日志采集、汇聚和传输的系统。
Flume可以采集文件，socket数据包（网络端口）、文件夹、kafka、mysql数据库等各种形式源数据，又可以将采集到的数据(下沉sink)输出到HDFS、hbase、hive、kafka等众多外部存储系统中
一般的采集、传输需求，通过对flume的简单配置即可实现；不用开发一行代码！
Flume针对特殊场景也具备良好的自定义扩展能力，因此，flume可以适用于大部分的日常数据采集场景
Flume中最核心的角色是agent，flume采集系统就是由一个个agent连接起来所形成的一个或简单或复杂的数据传输通道。
对于每一个Agent来说,它就是一个独立的守护进程(JVM),它负责从数据源接收数据，并发往下一个目的地，如下图所示：
每一个agent相当于一个数据(被封装成Event对象)传递员，内部有三个组件：
Source：采集组件，用于跟数据源对接，以获取数据；它有各种各样的内置实现；
Sink：下沉组件，用于往下一级agent传递数据或者向最终存储系统传递数据
Channel：传输通道组件，用于从source将数据传递到sink
采集需求：比如业务系统使用log4j生成的日志，日志内容不断增加，需要把追加到日志文件中的数据实时采集到hdfs
根据需求，首先定义以下3大要素
采集源，即source——监控文件内容更新:exec‘tail-Ffile’
下沉目标，即sink——HDFS文件系统:hdfssink
Source和sink之间的传递通道——channel，可用filechannel也可以用内存channel
配置文件编写：
Logstash是一个开源的服务器端数据处理管道，它可以同时从多个源中提取数据，对其进行转换，然后将其发送其他存储。
主要由inputfilter和output组成
原始日志文件：
[2019-01-1400:02:11][INFO]-com.test.pushTest(PushMessageExecutor.java:103)-消息推送结果:响应状态(200)、状态描述(成功。)、响应反馈()、请求响应耗时(232ms),deviceToken:7b64436eeea34a3ab4e0873b0682ad98e,userId:1659034,auId:null,globalMessageId:2d09f8d389524c1f9c66b61,appId:p_ios,title:null,subTitle:null,alertBody:请及时查阅。.
配置文件demo：
解析结果：
{"message"=>"[2019-01-1400:02:11][INFO]-com.test.pushTest(PushMessageExecutor.java:103)-消息推送结果:响应状态(200)、状态描述(成功。)、响应反馈()、请求响应耗时(232ms),deviceToken:7b64436eeea34a3ab4e0873b0682ad98e,userId:1659034,auId:null,globalMessageId:2d09f8d389524c1f9c66b61,appId:p_ios,title:null,subTitle:null,alertBody:请及时查阅。.","@version"=>"1","@timestamp"=>"2019-01-17T01:16:06.468Z","host"=>"xy1","path"=>"/data/liuzc/test_log/test-2019-01-14.log","type"=>"aa","time_local"=>"2019-01-1400:02:11","log_level"=>"INFO","pushExecute"=>"com.test.pushExecute(PushMessageExecutor.java:103)","apns_push_result"=>"消息推送结果:响应状态(200)、状态描述(成功。)、响应反馈()、请求响应耗时(232ms)","deviceToken"=>"7b64436eeea34a3ab4e0873b0682ad98e","userId"=>"1659034","auId"=>"null","globalMessageId"=>"2d09f8d389524c1f9c66b61","appId"=>"p_ios","title"=>"null","subTitle"=>"null","alertBody"=>"请及时查阅。."}
Logstashgrok在线验证地址：
lLogstash和flume都能作为日志采集工具
lLogstash是由ruby开发，flume使用java语言开发
lLogstash每起一个进程，默认占用1G内存，如果进程起的多的话给应用服务器带来很大的压力
数据清洗的任务是过滤那些不符合要求的数据
数据转换的任务主要进行不一致的数据转换、数据粒度的转换，以及一些业务规则的计算。
下面会介绍模型建设
数据同步到其他存储系统，如mysql，hbase
数据存储在hdfs，包含元数据和主数据的存储
数据建模简单来说就是基于对业务的理解，将各种数据进行整合和关联，并最终使得这些数据可用性，可读性增强，让使用方能快速的获取到自己关心的有价值的信息并且及时的作出响应，为公司带来效益。
数据建模是一套方法论，主要是对数据的整合和存储做一些指导，强调从各个角度合理的存储数据。
·进行全面的业务梳理，改进业务流程。
在业务模型建设的阶段，能够帮助我们的企业或者是管理机关对本单位的业务进行全面的梳理。通过业务模型的建设，我们应该能够全面了解该单位的业务架构图和整个业务的运行情况，能够将业务按照特定的规律进行分门别类和程序化，同时，帮助我们进一步的改进业务的流程，提高业务效率，指导我们的业务部门的生产。
·建立全方位的数据视角，消灭信息孤岛和数据差异。
·解决业务的变动和数据仓库的灵活性。
通过数据模型的建设，能够很好的分离出底层技术的实现和上层业务的展现。当上层业务发生变化时，通过数据模型，底层的技术实现可以非常轻松的完成业务的变动，从而达到整个数据仓库系统的灵活性。
·帮助数据仓库系统本身的建设。
通过数据仓库的模型建设，开发人员和业务人员能够很容易的达成系统建设范围的界定，以及长期目标的规划，从而能够使整个项目组明确当前的任务，加快整个系统建设的速度。
有了合适的数据模型，是会带来很多好处的：
所以大数据系统需要数据模型方法来更好的组织和存储，以便在性能,成本，效率和质量之间取的平衡。
PowerDesigner：
powerdesigner是能进行数据库设计的强大的软件，是一款开发人员常用的数据库建模工具。使用它可以分别从概念数据模型(ConceptualDataModel)和物理数据模型(PhysicalDataModel)两个层次对数据库进行设计。在这里，概念数据模型描述的是独立于数据库管理系统(DBMS)的实体定义和实体关系定义；物理数据模型是在概念数据模型的基础上针对目标数据库管理系统的具体化。
辐射状企业信息工厂(CIF)方法由BillInmon及业界人士倡导的。在这个环境下，数据从操作性数据源中获取，在ETL系统中处理，将这一过程称为数据获取，从这一过程中获得的原子数据保存在满足第三范式的数据库中，这种规范化的原子数据的仓库被称为CIF架构下的企业级数据仓库(EDW)
与Kimball方法相似，CIF提倡企业数据协调与集成，但CIF认为要利用规范化的EDW承担这一角色，而Kimball架构强调具有一致性维度的企业总线的重要作用
Inmon企业级数据仓库的分析数据库通常以部门为中心（而不是围绕业务过程来组织），而且包含汇总数据，并不是原子级别数据，如果ETL过程中数据所应用的业务规则超越了基本概要，如部门改名了或者其他的类似计算，要将分析数据库与EDW原子数据联系起来将变得很困难
Inmon架构是自顶向下，即从数据抽取-->数据仓库-->数据集市，以数据源为导向，是一种瀑布流开发方法，模型偏向于3NF，
Kimball:架构是自下向上，即从数据集市(主题划分)-->数据仓库-->数据抽取，是以需求为导向的，一般使用星型模型
Inmon架构下，不强调事实表和维表的概念，因为数据源变化可能会比较大，更加强调的是数据清洗的工作
kimball架构强调模型由事实表和维表组成，注重事实表与维表的设计
Inmon架构中，数据集市有自己的物理存储，是真实存在的。
Kimball数据仓库架构中，数据集市是一个逻辑概念，只是多维数据仓库中的主题域划分，并没有自己的物理存储，也可以说是虚拟的数据集市。是数据仓库的一个访问层，是按主题域组织的数据集合，用于支持部门级的决策。
Inmon架构是以部门为中心，而Kimball架构是以业务过程为中心
Inmon架构中用户可以直接访问企业数据仓库(EDW)
Kimball架构中用户不可以直接访问企业数据仓库(EDW)，只能访问展现区数据
企业开发中一般选择Kimball维度建模
生成业务模型，主要解决业务层面的分解和程序化
生成领域模型，主要是对业务模型进行抽象处理，生成领域概念模型。
生成逻辑模型，主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。
生成物理模型，主要解决，逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题。
ER模型是属于三范式的，是企业级的主题抽象而不是单独描述某个业务
当分类不可再分时，这种关系是规范化的，一个低级范式分解转换为更高级的范式时，就叫做规范化
数据表可以分为1-5NF，第一范式是最低要求，第五范式则是最高要求
最常用的范式有第一范式（1NF）、第二范式（2NF）、第三范式（3NF）
表中的每一列都是不可拆分的原子项
由上图可知，phone字段里面存了2个值，具有可分割性，不符合1NF，可以改成：
第二范式要同时满足下面两个条件：
上图可以看出，如果一个用户下了很多订单，则用户名，收获地址和手机号有重复出现的情况造成数据冗余，很明显不太符合第二范式，可以改成：
第三范式要同时满足下面两个条件：
简单点说，关系重复，能互相推导出来
如上图所示，如果知道了zip邮编，其实是能推出来省市区的，相反，知道了省市区，也是可以推出邮编的，有传递依赖，造成了冗余，不符合第三范式，需要改造:
在关系数据模型设计中，一般需要满足第三范式的要求。如果一个表有良好的主外键设计，就应该是满足3NF的表。
规范化带来的好处是通过减少数据冗余提高更新数据的效率，同时保证数据完整性。然而，我们在实际应用中也要防止过度规范化的问题。规范化程度越高，划分的表就越多，在查询数据时越有可能使用表连接操作。
而如果连接的表过多，会影响查询的性能。关键的问题是要依据业务需求，仔细权衡数据查询和数据更新的关系，制定最适合的规范化程度。还有一点需要注意的是，不要为了遵循严格的规范化规则而修改业务需求。
维度建模是一种将大量数据结构化的逻辑设计手段，包含维度和指标，它不像ER模型目的是消除冗余数据，维度建模是面向分析，最终目的是提高查询性能，所以会增加数据冗余，并且违反三范式。
其中最常用的其实是星型模型
在多维分析的商业智能解决方案中，根据事实表和维度表的关系，又可将常见的模型分为星型模型，雪花型模型及星座模型。在设计逻辑型数据的模型的时候，就应考虑数据是按照星型模型，雪花型模型还是星座模型进行组织。
指存储有事实记录的表，如系统日志、销售记录等；事实表的记录在不断地动态增长，所以它的体积通常远大于其他表。
事实表作为数据仓库建模的核心，需要根据业务过程来设计，包含了引用的维度和业务过程有关的度量。
作为度量业务过程的事实，一般为整型或浮点型的十进制数值，有可加性，半可加性和不可加性三种类型
最灵活最有用的事实是完全可加，可加性度量可以按照与事实表关联的任意维度汇总。比如订单总金额
一些度量是完全不可加的，例如：比率。对非可加事实，一种好的方法是，分解为可加的组件来实现聚集
维度表（DimensionTable）或维表，有时也称查找表（LookupTable），是与事实表相对应的一种表；它保存了维度的属性值，可以跟事实表做关联；相当于将事实表上经常重复出现的属性抽取、规范出来用一张表进行管理。常见的维度表有：日期表（存储与日期对应的周、月、季度等的属性）、地点表（包含国家、省／州、城市等属性）等。维度是维度建模的基础和灵魂。
下钻是商业用户分析数据的最基本的方法。下钻仅需要在查询上增加一个行头指针，新行的头指针是一个维度属性，附加了sql语言的groupby表达式，属性可以来自任何与查询使用的事实表关联的维度，下钻不需要预先存在层次的定义，或者是下钻路径。
有时，维度除了主键外没有其他内容，例如，当某一发票包含多个数据项时，数据项事实行继承了发票的所有描述性维度外键，发票除了外键无其他项，但发票数量仍然是在此数据项级别的合法维度键。这种退化维度被放入事实表中，清楚的表明没有关联的维度表，退化维度常见于交易和累计快照事实表中。
星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余，如在地域维度表中，存在国家A省B的城市C以及国家A省B的城市D两条记录，那么国家A和省B的信息分别存储了两次，即存在冗余。
当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的维度表，形成一些局部的"层次"区域，这些被分解的表都连接到主维度表而不是事实表。如图，将地域维表又分解为国家，省份，城市等维表。它的优点是:通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。
星座模型是由星型模型延伸而来，星型模型是基于一张事实表而星座模式是基于多张事实表，并且共享维度表信息，这种模型往往应用于数据关系比星型模型和雪花模型更复杂的场合。星座模型需要多个事实表共享维度表，因而可以视为星形模型的集合，故亦被称为星系模型
通过对比，我们可以发现数据仓库大多数时候是比较适合使用星型模型构建底层数据Hive表，通过大量的冗余来减少表查询的次数从而提升查询效率，星型模型对OLAP的分析引擎支持比较友好，这一点在Kylin中比较能体现。而雪花模型在关系型数据库中如MySQL，Oracle中非常常见，尤其像电商的数据库表。在数据仓库中雪花模型和星座模型的应用场景比较少，但也不是没有，所以在具体设计的时候，可以考虑是不是能结合两者的优点参与设计，以此达到设计的最优化目的。
建立核心模型与扩展模型体系，核心模型包括的宇段支持常用的核心业务，扩展模型包括的字段支持个性化或少量应用的需要，不能让扩展模型的宇段过度侵人核心模型，以免破坏核心模型的架构简洁性与可维护性。
越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用层实现，不要让公共逻辑多处同时存在。
适当的数据冗余可换取查询和刷新性能，不宜过度冗余与数据复制。
不改变处理逻辑，不修改代码的情况下重跑任务结果不变
字段命名及定义必须一致
表命名需清晰、一致，表名需易于使用方理解
DataVaultDanLinstedt发起创建的一种模型，它是模型的衍生，其设计的出发点也是为了实现数据的整合，但不能直接用于数据分析决策。它强调建立一个可审计的基础数据层，也就是强调数据的历史性、可追溯性和原子性，而不要求对数据进行过度的一致性处理和整合；
同时它基于主题概念将企业数据进行结构化组织，并引入了更进一步的范式处理来优化模型，以应对源系统变更的扩展性。DataVault型由以下几部分组成。
DataVault模型比ER模型更容易设计和产出，它的ETL加工可实现配置化。
进一步规范化处理，其核心思想是所有的扩展只添加而不是修改，因此将模型规范到6NF，基本编程了K-V结构化模型。
那么总的来说，分为三个阶段：
数据仓库一般分为三层，自上而下分别为数据贴源层（ODS，OperationDataStore）、数据公共层（CDM，CommonDataModel）和数据应用层（ADS，ApplicationDataService）。
贴源层，与业务库保持一致，不做任何处理
数据公共层CDM（CommonDataModel，又称通用数据模型层），包括DIM维度表、DWD,DW和DWS，由ODS层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标
公共维度层（DIM）：基于维度建模理念思想，建立企业一致性维度。降低数据计算口径和算法不统一风险。公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应。
明细粒度事实层（DWD）：对数据进行规范化编码转换，清洗，统一格式，脱敏等，不做横向整合
主题宽表层(DW)对dwd各种信息进行整合，输出主题宽表(面向业务过程，不同业务过程的信息不冗余建设，采用外键形式)
公共汇总粒度事实层（DWS）：以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。
公共汇总粒度事实层的表通常也被称为汇总逻辑表，用于存放派生指标数据。
数据应用层ADS（ApplicationDataService）：面向业务需求定制开发，存放数据产品个性化的统计指标数据。
建表表名一律小写
表名命名规则：[层次].[业务]_[表内容]_[周期+处理方式]
表名命名规则：[层次].[主题]_[表内容]_[周期+处理方式]主题在dw层以后，表内容参考业务系统表名，做适当处理，分表规则可以没有
如：ods.test_order_info_df
ods表示层次，test表示主题，order_info表示表内容，d表示周期(天)，f表示处理方式(全量抽取)
如：order_amt订单金额
如：order_idvarcharcomment‘订单id’
order_statustinyintcomment‘1：已支付2：已发货3：已签收’
根据实际需求选择字段类型
目前90%以上的分区表都是以日期分区的，当然，一些日志表还是有二级分区，如三端日志
需要新增一个词根的时候，需要部门评审，看看是否有必要新增，并且如果确定下来需要新增的话如何命名
比如cnt这个词代表的意思是count数量，如果之前词根里面没有的话，理论上来说，新增该词根是没毛病的
指标的定义(口径)需要与业务方，运营人员或者数据分析师综合确定
现列举一些常用流量指标：
主要是指不能再拆解的指标，通常表达业务实体原子量化属性的且不可再分的概念集合，如订单数
单个基础指标词根+修饰词
建立在基础指标之上，通过一定运算规则形成的计算指标集合，如人均费用=总费用/人数
指的是基础指标或复合指标与维度成员，统计属性，管理属性等相结合产生的指标，如最近7天医生接单量=医生在过去7天一共接到的订单
多个基础指标词根+修饰词
每定一个指标都是需要业务方(或其他部门)与数据部门一起评审决定的，包括指标是否有必要新增，如何定义等
可以通过自研WEB系统来进行展示
展示内容可以有：
Mysql数据准备
第一天9月10号数据
第二天9月11号数据
对比mysql第一天和第二天的数据发现，第二天新增了订单id为4和5这两条数据，并且订单id为2和3的状态更新为了已支付
每天的所有的最新状态的数据。
9月10号全量抽取到ods层
9月11号全量抽取到ods层
全量抽取，每个分区保留历史全量快照。
增量表：新增数据，增量数据是上次导出之后的新数据。
9月10号全量抽取到ods层(全量初始化)
9月11号抽取更新的数据及当天新增的数据，即订单id为2,3,4,5的数据
wedw_dwd.order_info_di表9月10号的分区数据与wedw_ods.order_info_20200911增量抽取的数据合并，有2种方案
a.两个表通过主键关联，dwd表存在并且ods表不存在的数据
unionall一下wedw_ods.order_info_20200911表所有的数据，即全量数据插入到dwd表的9月11号的分区
特殊增量表：da表，每天的分区就是当天的数据，其数据特点就是数据产生后就不会发生变化，如日志表。
如果表中信息变化不是很大，每天都保留一份全量，那么每次全量中会保存很多不变的信息，对存储是极大的浪费
优点
建立dwd层拉链表
end_dt=‘9999-12-31’表示该条记录目前处于有效状态
注：第一次加工的时候需要初始化所有数据，start_time设置为数据日期2020-09-10，end_time设置为9999-12-31
9月11号抽取更新的数据及当天新增的数据到ods层，即订单id为2,3,4,5的数据
查询当前的所有有效记录：
查询9月10号历史快照:
查询9月11号历史快照:
对于表的每一个修改都会记录，可以用于反映实际记录的变更
在一些情况下，保留历史数据没有什么分析价值，而在另一些情况下,保留历史数据是非常重要的
在维度表中，仅需以当前值重写先前存在的值，不需要触碰事实表
缺点：如果业务需要准确的跟踪历史变化，这种方案是没法实现的，并且在以后想改变是非常困难的
修改之前
修改后：
插入新的维度行。采用此种方式，保留历史数据，
维度值变化前的事实和过去的维度值关联，维度值变化后的事实和当前的维度值关联
缺点：虽然此方案能够区分历史情况，但是该方式不能将变化前后记录的事实归一为变化前的维度或者归一为变化后的维度
有些是只保留最新的维度值和最近的维度值，也有的是维度值一有变化就新增一个属性字段。都不是很好的解决方案
变化前：
变化后：
这是精确跟踪缓慢变化维度属性的主要技术，因为新维度行能够自动划分事实表的历史，所以这是一项非常好的技术
正常情况下，维表和事实表之间是一对多的关系，维表中的一行记录会连接事实表中的多行记录，事实表中的一行记录在维度表中只能关联上一条记录，不会发生数据发散的现象
想法是美好的，但是事实总是不尽人意。因为现实中不但事实表和维度表之间存在多对多的关系，维度表和维度表之间也存在多对多的关系
这两种情况本质是相同的，但事实表和维度表之间的多对多关系少了唯一描述事实和维度组的中间维度。
对于这两种情况，一种称为桥接表的中间表就需要派上用场了，并且还可以支持更为复杂的多对多的关系
比如下单了一套学习课程，但是这套课程并不是某一个用户买的，而是好几个用户合买的，所以为了处理这种情况，需要创建一个桥接表，将这些合买的用户组成一个组
ETL过程需要对每条事实表中的用户组，在桥接表中查找相应的用户主键,上图所示的桥接表有重复计数的风险。如果按用户累加购买金额，对某些分析而言结果是正确的，但对于其他情况仍会有重复计数的问题。要解决这个问题，可以向桥接表中添加权重。
权重是一个分数值，所有的用户组的权重累加起来为1。将权重和累加事实相乘，以按照每个用户在分组中的比重分配事实。
优点：
缺点：
桥接表的维护比较复杂，当出现一个新组合时，得先判断桥接表中是否已存在
从分析的角度来看，维度之间的多对多关系是一个很重要的概念，大多数维度都不是完全相互独立的。
在银行系统中，账户和顾客之间有直接关系，但不是一对一的关系。一个账户可以有一个或多个签名确认的用户，一个用户也可有多个账户
有2种方案解决
和多值维度一样，创建账户-用户组桥接表来连接事实表
还有一种方法是利用账户和用户之间的关系，如下图
桥接表可以捕获多对多关系，并且由于源系统中的关系是已知的，因此创建桥接表比多值维度手动构建维度表(桥接表)更容易
处理多值维度最好的办法是降低事实表的粒度。这种处理方式也是维度建模的一个原则，即事实表应该建立在最细粒度上。这样的处理，需要对事实表的事实进行分摊。
但是有些时候，事实表的粒度是不能降低的，多值维度的出现是无法避免的。如上述交叉维度，事实表与用户维度没有直接的关系，不能将数据粒度进行细分，即使细分的话帐户余额也很难分摊。这时，可以采用桥接表技术进行处理。在帐户维度表和用户维度表之间建立个帐户-用户桥接表。这个桥接表可以解决掉帐户维度和用户维度之间的多对多关系，也解决掉的帐户维度表的多值维度问题。
总之，多值维度是应该尽量避免的，它给数据处理带来了很大的麻烦。如果多值维度不能避免的话，应该建立桥接表来进行处理。
码表(编码表)：
disease_code
disease_name
7863
糖尿病
6575
高血压
......
一个疾病编码只有一个对应的疾病名称
主题域是对某个主题进行分析后确定的主题的边界。
如用户主题，日志主题
数据域是指面向业务分析，将业务过程或者维度进行抽象的集合
如订单域，业务过程可能为：加入购物车->支付->发货->收货，整个业务过程的数据都属于订单域
粒度问题是设计数据仓库的一个最重要方面。粒度是指数据仓库的数据单位中保存数据的细化或综合程度的级别。细化程度越高，粒度级就越小；相反，细化程度越低，粒度级就越大。
笼统的说，粒度就是维度的组合
将一些常用的维度属性直接写到事实表中的维度操作称为维度退化
维度中的一些描述属性以层次方式或一对多的方式相互关联，可以被理解为包含连续主从关系的属性层次。层次的最底层代表维度中描述最低级别的详细信息，最高层代表最高级别的概要信息。维度常常有多个这样的嵌入式层次结构。
数据明细，粗粒度到细粒度的过程，会细化某些维度
下钻是商业用户分析数据的最基本的方法。下钻仅需要在查询上增加一个维度属性，附加在SQL的GROUPBY语句中。属性可以来自任何与查询使用的事实表关联的维度。下钻不需要存在层次的定义或是下钻路径。
数据的汇总聚合，细粒度到粗粒度的过程,会无视某些维度
按照三范式形成设计是事实和纬度表的方式管理数据称为规范化
规范化常用于OLTP系统的设计
将维度的属性层次合并到单个维度中的操作称为反规范化
反规范化会产生包含全部信息的宽表，形成数据冗余；实现用维表的空间换取简明性和查询性能的效果，常用于OLAP系统的设计
维表公用，所以基于这些公共维度进行的交叉探查不会存在任何问题
其中一个维度的属性是另一个维度的维度属性的子集，且两个维度的公共维度属性结构和内容相同
两个维度具有部分相同的维度属性
总体来说，数据治理能够带来的好处就在于，更高效地帮助企业将数据价值转化成实际的业务价值。
由于前期缺少规划，随着集团业务发展，暴露的问题越来越多，给数据治理工作带来了很大的挑战，在数据仓库建设过程中，主要发现了以下几个问题：
借用大数据平台，我们实现了：
基于数据平台形成的资产管理体系，如下图所示：
元数据通常定义为”关于数据的数据”，元数据贯穿了数据仓库的整个生命周期，使用元数据驱动数据仓库的开发，使数据仓库自动化，可视化。元数据打通了源数据、数据仓库、数据应用，记录数据从产生到消费的全过程。
例如我们看一部电影，电影本身就是数据，那么元数据就是用来描述这部电影的数据。如下图所示：
元数据主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及ETL的任务运行状态。在数据仓库系统中，元数据可以帮助数据仓库管理员和开发人员非常方便地找到他们所关心的数据，用于指导其进行数据管理和开发工作，可以极大的提升工作的效率。
将元数据按用途的不同分为两类：
技术元数据是存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据。常见的技术元数据有：
1.存储元数据：
如表、字段、分区等信息。记录了表的中英文名及表状态。分区信息、责任人信息、对应主题，文件大小、表类型，生命周期，权限信息
记录列的字段中英文名、字段类型、字段备注、是否是分区字段，保密级别及权限信息等信息。
2.运行元数据，
3.数据开发平台中数据同步、计算任务、任务调度等信息
包括数据同步的输入输出表和字段，以及同步任务本身的节点信息：计算任务主要有输入输出、任务本身的节点信息任务调度主要有任务的依赖类型、依赖关系等，以及不同类型调度任务的运行日志等。
业务元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层，使得不懂计算机技术的业务人员也能够读懂”数据仓库中的数据。
对于元数据管理，目前来说有三种方式可供选择。
对于规模比较小，并且业务不大的公司，可能会用这种方式，但是这种方式太古老，且容易出错
自研元数据管理系统或者在数据平台开发元数据管理模块
Atlas是一个可伸缩且功能丰富的元数据管理系统，深度对接了Hadoop大数据组件。
简单理解就是一个跟Hadoop关系紧密的，可以用来做各类数据的元数据管理的一个软件系统；
atlas本身从技术上来说，就是一个典型的JAVAWEB系统，其整体结构图如下所示：
核心组件
核心特性
ATLAS的使用，包含两个方面：
注入元数据信息到atlas中（本质是：写入元数据到atlas中）
注入方式1：通过atlas为数据系统开发好的hook来注入
注入方式2：通过atlas自带的WEB-UI来人工填写元数据信息再注入
注入方式3：通过在自己的数据系统中调用atlas对外暴露的api，来灵活注入
使用atlas中的元数据信息来为我们服务（本质是：从atlas中读、改元数据）
方式1：通过atlas自带的WEB-UI前端系统来查看、修改元数据
方式2：通过调用atlas对外暴露的api，来开发自己的管理系统
数据质量管理（DataQualityManagement），是指对数据从计划、获取、存储、共享、维护、应用、消亡生命周期的每个阶段里可能引发的各类数据质量问题，进行识别、度量、监控、预警等一系列管理活动，并通过改善和提高组织的管理水平使得数据质量获得进一步提高
数据质量管理不是一时的数据治理手段，而是循环的管理过程。其终极目标是通过可靠的数据，提升数据在使用中的价值，并最终为企业赢得经济效益
l完整性
数据完整性问题包含数据条目不完整，数据属性不完整等
l一致性
多源数据的数据模型不一致，如命名不一致，数据编码不一致，含义不一致，生命周期不一致等
l准确性
准确性也叫可靠性，不可靠的数据可能会导致严重的问题，会造成有缺陷的方法和糟糕的决策
l唯一性
用于识别和度量重复数据，冗余数据，重复数据是导致业务无法协同，流程无法追溯的重要因素，也是数据治理需要解决的最基本的数据问题
l关联性
l真实性
数据必须真实准确的反映客观的实体存在或真实的业务，真实可靠的原始统计数据是企业统计工作的灵魂，是一切管理工作的基础，是经营者进行正确经营决策必不可少的第一手资料。
l及时性
数据的及时性(In-time)是指能否在需要的时候获到数据，数据的及时性与企业的数据处理速度及效率有直接的关系，是影响业务处理和管理效率的关键指标。
l逻辑检查
不同表字段之间可能会有逻辑关联，需要稽核
l离群值检查
部分数据可能会偏离其他数据，比如同一个商品金额大家都是100元，而有一条数据是1W
l自定义规则
l波动稽核
与上周环比稽核波动情况
l强弱规则
每个规则的权重应该是不一样的，需要配置优先级，这对后续的告警方式是有帮助的
我们最终的目的是希望做到页面可配置
单表通用配置
质控规则
规则定义
唯一性
数据不能重复
多表自定义规则配置(自定义业务规则)
规则名称
规则内容
责任人
订阅人
操作
以上如果有异常都需要邮件短信报警，对应负责人根据优先级判断是不是需要及时处理
1.警告邮件短信通知
数据质量管理贯穿数据生命周期的全过程，覆盖质量评估、数据监控、数据探查、数据清洗、数据诊断等方面。数据源在不断增多，数据量在不断加大，新需求推动的新技术也不断诞生，这些都对大数据下的数据质量管理带来了困难和挑战。因此，数据质量管理要形成完善的体系，建立持续改进的流程和良性机制，持续监控各系统数据质量波动情况及数据质量规则分析，适时升级数据质量监控的手段和方法，确保持续掌握系统数据质量状况，最终达到数据质量的平稳状态，为业务系统提供良好的数据保障。
江湖传言：数据玩的溜，牢饭吃的久？众看官是不是闻风丧胆？
每个数据开发者都应该非常深刻的明白数据安全意味着什么。简直就是一根红线，丝毫不能越过。
数据脱敏是保证数据安全的最基本的手段，脱敏方法有很多，最常用的就是使用可逆加密算法，对数仓每一个敏感字段都需要加密。
需要开发一套完善的数据权限控制体系，最好是能做到字段级别，有些表无关人员是不需要查询的，所以不需要任何权限，有些表部分人需要查询，除数据工程师外，其他人均需要通过OA流程进行权限审批，需要查看哪些表的哪些字段，为什么需要这个权限等信息都需要审批存档。
有些字段明显是敏感数据，比如身份证号，手机号等信息，但是业务库并没有加密，而且从字段名来看，也很难看出是敏感信息，所以抽取到数据仓库后需要使用程序去统一检测是否有敏感数据，然后根据检测结果让对应负责人去确认是否真的是敏感字段，是否需要加密等。
流程化主要是体现在公司内部取数或者外部项目数据同步，取数的时候如果数据量很大或者包含了敏感信息，是需要提OA审批流程的，让大家知道谁要取这些数据，取这些数据的意义在哪，出了问题可以回溯，快速定位到责任人。开发外部项目的时候，不同公司之间的数据同步，是需要由甲方出具同意书的，否则的话风险太大。
及时发现敏感sql的执行并询问责任人，事后分析操作日志，查出有问题的操作。
把数据安全当做一项KPI去考核，让大家积极的参与到数据安全管理当中去。
不要为了一时的利益，泄露公司数据资产，轻则行业名声败坏，重则要负法律责任，一定要三思而后行！
目前来说我所了解的基本都是需要手工维护的，有些公司维护在excel中，有些公司维护在web系统中
Kafka+flink+clickhouse
敬请期待
word文档目录长图(此版本出的比较匆忙，是初版，之后会完善)：