数据仓库工程师面试题

什么是数据仓库？
数据仓库，英文名称date warehouse 简称DW,数据仓库，就是一个很大的用来存储数据的集合，用于解决企业数据分析性和决策目的创建，对多样的数据进行筛选与整合，指导业务流程曾改进，成本，质量以及控制。
数据仓库的输入方就是各种各样的数据源，最终的输出用来为企业做数据分析，数据挖掘和数据报表。

数据仓库特点：

1. 主题性 不同于传统数据库对应于某个或多个项目，数据仓库根据使用者实际要求，将不同数据源的数据在一个较高的抽象层次上做一个擂台，所有数据都围绕某一个主题来组织。
2. 集成性 数据仓库中存储的数据是来源于多个数据源的集合，原始数据来自不同的数据源，要整合为最终的数据集合，需要把数据源经过抽取>清洗>转换的过程。（其实这就是ETL）
3. 稳定性 数据仓库中保存的数据是一系列历史快照，不允许被修改。用户只能通过分析工具进行查询和分析
4. 时变性 数据仓库会定期接受新的集成数据，反应出最新的数据变化。（这个是稳定性并不矛盾）
   数据源多种多样，那么数据仓库要做数据集成，所依赖的就是（ETL）

什么是ETL？
ETL的英文字母是EXTRACT-TRANSFORM-LOAD的缩写。
Extract ：数据抽取，也就是把数据从数据源读取出来
Transform：数据转换，把原始数据转换成期望的格式与维度。如果用在数据仓库的场景下，transform 也包括数据清洗，清洗掉噪音数据。
Load：数据加载，把处理后的数据加载到目标处，比如数据仓库。

市面上常用的数据仓库有哪些？
Hive是基于Hadoop的数据仓库工具，可以对存储在HDFS上的文件数据集进行查询和分析处理。Hive同时也提供了类似与SQL语言的查询语言hiveql,在做查询时将hql语句转换成mapreduce任务进行执行。

ETL日志，警告发送

1. ETL日志
   ETL日志分为三类
   一类是执行过程日志，这一部分日志是在ETL执行过程中每执行一步的记录，记录每次运行每一个步骤的起始时间，影响了多少行数据，流水账形式。
   一类是错误日志，当某个模块出错的时候写错误日志，记录每次出错的时间，出错的模块以及出错的信息等。
   第三类日志是总体日志，只是记录ETL开始时间，结束时间是否成功信息。如果使用ETL工具，ETL工具会自动产生一些日志，这一类日志也可以作为ETL日志的一部分。
2. 警告发送
   如果ETL出错了，不仅要形成ETL出错日志，而且要向系统管理员发送警告。发送警告的方式多种，一般常用的就是给系统管理员发送邮件，并敷上出错的信息，方便管理员排查错误。

ETL开发
概述：ETL是数据仓库的后台，主要包括抽取，清洗，规范化，提交四个步骤，传统数据仓库一般分为四层模型。 作用：划分ETL阶段工作重心，便于管理
STG：与源系统模型一致 增量/全量抽取 不做数据转换 添加审计列。 作用：降低开发和维护成本
ODS: 与源系统模型一致 全量数据 标识逻辑删除 标识逻辑删除 标识增量时间戳 添加审计列 作用：减少需求变化带来的冲突
DW : 维度模型 增量抽取 数据清洗、规范化 添加审计列 作用：便于数据问题跟踪

STG层
在维度建模阶段已经确定了源系统，而且对源系统进行了数据评估。Stg层是根据cdc策略把各个源系统的数据抽取到数据仓库中，stg层主要是面向批处理的形式，如果是根据日志信息实时同步，可以跳过stg层直接进入ods层。

Stg的作用
1.减轻源系统的压力
2.数据备份，支持重跑
3.便于数据问题跟踪
4.数据质量检查

开发步骤

1. 确定CDC策略，根据源系统的数据状况选择一个合适的CDC策略
2. 设计mapping文档
3. 设计物理模型，stg的物理模型一般包括源系统的所有字段和审计字段，例如：原系统名称，源表名称，加载时间，加载方式。可以去掉其他约束条件，比如主键，索引，默认值。如果源表和目标表的数据库类型不同，最好字段长度要进行扩充，一般目标表的数据类型就选择几种常用，长度就选择几个固定的长度
4. 抽取数据，stg层面向异构数据源，最好选择用ETL工具，一般ETL工具都支持多种数据源，stg层不做数据转换。
5. 加载数据，stg层一般保留7天或一月的数据

