如何从0到1建设一个数据平台

注：这篇文章没什么技术内容，基本都是在谈经验。

为什么会写这篇文章？是因为做了一段时间的企业数字化工作，发觉不是所有的地方，都已经做好了一个数据平台，等你来大展身手。

更多的时候，你是来到了一片荒漠之中，把过去那些已经做的比较成熟的事情，重新的再做一遍，就像游戏开荒那样。因此，如果快速度过0-1的过程，从1开始发挥自己的价值，就显得很有必要，这是一个战略问题。

其实，数据在没有积累到一定程度时，是很难发挥出它的智能价值的，也就是数据平台的发展，绕不过“看数”的阶段。只要业务成熟到一定程度，数据才能发挥出它的增值潜力。

就像石油，我们都知道它是“工业的血液”，但中古时期的人们，除了战争，就无法有效的利用石油。但数据积累到了一定程度，就不能只玩数据本身。还是石油，能够分练出很多的有效产品，写很多的论文，但如果不能用在汽车、飞机上，就不能发挥出它的最大价值。

因此，在战略上，我们首先要重视0-1的过程，就要像军事那样筹备一场场的战役：“打仗，打的就是钱粮；数据，比的就是人力和机器成本。”如何在最短时间内，把石油精炼的体系给做出来，保证工厂能够长期稳定运行，是首要的目标。

毕竟，不论是做数据行业的人，还是用到的大规模机器，都是一笔不小的开支。

其实大多数的从业者，都心心念的希望能够做一个比较不错的项目，能够帮助客户或者用户挖掘出数据背后的价值，但现实却是，我们面临的往往是基础性的工作：看数。

所谓的“看数”，大体就是一个数据产品的雏形，包括非常多维的数据分析、下钻等功能，再配合几个简单的分析模式，成型了。

但，做好一个数据平台，仅仅依靠自己的力量是不够的，还需要跟前端、运营、算法、分析师等岗位结合，把数据炮弹送给前方，仗才有的打。

例如缺少了前端，平台的体验肯定是个问题；缺少了运营，平台推广不出去，直接价值就产出不来；缺少了分析师，指标体系做的就只是个空壳子；缺少了算法，智能肯定就谈不上了…… 所以，数据平台，更像是搭了个场子，欢迎大家都来使用，发挥群策群力的力量。

这就决定了，几乎没有什么平台，是一开始就做好了，都是先随着业务跑起来，再逐步的把基建夯实。但因为业务总是做不完的，平台也不会覆盖所有的case，因此最后都将迈向做业务的终极目标：提效降本。

所谓：提效降本，简单讲，就是把尽可能多的业务过程，自动化掉，把人均能做的工作量、运营背负的KPI，用数据工程的力量，来提升一个档次。同时，我们所消耗的资源，不论是人力还是机器，要尽可能的小。

既然所有的价值，都要回归到“提效降本”上，其实是说明，这世界上本就没有那么多的价值去做，基础科学不突破，地球舰队再庞大，终归不是水滴的对手。

讲完了战略，再讲策略，就是我们到底要做什么？

做什么，最好要有个参照物，假如你是一家互联网公司，阿里云就提供了大数据三件套：Dataphin + Quick BI + Quick Audience，这个是官网能够搜得到的。

这三件套中，Dataphin用作数据开发与建模，Quick BI用于报表产品搭建，Quick Audience则是最基础的用户增长的产品化方案。

所以，既然是从0-1，那么这个参照物，就把数据从采集、加工、分析、应用的全过程，提炼的比较完整了。当然，如果是其他的行业，或者是策略有差异，那么也可以参照一些其他的参照物。

早年我们把美国的商业模式搬到中国，称之为“C2C”，今天的参照物，不过是进一步细化了“C2C”，把商业模式的借鉴，下放到了产品设计中。

因为产品设计，尤其是像数据产品，并不像商业模式那样，能够直接产生经济价值，因此对软件领域PAAS层的借鉴或者说是抄袭，就不会像SAAS那样敏感，甚至样子都可以一模一样，基本上不会对外的。

有了参照物，接下来，就可以着手把数据平台的样子，画一张草图出来了。这张草图里，一定要有如下的这么几个部分：

• 开发工具；
• 研发规约；
• 协作流程；
• 质量保证；
• 报表工具。

五个注意事项 + 3个参照物平台，一个数据平台的框架，就清晰可见了。掌握了这些能力，搭建出一个可靠好用的数据平台，就只是时间问题了。

