数据仓库基础理论笔记

Posted 2022-02-07 燃烧的岁月_

第一节
互联网电商大数据环境
如果你真正进入这个行业了！
入职后你所在部门一般叫：数据平台、数据中心、数据部
可能的团队：数据仓库组；BI（商业智能）组、某事业部数据组；架构组；数据专家组；...
部门里重要的几拨人，一拨是搭建和保证hadoop系统每天正常运行和改进hadoop系统的架构人员，这批人对hadoop细节非常熟悉，另一拨是满足业务系统需求，每天都在开发应用的开发人员，这批人员开发经验非常丰富，
业务流程也很熟悉，还有一拨是管理系统的上线下线运行监控授权等运营工作的运营人员，这批人可能有很多女生，还有一拨人使用平台的数据进行分析，提供一些决策或者运营支撑的而数据分析人员，这批人大部分是研究生。
但数据平台大概是可以分为平台建设和数据开发两部分；随着公司的发展，会分得更细可能还会有：需求组，推荐组，情报组，挖掘组，实时数据组，营销数据组，等等。


数据分析人员可能在另外的一个部门，不是数据平台。


可能会有哪些重点项目:
-DW数据仓库建设
-经营分析报表（各部门都有常用报表）
-客户精准营销
-推荐系统需求
-移动端数据分析


可能会有哪些重点方向
-流量数据
-交易数据
-会员与活动数据
-物流与配送数据
-内部财务数据


典型数据产品
-淘宝数据魔方，腾讯用户画像，京东罗盘，客户标签


平台建设你可能每天会做什么工作
-解决系统挂了，运行慢，报错，不好用，不会用
-系统改进，上线，工具开发，权限控制
-开发监控程序，解决各种疑难杂症等


数据开发你每天可能会做什么工作
-抽取和装载日志数据和源系统数据
-开发宽表、模型（一种很多字段的冗余的表）
-各部门的源源不断的数据开发需求砸过来
-各种业务咨询，线上问题查找，优化程序
-临时提取数据，或者计算某一个马上要用的指标


电商一般项目的声明周期
-产品经理，或者业务人员提出需求，带需求文档
-各负责人讨论可行性，与初步的数据来源
-开发人员接触需求，进行需求调研，制定初步实现方案和预估时间
-PMO跟进项目并整体排期：开发排期，提测试日期，数据质量测试排期
-开发人员根据排期开展工作，制定详细实现方案，并初步完成Mapping发给数据质量测试人员
-开发人员根据实现方案建表，并开发ETL过程，ETL过程单元测试，调通并部署到调度平台


电商项目生命周期
-开发好之后编写详细Mapping，并提测，并将ETL逻辑上到测试环境，每天跑批
-测试人员根据Mapping按字段写测试SQL来测试ETL逻辑是否正确。
-数据质量测试人员测试完成后，数据就保证是正确的，会提交给分析人员或者业务人员使用（可能还有业务测试）
-各人员确认没有问题后上线


互联网电商大数据环境
Hadoop在国内的情景
-数据仓库、商业智能（阿里系、腾讯系、百度、京东、新浪、...)
-互联网广告计算（亿赞普，科捷，各类大互联网企业）
-大搜索引擎项目（YaHoo，人民搜索）
-站内搜索引擎项目（Ebay，支付宝）
-内容推荐引擎（人人，新浪微博，优酷）
-病毒分析，垃圾邮件识别（Yahoo，趋势科技，360）
-云计算服务项目（百度云，亚马逊云，阿里云）
-其它：地图项目，科研项目，电信项目，金融项目


华南区Hadoop工作机会
-深圳：腾讯、华为、迅雷、平安科技、顺丰、珍爱网、中国电信、TCL，文思海辉（乙方），天源迪科（乙方），华傲（乙方）等等
-广州：UC，精品汇，YY语言，酷狗音乐，太平洋网络，4399，亿讯（乙方），宇信网络（乙方）
-据可靠消息：富士康，美的传统制造业正在布局电商招大数据人才
-注意一下新兴的由潜力的创业公司机会，薪水高，工作累，如果创业成功，你懂的！


