数据中台出现的背景

本文主要是介绍数据中台出现的背景，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

数据中台产生背景

数据建设中出现的问题

在企业数据建设过程中，都离不开大数据平台建设，大数据平台建设涉及数据采集、数据存储、数据仓库构建、数据处理分析、数据挖掘、数据可视化等一系列流程。

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

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

在这里插入图片描述

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

在这里插入图片描述

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

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

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

效率低下
- 数据研发效率低下
  针对公司运营活动来说，一般一周甚至一月搞一次运营活动，每次运营活动后我们都会根据当前运营活动数据做复盘和分析，这种情况对数据开发效率上没有太大要求。假设现在每天甚至半天都要做一次运营活动，活动结束后立刻对活动数据进行复盘分析，这时要求数据研发在一天活半天内作出数据需求交付，数据研发有可能就跟不上这种节奏，就会导致分析数据无法支持业务问题，数据研发效率低下。
- 数据发现效率低下
  随着数据量和业务越来越多，由于没有对数据进行很好管理，各个数据仓库中的数据表越来越多，对于数据开发人员、数据分析人员、运营人员根本不清楚我们拥有哪些数据，这样就很难对数据进行管理复用。针对数据开发人员就会出现一种情况：当我使用一张表数据时，去数仓中找到针对这张表分析的结果所花费的时间与重新开发分析这张表的数据的时间相差无几，所以在面对几万张表时如何快速找到并准确理解这些数据也是很大的挑战。
- 数据取数效率低下
  在数据建设过程中，有一些指标可能在构建数据应用体系下没有及时地统计在数据集市中，就造成了运营、数据分析这些非技术人员需要给技术人员提临时性的数据分析需求，这个过程中来来回回沟通加上调试，可能需要一周时间才能准确完成运营需要的指标，数据开发人员约有50%的时间浪费在了临时性需求上面，按道理来说数据开发人员应该将更多的经历放在数据模型的构建、公共数据逻辑的建设上而不应该将大部分时间浪费在临时性的需求上。
以上结果就造成了运营人员感觉开发人员效率低下，开发人员累死累活浪费了大量精力在这些临时性需求上，没有更多精力来完善数据平台建设，这样就形成了一个恶性循环，对于数据开发方和数据使用方来说都不是一个很好的体验。
数据质量问题

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

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

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

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

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

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

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

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

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

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

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

为什么要构建数据中台

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

烟囱式开发模式
一个企业体量不大时，对于业务需求我们可以直接由底向上直接开发，由原始表深度加工出一张表对外提供服务，针对不同业务需求我们都可以这样实现，这就形成了烟囱式开发，随着企业体量变大，业务变多，这种烟囱式开发会导致我们的数据服务复用，做很多重复的开发，这时我们可以构建一套数据分析平台，这里涉及数据采集、数仓构建、数据分析、数据可视化等，由于我们构建了统一数仓平台，几乎解决了烟囱式开发问题。
但是当企业体量继续变大时，企业内部业务线增多，部门增多，由于一些公司内部组织架构原因，可能会出现不同部门都会搞一套大数据平台，而这些部门之间都有一些极其相似的业务，如：淘宝业务线，聚划算业务线，天猫业务线都设计交易信息统计，用户信息统计，用户活跃、流失、留存统计。每个大数据平台都会针对以上业务做相同的业务分析，各部门使用了企业资源运行了大量想通的业务逻辑，涉及各业务部门之间需要进行数据交换关联时还需要各个业务线领导牵头完成数据统一交换使用，那么站在全企业角度来看各个业务部门之间这些相似业务开发就是一个个烟囱式开发，做不到相同业务合并处理，业务数据公用和复用。
对于烟囱式开发从企业角度来说，相当于付出两倍的人力去研发同一件事情，从资源角度来说，使用两倍的资源来加工相同的数据，实际上烟囱开发效率是高的，但烟囱多了，从全局角度来看，效率是低的~
数据管理能力缺失

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

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

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

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

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

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

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

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

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

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

这篇关于数据中台出现的背景的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！