最近几年“中台”被行业大厂炒得如火如荼，甚是火爆，业务中台、数据中台、技术中台、风险中台、管理中台等等概念层出不穷，生怕错过中台这一“大风口”，但并不是每个公司都适合追这一风口，甚至举整个公司之力来搭建中台体系。

什么时机建设中台，不取决于公司大小，而是取决于公司是否需要快速扩张。但在公司是否决定建设中台之前，作为产品经理，需要为领导提供一份可行性调研报告，以此说明公司中台建设的时机是否成熟，而为了建设中台，公司又需要做哪些努力和调整。

一、什么是中台

所谓中台，结合公司现有业务通俗来讲，是将预付卡支付、互联网支付、跨境支付及企业钱包等各业务线的共性需求加以提炼并抽离，比如商户中心、账户中心、计费中心、支付中心、清算中心、风控中心、数据中心等，将其打造成为一种具有平台化、标准化、组件化的系统服务能力，然后以接口或服务的形式提供给前台各业务单元使用。使前台的各支付产品在更新迭代、创新拓展的过程中研发更灵活、业务更敏捷，最大限度地减少“重复造轮子，烟囱式架构’的KPI项目、组织架构或设计思维。

二、为什么要建中台

结合我司目前的业务现状，各条业务线“各自为政”，自己建设自己的业务模块，完全业务闭环。导致一些系统功能重复建设且无法在其他业务线进行复用。由于各业务线的系统架构设计不统一，一旦涉及到多条业务线的协作配合，就会出现系统功能扩展性较弱，业务处理流程繁琐，对接周期长等问题，严重影响了前端商户的使用体验，同时也浪费了公司的各种资源。

三、中台建设方案

1.建设目标

基于目前各支付业务的发展状况，避免各支付业务线的系统功能重复建设，节约公司成本；将各支付业务线的共性需求提炼抽离出来形成一套标准化、组件化、松耦合的各业务线可以共享的系统能力，支持前台各支付产品的快速迭代，灵活创新；不断沉淀并增强系统的服务能力，在不大量增加人力的情况下，支撑公司3-5年内前台各支付业务线得以更好地建设和发展。

2.建设领域

3.涉及业务单元

4.中台建设图

四、可能遇到的困难

1.因为各支付业务线各自独立运营，进行中台建设，需要清晰梳理各支付业务线的业务需求及系统逻辑，投入的成本巨大；

2.各支付业务线已各自正常运营多年，一旦进行中台建设，会对现有业务的开展产生冲击，影响到相关市场销售的利益；

3.各支付业务部门领导早已习惯目前系统的运营状况，说服他们配合推进中台建设，难度较大。

五、最后小结

中台建设的目标大概可以分为三种：去重、复用和做强。去重，即避免重复建设，规避重复造轮子、烟囱式架构，节约公司成本；复用，即系统重复使用，标准化、组件化、松耦合，支持前台业务快速迭代，灵活创新；做强，即能力不断沉淀，服务可被不断滋养，体验可统一把控。

作为产品经理，对于公司是否需要建设中台这一问题，需要做很多的前置性思考和规划。首先需要明确公司背景，比如从长期来看公司会关注什么事情？目前现状如何？目前的问题可能是什么？通过这步把公司的情况思考清楚，我们现在有什么项目，未来可能会开展什么项目？然后梳理价值，公司哪部分业务或系统适合作为中台？中台在其中的价值是什么？是开源、节流还是提效？因为你要立项，就必须先取得上级的认可，作为高层最关注的就是你做的事情到底有什么价值。明确项目价值之后，才会去关注你想怎么干。最后就是初步的方案构想。在阐述清楚中台价值后，就可以阐述初步方案。

对于初步方案，简单看就是梳理清楚：方案的影响面（会涉及哪些部门）、大概的方向（我们大概会怎么做）、以及可能遇到的困难。

免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！

元数据一般被称为“数据的数据”，以元数据为关键展开数据治理，能够帮助企业更好地对数据资源进行管理，理清数据之间的关系，实现更精准高效的分析和决策。本文作者从自身工作出发，对元数据的基本功能展开了介绍说明，与大家分享。