关于猎头的知识
-猎头是按你的月薪水来提成的
-有些公司可能对猎头推荐的人要求严格一些，因为他们感觉付钱了，要对得起付出的钱
-JD是job describe的简称，就是职位要求
-大公司BAT，对你每次的面试都记录在案，而且所有以后面试你的人都会看到这些评论，所以你运气不好，或者遇上心情不好的面试官或者你翅膀没硬就去面试，你的
评论会伴随你终身哦（稍微有一些化解小技巧，虽然不是百分百管用，加入VIP群可以得到答案）
-印象中阿里有些面试官对电话面试的人不是很重视。
-------------------数据仓库理论-目录----------------------------------------------------------------------------------
--------BI的作用------------------------------
    操作型数据
    特点：细节化、分散化
    决策型数据
    特点：综合化，集成化
企业对当前应用系统的要求
提供企业内部和外部的有用信息以支持中期或远期决策
提供事实的全局信息进行实时监控与临时决策
现行应用系统无法达到企业的要求：
-数据分散
-数据不兼容
-系统应用孤立
通过集成实时与历史数据，将分析转换为执行力
洞察力
    -获得对业务绩效，流程和客户的可见性和洞察力
    -更好的进行决策和执行决策，以快速应对机会和挑战
协同一致
    -横跨多个业务和数据源，获得唯一的、一致的企业信息
    -在各业务层面中协同战略和执行
BI应用带来的关键效益-洞察力
高层领导分析：专注点是计划战略&目标制定业务发展得如何，我们下一步该往哪里走
中层管理分析：专注点是绩效的战术应用与目标相比，我做的如何？问题在哪里
一线分析：专注点是执行有效性与行动 我每天要做的是3-5件事 哪些信息能让我更有效的执行这些行动？
回答问题：我现在该做哪些事情？
------------BI的定义：
BI是Business Intelligence的英文缩写，中文解释为商业智能，用来帮助企业更好的利用数据提高决策质量的技术集合，是从大量的数据中钻取信息与知识的过程。简单讲就是业务、数据、数据价值
应用的过程。


BI不能产生决策，而是利用BI过程处理后的数据来支持决策。
那么BI所谓的智能到底是什么呢？BI最终展现给用户的信息就是报表或视图，但它不同于传统的静态报表或视图，它颠覆了传统报表或视图的提供与阅读的方式，产生的数据集合就像玩具“魔方”一样，可以
任意快速的旋转组合报表或视图，有力的保障了用户分析数据时操作的简易性、报表或图视直观性及思维的连惯性。
------------数据仓库的概念--------------------------------------------------------------
数据仓库（Data Warehouse）是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支撑管理决策。
上面的话要倒背入流！
面向主题
数据仓库围绕一些主题，如顾客、供应商、产品和销售组织。数据仓库关注决策者的数据建模与分析，而不是集中于组织机构的日常操作和事务处理。因此数据仓库排除对决策无用的数据，提供特定简明的视图。
例子：数据仓库以不同主题分类：如应收账款，应付账款。
集成：
通常，构造数据仓库是将多个异种数据源，如关系数据库，一般文件和联机事务处理记录集成在一起。使用数据清理和数据集成技术，确保命名约定、编码结构和属性度量等指标的一致性。
例子：对于币种人民币，源系统过来可能有些以RMB显示，有些以CNY表示，应只集成统一的。
相对稳定
数据仓库的数据是有历史保存意义的，数据仓库的数据也只使用添加的方式，进入了数据仓库的数据一般情况下是不需要更新的，这样就保证了数据的稳定性，通常，它只需要三种数据访问：数据的初始化装入、
数据的添加和数据查询访问。
例子：数据仓库去年卖了100件啤酒，那今年与去年同期比较也是去年100件，不能更新也不能删除去年的数据。
反映历史变化
操作型数据库主要关心当前某一时间段内的数据。
而数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点（如开始应用数据仓库的时点）到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。
例子：两个客户在某超市都是总共购买了5箱啤酒，一个是这一个月购买的，一个是去年1月~10月购买的，对于决策者是不一样的。
---------数据仓库的特性--------------
企业数据仓库的建设，是以现有企业业务系统和大量业务数据的积累为基础。
数据仓库不是静态的概念，只有把信息及时交给需要这些信息的使用者，供他们做出改善其业务经营的决策，信息才能发挥作用，信息才有意义。
而把信息加以整理归纳和重组，并及时提供给相应的管理决策者，是数据仓库的根本任务。因此，从产业界的角度看，数据仓库建设一个工程，是一个过程。而不是一种可以购买的产品。
---------数据仓库基础理论---------------------------------------------------------
面试必问几大问题：
-SCD问题处理方法并举例？
Slowly Changing Dimensions，中文一般翻译成“缓慢变化维”。缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流失发生缓慢的变化。这种随时间发生变化的维度我们一般称为
缓慢变化维，并且把处理维度表的历史变化信息的问题称为处理缓慢变化维的问题，有时也称为处理SCD的问题。
-ODS是什么，在数据仓库起的作用？
Oprational Data Store 操作型数据存储，对于一些准实时的业务数据库当中的数据的暂时存储，支持一些同时关连到历史数据与实时数据分析的数据暂时存储区域。
-ETL加载策略与举例？
数据抽取（Extract）、转换（Transform）、清洗（Cleansing）、装载（load）的过程。
-------------BI的构建---------------------------------------------
数据仓库基础理论
----------------------------------------------------------------------------------------
维度建模基础理论
事实表：聚集事实表、合并事实表、旋转事实表、预连接聚集表、非事实型事实表、切片事实表


