无论是叫“数据中台”、“大数据平台”或者“数据PaaS平台”也好，名称不重要。透过现象看本质，一切的平台构建最终目的均要服务于业务，进而给企业带来价值，并力求过程中不耗费企业过多的建设和运营维护成本。

数据中台如火如荼，不少企业客户以及创业公司都在围绕数据中台进行布局。

近期阅读了很多有关阿里数据中台的文章，包括阿里云团队对阿里数据中台的解析，阿里对中台的定义、架构，中台和传统数仓/数据湖的区别以及阿里数据中台建设的一些案例。

阿里的中台建设对很多数据中台创业公司具有较强的启发意义。但创业公司作为一个第三方的数据中台服务提供商，面向的是各行业的客户需求和非标准化的业务数据类型，面临的挑战甚至更大。

本文和大家一起探讨数据中台赋能行业的话题。

数据中台是什么？

这两天看到谭虎、陈晓勇两位作者写的关于阿里云（阿里巴巴）数据中台的详解和阿里云公开的《阿里巴巴数据中台实践》，结合个人过往的见闻，写下关于数据中台的一些粗浅的看法。

数据中台的概念是最早由阿里巴巴首次提出，是为了应对内部众多业务部门千变万化的数据需求和高速时效性的要求而成长起来的，它既要满足业务部门日常性的多个业务前台的数据需求，又要满足像双十一，六一八这样的业务高峰、应对大规模数据的线性可扩展问题、应对复杂活动场景业务系统的解耦问题，而在技术、组织架构等方面采取的一些变革。——《详解阿里云数据中台，一篇文章全面了解大数据“网红”》

既然数据中台来自于阿里巴巴，我们就直接来看看最近公开的《阿里巴巴数据中台实践》中阿里巴巴的数据中台全景。

▲图片来源：《阿里巴巴数据中台实践》

乍一看和我们见过的很多大数据处理的平台有些类似：底层IAAS大数据计算平台、中层数据接入管理清洗融合、上层数据接口和服务中间件，最终承载数据应用和业务系统的数据需求。

诚然，从大的架构分层来说确实和很多大数据公司的架构类似，但数据中台意义的并不在架构本身。

正如文中对数据中台的定义的说明：

阿里巴巴数据中台是阿里云上实现数据智能的最佳实践，它是由数据中台方法论+组织+工具所组成。

数据中台方法论采用实现企业数据的全局规划设计，通过前期的设计形成统一的数据标准、计算口径，统一保障数据质量，面向数据分析场景构建数据模型，让通用计算和数据能沉淀并能复用，提升计算效能；数据中台的建设实施必须有能与之配合的组织，不仅仅相应岗位的人员要配备齐全，而且组织架构建设也需要对应，有一个数据技术部门统筹企业的数字化转型，数据赋能业务中形成业务模式，在推进数字化转型中实现价值；数据中台由一系列的工具和产品组成，阿里云数据中台以智能数据构建与管理Dataphin产品、商业智能QuickBI工具和企业参谋产品为主体等一系列工具组成。——《详解阿里云数据中台，一篇文章全面了解大数据“网红”》

一个完整的数据中台不仅仅是简单的产品和技术分层，更多的是需要前期的顶层设计，多场景的数据融合和标准化，以及一个合理的组织架构将其运营应用好。

数据中台价值所在

既然看起来一个好的数据中台要应用起来并不容易，那企业为什么会花大量精力去实施这么一套平台呢？

这就涉及数据中台本身能够解决的问题和现有系统的痛点了：

1. 企业数据来源分散在多个不同的系统中

如阿里系就有淘宝、天猫、聚划算等多个业务子系统。但如果你仅仅拥有一个或者两个业务系统，花费力气构建一套完整的数据中台产品可能让你得不偿失。

2. 不同子系统之间的数据存在大量复用的情况，数据相互间调用可能存在网状结构

举个最简单的例子，你可用淘宝账号登录天猫商城、支付宝的订单支付统计数据需要反馈给各大商城。

▲图片来源：《阿里巴巴数据中台实践》

3. 部门/人员数据之间的协作频繁

很多数据挖掘工程师往往会自嘲是爬数工程师，而这其中最苦恼的在于运营/业务人员提出的微小的数据需求变动也往往需要重新编写或者修改脚本、再运行，缺乏一个产品化的平台快速响应上层业务的数据需求。

4. 现有数据仓库数据库已经无法解决的问题

现有的数据仓库更多的是面向决策层，以报表或者BI的形式输出，而数据中台更多的是面向一系列的业务系统以API的方式提供给现有的业务系统使用，甚至直接开发出阿里生意参谋类似的数据化业务。

数据中台与传统数仓有很多明显的区别：

首先表现在服务对象方面，传统的数仓只是满足领导数据决策的需要，因此更多的体现在报表输出，使用者以小部分的业务人员和决策层为主，新需求的开发周期以月甚至到年为计。而数据中台由于起家于互联网企业，其使用对象扩大到一线服务人员和商家企业，其业务需求更繁杂，很难用一套报表系统满足需求，因此催生出一个生态的数据服务。

