1 数据中台出现的背景

1.1 数据建设中出现的问题

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

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

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

上图中淘宝、天猫、聚划算、1688业务线都有各自的大数据平台，基于此数据存储平台之上各自构建了很多个分散独立、烟囱式的数仓平台，通过数据仓库分析后的结果数据主要有四个产品应用，分别为：数据产品、数据报表、风控、推荐搜索。
数据产品主要是可以把分析后的结果与业务系统进行联动，例如： 在直播活动时，我们可以根据用户下单和历史购物行为，来给用户打标签，然后进行精准推送优惠券；在会员营销活动时，可以给特定标签用户群体发优惠短信或app信息，促使用户返场购物等。数据报表主要是报表分析，例如经营性的分析，报表结果是给各部门人员去看的，辅助决策使用。风控应用主要是基于分析后的用户行为结果数据来判断哪些是异常交易，哪些是机器人操作，那些是攻击行为等。推荐搜索应用主要是根据分析后的结果数据进行商品推荐和搜索。

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

1)效率低下

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

2)数据质量问题

由于构建了很多数据仓库，没有有效的对数据进行很好的质量管理以及数据开发过程中存在bug问题，导致数据经常算错，结果违反常识，开发人员浪费大量精力定位数据质量问题，经常没有办法按时产出报表数据。计算出来的结果又不正确，导致数据使用方丧失信任，不再使用数据分析的结果。
更为严重的是往往数据质量问题90%都是被数据使用方发现，也就是说在数据有质量问题时，我们数据开发人员根本不知道出现了数据质量问题，都是通过数据使用方投诉到CTO层面转给数据分析团队负责人。
从开发者角度来看工作已经由996变成007依然天天被人怼，工作非常被动，背负巨大压力。从数据使用者角度来看数据查询非常慢，需求相应非常慢，数据结果不正确，导致数据不想用，最终用不好。从公司高层来看就是花了这么多钱，还每天被抱怨数据不好用，数据天天出问题，数据不能支撑起业务。最终各方都对数据产生了很大的抱怨。

3)集群资源成本大

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

4)数据口径难统一

当一个公司体量非常大时，其业务形态比较复杂，往往统计同一个指标时不同的部门有各自的口径。假设我们公司是一个年销售额几千亿的企业，在计算一些指标时要考虑各种各样的因素。
例如：要计算商品的销售额，例如商品售出还没有完成商品售出周期是否应该计算在总销售额之中？如果是退货的商品算不算到总销售额之中？如果在用户下单时用了优惠券付款，这种使用优惠券抵消的金额算不算到总的销售额之中？ 总公司销售商品到子公司这种订单算不算商品销售额？
再如：在计算商品库存量时，在途（商品售出，用户没确认收货）商品算不算库存？给供货商付款了供货商还没有发货的商品算不算库存量？用户退款了商品算不算库存？
往往针对以上指标统计财务部门有自己的一套口径、仓储部门有自己的一套口径、IT部门有自己的一套口径、运营部门有自己的一套口径，这样往往在公司内部引起“拌嘴” 这种情况在给公司高层汇报数据时往往会有“这个结果是根据运营部门统计出来”、“这个结果是根据销售部门统计出来”、“这个结果根据仓储部门统计出来”，“这个结果根据财务部门统计出来”，每个部门统计的结果最终形成“烟囱式”统计，更要命的时当公司高层提出一个需求，假设针对销售商品销售额和库存量来做某个商品的销量预测，我们也不知道哪个部门统计的结果是正确无误的，不清楚应该以哪个部门的数据为基准进行预测分析。
当一个企业发展到一定规模后，当各个部门计算的某些需求指标有交集时，虽然每个部门都有各自的大数据平台、数仓平台，每个部门有成百上千张各种眼花缭乱的报表数据及指标数据，但是各个部门统计的指标数据根本不一致。
对于一些关键指标的核对，例如：每日GVM销售额，一些公司一般需要副总裁牵头，针对每个指标每个部门可能需要核对上百张报表数据，才能发现到底那个部门出现了问题，费事费力效率还极低。

5)数据安全问题

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

1.2 为什么要构建数据中台

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

1)烟囱式的开发模式

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

2)数据管理能力缺失

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

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

