背景
- “XXX，看一下这两份数据为什么对不上？”
- “XXX，你出的这份儿数据，和上个月XXX出的数据差异很大，你们看一下是什么问题”
- “这个指标是怎么算出来的？”“你去问XXX，这个是他做的。”
- ……
对于数仓同学、或者数据分析师同学，这类拉扯一定不陌生。每周都要花费一定比例的时间，在“排查数据为什么对不上”这个事情上。甚至随着BI的持续建设、产品的持续完善，这类问题越来越多。以至于数据分析师意外地成为了一个流动性很高的岗位。
这背后的问题根源是什么？我们又如何解决呢？
原因浅析
听说过这样一句话：
“数据就像UI一样，即使再外行的人，也能过来指点几句”
别看全公司从上到下、横跨各个部门都在重视数据，但真正能把指标含义讲清楚的，可能连10%的人都不到。
可以试试去问问自己公司里那些重视数据的同事们，“咱们公司的GMV是怎么算的”。看看能得到多少个不同的答案。
在不同人心中，对同一个指标有不同的理解，是很正常的事儿。
首先，不是每个人都需要知道指标的含义，他们只需要知道哪些指标和自己的业务挂钩，怎样努力能让指标上升/下降即可。
其次，指标名称往往是一个很短的词汇，大多在十个字以内，甚至有些还是英文缩写，单从名称上根本想象不出来它背后有多么复杂的处理加工过程。
然后，公司业务在持续发展，同一个指标在不同时期的含义也可能会发生变化。例如某项业务是中途新开展的，那早期的数据指标里就不可能包含此业务相关的部分。换句话说，同一指标在不同时期的含义也会有所不同。
最后，人员流动造成的影响使这一问题变得更加不可控。一批又一批新人的加入、一批又一批老人的离职，把团队在“事理”和“人理”上的管理的重要性提升到了一个很高的高度。流程、规范、跨部门沟通等，任何一项做的不到位，都会导致混乱。
我们把以上全部原因放到一起分析之后就会发现，这不是光靠管理上的提升就可以解决的问题。我们需要把能靠系统解决的问题，全部放到系统中，将人为造成影响降到最低。
明确方向
整个取数流程，在需求提出后，可能涉及到的步骤包括：
- 需求分析；
- 任务分配/确认排期；
- 开发；
- 测试/数据校验；
- 交付；
“需求分析”较为复杂，需要双方甚至多方进行沟通、会议等途径来达成一致，因此必须靠人工。剩下的步骤都可以通过系统解决。
愿景
1. 取数平台本身
我们对于取数平台本身的愿景，根据不同的使用者角色、以及不同的用数场景，大概分为以下几类：
- 中长期周期性关注的数据。
- 考虑将这类数据做成表格或图表，固化在BI平台中，一次开发，多人、长期使用；
- 考虑制作取数模板，可以在需求方需要取数时，人工使用模板取数；或提供周期性自动取数功能；
- 临时性取数需求，且需求方没有数据分析能力。
- 提供标准化自助取数功能。使用者无须深入理解数据的含义，只需在界面上填充取数条件、指标等信息，即可完成取数；
- 提供标准化的取数工单功能。数仓或数分同学提供专业的一对一服务，指导需求方使用自助取数功能、或直接提供数据结果；
- 临时性取数需求，且需求方有数据分析能力。
- 提供基于SQL的分析平台。使用者可以在平台上自定义SQL进行数据分析；
我们希望，100%的取数需求可以通过取数工单或自助取数功能解决，其中70%以上的取数需求能由需求方自己操作自助取数功能解决。
2. 全公司的数据输出
数据的输出，不止有BI、临时数据需求这几个途径。还会有大量的数据被固化到产品功能中，例如用户端APP上的某些数据看板、后台系统上的数据统计模板等等。按上述方案，虽然能保证BI、临时数据需求的口径统一，但还无法保证与其他产品功能中的数据口径也一致。
如上图，我们在“数据仓库”与“应用层”之间，增加一层DataAPI，所有的取数都通过DataAPI提供服务，即可避免多源头造成的数据混乱。