本人在一家金融科技公司做B端产品经理，大数据方向的，2019年我们公司轰轰烈烈的启动了数据中台建设，作为数据中台的重要组成部分，元数据自然被提上了日程。在产品建设过程中遇到了很多坑跟大家分享下（第一次分享有错误还请大家多多包涵）。

关于元数据的概念的科普、介绍我这里就不多说了，大家在人人都是产品经理随便搜一下就有。

元数据功能介绍

在做元数据之前本人也做了很多的竞品分析（简单的），像这类产品更多还是乙方比较有经验举例几个亚信、普元信息、网达、星环等等。根据我们的需求现状我们确定任何一家成熟的产品都cover不住我们的需求，对于乙方习惯于标准化，非标的需求都不太愿意做，所以我们干脆就从0到1开始建设，不用他们的产品，只用他们的技术能力。

对于要不要从0到1建设取决于数据量和数仓建设情况，如果数据量不大直接买一个成熟产品即可或者根本不需要元数据产品，毕竟没有元数据也能建立数仓的（扯远了~），每个公司对元数据的需求可能都不太一样，元数据的标准化其实不太好做（对技术要求很高），因为要你能cover住大部分用户的需求，cover不住要么用户妥协、要么你妥协二次开发一些功能给用户使用。

根据我们的需求我们规划了以下功能（简单的介绍下）：

1. 数据地图

数据地图分为数据资产、元数据中心，为用户提供元数据资产统计服务。

1）数据资产统计：用户可以通过数据地图清晰的了解数据的使用情况、分布等对整个数据资产情况有个大概的了解（这种分析统计类的需求是无止尽的，做一部分常用的即可，剩下的入库自己用可视化分析工具展示）

2）元数据中心：这是元数据核心功能之一，整个元数据的输出就是数据地图，用户可以通过元数据中心查看表的元数据信息（技术元数据、业务元数据）、任务信息、血缘关系（表级、字段级）血缘分析、使用信息等等（再多就看自己公司诉求了）

3）元模型：元模型是元数据的核心功能之一，主要实现技术元数据和业务元数据的管理、维护；这里说下子模型的概念，考虑场景的多样性比如运维更关注技术元数据、业务更关注业务元数据，针对不同的库、表可以应用不同的元模型，以满足不同人群的需求。

4）管理中心：管理中心主要针对功能权限、数据权限进行管理包括权限申请、审批、实施等。

5）我的数据：为用户提供查看自身权限、建表等功能。

6）数据管理：数据管理包含元模型、数据源管理等功能，用于元数据的手动、自动采集（生产的元数据采集依赖外部平台，大数据侧元数据采集我们自己做的）

7）元数据质量：主要做元数据治理用的，包含库、表元数据治理功能，分多个维度统计元数据完成情况，并可以做相应通知等。

8）其他：还做了一些其他功能如审计等，这里不细讲了。

2. 产品架构

我简单描述下：

• 存储/计算：元数据使用MySQL进行存储、图数据库，查询使用clickhouse，缓存分布式redis；
• 服务层：服务层提供基础的平台服务能力，包括元数据管理、元数据地图、管理中心、用户权限管理等。
• 通知服务：元数据管理系统中通知类消息目前有三种呈现形式，分别为站内信、短信、邮箱；
• 元数据采集：kafka、hook插件、flume、sftp
• 安全服务：LDAP认证、kerberos

至此介绍部分基本结束，后续会在补充。

免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！

数据中台建设方针：横向规划，各个击破。

横向规划即在数据中台规划初期，需要打通企业各个业务系，打破数据孤岛现象。其实就是我们建设数据仓库的阶段。比如电信业务，我们要把客户、账务、客服、营销等业务板块打通数据，全盘考虑，融通数据形成数据资产。

数据中台建设过程中涉及到大数据平台建设、数据仓库建设、模型算法、数据治理、数据服务等一系列工程，不可能一蹴而就，我们需要梳理业务场景，看他们需要什么样的服务先找一个业务场景，搭建起数据中台的服务能力，然后依次迭代，各个击破。