面对成千上百的数据表，在进行业务开发时，可能遇到很多相似的字段，例如：全量新增用户、新增用户两个相似字段由于区分不了两个字段代表意义，我们不清楚在业务中应该使用那个字段进行数据统计。
在某个数据处理流程中可能涉及到几十张表处理流程，当任意一张表出现问题都会导致下一个张表处理出现问题，当某张表出现问题时，需要逐层向上排查定位哪张数据表出现问题，这个过程会花费很长时间，尤其是这张表是上游链路中比较靠上的一张表时，需要对涉及到的所有流程需要任务重跑，故障恢复有需要花费很长时间，甚至有时候需要半天或者一天的时间，如果其他部门基于你的数据结果进行工作，不仅影响自己部门的产出还会影响到其他部门正常工作，例如数据运营部门。
对于数据使用方来说，数据质量非常重要，在数据分析时常常由于业务逻辑处理不严谨、数据清洗问题导致数据质量问题，如果很多业务有数据质量问题，对于数据质量问题定位也需要很多时间，往往数据开发人员被数据质量问题拖慢数据开发进度。
此外，数据安全也非常重要，对于数据建设中成千上百张表我们需要知道哪些表被哪些人访问了，哪些人有权限访问敏感数据表，访问哪些数据，对数据安全管理的忽视往往会给企业带来很大的风险。

4)成本粗放式管理

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

5)数据使用不灵活

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

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

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

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

2 数据中台

什么是数据中台

2014年马云正式提出“DT(Data Technology)”的概念，人类从IT时代走向DT时代，阿里内部的数据平台事业部大刀阔斧的建立整个集团的数据资产，同年，阿里从芬兰Supercell公司接触到中台概念后，在集团内部积极践行，开创了“大中台、小前台”的组织机制和业务机制，通过高效、统一的后方系统来支撑快速变化的前端业务，提高业务产出效率，减少成本投入。
2018年中台概念开始深入互联网公司，2019年数据中台概念大火。之所以现在推崇数据中台的建设原因是数据中台确实给小前台提供了强有力的数据支持，实现了对需求快速响应，另一个重要的原因是数据中台已经在阿里体现了巨大的商业价值和应用价值。

数据中台概念

数据中台是一套可持续“让企业的数据用起来”的机制，通过有形的产品和实施方法论，构建一套持续不断把数据变成资产并服务于业务的机制，数据来自于业务，并反哺业务，不断循环迭代，实现数据数据可见、可用、可运营，通过数据中台把数据变成一种服务能力，其目标是提供普惠的数据服务。

关于数据中台有以下几个功能特点：
1)数据中台具备数据汇聚整合、数据提纯加工、数据服务可视化、数据价值变现核心能力。
2)数据中台的核心就是实现公共计算逻辑下沉，实现数据复用，提供给接口使用。
3)数据中台不是某一个单一的产品或者某个技术。本质上讲数据中台就是从数据中发现价值，赋能业务数据管理机制。
如果我们把数据比喻成血液，那么数据中台就是心脏和毛细血管，构建中台可以能让数据价值渗透到各个业务场景中去。
4)数据中台最核心的理念就是“OneData OneService”
“oneData”指的是对于企业数据我们需要按照主题和分层方式进行管理、统一表及指标的命名规范，保证数据完整性及复用性，全企业数据只有这一份统一管理的数据。
“oneService”指的是业务使用的所有数据来源于数据中台，数据中台提供统一的数据服务功能，屏蔽底层数据存储，做到接口复用，减少不规范的烟囱式的接口开发。

构建数据中台时需要企业从战略、组织、人才方面全方位规划配合，而不仅仅停留在工具和产品层面，所以在一些大互联公司在宣布中台战略时，会伴随组织架构调整，例如：合并数据处理部门，合并业务部门等等。

数据中台类比案例

