报表开发的几点原则

数据报表可以说是企业内部最常见的一种数据工具，不仅数据分析师每天要用它，业务部门也会每天用它。如果将房屋比作数据体系的话，报表可以算是砖瓦了。

此处讨论的报表暂且定义为传统数据报表，olap等自主bi报表不在范围内（虽然开发的原则很多是一致的）

数据来源

报表开发首先要保证的数据准确，不含脏数据，这是最基础的要求。规模较大的企业内部的数据来源都不一致，有的来自业务数据库口径，有的是ETL搭好的中间表，有的来自业务部门的填报数据。有的时候一致的指标口径还有不同的写法，避免数据混乱，尽量采取一致的口径，不自相矛盾。

优先使用ETL搭好的数仓中间表，不能实现的再使用业务库口径。
做好数据清洗与校对，同一个指标的实现可以从其他方向进行校对，检验逻辑
写好注释，写注释是一个好习惯，可是有的人就是不写。每次遇到没有注释的报表要修改时，有的还附带各种存储过程与自定义函数，没有注释的话简直痛不欲生。写好注释，造福大家。

报表的从呈现形式一般可以分为两种，一种是统计类报表。
统计类可以直接做报告用或者在报表里开发可视化，一般不需要二次加工。还有一种是明细数据，这种主要用来进行更细颗粒的分析和挖掘。

针对第一种报表的基础指标，如app活跃日指标与日业绩指标等，尽量要做成可视化的形式。

针对明细数据，需要更加谨慎

明细数据会让业务同学无所适从，养成什么数据都想看，看了却不知道干什么的境地，无形中增加了双方的工作量。对明细数据要深入聊业务方的具体需求，想要做什么最终实现，否则工作量是巨大的。
明细数据一般的颗粒度都比较小，所以信息安全问题要格外注意。敏感的数据避免出现，或者直接在数仓做隐藏处理。

对业务的支撑及扩展是开发报表最需要恪守的一个原则，需要和业务方深入沟通。

明确业务方目的
- 业务方有时候并不清楚自己提的需求是什么目的，这个时候需要和业务方一层一层沟通当前业务的处境，让大家都理解需求的目的。否则稀里糊涂做了又是无用功。
- 业务方有时候提的需求是不合理的，可能业务放的需求用A字段实现，可业务方偏偏提了B字段的需求，这个时候需要分析师从数据的角度来矫正及建议。
对业务的扩展
- 明确了业务需求目的后，最基本的报表方向就不会跑偏了。其次就是从业务和数据的角度去扩展理解
- 比如报表需求要支撑的业务周期是多久？后续会不会进行一些迭代？观察了业务库的表结构后采用那种逻辑比较经得起变更？要不要考虑了预留字段
- 支撑和扩展考虑的主要是长度和宽度。长度指的是时间，如果报表开发完预计使用只有1个月，还划不来开发成本。宽度指的就是延展性，是否经得起业务变更。

写文档尤其重要，因为这个使用报表的人不一定是很熟悉业务的人，也可以顺带锻炼自己对业务的理解能力。