ODS层
ODS层是把stg层数据进行历史存档，保留源系统的所有历史数据，如果是流式的，可以跳过stg层，试试同步到ods层

ODS的作用

1. 全量存储源系统的数据
2. 支持下游系统实时查询服务
3. 数据质量检查

开发步骤

1. 设计mapping文档
2. 设计物理模型，ods的物理模型一般包括源系统的所有字段和审计字段，但是和源系统最主要的区别是ods层加了逻辑删除标记和增量时间戳。因为很多源系统都可能进行物理删除数据，即使有逻辑删除标记，但是也可以在后台人工删除数据。
3. 抽取数据，ods层从stg层抽取数据，再同一个数据平台上，可以采用ETL工具，也可以手工编码。
4. 加载数据，进行数据比较，判断是否有物理删除情况，如果有打上删除标记，ods层保留全量数据

DW层
Dw层是清洗，规范化，提交一致化维度和事实的工作区，建立反规范化的维度模型。
数据清洗
数据清洗时发现数据质量问题并纠正数据的过程，通用的方法是戴明质量环
行动->计划->实施->监控->行动
主要步骤

1. 定义数据质量要求，根据业务需求和数据剖析结果确定数据质量需求的优先级
2. 制定数据质量测量类型
3. 提交数据质量测量结构表，通常异常数据处理策略有
4. 中断处理
5. 把拒绝记录放到错误事件表里
6. 只做标记，数据继续处理
7. 纠正数据
8. 必须在ETL处理
9. 最好在ETL处理
10. 最好在源头处理
11. 必须源头处
    规范化
    有雨数据仓库的数据来源各个业务系统，每个业务系统相对都是封闭的，他们在命名，取值上都有自己的特点。规范化就是经过标准化，去重，合并，拆分，整合等过程把各个业务系统的数据统一命名，统一取值，监理企业标准版本数据。
    主要步骤
12. 数据标准化
    从数据的内容，格式，命名，计算规则等输出为唯一的版本数据，把各个源系统的相同
    描述对象但是不同取值进行统一，比如：性别字段，有的源系统用0和1或man和wonen。通过映射表统一命名为m和f
13. 删除重复数据
    如果源系统中存在重复数据或者多个源系统维护了相同对象的数据，这时候就要根据保留规则，删除重复数据，只保留唯一的一条数据。
14. 数据共存
    把各个业务新系统的数据经过拆分，合并，整合。例如相同的客户号，两个源系统都维护了这个客户的联系方式，这时候就要根据业务规则来选择保留那个原系统的值。
    提交维度表和事实表
    提交维度表主要步骤
15. 确认粒度
    维度表的粒度就是表的业务主键，根据业务主键来判断记录的唯一性。
16. 选择代理键生成器
    ETL工具和数据库都要设置字段自增长的功能
17. 选择维度表类型
    根据业务系统的实际情况选择合适的维度表类型，一般采用缓慢变化维类型1和类型2.
18. 增量加载维度数据
    维度表的每个字段都要设置默认值，不能为空。首次加载的时候要有一条代理键为-1的默认记录，为了防止事实表查找不到代理键
19. 生成代理键管道
    为了生成事实表的维度代理建，一般会建一个查找维度，查找维表包含业务主键和代理建的映射关系。

提交事实表主要步骤

1. 选择事实表类型
2. 用代理键替换主键
3. 增量加载事实数据
4. 提交错误事实表
5. 事实表合并
6. 事实表归档

维度和事实数据修正

1. 纠正事实
2. 优化和更正事实表主要有
3. 处理延迟的事实
4. 维度重建

DM层
DM层根据业务需求把dw层数据进行聚合或生成宽表
1.创建聚合事实表
创建聚合表的方法

1. 增量加载，创建聚合表，增量加载聚合表
2. 聚合导航，用户通过报表分析工具，根据用户请求把基础事实表自动生成聚合数据
3. 物化视图，创建物化视图定时刷新聚合表
   2.创建缩小维度表
   由于聚合事实表的粒度和基础事实表粒度不同，需要创建和聚合表相同粒度的维度表，这些维度表只是基础维度表的缩小版
   ETL优化
