大数据技术研发：挖了三年数仓才懂，不是数据越多越好

三年前刚进公司大数据部门，leader扔给我一堆服务器权限，拍着我肩膀说，新业务要上，把能拿到的用户数据都存进来，越大越好。那时候刚毕业满脑子都是网上看到的ZB级处理、海量数据挖掘，觉得干大数据就是要处理别人处理不了的大数量，所以想都没想就申请了扩容。三个月把集群容量翻了一倍，还拿了季度的公开表扬。

半年后项目复盘，财务拉存储账单出来，我脸都绿了。百分之八十的存储从上线到那次复盘，一次都没被读取过。几百万的存储费用就这么打了水漂，说不懊恼是假的。

入行第一年踩的坑：把堆数据当成了做研发

说实话，现在很多公司做大数据技术研发，第一步就踩了这个坑。业务说我要大数据，老板说我们要砸钱做数字化，上来就是买集群、招团队、把所有能爬虫能拿到能导出的数据都往里面塞，仿佛存的数据越多，大数据做成了的概率就越大。

我之前参加行业沙龙，听过一个创始人吹，说他们公司存了PB级的用户行为数据，未来肯定能爆发。我当时就想问，你这些数据洗过吗？标过标签吗？有人用吗？没好意思开口罢了。

很多外行人，甚至很多刚入行的研发，都觉得大数据技术研发就是搭平台、扩集群、跑ETL，把数据从各个业务库抽出来存到数仓就算完工了。不对啊。要是这么简单，买个云服务开个容量不就完事了，要研发干嘛？

我刚入行那会，天天对着监控看集群的CPU利用率、存储使用率，就怕利用率不够被说浪费，结果现在反过来想，越追求把存储塞满，越浪费。那些塞进去就没人碰的僵尸数据，才是真的无底洞。

大数据技术研发到底在研什么？本质是做翻译

后来跟着部门的老架构师做了一个连锁零售的项目，才明白过来这个事。大数据技术研发的核心从来不是“堆数据”，而是“匹配需求”，把杂乱无章的原始数据，翻译成业务能用的格式，说白了就是给需求做适配。

举个例子你就懂了。原始数据就像是你从批发市场拉回来一整车没处理的菜，带泥带根还有烂叶子，堆在仓库里。业务要做一盘番茄炒蛋，你不能直接把一整车菜拉给厨师吧？你得把番茄挑出来，洗干净切好，把鸡蛋打好，装到盘子里给厨师端过去，这才是大数据研发要干的活。

要是你说，我把所有菜都堆给厨师，你自己找呗，那要你干嘛？厨师自己不会去拉菜吗？

很多人觉得大数据研发就是天天写SQL，没啥技术含量。这话错一半，写SQL确实是日常，但写之前的事，才是真的考功夫。你得先搞明白业务要解决什么问题，需要哪些维度的数据，哪些是噪音可以丢掉，哪些是核心必须留，然后设计分层，算存储成本，调查询性能，让业务要的时候能最快拿出来，还不花冤枉钱。

我之前做那个零售项目，客户要优化门店库存，一开始说要所有门店五年的所有收银数据，我们去捋了一遍，发现前两年的数据因为系统升级，品类编码全乱了，根本对不上，而且五年前的消费习惯和现在差太多，用上反而干扰预测。最后我们只取了近两年按新编码整理的销售数据，去掉了已经下架不做的品类数据，跑出来的预测结果，比全量数据跑的准确率还高十个点，存储只花了原来要求的三分之一。这不就是研发的价值吗？

没人愿意明说的误区：大数据技术研发也有边界

做了这么多年，见过太多无效的大数据项目，总结下来，大多都是踩了几个常见的误区，说出来给大家提个醒。

第一个误区，就是数据越多效果越好。我之前做消费信贷授信项目，一开始为了“做大做强”，把能拿到的用户数据全加进去了，什么社交好友数据、收货地址小区均价、甚至手机里的APP安装列表，全塞进去训练模型，结果出来的效果，还不如只用消费和历史还款数据的模型好。为什么？噪音盖过了信号啊，一堆和还款能力没关系的数据，只会让模型跑偏。

第二个误区，就是大数据研发必须搞AI搞大模型才能体现价值。不对啊，很多传统行业，哪怕不用任何算法，只要把数据理清楚，就能直接赚钱。我刚才说的那个零售项目，最后也没上多复杂的模型，就是把历史数据按季节、天气、地段分好类，算出每个店每天该进多少货，就把损耗降了两成，一年省几百万，这就是实实在在的价值，不比那些花里胡哨的模型差。

不过话说回来，大数据技术研发也不是万能的，它有自己的边界。它解决不了“你根本不知道自己要什么”的问题。很多老板说，你先把所有数据都存了，以后肯定有用。这种话听听就算了，百分之九十的“以后有用”，到公司关门都不会用上，年年交存储费，纯纯的冤枉钱。

当然，合规要求必须存的交易数据那另说，那是必须的，不算在这个里面。

我现在做新项目，开口第一句从来不是“我们能拿到多少数据”，而是“我们要解决什么问题”。先把问题定清楚，再倒推需要什么数据，需要多少数据，再开始做研发设计。这么做下来，少踩了不知道多少坑，也少浪费了不知道多少钱。

做技术久了就明白，不管叫什么名字，多大的概念，本质都是解决问题。大数据技术研发也一样，不是比谁存的数据多，是比谁能把对的数据，在对的时间，给到对的人。就这么简单。