储存环节，数据分析师应该根据具体业务的实际需求，向数仓工程师提出相关的结果表建表需求，和与之配套的调度需求，同时也可以利用上一节梳理过的数据分析指标体系参与到数仓结构规划的讨论中。
做数据分析如何保障数据的准确性？
从业多年，在数据准确性上摔过不少跟斗，总结了一些切实有效的方法，能够帮你尽可能的规避错误，确保数据的准确性，分享给大家对数据上游的管理虽然看上去，数据分析师是掌握数据资源的人，但从数据的生产流程来看，数据分析师其实位于数据的下游，数据需要至少先经过采集环节、清洗环节、存储环节才能被数据分析师拿到，甚至有的体量特别大的数据，他的调取和处理环节也不能被数据分析师控制。
所以，想要最终做出的数据不出错，那就要先确保我们的数据上游是准确的。虽然数据上游一般是由其他业务或技术人员负责，但数据分析师也可以通过提需求或生产过程参与的方式，对数据上游进行管理：采集环节，负责采集环节的业务或技术人员往往会把注意力聚焦在采集实现方式上，而忽略了采集来的数据本身对应的业务含义，数据分析师需要在这个环节上跟他们反复说明根据业务含义反推出来的采集细节，确保大家在理解和实际执行上没有偏差，最好在设置一些采集质量的控制点，帮助业务或技术人员做好采集工作。
例如，APP的数据采集经常需要前端技术同学进行打点采集，这时数据分析师应该和技术同学一起讨论打点方案的各个细节，比如“启动”这个点对应的业务含义是想计算每天的活跃用户数量，那么启动点的采集就应该既包含点击APP图标启动又包含后台呼启，其中后台呼启与上一次退入后台的时间间隔应该至少大于30秒，否则可能被认为是用户的正常操作而非完成一次使用后的退出，30秒也是根据业务实际情况人为讨论设定的。
清洗环节，分析师应该在确认采集环节的细节后跟数仓工程师沟通数据清洗的规则，比如某个字段可能会含有某些方面的脏数据，需要通过何种规则被清洗掉。例如，打点采集上来的行为数据可能会因为用户手机网络环境问题或其他前端原因而导致上报的行为时间戳错误，那么清洗的时候就应该利用获取到的数据上报时间戳去填充或直接去掉这条记录。
储存环节，数据分析师应该根据具体业务的实际需求，向数仓工程师提出相关的结果表建表需求，和与之配套的调度需求，同时也可以利用上一节梳理过的数据分析指标体系参与到数仓结构规划的讨论中。例如，公司管理层需要每天关注的核心数据指标最好统一放在一张结果表里储存（为了提升BI的计算效率），管理层每天要在早上10点看到，那么对应的数据分析师应该在早上8点看到（以便提前发现问题并留出修正时间），结合数据采集和数仓拉取时间那么保险起见应该在7点完成底层表调度。
调取环节，我建议数据分析师能够梳理出一个常用的数仓表文档，便于平时日常的数据调取，而如果用到相对陌生的表则应该先与数仓工程师沟通确认表的字段含义、数据源头等再进行调取使用。处理环节，遇到体量比较大的数据需要借助工程师进行处理时，应该先明确好数据处理的要求和步骤，最好落实成一个执行文档再交给工程师让他按此进行处理，处理结束后要对数据结果进行核验。
设立数据“安检站”“大包小包过机安检”只要你坐过北京的地铁，相信这句话一定耳熟能详，为了确保所有旅客不把易燃易爆等危险品带入地铁内危及他人安全，地铁在每个进站口设置安检站对所有过往人员物品进行检查。虽然避免数据错误的最主要方法就是检查，但全流程无休止的数据检查显然是费时费力且效率低的，我们其实也可以在数据流入流出的关键节点设立“安检站”，只在这个时候进行数据检查。
一般我会在这些地方设立“安检站”：数据调取完成，如果原材料出错，后面一切都错，所以你需要把住数据流入的第一道关。数据处理完成，你需要利用数据处理后的结果进行分析判断，如果处理结果出错，你可能会因此错失关键线索而在问题里打转，会浪费远比你检查一下数据而多的多的时间。数据报告撰写完成，这是数据流出前的最后一道关，当然要仔细检查一遍，出了这个“安检站”，数据错误就会暴露在外无法再挽回了。
几种行之有效的检查方法：直接核对，拿处理前和处理后的某条数据对比，虽然简单粗暴，但对于一些关键数据的确认很有必要。勾稽关系验证，利用数据与数据之间的逻辑或计算关系，来验证数据的准确性。比如，A B=C或者A