为了方便理解中台概念我们举个例子：
每个人家里厨房都有油、盐、糖、酱油、醋、料酒、生抽很多调料，这些调料相当于数据，你相当于业务部门，特别喜欢吃糖醋鱼、糖醋排骨、糖醋猪蹄、糖醋里脊，以上食物成品相当于各种业务应用。你家里老妈做饭，相当于IT部门，她觉得每天都按照比例调制糖醋汁很麻烦非常浪费时间，每次调制的味道还不同，于是你老妈决定按照一定的比例（1酱油+2料酒+3醋+4生抽+5盐，这个比例就相当于数据处理及数据算法）来调制一大桶糖醋汁（相当于数据产品），以后每天倒一点点糖醋汁就可以做出一盘糖醋菜（业务应用）， 这个调制糖醋汁以及使用糖醋汁做出一盘糖醋菜的这个过程就相当于构建了一个数据中台。如果你家十天半个月才吃一次糖醋菜，频率很低（相当于某个业务应用很低），就没有必要调制一大桶糖醋汁放在那儿（没必要构建中台）。
所以在构建数据中台之前首先看一看有没有数据产品的需求，有多少人使用这个数据产品产生的业务结果，使用的需求量大不大？以及使用这个数据产品业务结果的频率高不高？如果以上都合理就可以规划构建数据中台。
数据中台的核心理念就在于数据取之于业务，用之于业务，它相对于数据平台注重的是对业务的积累和沉淀，构建了从数据生产到消费，消费后产生的数据再回流到生产流程的闭环过程。

前、中、后台概念

前台概念

由各类前台系统组成的前端平台，每个前台系统都是用户的一个触点，即企业的最终用户直接使用或交互的系统，是企业与最终用户的交点。例如用户直接使用的网站、手机app、微信公众号、企业看板等都是前台范畴。小前台一般都是敏捷前台，强调敏捷交互及稳定交付的组织能力建设，对于阿里来说，小前台就是各个业务部门。

中台概念

中台的设置是为了提炼各个业务线的共性需求，并将这些打造成组件化的资源包，然后以接口的形式提供给前台各业务部门使用，可以使产品在更新迭代、创新拓展的过程中研发更灵活、业务更敏捷、最大限度地减少“重复造轮子”的KPI项目。中台是一种经营理念，是一种组织形式，是“平台思维”的自然演进。
中台又包含业务中台、技术中台、数据中台。
业务中台
业务中台更多偏向于业务流程管控，将业务流程中共性的服务抽象出来，形成通用的服务能力。
比如电商平台，有C2C、B2C、C2B、B2B四种模式，其中订单、交易、商品管理，购物车模块、短信中心，用户中心、支付中心、交易中心、搜索服务都是有共性的，将这些组件沉淀出来，形成电商行业的业务中台，再基于这些业务中台组件的服务能力，可以快速搭建前台应用，譬如：C2C模式的淘宝、B2C模式的天猫、B2B模式的1688、C2B模式的聚划算，用户通过这些前台业务触点使用业务服务，业务中台不直接面向终端用户，但可以极大提升构建面向终端用户的前台的速度和效率。

技术中台
主要负责基础服务、基础组件、基础平台、存储体系、云平台、运维相关等技术支撑。
数据中台
业务中台是抽象业务流程的共性形成通用业务服务能力，而数据中台则是抽象数据能力的共性形成通用的数据服务能力。
例如：原始业务数据通过资产化、服务化，形成用户画像服务，这个服务可用于电商平台的商品推荐，也可以用于地产购房意愿，还可以用于金融领域的信用评级等。同一个服务在应用层面展现的内容可能不一致，但是底层的数据体系是一致的。

后台概念

由后台系统组成的后端平台，每个后台系统一般管理了企业的一类核心资源，例如：财务系统、产品系统、客户管理系统、仓库物流管理系统等，这类系统构成了企业的后台，后台更多解决的是企业管理效率问题，为前中台提供数据支撑，而中台要解决的才是前台创新的问题。

数据中台与业务中台区别和联系

一个企业中可以同时拥有业务中台和数据中台，两者是相辅相成的。业务中台中沉淀的业务数据进入到数据中台进行体系化加工，再以服务化的方式支撑业务中台上的应用，而这些应用产生的新数据又流转到数据中台，形成循环不息的数据闭环。

