随着企业体量的增大，一个企业可能有总公司及很多个子公司，随着企业各类业务多元化和垂直业务发展，从全企业角度来看，每个子公司或者某些独立的业务部都在构建大数据分析平台，在企业内部形成了很多分散、烟囱式、独立的小数仓，形成了一个个垂直的数据中心，从而导致了大量系统、功能和应用的重复建设，更造成了计算资源、存储资源和人力资源的浪费。

例如阿里巴巴集团旗下的业务和关联公司非常多，如：淘宝网、天猫、聚划算、阿里巴巴国际交易市场、1688、阿里妈妈、阿里云、蚂蚁金服、菜鸟网络等，每个业务和关联公司都构建了自己对应的数据仓库，甚至在某个业务板块中都有可能构建多个小型数据仓库，例如淘宝网业务中涉及到的平台有会员管理系统、购物车系统、安全系统、支付系统、广告系统、用户信息跟踪系统、商户系统等，单独一个淘宝网构建的业务数据应用体系如下：

站在全企业角度来看，我们这里只拿淘宝网、天猫、聚划算、1688业务板块举例来说，构建的电商业务数据应用体系如下：

上图中淘宝、天猫、聚划算、1688业务线都有各自的大数据平台，基于此数据存储平台之上各自构建了很多个分散独立、烟囱式的数仓平台，通过数据仓库分析后的结果数据主要有四个产品应用，分别为：数据产品、数据报表、风控、推荐搜索。

数据产品主要是可以把分析后的结果与业务系统进行联动，例如：在直播活动时，我们可以根据用户下单和历史购物行为，来给用户打标签，然后进行精准推送优惠券；在会员营销活动时，可以给特定标签用户群体发优惠短信或app信息，促使用户返场购物等。数据报表主要是报表分析，例如经营性的分析，报表结果是给各部门人员去看的，辅助决策使用。风控应用主要是基于分析后的用户行为结果数据来判断哪些是异常交易，哪些是机器人操作，那些是攻击行为等。推荐搜索应用主要是根据分析后的结果数据进行商品推荐和搜索。

当企业体量变大，业务线变多，各个业务线独立的小数仓构建的数据应用体系存在以下问题：

1、效率低下

效率低下主要体现在以下三点：

数据的研发效率低下

针对公司运营活动来说，一般是一周甚至是一个月搞一次运营活动，每次运营活动后我们都会根据当前运营活动数据做复盘和分析，这种情况对数据开发效率上没有太大要求。假设现在每天甚至半天都要做一次运营活动，活动结束后立刻需要对活动数据进行复盘分析，这时要求数据研发在一天或者半天内做出数据需求交付，数据研发有可能跟不上这种节奏，就会导致分析的数据无法支撑业务问题，数据研发效率低下。

数据的发现效率低下

随着数据量和业务越来越多，由于没有对数据进行很好的管理，各个数据仓库中的数据表越来越多，对于数据开发人员、数据分析人员、运营人员根本不清楚我们拥有哪些数据，这样就很难对数据进行管理复用。针对数据开发人员就会出现一种情况：当我使用一张表数据时去数仓中找到针对这张表分析的结果所花费的时间与重新开发分析这张表的数据的时间相差无几，所以在面对几万张表的时候如何快速找到并准确理解这些数据也是很大的挑战。

数据的取数效率低下

在数据建设过程中有一些指标可能在构建数据应用体系下没有及时的统计在数据集市中，就造成了运营、数据分析这些非技术人员需要给技术人员提临时性的数据分析需求，这个过程中来来回回沟通加上调试，可能需要一周时间才能准确完成运营需要的指标，数据开发人员约有50%的时间浪费在了临时性的需求上面，按道理来说数据开发人员应该将更多的精力放在数据模型的构建、公共数据逻辑的建设上而不应该将大部分时间浪费在临时性的需求上。

以上结果就造成了运营人员感觉开发人员效率极低，开发人员累死累活浪费了大量精力在这些临时性需求上，没有更多精力来完善数据平台建设，这样就形成一个恶性循环，对于数据开发方和数据使用方来说都不是一个很好的体验。

2、数据质量问题

由于构建了很多数据仓库，没有有效的对数据进行很好的质量管理以及数据开发过程中存在bug问题，导致数据经常算错，结果违反常识，开发人员浪费大量精力定位数据质量问题，经常没有办法按时产出报表数据。计算出来的结果又不正确，导致数据使用方丧失信任，不再使用数据分析的结果。

更为严重的是往往数据质量问题90%都是被数据使用方发现，也就是说在数据有质量问题时，我们数据开发人员根本不知道出现了数据质量问题，都是通过数据使用方投诉到CTO层面转给数据分析团队负责人。

