0x01-什么是数据中台--来自一线程序员的土(di)味(dao)解读

        数据中台，站在一个在数据开发领域多年的程序员角度来说，可以用一句话去概括：“让业务人员能快速拿到自己想要的数据，加以利用，赋能业务”的架构或者系统组织形式就是数据中台，这是个人认为数据中台的本质。数据中台其实就是一种概念，一种架构思路。

        回归数据中台的本质，即使这个概念没有被提出来之前，但凡想要提高公司人效的数据开发人员也早就在践行这样的数据中台的建设思路。例如初入数据开发这行，很多的工作其实就是照着业务写SQL，后面发现其实大部分业务都类似，不甘陷于重复机械工作的程序员，大概率会开发一个工具或者脚本，给到业务方“只要是这类需求的，你用这个工具就好，不用在来找我，提需求了”。在这个例子中，经历了如下图的变化。

        从结果上来看，业务人员快速拿到自己想要的数据，数据开发人员为整个公司人效贡献了一个长期的价值。笔者不是想说这例子就是已经落地整个数据中台，而是数据研发人员的行为，一定程度上来讲就是在践行数据中台所提倡的理念。所以当数据中台这样的概念被提出来之后，不甘于满足现状的数据研发人员，但是表达和总结能力又比较差的程序员哥哥，终于为自己努力的方向找到了一个很好的总结名词。

        对于中台概念有点意会后，我们就可以实实在在聊聊一个企业中落地数据中台后应该是什么样子。在聊这个之前，我们可以回想想在没有数据中台之前，公司从数据生产到能进行使用整个的流程。一般一个比较靠谱的研发流程，会经历如下图的几个环节。

        1. 业务人员先向数据研发人员提数据

        2. 数据研发人员理解和评审业务需求

        3. 数据研发同业务人员二次确认需求，确保业务口径理解正确，以及该业务人员是否有该权限能够查询该数据。

        4. 进入研发流程，同其他的业务开发进行数据基本口径的对齐

        5.从业务研发那得到的数据口径，确认数仓是否具备满足需求的数据，如果不具备满足需求的数据，从业务库同步到数仓，在经过数仓一系列的处理，形成业务所需的数据

        6.数据研发反馈结果数据，业务人员确认最终的数据并加以利用。

        从整个流程来看，一个数据需求，一般要跨越业务，数据，业务研发三个部门或者组。需要经过6个步骤。如果要达成业务人员能够快速拿到自己想要的数据这样的一个目的，理论上可行的方式就是业务人员能干完数据研发所有工作。但是实际上，从时间精力，专业能力上，并不可行。“样样行，样样废”，最终产出就是一个平庸的输出。

        如何破局？

        对照上面的数据开发流程，在结合中台的想到达的效果，业务人员想要快速获取所需的数据，需要经历俩个基本坎：

        1.认知差异，跟技术核对技术口径，理解数据结构，这里的数据结构一般就是指业务数据库的数据表结构设计。理解这个需要一定的技术背景，按照数据库的设计流程，一般会经历概念模型，逻辑模型，物理模型。概念模型对应的就是客观世界的事实描述，业务人员可以理解，但是转成最后的物理模型，这个物理模型是给机器用的，并不是给无技术背景的人看的。所以理解起来会有比较大的技术难度。

        2.海量数据的处理能力。业务数据库的设计并不适合进行大数据的分析，如果直接在业务库上写SQL，最终的结果往往是任务跑不动，数据无法产出。需要掌握数仓和使用数据基础平台的能力。

        如果一个企业能让业务克服这俩个门槛，整个数据中台基本也算基本搭建成功

（数据团队的能力增长和数据中台0-1落地实践，PART I）