在企业中构建数据中台与业务中台没有先后之分，根据企业实际情况进行规划建设。
从数据层面上来看，业务中台只是数据中台的数据源之一，除此之外，企业还有很多其他的数据来源，如：APP，小程序，IOT等多源数据。
服务层面上来说，数据中台的数据服务也不一定经过业务中台作用于业务，也可以直接被上层应用系统进行封装，如电商领域推荐系统。
中台不是平台，平台可以有很多，例如：营销平台、风控平台、管理平台，平台解决的是特定领域业务的问题，而中台解决的是全企业各个业务领域综合问题，一般一个企业只需要一个中台就可以，现在还有业务中台、数据中台之分，未来当数据与业务更加紧密集合，会统一形成“企业中台”。

数据中台与大数据平台关系

大数据平台更关心技术层面的事情，提供数据加工处理的能力，提供数据集成、数据开发、数据测试、任务上线等，针对的往往是技术人员。而数据中台的核心是数据服务能力，要结合场景，比如精准营销、风控等，通过服务直接赋能业务应用，数据中台不仅仅面向技术人员，更需要面向多个部门的业务人员。
如果把数据中台看成一个工厂，大数据平台就是工厂中的设备，为工厂运行提供加工处理数据能力，通过一系列的整合、加工、处理最终为客户提供有价值的数据结果和服务，当然，属于大数据平台的数据仓库也当属数据中台的重要组成部分。
数据仓库的主要场景实支持管理决策和业务分析，而数据中台则是将数据服务化之后提供给业务系统，目标是将数据能力渗透到各个业务环节，不限于决策分析类场景。例如：

所以数据时代带来的挑战不仅仅是数据量的爆发式增长，更重要的是如何管理好、治理好、利用好这些数据，显然传统的大数据平台建设方法论不能满足以上需求，数据中台应运而生。

构建数据中台价值

构建数据中台价值如下：

1)提升数据应用能力

数据中台将海量数据转化为高质量的数据资产，为企业提供更深层的客户洞察，从而为客户提供更个性化和智能化的产品和服务。

2)打破数据应用屏障

在传统数据建设中，数据无法被业务使用，其中一个重要的原因是业务人员不够懂数据，导致数据应用到业务变得困难，数据分析人员不管业务，只是按部就班产出报表结果，以上情况导致数据分析结果不能很好地反哺到业务中，构建数据中台之后，数据分析人员将数据变成业务人员可阅读、易理解的内容，业务人员看到内容后很快可以将数据结合到业务中。

3)打破数据孤岛，盘活全量数据

数据中台构建将分散割裂的海量数据做到集成，打破数据孤岛的现状，同时降低使用数据服务的门槛，实现数据“越用越多”的价值闭环。

4)支持跨主题域访问数据

企业早期建设的应用数据层ADS(传统数据仓库分为ODS/DW/ADS)更多是为了某个主题域所服务，例如：营销域、人力资源域、风控域。而企业在数据应用到业务的时候往往需要打破各个主题，会从业务对象主体出发来考虑数据应用，如人（会员、供应商、渠道、员工）和物（商品、仓库、合同），从全域角度设计完整的面向对象的数据标签体系。

5)数据快速复用

传统的架构中，将分析后的数据应用到业务中，通常做法就是通过数据同步能力，把结果同步到业务系统中，由业务系统自行处理，这会带来数据管理问题，整个数据血缘链路是割裂的。数据中台可以很好的提供数据服务，业务系统只需要从数据服务中获取数据即可。

数据中台-背景与概念相关推荐

1. 数据中台，概念炒作还是另有奇效？ | TVP思享

   导语 | 数据中台被誉为大数据的下一站,成为了人们谈论的焦点,2019年也被称为数据中台元年.但是数据中台是什么?它和数据仓库.商业智能.大数据平台有什么区别?它的主要功能是什么?本文是对TVP史凯老 ...

2. 进击的数据中台，企业数字化转型的新引擎

   经历过"追捧"和"质疑"等种种考验后,当前,数据中台已经走到验证其价值的关键路口. 数据中台是企业数字化转型新引擎 在人工智能.大数据等技术发展和企业数字化转型 ...

3. 数据中台，我还能爱你吗（文末送书）

   背景 从2015年阿里提出"大中台"的数据中台战略,到2019年大厂及中台服务商"大兴"数据中台,再到2021年大厂又开始拆中台.数据中台从小甜甜变成牛夫人仅仅 ...