从开发者角度来看工作已经由996变成007依然天天被人怼，工作非常被动，背负巨大压力。从数据使用者角度来看数据查询非常慢，需求相应非常慢，数据结果不正确，导致数据不想用，最终用不好。从公司高层来看就是花了这么多钱，还每天被抱怨数据不好用，数据天天出问题，数据不能支撑起业务。最终各方都对数据产生了很大的抱怨。

3、集群资源成本大

在企业数据建设中经常是“数据上线容易下线难”，在数据开发中一张数据表从上线之后，我们就一直不停的加工产出结果，很少关注这张表到底产生了多少价值，被多少部门多少人在使用，如果一张表后期没有人去使用，我们还在不停的计算加工、存储，那无疑给集群资源带来极大浪费，一些企业甚至在没有挖掘出数据价值时已经被这种高额的成本压垮，在企业数据分析中往往都存在大量的表或者临时表30天内都没有人访问，而占据了极大空间资源。

4、数据口径难统一

当一个公司体量非常大时，其业务形态比较复杂，往往统计同一个指标时不同的部门有各自的口径。假设我们公司是一个年销售额几千亿的企业，在计算一些指标时要考虑各种各样的因素。

例如：要计算商品的销售额，例如商品售出还没有完成商品售出周期是否应该计算在总销售额之中？如果是退货的商品算不算到总销售额之中？如果在用户下单时用了优惠券付款，这种使用优惠券抵消的金额算不算到总的销售额之中？总公司销售商品到子公司这种订单算不算商品销售额？

再如：在计算商品库存量时，在途（商品售出，用户没确认收货）商品算不算库存？给供货商付款了供货商还没有发货的商品算不算库存量？用户退款了商品算不算库存？

往往针对以上指标统计财务部门有自己的一套口径、仓储部门有自己的一套口径、IT部门有自己的一套口径、运营部门有自己的一套口径，这样往往在公司内部引起“拌嘴” 这种情况在给公司高层汇报数据时往往会有“这个结果是根据运营部门统计出来”、“这个结果是根据销售部门统计出来”、“这个结果根据仓储部门统计出来”，“这个结果根据财务部门统计出来”，每个部门统计的结果最终形成“烟囱式”统计，更要命的时当公司高层提出一个需求，假设针对销售商品销售额和库存量来做某个商品的销量预测，我们也不知道哪个部门统计的结果是正确无误的，不清楚应该以哪个部门的数据为基准进行预测分析。

当一个企业发展到一定规模后，当各个部门计算的某些需求指标有交集时，虽然每个部门都有各自的大数据平台、数仓平台，每个部门有成百上千张各种眼花缭乱的报表数据及指标数据，但是各个部门统计的指标数据根本不一致。

对于一些关键指标的核对，例如：每日GVM销售额，一些公司一般需要副总裁牵头，针对每个指标每个部门可能需要核对上百张报表数据，才能发现到底那个部门出现了问题，费事费力效率还极低。

5、数据安全问题

各个独立、烟囱式的数据平台开发带来了数据监管难的问题，各个业务线数据会不会泄漏？

没有数据权限的人会不会看到敏感数据，例如针对用户交易数据，A部门由于业务需要可以看到用户的电话号码，其他信息看不到。B部门由于业务需要可以看到账户余额，其他信息看不到，C部门由于业务需要可以看到用户收货地址，其他信息看不到等，但是从各个部门获取的数据来看，这份数据包含了用户所有隐私信息，站在企业角度来看这些数据安全问题管理起来分散不统一，存在巨大的风险。

二、为什么要构建数据中台

以上我们分析了数据建设中出现的各种问题，那么为什么出现这些问题呢？主要原因有如下几点：

1、烟囱式的开发模式

一个企业体量不大时，对于业务需求我们可以直接由底向上直接开发，由原始表深度加工产出一张表对外提供服务，针对不同的业务需求我们都这样实现，这就形成烟囱式开发，随着企业体量变大，业务变多，这种烟囱式开发会导致我们的数据无法复用，做很多重复的开发，这时我们可以构建一套数据分析平台，这里涉及数据采集、数仓构建、数据分析、数据可视化展示等，由于我们构建了统一数仓平台，几乎解决烟囱式开发问题。

但是当企业体量继续变大时，企业内部业务线增多，部门增多，由于一些公司内部组织架构的原因，可能会出现不同部门都会搞一套大数据平台，而这些部门之间有一些极其相似的业务，例如：淘宝业务线、聚划算业务线、天猫业务线都涉及交易信息统计、用户信息统计、用户活跃、流失、留存统计。每个大数据平台都会针对以上业务做相同业务的数据分析，各个部门使用了企业资源运行了大量相同的业务逻辑，设置各个业务部门之间需要进行数据交换关联时还需各个业务线领导牵头完成数据统一交换使用，那么站在全企业的角度来看各个业务部门之间这些相似的业务开发就是一个个的烟囱式开发，做不到相同业务合并处理，业务数据共用和复用。