维度表：缓慢变化维、快速变化维、大维、退化维


模型：星形模型、雪花模型、多维模型


粒度：指数据仓库中数据的细化或综合程度的级别，也就是数据的详细程度


层次：ODS、DW、DM


事实表（Fact Table）
事实表是指其中保存了大量业务度量数据的表。在事实表中最有用的事实就是数字类型的事实和可加类型的事实。事实表的粒度决定了数据仓库中数据的详细程度。
一般事实表中只存放数字或者一些标志用来做统计（Count），如收益、数量、支出等
|--------|
|销售事实|
|维度ID  |
|收益    |
|数量    |
|支出    |
|毛利    |
|...     |
|--------|


维度表(Dimension Table)
维度表可以看作是用户分析数据的窗口，维度表中包含事实数据表中事实记录的特性，有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分析者提供有用
的信息。


|--------|
|时间维  |
|产品维  |
|商场维  |
|--------|
|--------|
|客户维  |
|客户ID  |
|客户编码|
|客户名字|
|客户年龄|
|客户性别|
|--------|
|--------|
|销售事实|
|时间ID  |
|客户ID  |
|产品ID  |
|商场ID  |
|收益    |
|数量    |
|支出    |
|毛利    |
|--------|


粒度(Grain)
-粒度是指数据仓库中数据的细化或综合程度的级别，也就是数据的详细程度。粒度越细，数据量越大，所需要的存储空间越大，查询性能越慢，反之亦然。设计粒度是设计数据仓库的一个重要前提
高细化----》询问某一电话的细节------》通过检索可以回答
每月200个记录
每月40000个字节


低细化-----》询问某一电话的细节----》无细节无法回答
每月一个记录
每月200个字节
------------------------------------------------------------------------------------------------------------
高度综合级   每月销售 1994-2001
轻度综合级   每周销售 1994-2001
（数据集市）
当前细节级   销售细节级2000-2001
操作型转换


早期细节级      销售细节级 1994-1999
------------------------------------------------------------------------------------------------------------
层次（Hierarchy）
-层次指描述明细数据的层次
-比如国家-省-地级市-县-镇就是一个典型的层次
-------------------------------------------------------------------------------
星形模型(Star Schema)：
-事实表被维度所包围，维表和事实表通过主关键字和外关键字联系在一起，且维度没有被新的表连接
|-----------------------|
|销售事实               |
|-----------------------|
|时间维--》销售事实表   |
|-----------------------|
|客户维--》销售事实表   |
|-----------------------|
|产品维--》销售事实表   |
|-----------------------|
|商场维 --》销售事实表  |
|-----------------------|


雪花模型(Snowflake Schema):
-事实表被多个维表或一个或多个层次所包围，雪花模型一般在处理大的且相对静态的层次的时候使用
|--------------------------------------------|
|时间维--》销售事实表                        |
|--------------------------------------------|
|产品维--》销售事实表                        |
|--------------------------------------------|
|商场维--》销售事实表                        |
|--------------------------------------------|
|区域维 --》联系人维 --》客户维--》销售事实表|
|--------------------------------------------|
|销售事实表                                  |
|--------------------------------------------|
多维模型(Multi-dimension Schema)
VIP问题：星形模型与雪花模型有什么区别？
-----------------------------------------------------------------------
缓慢变化维(Slowly Changing Dimension)
-VIP讲解
快速变化维(Rapidly Changing Dimension)
    -当某个维度的变化是非常快的时候，我们认定他为快速变化维（具体要看实际的变化频率），比如：客户的地址、联系电话等。