4. 减少磁盘i/o
   关联查询的时候，尽可能把无效的数据过滤掉
   只查出需要的列
   大数据量尽量不要有排序
   在加载数据时关闭日志
5. 分区和并行
   大数据量可以进行分区
   查询和任务调度都可以进行并行处理
6. 增量加载
7. 增加索引
8. 大而化小，复杂的查询可以分成多个子任务来执行
9. 重用结果集，把多个查询任务的共用数据可以单独建临时表。

数据的抽取（extract）
这部分需要在调研阶段做大量的工作，首先要搞清数据是从几个业务系统中来，各个业务系统的数据库服务器运行什么DBMS，是否存在手工数据，手工数据量有多大，是否存在非结构化的数据等等，当收集完这些信息后才可以进行数据抽取的设计。

1. 对于与存放DW的数据库系统相同的数据源处理方法
   这一类数据源再设计上比较容易，一般情况下DBMS（sqlserver,oracle）都会提供数据库连接功能，在DW数据库服务器和原业务系统之间建立直接的链接关系就可以写select语句直接访问
2. 对于与DW数据库系统不同的数据源的处理方式
   对于这一类数据源，一般情况下也可以通过ODBC的方式建立数据库链接——如SQLserver和Oracle之间。如果不能建立数据库链接，可以有两种方法完成，一种是通过工具将源数据导出成.txt,.xls文件，然后再讲这些源系统文件导入到ods中，另外一种方法是通过程序接口来完成。
3. 对于文件类型数据源（.txt,xls），可以培训业务人员利用数据库工具将这些数据库导入到指定的数据库，然后从指定的数据库中抽取。或者还可以借助工具实现。
4. 增量更新的问题
   对于数据量大的系统，必须考虑增量抽取。一般情况下，业务系统会记录业务发生的时间，我们可以用来做增量的标志，每次抽取之前首先判断ods中记录最大的时间 ，然后根据这个时间区业务系统取大于这个时间所有的记录。利用业务系统的时间戳，一般情况下，业务系统没有或者部分有时间戳。
   数据的清洗转换（cleaning，transform）
   一般情况，数据仓库分为ods，dw两部分，通常的做法是从业务系统到ods做清洗，将脏数据和不完整数据过滤掉，在从ods到dw的过程中转换，进行一些业务规则的计算和聚合。
5. 数据清洗
   数据清洗的任务是过滤那些不符合要求的数据，将过滤的结果交给业务主管
   部门，确认是否过滤掉还是由业务单位修正之后在进行抽取。
   不符合要求的数据主要是有不完整的数据，错误的数据，重复的数据三大类。
   1.不完整的数据：这一类数据主要是一些应该有的信息缺失，如供应商的名称，分公司的名称，客户的区域信息缺失，业务系统中主表与明细表不嗯呢该匹配等。对于这一类数据过滤出来，安缺失的内容分别写入不同Excel文件向客户提交，要求在规定的时间内补全。补全后才写入数据仓库。
   2.错误的数据：这一类错误产生的原因是业务系统不够健全，在接受输入后没有进行判断直接写入后台数据库造成的，比如数值数据输出成全角字符，数据前后有不可见字符的问题，只能通过写SQL语句方式找出来，然后要求客户在业务系统修正后抽取。
6. 数据转换
   数据装换的任务主要进行不一致的数据转换，数据粒度的转换，以及一些商务规则的计算。