对于烟囱式开发从企业角度来说相当于付出两倍的人力去研发同一件事情，从资源角度来说使用两倍的资源来加工相同数据，实际上烟囱开发效率是高的，但是烟囱多了，从全局角度看，效率是低的。

2、数据管理能力缺失

随着企业业务线增多，企业业务量和业务指标增多，在数据分析时对应任务和数据表也非常多，如果我们缺少了对这些任务和数据的管控能力，不清楚一个任务挂掉影响哪些数据表结果，不清楚每张数据表被哪些用户使用，当一张表数据量庞大到一定程度需要下线时不清楚这张表是否还在被使用？被哪些人在用？表中数据多久之前的数据可以被删除？由于对数据管理能力缺失导致一系列不可预估的问题。

3、缺少全链路数据治理监控

面对成千上百的数据表，在进行业务开发时，可能遇到很多相似的字段，例如：全量新增用户、新增用户两个相似字段由于区分不了两个字段代表意义，我们不清楚在业务中应该使用那个字段进行数据统计。

在某个数据处理流程中可能涉及到几十张表处理流程，当任意一张表出现问题都会导致下一个张表处理出现问题，当某张表出现问题时，需要逐层向上排查定位哪张数据表出现问题，这个过程会花费很长时间，尤其是这张表是上游链路中比较靠上的一张表时，需要对涉及到的所有流程需要任务重跑，故障恢复有需要花费很长时间，甚至有时候需要半天或者一天的时间，如果其他部门基于你的数据结果进行工作，不仅影响自己部门的产出还会影响到其他部门正常工作，例如数据运营部门。

对于数据使用方来说，数据质量非常重要，在数据分析时常常由于业务逻辑处理不严谨、数据清洗问题导致数据质量问题，如果很多业务有数据质量问题，对于数据质量问题定位也需要很多时间，往往数据开发人员被数据质量问题拖慢数据开发进度。

此外，数据安全也非常重要，对于数据建设中成千上百张表我们需要知道哪些表被哪些人访问了，哪些人有权限访问敏感数据表，访问哪些数据，对数据安全管理的忽视往往会给企业带来很大的风险。

4、成本粗放式管理

在做一些数据开发业务时，往往我们想的是快速的进行数据价值挖掘，而忽略了数据成本，结果导致有可能产出很多临时表和使用少量次的报表，这些使用少量次的表可能还会每天都在加工处理，但是有可能下游根本没有人在使用，导致线上资源出现大量浪费。

5、数据使用不灵活

当业务复杂时，报表展示的各类业务指标非常多，面对成百上千的表和指标，不能进行快速精准的业务数据定位，不能进行关键指标快速可视化展示。

以上几点原因总结下来主要有三个方面：

第一就是流程规范的缺失，我们没有一个很完善的流程、标准、规范来进行数据的研发，数据的管理，导致在使用数据的时候，出现了混乱失控的状态。
第二就是缺少平台工具支撑，当我们有了流程、标准和规范后，如何保证这些流程和规范高效的执行，这就需要一些平台工具进行支撑
第三就是组织架构分散，企业中构建了很多独立的小数仓平台根本原因是按照组织架构来分的，比如我们几个人是一个部门，我们就构建一个自己的数仓体系，他们是另外一个部门，他们就构建自己的一个数仓体系，这样一个庞大的企业中就会有N多个小数仓，当我们需要打通数据进行关联分析时，发现我们无能为力。

解决以上三个方面问题关键就是需要一套机制，通过这套机制整合企业数据，规范、快速的形成数据服务能力，为企业经营决策、精细化运营提供支撑，这套机制就是数据中台。

三、思维导图总结

📢博客主页：https://lansonli.blog.csdn.net
📢欢迎点赞 👍 收藏 ⭐留言 📝 如有错误敬请指正！
📢本文由 Lansonli 原创，首发于 CSDN博客🙉
📢停下休息的时候不要忘了别人还在奔跑，希望大家抓紧时间学习，全力奔赴更美好的生活✨

以上是关于数据中台建设：数据中台出现的背景的主要内容，如果未能解决你的问题，请参考以下文章

数据中台之数据仓库架构设计|清风

数据中台体系规划建设

支撑阿里“双十一”的消息中间件，带你云淡风轻面对高并发

中台产品化是另一个噱头？看这篇文章就懂了

集成底座平台和数据中台的关联分析