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

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层需要统一管理，这样应用层只取一处数据可以缓解的这个问题。

商业，总体上关注成本和收入，钱是安身立命之本，所以从宏观维度看，成本构成、收入贡献是核心关注点，比如资产负载表、利润表、现金流量表。

从执行层面，可以继续细化，如下图：

商家Business、用户Customer、客户关系CRM

渠道Channels

关键活动、核心资源、核心伙伴

CRM

每个商业活动，我们希望不是一锤子买卖，所以客户关系建立和维系是很重要的，客户的发生和维系需要渠道能力支撑。

CRM主要关注三个方面：
1、用户信息建立，用户信息化
2、关键活动记录，用户个性化
3、用户关系管理，用户关怀

渠道Channels

渠道，包含收入渠道、支出渠道，包含各种触达用户的各种工具，比如：小程序、APP、PC、WEB、线下柜台。不同渠道成本、收入的效率是不一样的。渠道的种类和数量决定了商业规模，成本、收入的效率决定商业是否能否持续开展。

渠道的管理也是需要不断拓展和维系的。用户、渠道、CRM我们可以统称为3C。渠道的关注三个主题：降本、提效、增收。不同的考核对象关注不同的指标。

关键活动

买货、卖货，需要很多的活动去开展，即拓展和运营。而拓展和运营受限于我们的所拥有的核心资源、核心伙伴。我们可以统称三者为3K。

关键活动主要关注：
1、活动目标
2、投入成本
3、效果情况

核心资源、核心伙伴

核心资源和核心伙伴是发展壮大的主要因素，商业活动不可能一人成事。每个关键活动，需要供应商、合作方协作推动。

核心资源即竞争力，主要关注：
1、研发资源
2、客户资源
3、品牌价值

核心伙伴，主要考虑合作商家情况，比如供应商、开发商。