【干货】公司年终业绩分析报告,你的数据统计对么?

每年年终或新年伊始,公司管理层都要从各个角度比如部门、产品线等考察公司过去一年的业绩,作为数据分析团队,你需要向管理层准备这样的数据分析报告,而在此过程中,你可能会面临着这样的问题:

* 公司的组织架构在过去的一年中发生了调整,部分人员的所属部门也因此发生了变动,那各部门的业绩如何统计?

* 由于业务优化,公司一些产品的分类发生了变更,那全年各产品分类的销售数字如何统计?

为了生成上述业绩报告,多维数据分析是最常用与高效的技术手段。通过多维建模,将员工业绩、产品销售定义为事实表,把员工、产品、日期等定义为维度表,从而方便高效的从各个维度对公司核心 KPI 进行汇总统计和对比分析,以下便是基于销售数据的一个简单多维分析模型示例。

图表1:一个简单的多维模型示例

事实表一般会每天更新,而维度表尽管基本稳定,但也会随着时间发生变化,比如产品的分类、客户的国家、员工的部门等,这就是多维数据分析中的缓慢变化维概念(Slowly Changing Dimension, SCD)。如何处理这个变化,回答本文开始的问题,需要根据查询分析的特定需求分别处理,业界称之为缓慢变化维度的处理


缓慢变化维度的常见处理方法

一般来说,最为常见的缓慢变化维度的处理方法有类别 1 (Type 1) 和类别 2 (Type 2),其具体处理方法和查询举例如下:

* 类别 1:维度表中直接覆盖原值,查询时只能使用最新的维度属性,反应维度最新状态(latest status);

* 类别 2:维度表中添加新的记录,通常增加有效期字段来区分,记录维度表所有历史变化,从而使得历史可追溯。在查询时一般使用当时的维度属性,反应历史事实(historical truth)。

以图表1的多维模型为例,假设产品 iPhoneX 在 2018 年双 11 后,分类从 3C 调整为了 Mobile,以下分别是类别 1 和类别 2 对产品维度表的处理方法,以及在查询 2018 年各产品分类的销售数字时的结果:

图表2: 缓慢变化维类别 1 和类别 2 的处理方法与查询结果示例

注:类别 2 的处理方法有各种具体实现方法,比如常见的拉链表,但基本原理一致。

讲到这里,相信各位已经对文章开头的问题已经有答案了,现在需要做的就是和业务方沟通,统一数据统计口径,然后在 ETL 或者数据仓库中具体实现。在一些复杂的场景中,还会使用到类别 3 和类别 4,甚至是混合的处理方法,本文不在此进行深入讨论,具体内容各位可以参考相关文档。


Kyligence的缓慢变化维处理实践

在大数据场景下,为了加速数据分析的性能与并发,基于多维模型(Cube)进行预计算是最为行之有效的方法之一。开源顶级项目 Apache Kylin 便是其中代表,而基于它为核心的企业级大数据分析平台 Kyligence Enterprise,更是实现了 PB 级数据的亚秒级查询响应和数以千计的高并发访问。

默认情形下 Apache Kylin 与 Kyligence Enterprise 对所有维度表均做类别 2 处理,每次 Cube 刷新时记录当时的维度表数据,以便在查询时使用并反应当时的历史事实。


启用缓慢变化维类别 1

在默认情形下,当用户需要使用最新维度表信息统计结果时,即需要类别 1 处理方法时,就需要刷新所有 Cube 历史数据,这带来了大量额外的计算开销,在海量数据场景下无法接受。因此,Kyligence Enterprise 从 v3.2.2 版本之后,内生支持缓慢变化维类别 1,用户可以在定义模型时,通过简单的设置,即可对维度表启用缓慢变化维类别1处理,如下图:

图表3 Kyligence 支持缓慢变化维类别1处理

对于启用了缓慢变化维 Type 1 的维度表,Kyligence Enterprise 将仅保留一个最新版本,并在每次 Cube 数据刷新时更新该维度表,而在查询时,所有 Cube 历史数据(Segments)将与该最新的维度表联接并反馈查询结果,其原理如下图所示:

图表4 Kyligence 支持缓慢变化维类别1处理原理


总结

以上便是多维分析中缓慢变化维与常见处理方法的简单介绍,以及 Kyligence 与 Apache Kylin 在大数据场景下的实践。

在海量数据多维分析场景下,Kyligence Enterprise 实现了灵活的缓慢变化维类别 1 和类别 2 的处理,既保障了查询性能,又避免了不必要的 Cube 数据刷新的开销,从而满足不同的数据分析需求,大幅提升大数据分析的效率。

未来 Kyligence 还会做更多探索与改进,比如类别 1 和类别 2 的灵活切换,支持更多缓慢变化维处理类型等,敬请期待。


更多详情,请参考 Kyligence 官方网站:

Kyligence - Enterprise OLAP for Big Data​www.kyligence.io

或 Kyligence Enterprise 用户手册:

https://docs.kyligence.io​docs.kyligence.io


关于Kyligence

Kyligence 由首个来自中国的 Apache 软件基金会顶级开源项目 Apache Kylin 核心团队组建,是专注于大数据分析领域创新的数据科技公司。Kyligence 提供基于 Apache Kylin 的企业级大数据智能分析产品 Kyligence Enterprise,以及基于公有云的托管式 Kylin 在线服务 Kyligence Cloud。目前,Kyligence 已赢得了海内外多家金融、保险、证券、电信、制造、零售、广告等企业级客户。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,802评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,109评论 2 379
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,683评论 0 335
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,458评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,452评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,505评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,901评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,550评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,763评论 1 296
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,556评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,629评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,330评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,898评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,897评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,140评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,807评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,339评论 2 342

推荐阅读更多精彩内容