一、从目的上说 ， 这是为做分析，建数仓，组织管理 数据的一种方式，即就是所谓说的数据建模
你不列出可分析维度，你们做各角色的数据集，你没有一个纵向组合的维度把数据管理起来，你的数据怎么能成为数据资产，那只能是分散在业务中的数据，你给人说你有多少线索多少城市，没有根据，这就是一种拿数据说话 的方式，有零有整，不和你瞎说对不这才有可信度
二、技术角度，预计算，平埔， 加速，，
三、 仓库建模本身有维度粒度度量的概念的，不能用db思想去理解 和思考，它是来自字段，但有些不是，如80 90 后，Q1 Q2这是生成的观测维度，业务表只时间字段，再一个是据分析需求粒度，可以到天级 市级，而不在细分，或地域和负责人区分开不同维度，未来给观察人做的数据 集或是权限隔离了什么的都可以从这上面做
四、DB ER模型方便做分析的上钻下取旋转切片，那就没有数仓建模啥事了，是吧，自己写写SQL，我要看哪个城市 个哪省区线索最高，同时要看哪个季度，哪个月最高，同时我继续看，哪个季度月在哪个省市区最高，就这一个分析线索指标是吧不同维度粒度切换，你哪db sql 原始的方式，省 区，季 ， 月，这个用函数求了多少遍，得写多少条sqL
总结 ：要用数仓 立方体的思维， 不要用db 二维表的思维，思想很重要
仓库、模型、事实表建立：
1.仓库可按业务及业务组合分别分层建立（如：报名，邀约，成交，报名成交等），也可用通用观测维建立分层观测仓
2.仓库中含一和多个模型（星型，雪花型，或3f混合）建立分层数据集
3.一模型中通常由维表，事实表，lookup表组成
3.事实表由观测维度列（一般为基层维id，如图红色标注维列，及状态和可过滤维度列）和指标列（可度量列）组成
4.维度又有状态过滤普通/标准维和JOIN/导出维及通用/强制组合维（如图中四大通用/强制维在每个业务都有观测需求）和层级维之分，目的是为优化CUBE的创建，避免随着维度的增加，计算量和存储量呈几何倍数增长
5.cube是dm的预计算结果集，最快的查询优化计算方法就是不计算，它用空间换时间来提速大数据查询，实现秒级响影
参考kylin相关概念
3.1 Fact Table(事实表)：
事实表是指包含了大量不冗余数据的表，其列一般有两种，分别为包含事实数据的列，包含维表foreign key的列。
3.2 Lookup table：包含了对事实表的某些列扩充说明的字段。
3.3 Dimenssion Table(维表)：
由fact table和lookup table 抽象出来的表，包含了多个相关的列，提供对数据不同维度的观察，其中每列的值的数目称为cardinatily。
3.4 model:用来定义用户需要使用的hive表名，及所包含的维度列、度量列、partition列和date格式。
3.5 cube:用来定义某具体查询时会涉及到的维度列及相互之间的关系（如层级关系）、度量列的具体类型（如max，min，sum）等,一个model下可存在多个cube。
1.什么是cube？
cube是所有dimession的组合，每一种dimession的组合称之为cuboid。某一有n个dimession的cube会有2n个cuboid，如图：
对应一张hive表，有time,item,location,supplier这四个维度，则0-D cuboid时对应的查询语句为 select sum(money) from table;1-D cuboid对应的查询语句有四个，分别为select sum(money) from table group by time，以及select sum(money) from table group by item,以及select sum(money) from table group by location。对应的在2-D时group by 后面的维度会是time,item,location,supplier两两组合。如果不采取优化措施，理论上kylin在预计算过程中会对上述每一种组合进行预计算，随着维度的增加，计算量将会呈几何倍数的增长。为了解决这种问题，kylin对dimession做了分类，见下文。
2.dimession
为了减少cuboid的数量，kylin对dimession做了如下分类
normal：最为普通常见的dimession类型，与其他类型的dimession组成cuboid。
mandatory：每次查询均会使用到的dimession，在下图中A为Mandatory dimension，则与B、C总共构成了4个cuboid，相较于normal dimension的cuboid（23=8)减少了一半。
在实际生产应用中，比如对于日报表的分析，可能日期就是一个mandatory dimession。
hierarchy：带层级的dimession,如：年->月->日，要求子级的父级必须存在。如下的例子中cuboid由2n降为了n+1。
然而，Kylin的Hierarchy dimensions并没有做集合包含约束，比如：kylin_sales_cube定义Hierarchy dimension为META_CATEG_NAME->CATEG_LVL2_NAME->CATEG_LVL3_NAME，但是同一个CATEG_LVL2_NAME可以对应不同META_CATEG_NAME。因此，hierarchy 显得非常鸡肋，以至于在Kylin后台处理时被废弃了。
derived：指该dimession与维表的primary key是一一对应的关系，可以有效减少cuboid的数量，derived dimession只能由Lookup Table生成。
3.measure
measure为事实表的度量值，kylin提供了下面几个函数：
sum,count,max,min,avarage,count_distinct
其中count_distinct有两种实现方式：
（1）近似Count Distinct。Apache Kylin使用HyperLogLog算法实现了近似Count Distinct,提供了错误率从9.75%到1.22%几种精度供选择；
算法计算后的Count Distinct指标，理论上，结果最大只有64KB，最低的错误率是1.22%；这种实现方式用在需要快速计算、节省存储空间，并且能接受错误率的Count Distinct指标计算。
（2）准Count Distinct。从1.5.3版本开始，Kylin中实现了基于bitmap的精确Count Distinct计算方式。当数据类型为tiny int(byte)、small int(short)以及int，
会直接将数据值映射到bitmap中；当数据类型为long,string或者其他，则需要将数据值以字符串形式编码成dict(字典)，再将字典ID映射到bitmap;
指标计算后的结果，并不是计数后的值，而是包含了序列化值的bitmap.这样，才能确保在任意维度上的Count Distinct结果是正确的。
这种实现方式提供了精确的无错误的Count Distinct结果，但是需要更多的存储资源，如果数据中的不重复值超过百万，结果所占的存储应该会达到几百MB。
Mandatory Dimensions：每次查询均会使用的维度可添加在此。比如某些情况下的partition column.
Hierarchy Dimensions：维度列中彼此间存在层级关系的列，比如“国家-省份-市-县”
Joint Dimensions：每次查询会同时使用或不使用的维度组合。
Aggregation Group:在不同的查询中，两组维度组合之间不会产生交叉，可选择此选项，比如所有的cube维度有 [ a,b,c,d,e,f ] 6个，每次查询中只会同时查与 [ a,b,c ] 相关的信息（比如[a],[a,c]等）而不会查询 [ d,e,f ]，或者相反，则可选择此选项。
以上选择均可减少build过程中的数据量，是加快build与query速度的优化点之一。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