4. 什么是BI、数据仓库、数据湖和数据中台，他们有什么差异？

   随着大数据技术的不断更新和迭代,数据管理工具得到了飞速的发展,相关概念如雨后春笋一般应运而生,如从最初决策支持系统(DSS)到商业智能(BI).数据仓库.数据湖.数据中台等,这些概念特别容易混淆,本文 ...

5. 从产品到平台和生态，数据中台「竞争」升级

   据可靠信源,中国首家数据中台公司袋鼠云已于去年年底完成C轮融资,由中信证券领投,东方富海.杭州凯泰资本跟投. 这意味着自去年以来颇受争议的数据中台赛道已经有公司率先突破C轮魔咒.迈上新台阶. 创投圈存 ...

6. 手把手演示：如何规划一个企业级数据中台

   开局一张图 最近有好朋友找到古牧君,说所在的公司要上数据中台项目了,有没有空闲聊一下.出谋划策.这种只耍嘴皮子不用干活儿.还能了解一线实际业务需求的好事儿,古牧君自然是不会放过啦-于是乎,一场有条不紊 ...

7. 排队五小时才能吃上一口的Popeyes，要借阿里云数据中台10年内开足1500家门店

   几个月前,还没多少国人了解美国炸鸡品牌Popeyes,但现在,Popeyes却成为上海滩最火爆的网红店:5月在上海市淮海中路开出首家门店当天,早上7点半,第一条队伍就已排出了半条街. 面对良好的开局, ...

8. 终于有人把数据中台讲明白了

   导读:要建设数据中台,我们首先需要明确什么是数据中台,以及数据中台能为企业带来什么价值. 作者:陈新宇 罗家鹰 江威 邓通 等 来源:大数据DT(ID:hzdashuju) 01 数据中台定义 数据中 ...

9. 【中台实践】华为大数据中台架构分享.pdf

   今天给大家分享华为云龙江先生在2019中国大数据技术大会(BDTC)上做的分享<大数据中台架构分享.pdf>,分享包括三个方面:1.数据中台背景洞察:2.华为数据中台顶层设计:3.华为云数 ...

10. 【大数据架构】浅谈数据中台

    数据中台背景 大环境背景 近几年较火的数字化转型,很多企业也从信息化到数字化. 信息化时代:是信息化为物理世界活动服务的:更多的是为物理世界活动提升效率.例如我们现在很多系统其实也是信息化,例如OA系 ...

最新文章

1. 链表中倒数第k个节点 1
2. Mathematica该注意的两种特殊的输入方式（blanksequence and ruledelayed）
3. 单例设计模式-饿汉式
4. 【LCT】城市旅行（luogu 4842/金牌导航 LCT-3）
5. C语言 野指针 - C语言零基础入门教程
6. web api添加拦截器
7. 55种数据可视化开源工具_通过开源工具增强学生能力的15种方法
8. java 获取 classpath下的配置文件
9. 27个澳洲年轻人，重演了少年马云的一段奇遇
10. 定时任务发展史(二)
11. 诺基亚N9——刷机教程——为双系统做铺垫
12. 手机怎么解决同ip多账号_原神手游如何多开刷初始号赚钱技巧攻略 | 兔子IP
13. MyEclipse 7.0 + PHPEclipse下调试环境搭建(xDebug)
14. 微信支付对账单的详细说明
15. easyUI非常迷惑性的bug:分页插件点击下一页和尾页后,发送两次请求,第二次请求回跳转到第一页
16. 真！一文搞定 HTTP 和 HTTPS
17. 值得反复研读的表连接之CARTESIAN JOIN方式
18. 重装系统电脑黑屏开不了机如何处理
19. 小汽车的位置（二维坐标运算）
20. 办公室业务杂志办公室业务杂志社办公室业务编辑部2022年第18期目录

热门文章

1. 安卓学习 布局篇 Android studio
2. Java编写五线谱上的音符_五线谱音符（五线谱1234567表示图）
3. 5.1.2全景声音箱摆位_5.1.2全景声系统私人家庭影院设计方案
4. Idea标记（或书签）功能
5. Push to branch was rejected
6. 对话“第二人生”创始人：这不是一款游戏
7. json几种不同解析方式
8. hash_map C++
9. 积分商城系统积分兑换运营开源架构
10. Drillbeach---第二章 Drillbench 5.1 Dynaflodrill 用户指南