很多人会有一种误区，即做数据，我们要把整个流程都自己做，其实不是的。就像维度建模理论，能够把企业数据的“总线架构”给勾勒出来，但这并不代表你能够应对种种其他类型的需求，业务性的逻辑，还是交给工程组更合适一些。

因此，给数据平台划定一个研发的边界，是很有必要的，避免团队资源投入到大量无效的需求中去。或许1-100的过程里，个性化的需求需要去支持，但这绝对不是0-1应该考虑的。团队的研发协作，是有惯性的，如果一开始就掉进了需求陷阱里，就很难爬出来了，或者要退一层皮。

其实近年来，数据研发的岗位，招聘越来越难，一方面因为数据分析/算法岗太火，吃掉了绝大多数的增量从业者；另一方面，也是因为数据研发越来的越贴近业务，对于技术的要求有一种一言难尽的说法。要说面试造火箭吧，算法、架构都少不了，但实际的工作中，这些能力都被平台“赋能”了。

因此，越往上走，就要求对业务的贡献越大，对业务的理解也就要求越深，技术长期不用，能力自然会退化掉。

但这只是1-100过程中，所必须面临的问题。在0-1的过程里，需要的东西还是很多的。

讲完了策略，也就是数据平台目标的样子，接下来就是具体做事的方法了。简单讲，就是“轻重缓急”的选择。

如果我们画出完整的架构图，它大概是如下的样子：

在轻重缓急上，大体遵循：离线-->实时；模型-->报表；链路流程-->稳定性保障；单一工具-->多工具服务整合…… 这么几个原则。先做出可以使用的成果，在此基础上，再将架构图中缺失的部分一点点补充上，直到完成平台应有的样子。

这个过程要做的事情，其实是很多的，对抗“熵增”的具体技巧，就是工作经验所赋予我们的。

从这个角度上看，有两个“熵增”的最重要影响因素，需要控制住，即开发过程中的规范、维护需求迭代的协作方法。如何把规范做好，减少后期需要返工的工作量，同时控制需求不能无序增长，就是平台初建最重要的考量因素，而这些其实都与管理能力相关。

接下来，考量的是团队的分工，从框架、质量和建模等不同的角度入手，把整体框架搭建起来。这时候技术能力就很重要，例如实时能力选择什么技术方法，例如建模如何评价好坏，例如稳定性和质量如何在高速迭代中保持，等等。

当然，做过的东西，都要有所沉淀和输出，让后人理解我们这么设计的原因，同时遵循已经形成的规范，最好把影响力扩展到团队之外，吸引更多的人才加入。

所以，数据开发人才的三种能力：管理能力、技术能力（包括架构、代码能力）、沟通协作能力，就是具体需要学习的做事方法。

讲了这么多，从“提效降本”，到“参照物+规约工具流程”，再到需求的“轻重缓急”，基本上把0-1的过程讲述清楚了。

走完1之后，真正的挑战刚刚开始。今天我们大多数人倒腾的事情，也许只有本公司能用一下，一些业务看上去有价值，做起来是一坨屎，维护的人更是不想管它。

但，这都是表象。大公司的探索，是企业发展过程中都会遇到的问题，就像维度建模、数据治理、企业数字化这些理念，都是从大公司开始，扩散到了中小公司，最后普及到全行业。

这也就是说，大公司的探索，会成为日后小公司借鉴的经验。从这个角度看，我们折腾的各种东西，各种不靠谱的产品，其实都是在为这个行业的未来提供借鉴的经验。

所以，与其把过多的精力放在需求合不合理上，不如多思考这些需求背后的考量。

比如做一款企业决策型产品，大多数人会抱怨领导需求多么不靠谱、领导怎么又变需求了。但如果深入进去，你会发现，企业决策产品，其实跟“炒股软件”很像。

炒股软件如何支持你做决策？大致有这么几个功能：资讯提供、交易功能、自选行情及实时变动。对应到数据平台上，大体就是报表展示、自助分析、实时更新，以及一些管理功能，比如一键沟通对应的数据负责人。

所以，做企业决策平台久了，转向其他的决策类平台，就很容易。

从这个角度上讲，扎根一个业务场景，其实是数据从业者拔高自己的关键，也是对抗35岁陷阱的基础能力。如果卷算法能力、编码能力，我们也许永远都卷不过年轻人，但要论行业经验、专家解读，这些小孩就稚嫩的很。

数据开发，只是我们从业的能力，而从业所积累的专业经验，才是我们的核心竞争力。

共勉。

更多关注：

数据管道

专注于数据分析、Python、ML、DL等知识圈。定期分享Python数据科学系列、分析报告系列、趣味产品系列等免费资源。

88篇原创内容

公众号