其次是体系架构上，数据中台是由多系统组成，除了计算平台外，其方案由多个分布式服务系统提供，满足不同业务需求和高并发和系统自动扩容需求，除了大数据存储和计算平台外，还包含数仓建设、工作台开发IDE、任务调度、数据同步服务、对外统一数据服务、资产管理系统、实时流计算平台和开发平台、OneID计算和查询模块，敏捷BI报表开发等多个组件，通过多个维度组件组成一整套方案。

再则，在服务表现形式上数据中台体现的更多样化，数据中台不仅能提供报表基础服务功能，而且为了满足各个业务部门不同需求，会提供领导决策系统、行业分析、业务洞察、业务重塑，自助查询等多个功能，满足从领导层、PD、业务人员、开发人员等各个层级的需求。——《详解阿里云数据中台，一篇文章全面了解大数据“网红”》

阿里巴巴数据中台实际实施用到的技术本身并没有太多的秘密：数据加工处理基于Maxcompute或者Hadoop Hive和HDFS，业务数据查询基于分布式的MPP和KV数据库。

数据中台更多的价值在于是在技术平台之上构建了几大模块，来赋能更多的业务部门不同角色的需求，真正实现了支撑业务的目的：

• 垂直数据中心(OneClick)：本质是传统数据架构中的ETL，通过离线、实时等方式将各渠道的数据采集过来；
• 公共数据中心(OneData)：保证数据口径的规范和统一，沉淀共性的数据。阿里采用的是维度建模，通过分析业务过程抽象出维度和指标，最后汇总成所需要的仓库模型；
• 萃取数据中心(OneID)：一套以各种ID（业务核心对象）为唯一标识的业务中台；
• 统一数据服务中间件(OneService)：以数据仓库整合计算好的数据作为数据源，对外通过接口的方式提供数据服务。

创业公司面临的5大挑战

前面的观点更多的是从企业需求和平台建设本身来看，阿里巴巴的中台业务最初也更多的是支撑自身不同业务线的数据需求。

而如果一家创业企业要给客户提供数据中台建设，相比阿里构建数据中台可能面临更大的挑战：

1. 客户个性化需求

客户需求的梳理，可能需要针对企业业务本身前期承担大量的咨询调研服务。

需求不明确，分析场景设计不合理，数据指标和分析思路不够能解决用户痛点等情况，但这些都可以通过增加投入，特别是加强咨询和调研的力度来解决这些问题。——《详解阿里云数据中台，一篇文章全面了解大数据“网红”》

而这本身也是ToB创业企业最容易陷入的泥潭，当产品面向各行各业，甚至同一行业的不同客户时，你需要了解客户本身的业务，结合他们的业务帮助客户做顶层设计，最后花费大量的人工在教育和引导客户上。

2. 客户粘性和产品标准化的平衡

业务的粘性往往比技术更高，不同业务的场景抽象才更能放大数据中台的价值，以此构建业务中台。

但业务抽象又需要企业有非常强的业务领域知识，如何定义好业务的边界。而阿里的OneID体系就是典型的业务中台应用之一，以ID为中心可以融合多数据源构建多个业务底层画像，包括商家、客户、商品、内容、位置等。

3. 不同行业不同客户的扩展性问题

数据中台承担的是业务数据的汇聚存储和流转中心。因此，创业企业在提供产品和服务的同时，不可避免得和客户的业务数据打交道，如何在不同客户的多样繁杂的数据中抽象出一个通用化、可配置甚至低代码开发工具是目前数据中台服务商亟待解决的问题。

4. 关于产品出口的问题

是否给客户做上层的数据产品甚至应用系统？

传统的数仓往往以BI或者报表作为出口，支撑企业的整体运营决策，需求比较明确。

数据中台本身是为了支撑更多的业务系统的数据需求，而往往有的企业可能上层系统并不完善或者根本没有，甚至要求创业企业给提供一套完整且可能非标的数据产品甚至应用系统。而如果不提供的话，数据中台的价值就没有被充分放大；而如果提供的话，则可能产生大量定制化的需求。

5. 数据中台后期如何跟进客户的需求变更

客户的业务是伴随着客户的产品、营销、市场和供应链等策略实时变动的，业务系统的变更可能导致对中台的需求也越来越高。如何在后期低成本的进行中台的升级和更新，让中台产品如何持续为企业产生价值才是中台产品最终成功的关键。

数据中台建设是一个循序渐进的建设过程，数据积累和分析维度都有一个数据和知识积累，认知的过程，和业务系统的“交钥匙”工程有本质不同，营销，市场和供应链的数据是在不断变化中，营销活动，产品也在不断发展和更新中，因此，数据中台建设是一个不停迭代和发展的过程，需要持续投入是数据中台运营部门所面临的最大的挑战。——《详解阿里云数据中台，一篇文章全面了解大数据“网红”》

总之，无论是叫“数据中台”、“大数据平台”或者“数据PaaS平台”也好，名称不重要。

透过现象看本质，一切的平台构建最终目的均要服务于业务，进而给企业带来价值，并力求过程中不耗费企业过多的建设和运营维护成本。

因此，企业在考虑建设数据中台时也需要从自身需求出发，真正做到数据赋能业务。

作者：吴文超，晨山资本投资经理；公众号：晨山资本（ID：chenshancapital）

来源：https://mp.weixin.qq.com/s/zM5ehphndqtJ4yfdPFB6-Q

本文由 @晨山资本 授权发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议