7. 不一致数据转换：这个过程是一个整合的过程，将不同业务系统的相同类型的数据统一，比如同一个供应商在结算系统的编码是xx0001而在crm中编码是yy0001，这样在抽取过来之后统一转换成一个编码。
8. 数据粒度的转换：业务系统一般存储非常明晰的数据，而数据仓库中数据时用来分析的，不需要非常明晰的数据。一般情况下，汇建行业务系统数据按照数据仓库粒度进行聚合。
9. 商务规则的计算;不同的企业有不同的业务规则，不同的数据指标，这些指标有的时候不是简单的加加减减就能完成，这个时候需要在ETL中将这些数据指标计算好了之后储存在数据仓库中，分析使用。
   1 缓慢变化维的设计？（真心常问，标准答案必备）
   三种：直接覆盖，增加新行，增加心属性列
   Type 1:覆盖：直接用新值代替旧值。
   Type 2:增加新行。将当前行的状态设置为off，并设置一个endtime时间戳，将当前时间标记上。
   同时新增1行，将其状态标记为on，设置begintime时间戳为上一个记录的endtime+1。
   Type 3:增加新列：给表增加一个新列，来存储新值，同时保留原来的值不变。
   2 拉链表使用场景和实现方式？
   拉链表使用场景：需要查看历史某一时间节点的状态，同时考虑到存储空间。
   实现方式：
   首先是拉链表dw_order_his的设置，有start_date和end_date两个字段；
   其次在ods层创建一个ods_order_update表，储存当变化数据（包括insert和update的数据）
   源表（order）
   ods_order_update表和dw_order_his表的交集进行封链操作，end_date=current_date
   ods_oder_update数据插入到his表中，对于记录的end_date=9999-12-31,start_date=current_date
   使用场景
   在数据仓库的数据模型设计过程中，经常会遇到下面这种表的设计：
    有一些表的数据量很大，比如一张用户表，大约10亿条记录，50个字段，这种表，即使使用ORC压缩，单张表的存储也会超过100G，在HDFS使用双备份或者三备份的话就更大一些。
    表中的部分字段会被update更新操作，如用户联系方式，产品的描述信息，订单的状态等等。
    需要查看某一个时间点或者时间段的历史快照信息，比如，查看某一个订单在历史某一个时间点的状态。
    表中的记录变化的比例和频率不是很大，比如，总共有10亿的用户，每天新增和发生变化的有200万左右，变化的比例占的很小。
   【实现方式】
   全量主要数据表加载的策略为每次加载时需要根据主键将目标表的数据与源表数据进行比对，删除目标表中在源数据表中的相关记录，然后将源表数据全部插入目标表。表现在脚本上为先delete相关记录，然后insert所有记录。主表加载策略主要用于大部分主表的加载，比如客户信息等主要数据表。
   增量拉链是指每次加载时，将源表数据视为增量抽取后的结果，加载到目标表时需要考虑数据历史情况。一般数据发生变化时关闭旧数据链，然后开新数据链。增量拉链针对的是历史表情况，由于数据仓库中记录了大部分数据历史表变化情况，因此增量拉链加载策略在数据仓库中是使用比较广泛的一种加载策略。通常这种历史表都含有start_date和end_date字段，首先全字段对比源数据和目标表得出真正的增量数据，这里的全字段不包含start_date和end_date字段，然后根据主键对目标表进行关旧链操作，然后对新增数据开新链，这种拉链策略同样可以处理全量数据。
   3 拉链表性能优化
   拉链表当然也会遇到查询性能的问题，比如说我们存放了5年的拉链数据，那么这张表势必会比较大，当查询的时候性能就比较低了，个人认为两个思路来解决：
   在一些查询引擎中，我们对start_date和end_date做索引，这样能提高不少性能。
   保留部分历史数据，比如说我们一张表里面存放全量的拉链表数据，然后再对外暴露一张只提供近3个月数据的拉链表。
   4 星型模型和雪花模型区别
   星形模型(Star Schema):
   Ø 事实被维度所包围，且维度没有被新的表连接
   Ø 星形模型是一个比较折中的的建模方式(BIAPPS中都是用的是星形的建模方式)
   雪花模型(Snowflake Schema):
   } 事实表被多个维表或一个或多个层次所包围
   } 雪花模型一般在处理大的且相对静态的层次的时候使用
   根据事实表和维度表的关系，又可将常见的模型分为星型模型和雪花型模型。
   　　星形模型：当所有维度表连接到事实表上的时候，整个图就像一个星星，故称之为星型模型。星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连，不存在渐变维度，所以数据有一定冗余。因为有冗余，所以很多统计不需要做外部的关联查询，因此一般情况下效率比雪花模型高。
   　　雪花模型：当有多个维度表没有直接连接到事实表上，而是通过其他维度表连接到事实表上时，其图形就像雪花，故称雪花模型。雪花模型的优点是减少了数据冗余，所以一般情况下查询需要关联其他表。在冗余可接受的前提下使用星型模型。
   星型模型和雪花模型的区别在于：维度表是直接连接到事实表还是其他维度表。
   5 简述数据仓库中的表的基本类型，以及为了保证引用完整性该以什么样的顺序对它们进行加载。
   答：数据仓库中的表的基本类型有维度表、事实表、子维度表、桥接表等几类。其中子维度表即雪花模型由支架维度技术处理，桥接表用来处理多值维度或层级结构。
   数据仓库中需要加载的各类表之间有相互依赖的关系，所以加载时需要以一定的顺序进行加载。下面是一些加载的基本原则：
   子维度表加载成功后，再加载维度表。
   维度表加载成功后，再加载桥接表。
   子维度表、维度表和桥接表都加载成功后，再加载事实表。
   这个加载顺序可以通过主外键的关系来确定。（注意，此回答为总线架构的数据仓库的表的加载顺序。）
   6 事实表和维度表的概念及类型
   6.1 事实表的概念
   Ø 每个数据仓库都包含一个或者多个事实数据表。
   Ø 事实数据表可能包含业务销售数据，如现金登记事务所产生的数据，事实数据表通常包含大量的行
   Ø 一般事实表中只存放数字或者一些Flag用来统计(Count)，如收益、数量、支出等
   6.2 事实的类型
   } 粒度事实表(Additive Fact)
   } 周期快照事实表(Semi-Additive Fact)
   } 聚合快照事实表(Non-Additive Fact)
   } 非事实事实表(Factless Fact Table)
   粒度事实表(AdditiveFact):
   } 表示的是在特定时间、空间点上的一次瞬间的测量。与粒度同层次的事实表，可以直接将事实字段进行Sum,Count等聚合操作
   } 在事实表的设计时，一定要注意一个事实表只能有一个粒度，不能将不同粒度的事实建立在同一张事实表中。
   } 交易粒度事实表的来源伴随交易事件成生的数据，例如销售单。在ETL过程中，以原子粒度直接进行迁移。
   周期快照事实表(Semi-AdditiveFact)
   } 周期快照事实表表现的是一个时间段，或者规律性的重复。这类表非常适合跟踪长期的过程，例如银行账户和其他形式的财务报表。最常用的财务上的周期快照事实表通常有一个月粒度。在周期快照事实表中的数据必须符合该粒度（就是说，他们必须量测的是同一个时间段中的活动）。对于一个好的周期快照事实表来说就是在粒度上有更多的事实。
   } 在ETL过程中，以固定的时间间隔生成累计数据。
   聚合快照事实表(Non-AdditiveFact):
   } 聚合快照事实表用于描述那些有明确开始和结束的过程，例如合同履行，保单受理以及常见的工作流。聚合快照不适合长期连续的处理，如跟踪银行账户或者描述连续的生产制造过程，如造纸。
   } 聚合快照事实表的粒度是一个实体从其创建到当前状态的完整的历史。
   } 在ETL过程中，随着业务处理过程的步骤逐步完善该表中的记录。
   非事实事实表(FactlessFact Table):
   } 每个事实表的粒度是一个事件量测。用来描述数据或事件。事件可以发生，但是没有具体的测量值。
   6.3 维度表
   Ø 维度表可以看作是用户来分析数据的窗口，
   Ø 维度表中包含事实数据表中事实记录的特性，有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分析者提供有用的信息，
   Ø 维度表包含帮助汇总数据的特性的层次结构。
   6.4 维度分类
   维度的类型:
   } 缓慢变化维(Slowly Changing Dimension)
   } 快速变化维(Rapidly Changing Dimension)
   } 大维(Huge Dimension)和迷你维(Mini-Dimension)
   } 退化维(Degenerate Dimension)
   缓慢变化维(SCD):
   } 大多数的维度的内容都会有不同程度的改变。比如：
   } 雇员的升职
   } 客户更改了他的名称或地址
   } 我们如何去处理这些维度中的变化呢？
   } 下面提供了三个处理缓慢变化维的方式
   } 直接更新到原先记录中
   } 标记记录有效时间的开始日期和结束日期，加入版本控制
   } 在记录中添加一个字段来记录历史
   快速变化维(FCD):
   } 当某个维度的变化是非常快的时候，我们认定他为快速变化维(具体要看实际的变化频率)，比如：
   } 产品的价格，地产的价格等
   } 例如在一个分析用户如何使用搜索引擎的DW项目中，将用户搜索的关键字作为一个维度。由于用户使用的关键字会快速变化，因此关键字维度中的数据量会迅速增加。
   } 另外一个例子就是精度为秒的时间维度，每秒就会增加一个维度值
   通常RCD的处理可以分为3类：
   Rapidly Changing Small Dimensions – 即维度表字段并不多，表的数据量也不大的情况。这种情形应用SCD中的Type2就可以了。(即：新增一行，旧行置过期)
   Rapidly Changing Large Dimensions – 即维度表字段较多，表的数据量较大的情况。这种情形Type2会增加过多的行并导致效率降低，因此通常采用Type3.（新增列：仅保存上一个值previous_value,current_value）
   Rapidly Changing Monster Dimensions – 最糟糕的情况，即维度表字段较多，表的数据量很大，且维度表中的一部分字段频繁变化的情况。此时应将相对稳定的字段和频繁变化的字段分割开，频繁变化的字段独立出来形成新的维度表与事实表相连或形成新的雪花关系。（维表分离）
   大维度(HugeDimension):
   } 数据仓库中最有意思的维度是一些非常大的维度，比如客户，产品等等。一个大的企业客户维度往往有上百万记录，每条记录又有上百个字段。而大的个人客户维度则会超过千万条记录，这些个人客户维度有时也会有十多个字段，但大多数时候比较少见的维度也只有不多的几个属性。
   } 大维度需要特殊的处理。由于数据量大，很多涉及大维度数据仓库功能可能会很慢，效率很低。你需要采用高效率的设计方法、选择正确的索引、或者采用其它优化技术来处理以下问题，包括：
   向大维度表填充数据
   非限制维度的浏览性能，尤其是那些属性较少的维度
   多限制的维度属性值的浏览时间
   涉及大维度表的对事实表查询的低效率问题
   为处理第二类修改所需要增加的额外的记录
   迷你维(MiniDimension):
   } 将常用的大维度中的少数字段提取出来，形成一个字段少的维度，在查询的时候便可以使用迷你维中的字段
   } 这样的设计明显提高查询效率
   普通维:
   普通维是基于一个维表的维度，由维表中的不同列来表示维度中的不同级别。
   雪花维：
   雪花维是基于多个维表的维度，各个维表间以外键关联，分别存储在同一维度中不同级别的成员列值。
   父子维：
   父子维是基于两个维表列的维度，由维表中的两列来共同定义各个成员的隶属关系，一列称为成员键列，标识每个成员，另一列称为父键列，标识每个成员的父代。
   父子维度通俗的话来讲，这个表是自反 的，即外键本身就是引用的主键；类似这样的关系，如公司组织结构，分公司是总公司的一部分，部门是分公司的一部分，当然如果定义得好的话员工是部门的一部 分；通常公司的组织架构并非处在等层次上的，例如总公司下面的部门看起来就和分公司是一样的层次。因此父子维的层次通常不固定的。
   因为父子维的复杂的自引用关系，如果按照缓慢维度的全历史记录方式来处理，必然导致逻辑关系混乱，处理起来比较棘手；任何一个组织的变动 (修改名称，更改引用，新增等等操作 )将会引起其下属节点相应的变动；任何一个意外都会导致整个结构的变化，同时发生意外后所带来的逻辑关系很难理顺。而 SQLServer2000中 Analysis Service对于这种急剧的变化处理并不稳定。
   因此建议按照缓慢变化维的覆盖方式解决，即只根据主键这个唯一标志进行判断是否是新增还是修改。
   索引：
   与在其他关系数据库中一样，索引对数据仓库的性能具有重要作用。每个维度表都必须在主键上建立索引。在其他列如标识层次结构级别的列上，索引对于某些专用查询的性能也很游泳。事实数据表必须在由维度表外键构成的组件主键上建立索引。
   粒度(Grain) 层次(Hierarchy)：
   Ø 粒度是指数据仓库的数据单位中保存数据的细化或综合程度的级别。细化程度越高，粒度级就越小；相反，细化程度越低，粒度级就越大。设计粒度是设计数据仓库中的一个重要的前提
   Ø 层次指描述明细数据的层次
   一些影响维度建模的因素:
   Ø 数据或展现的安全性
   Ø 复杂的查询和分析