压在数据分析同学身上的”三座大山”

最近跟数据分析同学闲聊,收集了一波数据分析同学被挑战的问题。比较有趣的是,不同部门的数据同学提的问题,很大部分问题是重叠的。问题简述如下:

1、这个数据为啥不一致,靠谱不靠谱?
2、计算为啥这么慢,跑一段sql的事情要这么久么
3、筛选维度为啥不能自由组合,多选+汇总+展开都支持
4、数据需求就跑sql,为啥那么慢呢
5、虽然没数据,逻辑你先写吧
6、我要这个数据,下午给我
7、我们什么时候搞点机器学习项目
8、自己模仿跑sql,挑战结果不一致
9、报表数据不能跨年查询
10、报表上线后很长一段时间都会被反复追问口径和逻辑,用的哪个表,怎么算的
11、希望在报表侧自由选时间段并且数据是时间段内按人数去重汇总
...

有些问题比较类似,进行了合并,并命名为压在数据分析同学身上的"三座大山",再简述如下:

数据计算慢

1、查询慢,这个报表能不能用,跨年查询卡死了
2、计算慢,日报还没推送,今天还没出,为啥这么慢
3、实现慢,这个需求只要简单跑个sql,为啥那么慢

数据维度繁杂

1、导数支持,要汇总也要细分,更要明细,报表麻烦支持下
2、实时去重,希望根据不同时间,去重统计UV
3、多维支持,再加几个维度吧,现在十多个维度还有点少

数据准确性

1、指标差异,这2个指标看起来一样,数值对不上
2、对数差异,模仿跑了下sql,结果不一致,给我解释解释
3、逻辑验证,逻辑复杂,计算逻辑和口径无法确认准确性

暂不讨论解决方案,要完整的解决这些问题 ,底层计算方案、BI方案是需要review的。

不过,我们从中可以窥探出,需求方理解的数据需求实现,特别是PB数据需求实现,是有理解偏差的。可能很多产品或者前端同学对“大数据”意味着什么,并没有概念,所以需求就可能想当然。

简单挑几个点讲讲。

“数据计算慢”的问题,如果需求方说:“帮忙跑个sql”,并且附带一句:“这个需求很简单”,一般的数据分析师会默念或者画圈圈。“实现慢”是按需求者视角,不考虑实现者的需求并行负担。另外的真正的“计算慢”的问题一般跟实现相关,数据倾斜的概率比较大,数据分析师是要好好解决的。

“数据维度”的问题,从开源的实现方案看,apache kylin可以部分解决"数据维度"的问题,但是多维度也是需要预先定义好的。

只要统计数据又要明细数据是见过最多的统计需求,问题是,统计需求又要明细,那么意味着原始数据存储的量是特别大,必要性要好好评估的。往往指标数据、监控数据或者原始记录的需求放一起是不对。

“数据准确性”的问题,当然,准确性是数据分析的基础要求,往往挑战来自于不同的报表实现,过多的特殊逻辑导致。整个数据的DWS层需要统一管理,这样应用层只取一处数据可以缓解的这个问题。

压在数据分析同学身上的”三座大山”