大维（Huge Dimension）和微型维（Mini-Dimension）
    -数据仓库中最有意思的维度是一些非常大的维度，比如客户，产品等等。一个大的企业客户维度往往有上百万记录，每条记录又有上百个字段。而大的个人客户维度则会超过千万条记录，这些个人客户
维度有时也会有十多个字段，但大多数时候比较少见的维度也只有不多的几个属性
    -将分析频率比较高或者变化频率比较大的字段提取出来，建立一个单独的维度表。这个单独的维度表就是微型维度表。
退化维(Degenerate Dimension)
    -退化维度一般都是事务的编号，如订单编号、发票编号等。这类编号需要保持到事实表中，但是不需要对应的维度表，所以称为退化维度。
-------------------------------------------------------------------
建模的一般过程
选择需要建模的业务过程，如：库存管理业务
1、确定该业务过程每个事实表的粒度
    确定详细数据的粒度级别
    此过程必须是在建模之前最需要考虑的问题
    比较经典的粒度指的是单独的，基于时间的或聚集在一个常用的维度的事务
2、确定维度的属性
    确定是否需要同时存储编号和描述，或者只有编号，或者只是描述的信息
    确定哪些字段的值需要被筛选掉或者需要存在
3、确定维度的层次
    对于时间维度，我们需要确定的是年，季度，月，周，日等不同的层次
    对于产品维度，我们需要确定的是产品大类、产品小类、产品等不同的层次
    需要注意的是比如在销售中，地理位置的层次可能和真正的地理位置的层次会有不同
4、确定每个事实所需要关联的维度
    通常的维度包括时间，产品，客户，和地理等常见对象
    请注意，创建的维度需要和与其连接的事实的粒度保持一致
5、确定数字型事实，包括预先计算的
    需要根据具体业务来确定事实及其量度
    对于每个聚合事实需要在应用（ETL）过程中进行计算
6、确定缓慢变化维
    根据需求，对缓慢变化维进行相应的处理
    比如：
    对于一个需求为不保留历史的客户维度，我们使用第一种类型的缓慢变化维来处理；
    对于一个需求为需要保留历史的产品维度，我们需要使用第二种类型的缓慢变化维来处理
----------------------------------------------------------------------
实例：
步骤1：选定某一业务过程，如：库存管理业务
                   xxx集团
企业管理 财务管理 煤炭生产 安全监督 运销公司 物资供应
市场分析 财务分析 煤种分类 安全政策 地区管理 物资计划


步骤2：根据各用户的需求（关注的主题），定义该业务处理的粒度。
例如：
-主题1及其粒度：矿厂中每种产品库存水平的日快照
-主题2及其粒度: 每种特定产品的仓库库存事务每日情况
-主题3及其粒度：每种特定产品每日的入库装运情况
步骤3：选定每个事实表的维度
例如：
-主题1（库存水平）事实表维度：日期、矿场、产品
-主题2（仓库库存事务）事实表维度:日期、仓库、产品、供应商、事务类型
-主题3 （入库装运）事实表维度：到货日期、检测日期、入库日期、销售批准日期、分拣日期、装箱日期、装运日期、最近回收日期、产品、供应商、仓库
步骤4：确定每个事实表的数字型事实
例如：
-主题1:(库存水平)事实表数字型事实：现有数量
-主题2：（仓库库存事务）事实表数字型事务：仓库库存事务金额
-主题3：（入库装运）事实表数字型事实：到货量、检测量、退货量、入库量、批准销售量、分拣量、装箱量、装运量、回收量、顾客退货量....


完成后的模型
主题1：矿厂中每种产品库存水平的日快照
|---------------------------------------------------------------|
|日期维度             矿厂库存快照事实              产品维度    |
|日期关键字           日期关键字                    产品关键字  |
|日期属性             产品关键字                    产品属性    |
|                     矿厂关键字                                |
|矿厂维度             现有数量                                  |
|矿厂关键字                                                     |
|矿厂属性                                                       |
|---------------------------------------------------------------|


