数据中台，是炒作还是未来？

从 2018 年末开始，数据中台这个词，突然在大数据圈儿走红。大家聊天如果不提中台，好像就落伍了。

但实话说，作为跟数据库打了十多年交道的人，我觉得，数据中台是个新词，但其背后的东西，其实历史悠久。
　　从技术运维日常工作来说，其意义如下。
　　第一、安全隔离。尽量防止前端请求直接调用数据库，要知道SQL注入曾经肆虐了互联网好几年，很多知名网站都暴露过致命问题，但那时候，确实互联网对数据库技术的应用，非常原始。
　　第二、压力控制。中间层可以有效减缓前端并发请求的瞬间压力，保障数据库系统的稳定性和可持续性。比如说，如果A业务遭受攻击，瞬间超高并发请求，由于存在中间层阻拦，A业务崩溃，但数据库仍然可以保持稳定，其他B业务，C业务，仍然可以稳健进行。如果没有中间层，那么数据库直接崩溃，A业务，B业务，C业务，一并崩溃。
　　第三，扩展能力。数据库容量增加，可能以前只需要10台服务器，现在需要50台，甚至500台，那么如果是业务直接对接数据库，随着容量和业务诉求增加，需要不断调整代码，改变链接接口和调用方法。但如果通过中间层链接，业务端无需顾虑数据库端的扩容，甚至一定程度的数据结构改变。
　　第四，代码维护和团队工作，降低耦合度。开发进行到一定规模，有很多业务分支，有很多业务团队同时对一套数据库系统做相关开发，这时候如果你想后台做优化，就会变得特别扎手，因为一点点调整和改动，指不定哪里就炸雷。这在具有一定体量的系统里，是很常见的事情，大家只能通过打补丁来处理诉求，谁也不敢做深入的重构。
　　数据中间层可以隔离所以具体业务诉求，优化数据结构，对数据系统做重构，只关心接口请求即可，第一看请求类型，第二看请求频次，减少彼此之间的耦合度，很多事情也就容易多了。
　　认真说，你在一定规模的团队工作一定时间后，你就会明白，为什么一直强调低耦合，低耦合。
　　以上说的是早期数据中间层的作用和意义，但现在提起数据中台，毕竟时代在前进，这个词已经包括了新的内涵，在业务逻辑上超越了我们那个年代，对一些大型互联网巨头来说，数据中台还会承载一些基于数据的基础服务能力的输出，举一些常见案例来说：
　　通用的风控防范反羊毛党能力
　　通用的推荐策略
　　通用的预警和灾难响应能力
　　通用的业务转化漏斗模型分析能力
　　你只要喂给它符合格式诉求的数据，并提出诉求，数据中台就会给你符合预期的数据报表或者相关数据服务，这让很多业务开发可以专注自身业务，现在很多大公司多业务线都是小团队各自为战，有数据中台后，整体效率和竞争力就上了一个台阶。这也是草根团队越来越无法跟巨头竞逐的一个重要原因。