总体规划

数据集成

首先我们需要确认平台接入哪些数据，确认数据接入的方式是实时接入还是离线抽取。离线抽取的话是全量抽取还是增量抽取。抽取频次数每天抽取还是每小时抽取。

实时接入可以使用kafka实时写入数据到HDFS集群上。

离线数据可以使用Sqoop抽取关系型数据库到HDFS。

模型建设

模型建设是数据中台的重要部分，可以说数据中台的成败在于模型建设的好坏。模型分为我们常指的数据仓库的分析模型和我们的一些通用算法模型。

分析模型

数据接入到数据仓库中，我们需要对数据进行加工，按照我们规划的业务域，对各个业务的数据汇总聚合，形成我们的数据模型。

这其中涉及到数据仓库建设，在这简单说下。

这是一个简单的数据分层结构。原始数据ODS，经过清洗成为数仓中的明细数据DWS和维度数据DIM，各个业务的明细数据按照业务域和维度数据关联形成我们的数据模型DW，不同的DW经过聚合形成各个业务指标数据APP层。

在数仓的建设中我们声明业务粒度，粒度能够精确的表明业务含义。同时还要确定维度，是用户维度还是商品维度等，最终形成我们的主数据，也就是模型数据的基础。

算法模型

我们在业务开发过程中会形成一些通用的算法，可以是封装好的随机森林、回归等通用算法，也可以是我们业务算法，比如用户商品推荐算法等。通过把这些算法总结，形成我们的算法模型，供各个业务直接调用。

ETL平台

在开发数据模型时，我们必须有一个统一的平台，能够像流水线一样，把数据一步步加工成数据模型。这其中涉及到数据萃取、数据聚合、作业调度等。

与业务研发不同，数据研发一般很少写详细的需求涉及文档，通常就是和业务人员简单的沟通，但是慢慢的你会发现开发完的任务会一改再改。为了避免此种现象，我们可以根据自己的实际业务整理一份需求模板。其中包括数据来源字段，数据口径，任务调度周期，字段mapping。

数据资产

通俗的来说，我们在数仓中开发的模型就是数据资产，数据资产需要规范的管控和治理。

资产管理最基础的工作是做好元数据的管理，元数据包含了数据的口径，数据模型的释义，模型之间的血缘等等，详细的可以看之前的元数据文章《数据仓库元数据》。将元数据和数据模型统一有序的管理起来形成企业的数据资产。

数据资产治理不是在事后管控的，在我们建设模型的过程中需要形成一套自己的数仓开发规范进行管理。

数据服务

俗话说，酒香也怕巷子深。我们做好数据资产后，要推销我们的资产，为更多部门使用，这也是数据中台建设的初衷。因此提供一套数据服务能力，对外统一对接是一件很重要的工作。

数据服务标准：数据结构标准化、在线查询实时化、数据开发可视化。

数据结构标准化

对各个业务板块的数据交互，我们需要提供统一的接口视图，可进行数据的查询、权限管控。

在线查询实时化

对于各业务的调用，我们需要提供指标级数据口径统一的实时数据结果。对于复杂的查询，需要我们优化后端的数据服务，屏蔽繁重的数据存储和计算引擎，对外提供轻量的在线服务接口。

数据开发可视化

提供数据接口的可视化统一管理页面，开发人员通过通过可视化管理API，降低接口理解的难度，易于维护。

讨论

关于数据中台的建设，最初是阿里提出来的，但是这之前，很多企业其实已经有了类似的想法，也实施了部分。对于大型集团企业，中台方法论很实用。打破了集团各版块的数据孤岛，形成了统一的数据服务能力。但是慢慢的很多人提出了，对于中小企业，中台方法论是不是太繁琐了，对于他们来说是负担，中小企业需要的也许是更快捷的迭代形式的数据服务。

那么关于中台建设，你怎么看呢？你的企业会选择中台吗？

免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！