主题2:每种特定产品的仓库库存事务每日情况
产品接收
产品送检
合格产品分发
次品退货
产品入柜
产品销售审批
产品出柜
产品包装
发货
回收
从库存中删除


主题3：每种特定产品每日的入库装运情况


到货日期维度            仓库库存累积事实
                      到货日期关键字
检测日期维度          检测日期关键字
                      入库日期关键字
入库日期维度          。。。
---------电信DW建模演示---------------------------------------------------------
步骤1：明确业务需求。在DW中，任何一事实表或维表都是业务需求的承载体，而不是凭空创建的；因此建模的第一步就是明确业务需求。业务需求可能是一句话，也可能是详细的需求说明文档，总之，我们
需要将业务逐步分解，直到可以用模型（表）来承载这些被分解的业务信息（概念模型-逻辑模型-物理模型）


步骤2：确定数据存储粒度。在电信DW中，事实表基本上是以聚集型事实表为准，因此其粒度基本上是由维度来决定


高度综合级（DM）  用户每月通话汇总
轻度综合级（EDS） 用户每日通话汇总
当前细节级（ODS） 用户通话清单


步骤3：确定事实表维度
时间-》区域-》语音->主被叫
分析时段的通话情况，明确闲忙时段区间分析每日\\周\\月通话情况，了解市场稳定性
分析用户漫游通话情况，制定漫游套餐 分析用户长途通话情况，调整长途资费
分析用户语音通话行为分析用户数据业务通话行为，开拓数据业务市场
分析用户主叫通话行为分析用户被叫通话行为


步骤4：确定事实表数值型字段
时长-》话费-》次数
可由通话开始时间和结束时间计算得到 一般只针对语音业务通话行为 一分钟原则
话费包括本地、长途及漫游费 应该不包含优惠冲减的话费 话费计算规则
可由通话次数累计计数得到
------------------------------------------












































---------------------------------------------------------------------------------------


企业大数据体系
6、战略分析与决策（战略）
5、数据产品（数据产品）
4、精细化运营平台（数据运营体系、自助数据提取、产品生命周期）
3、产品与运营分析（用户行为、收入、用户画像、数据挖掘、建模、分析工具）
2、数据报表与可视化（标准化可配置数据报表与直观的可视化输出（行为、收入、性能、质量））
1、数据基础平台（数据平台建设、数据规范、数据仓库、产品数据规范、产品ID、用户ID，统一SDK）
-----------------------------------------------------------------------------------------
传统数据仓库架构：
SRC（抽取）=》ODS（装载）=》DW（清洗）=》DM（清洗）=》ST（展现）
大部分的数据仓库架构都来源于传统数据仓库架构结合自身的特点的改进（CIF等）
-----------------------------------------------------------------------------------
电商数据平台架构
-真实中型电商数据仓库架构解密
-架构各层技术实现细节
-在下一章《电商数据平台从零搭建方案参考》中讲解
-需要加入VIP群
|---------------------------------------|
|ODS层DW层的区别                        |
|---------|---------------|-------------|
|目的     |数据仓库DW     |  ODS        |
|目的     |决策支持       |接近实时监控 |
|共同点   |整合数据       |整合数据     |
|         |面向主题       |面向主题     |
|---------|---------------|-------------|
|不同点   |静态数据       |动态数据     |
|         |（延迟>24小时）|（延迟>1秒） |
|  |历史数据       |当前数据/历史|
|  |概括性数据     |细节化数据   |
|-------------------------|-------------|


|---------------------------------------|
|ODS层与DM的对比                        |
|------|--------------|-----------------|
|对比  |ODS           |      DM         |
|------|--------------|-----------------|
|      |数据，可变的  | 数据，稳定的    |
|------|--------------|-----------------|
|      |当前及历史数据| 历史数据        |
|------|--------------|-----------------|
|      |业务明细的数据| 分主题的汇总数据|
|------|--------------|-----------------|
|      |/             | 含模型结构      |
|------|--------------|-----------------|


电商的源系统：流量
-流量日志：一般来源于三块：PC，WAP，APP，这些日志记录每次用户的点击和访问甚至鼠标的移动情况
-流量数据特点：数据量巨大，数据非结构化，数据有一定误差
-百度统计：
http://tongji.baidu.com/data/browser


