案例来源：@洪斌
1. 数据仓库处理：近源数据层→数据宽表→基础指标表
1）近源数据层：封装中间层，实现：
a. 合并不同业务数据，如pc和app的日志数据
b. 脏数据屏蔽
c. 冗余字段合并
2）数据宽表：提取足够常用的字段，如订单宽表：
a. 基本订单信息
b. 订单中的用户画像，如下单人性别、城市、画像标签等
c. 订单状态
d. 订单风险（如是否空壳交易）
3）基础指标层：从宽表中提取，如消费者指标表、商户指标表
2. 数据分析工具
1）即席查询：即数据分析人员写查询语句查询，灵活性高
2）多维分析系统：对于每个主题，提取多个维，并对各个维可以做聚合操作（和、最大最小、平均），从而可以方便地分析如“各种支付方式在每个省的分部如何”等问题
3）搜索分析系统：基于维度建立索引，帮助逐层查询，如在A类商品的用户地域属性进行查询
4）固定报表系统：如GMV报表、店铺报表
|
工具名称
|
基本技术
|
适用人群
|
速度
|
灵活性
|
适用场景
|
|
即席查询
|
hive
|
1. 数据分析人员
2. 有能力的运营人员
|
慢:10m~1h
|
强
|
所有数据分析场景
|
|
OLAP系统
|
olap
|
产品经理, 运营人员
|
较快: 10s~10min
|
中
|
特定主体的多维分析
|
|
搜索引擎
|
倒排索引
|
1. 目的性强
|
快: 10s以下
|
中
|
根据条件的主题检索
|
|
报表系统
|
mysql
|
报表相关人员
|
快: 10s以下
|
低
|
特定业务数据的查阅
|
——————————————————————————————
思考：
1. 对于面向普通B端的数据产品开发，为了后续数据报表设计的灵活性，可以先维护一张数据宽表，然后在宽表的基础上进行后续的数据报表开发
2. 对于普通B端用户使用的数据报表产品，借鉴数据仓库 维度-事实（这里就是宽表） 的设计思想，先分析B端可能考虑到的维度，让B端可以对这些维进行组合，并可以做聚合操作，从而让B端灵活地得到自己想要的数据。
但需要注意的是，这需要B端用户有较好的数据能力和意愿，想要“玩数据”，否则灵活度越高，则难度越高
3. 对于高频的维度组合，可以固定为固定报表的形式