不要并行维护多个版本的数据： 因为业务的拓展，数据背后的口径可能有所变更，基于旧有的数据报表，简单修改后出一份新数据，是一种成本较低的实现方式 。但最好不要并行维护多个版本的数据，当版本超过3个的时候，维护的成本是直线拉升的 。所以当要做数据变更时，一方面可以降低变更的频率，另一方面尽量在原有报表里修改，并替换掉原有口径 。
不要在单个脚本里写过多内容： 统计逻辑的实现，就像是传统工业里的不同工序，这个过程里存在两种极端 。一种是把一个逻辑在横向/纵向细分为太多的工序，部署过多计算任务，形成很大冗余；另一种是完全打包在一个大脚本里，这种情况也不利于问题定位和中间数据处理 。所以不要在单个脚本里写过多内容，可以将它拆分进最优数量的计算任务中 。
要有一些基本的约束条件： 做一些事情时，不仅要立足于眼下的问题点，也要考虑一下未来可能发生的变化 。就像是造一座桥，修一条路，总要考虑极限情况下的压力 。很多的数据异常，往往是在业务变化时，旧有的逻辑不能适应当前的场景 。所以在一开始写脚本时，要考虑一下未来的场景，有一些基本的约束条件，这样会让所部署的任务会有较好的稳定性 。
要采用尽量简洁的写法： 能够一步到位的统计逻辑，就采用尽量简洁的写法，千万不要去绕圈子 。尤其是一些核心脚本，是要在不同环节，不同阶段的同事之间传承的，很多人并不了解当时的业务背景和需求逻辑，如果写法太绕圈子的话，最终就把大家一起绕进去了 。
2.如何健康地做数据规划
数据规划是一个层级比较中等的概念，往下一层，做需求开发时，往往只聚焦于特定的需求点，并不涉及其它内容；往上一层，做数据工程的话，又是基于整个部门，整个产品形态的框架搭建 。但数据规划更多是应对一个相对独立的业务场景，所做的规划与设计 。
一个不够好的数据规划，可能会引发后续的诸多问题点，比如：
痛点1： PM提出要在视图上扩展一个细分字段，觉得很简单 。我也觉得很简单，但就是更改不了，因为这个字段在数据源处理中就舍弃了，无法从上一层数据表中获得 。
痛点2： 想要重跑一个时间范围内的数据，但这张表不是分区表，无法并行处理；想要剔除某个日期内的数据，但不同表中时间格式不一致，导致处理结果有差漏等 。
痛点3： 同样的一条统计链路，部分为了保障每日推送而独立出去，部分为了特性统计而独立出去，由此产生了众多的细分链路，此后的变更也要在不同链路之间同步处理 。
以上列出的三个痛点，分别对应了原始信息的保留，技术实现的最优路径，以及计算任务的细分问题等，不过也只是数据规划需要思考的其中一部分问题点 。在不同的业务场景下里，可以有不同的数据规划思路 。粗糙地讲，可以分为数据基础层和业务细分层独立处理 。
数据基础层： 做一个数据规划，首先应该要考虑数据本身，在数据基础层里，应暂时抛开具体的业务细节，以数据为重 。这个时候应在处理中尽量地保留原始信息，同时要对数据源做好质量检验，第一道防线，往往是很重要的一道防线 。原始信息要完整，数据质量要合格，任务部署要轻便，这些是数据基础层的一些目标，也是后续工作的一个前提 。
业务细分层： 数据基础要独立而完整，面向数据本身；业务细分层则可以去细分实现，面向业务细节 。基于不同的业务目标，可以从源表中筛选不同的内容，用于应对特定的场景 。这样的数据+业务层级，形成了一种“总-分”结构，是数据规划的其中一种实现方式 。
3.如何在破旧与立新之间寻找平衡点
很多的工作，都是基于当下的场景，即使做了详尽的规划和思考，也不可能应对未来的所有问题 。当业务逐渐地深入发展时，很多的内容也需要做一些同步处理，小的层面上是一些数据表和视图的表更，大的层面上可能涉及计算平台的迁移，视图系统的重建等 。
破旧与立新，往往是一个长期存在的问题点 。不需要每天都进行自我“革命”，但改良和优化，则是一个长期过程 。在这个长期过程里，我们需要在破旧与立新之间寻找到平衡点 。
以上是笔者在TDW体系下写SQL的一些实践和思考，欢迎评论区留言讨论~
作者：cooperyjli，腾讯 CDG 数据分析师
推荐阅读
- 详解PostgreSQL数据库压测工具之pgbench-tools
- 搞懂 面向对象 的核心思想，JAVA中封装、包和访问权限的知识点
- MySQL查看连接数
- 一文搞懂队列
- 自动补全、回滚！介绍一款可视化 sql 诊断利器
- 一文了解数据仓库
- 我一直以为SQL先执行SELECT语句？一个窗口函数，我突然发现错了
- 两万字深度介绍分布式，一文入魂
- 一文带你弄懂 Java 动态代理
- Linux下的MySQL Proxy 读写分离该怎么操作？