-----------------------------------------------------------------------
电商源系统和源数据特点
电商的源系统：交易数据
-网站数据：来自于B2C，C2C等网站的后台数据库中的数据，有商品，订单，用户，活动等很多模块的数据
-交易数据特点：是分析的核心数据，使用最多的数据，数据准确，有敏感信息


电商的源系统：仓库与物流数据
-仓储，仓储仓库信息和物流派送的情况
-仓储与物流数据特点：如果有8个仓库，这8个仓库可能部署同一套系统，这样进行抽取装载，需要从8个地方抽取装载一张同名表再合并。
-所以抽取和合并的过程比较麻烦
----------------------------------------------------------------------
电商的源系统：其它
-推荐系统：推荐商品
-营销系统：挑选营销用户
-消息系统：发送短信或者邮件，PUSH信息
-客服系统：客服接听电话与处理问题记录
-供应商系统：商品供应商信息
-移动系统：移动APP的数据
-等等
公司越大，系统越多，业务多时，某些系统会拆开，比如可以把公司的促销活动从网站中拆分成一个独立系统。
------------------------------------------------------------------
抽取：每天凌晨会把昨天的数据抽取一份放入数据仓库中，所以一般数据是T+1的
-抽取分全量和增量抽取，特别大的表全量抽取可能会拖垮源数据库(新手小心被点名)
-增量抽取，可以通过时间戳控制增量，源系统必须有最后更新时间这样的时间戳
-可以使用每次抽取近一个月有变更的数据，然后和目标表做外关联得到最新的数据
-注意点：不要用其他表的时间戳控制自己的增量，还有一些注意点将中VIP群中分享
装载：将落地的文件装入到hive数据表中
-一般好的公司，抽取与装载已经做成全自动了，只要稍微配置一下就行了，一般配置信息：抽取库地址，抽取SQL即可，苦B的公司要自己写抽取脚本
-入库方式：全量truncate then insert，drop then create；
增量：delete then insert，full outer join
注意点：字段的顺序极其重要，顺序错乱，hive是不会报错的，一个中文都可以插入到timestamp类型，还有一些注意点将在VIP群里分享
抽取装载一般使用sqoop来完成，sqoop也是hadoop的一个子项目。
--------------------------------------------------------------------
DW层数据特点
数据经过装载后真正进入了数据仓库
-DW层（或者叫ODS层）的数据一般都是贴源的数据
-这一层的数据还是明细的数据，而且保持E-R模型，也有一些公司在这一层放在一些ODS JOIN表（或者叫不汇总的宽表）
-DW设计规则:从字段数目和字段名上要十分贴源，进行不规则数据清洗和数字类型转换
-一个经典的DW层表：ODS_B2C_ORDERS
----------------------------------------------------------------------
DM是数据集市的意思，这里一般存储经过汇总的数据
-重要清洗的表(举例:解析json后的表)
-轻度汇总或者不汇总的宽表（举例：用户宽表）
-中间表（首单尾单表）
-汇总表（举例：区域访问情况表）
-预连接事实表


DM层的数据都是经过很多加工后的表，不一定是E-R模型，而且可以不遵守三范式
一个典型的DM表：DM_LOG_USER_VISIT
-----------------------------------------------------------------------
元数据管理：元数据就是数据的数据
-使用SVN管理DW清洗脚本(TortoiseSVN)
-DW层数据字典管理，可以使用excel记录，或者直接使用源系统的数据字典（因为是贴源的）
-构建自己公司的元数据管理系统
-不仅仅是DW层脚本，DM层的，ST层都会有许多元数据需要管理起来
----------------------------------------------------------------------
报表层：可以分为动态报表和静态报表，由于数据量比较大，大量的可加事实是已经算好的
-动态报表：BIEE，Cognos，基于多维模型，展现非常灵活，所以底层数据要建模，一般使用星型模型
-静态报表：纯粹是将数据表展现出来而已，没有钻取，旋转等功能。
---------------------------------------------------------------------
数据产品：把一个很大的需求固化下来，就可以做成一个成熟的数据产品
-阿里数据平台的数据产品 http://www.alidata.org/about-us/product
-最经典的数据产品：淘宝数据魔方，腾讯用户画像，京东罗盘，客户标签
------------------