数据中心平台被誉为大数据的下一站。提出“大中台、小前台”战略。2018年，因为“腾讯数据中台论”，中台再次成为讨论的焦点。2019年，似乎大家都在谈论数据中心，但并不是每个人都知道数据中心是什么意思。数据中心是不是只有大公司才需要考虑的崇高概念？普通企业应该做数据中心吗？数据中心的出现是否会给现有的数据从业者带来颠覆性的挑战？数据中心不是大数据平台！首先，它不是一个平台，也不是一个系统。如果厂商说他们有数据中心卖给你，对不起，那是骗子。要回答什么是数据平台，首先要讨论什么是平台。虽然没有明确的定义，但是作为理工科直男，我们首先可以把中台看成是中间层的一种。既然是中间层，中台确实是一个完整的技术名词，我们完全可以从技术角度来讨论。我们可以套用Gartner的PaceLayer来理解为什么会有中间层，这样我们就可以更好的理解中间平台的定位和价值。PaceLayer提到可以根据事物变化的速度对事物进行分层，这样可以逐层分析，设计合理的边界和服务。在数据开发中，核心数据模型的变化比较缓慢，同时数据维护的工作量也很大；但是业务创新的速度和数据需求的变化非常快。数据中心的出现，是为了弥补数据开发与应用开发之间响应速度跟不上开发速度不匹配的问题。数据中台解决的问题可以归纳为以下三点：效率：应用开发加个报表为什么要十多天？为什么无法实时获取用户推荐列表？当业务人员对数据有一点怀疑的时候，时间长了，结果发现是数据源的数据发生了变化，最终影响上线时间。协作问题：在开发业务应用时，虽然需求和其他项目大致相似，但数据还是需要自己开发，因为数据是其他项目组维护的。能力问题：数据处理和维护是一个相对独立的技术，需要相当专业的人来完成，但很多时候，我们的应用开发人员很多，而数据开发人员却很少。所有这三种类型的问题都会拖慢应用程序开发团队的速度。这就是中台的关键——让前端开发团队的开发速度不受后台数据开发的影响。数据中台是聚合管理跨域数据，将数据抽象封装成服务，为前台提供业务价值的逻辑概念。如下图所示：DDataAPI是数据中心的核心。它是连接前台和后台的桥梁。它通过API提供数据服务，而不是直接把数据库交给前台，让前台开发人员自己使用数据。至于DataAPI的生成过程，如何让DataAPI更快，如何让DATAAPI更清晰，如何让DATAAPI的数据质量更好，这些都是围绕数据中台要构建的能力。其实这些概念都太空谈了，下面就以阿里的例子来说明一下吧。阿里数据中心详解1.阿里数据中心赋能业务全景在架构图中可以看到最底层的内容主要是数据的采集和接入，按照业务类型（如淘宝、天猫、盒马、等），提取这些数据到计算平台；通过OneData系统，构建“业务板块+分析维度”架构的“公共数据中心”。基于公共数据中心，上层根据业务需求构建：消费者数据系统、企业数据系统、内容数据系统等，数据经过深度处理后，才能发挥其价值，为产品和业务所用;最后通过统一数据服务中间件“OneService”提供统一数据服务。2、经过多年实战，阿里数据中心和平台三大体系沉淀了阿里云数据中心的核心能力框架体系：产品+技术+方法论。经过在阿里生态的各种实践体验，云数据中台从业务角度而非单纯的技术角度出发，智能构建数据，管理数据资产，提供数据调用、数据监控、数据分析和数据展示等。种服务。传承技术创业，是构建智能数据、产生数据智能的引擎。在OneData、OneEntity、OneService三大体系的引领下，尤其是它们的方法论，云数据中心平台本身的核心能力也在不断积累和沉淀。在阿里巴巴，几乎人人都知道云上数据中心的三大系统，如上图所示。OneData致力于统一数据标准，让数据成为资产而不是成本；OneEntity致力于统一实体，允许数据集成而不是孤立存在；OneService致力于统一数据服务，让数据可以重用而不是复制。这三个体系不仅有方法论，还有深厚的技术积累和不断优化的产品积累，从而形成了阿里云数据中心平台的核心能力框架体系。3、阿里数据中心及其赋能商业模式支撑阿里数据中心，经历了阿里生态内所有业务的考验，包括新零售、金融、物流、营销、旅游、健康、娱乐、社交等领域。数据中台除了建立自己的核心能力外，向上赋能业务前台，向下连接统一计算后台进行整合。4.数据中台六大数据技术领域如前所述，在阿里数据公共层建设之初，规划了六大数据技术领域，即数据模型领域、存储治理领域、数据质量领域、安全权限领域、平台运营领域。维度领域，研发工程领域。阿里数据公共层建设项目二期，存储治理领域扩展为资源治理领域，进而升级为数据资产管理领域、安全权限领域、数据领域信任，因为许多任务已经在产品中实现，平台运维领域不再被提升为数据技术领域，数据模型和数据质量领域仍在推进，但增加了很多新的内涵，智能黑盒领域是一个新的领域星星。可见，数据技术领域并不是一成不变的，而是随着业务的发展和技术的突破而不断拓展和升华。那么，实时数据中心怎么做呢？下面是实现实时数据平台的逻辑架构，方便大家理解。其实最关键的一层是实时模型层。1、实时访问：不同类型的数据需要不同的访问方式。Flume+kafka现在是标准配置，还有文件和数据库DSG等其他技术。比如运营商有B域的下单、通话，O域的位置，上网等各种实时数据。2、计算框架：这里只列举一个，基于Kappa架构，实现实时/离线一体化业务开发能力。与传统的Lambda架构相比，开发者只需要面对一个框架，开发、测试、运维难度相对较小，可以充分发挥单点执行、高吞吐、毫秒级的特点Flink流计算框架的级响应、批流集成。例如，流计算组件划分实时数据切片，批处理组件提供离线数据模型（驻留在内存中），两类数据在处理过程中实现批流关联。3、实时模型：和数据仓库模型一样，实时模型首先要面向业务，比如运营商有流量运营、服务提醒、竞争响应、上架新品、堂店引流、语音消费、运营评估、实时关怀、实时预警、实时洞察、实时推荐等一系列实时场景，你总要根据你的实时业务抽取通用的数据模型元素。例如，在农民工分配新号码的实时营销中，可能的触发场景是针对漫游到某个交通枢纽并停留10分钟以上的用户发起营销活动。特征可以是可重用的实时模型。实时模型可以垂直分为两层，DWD和DW。DWD模型所做的就是将各种实时数据的命名和过滤字段操作标准化，方便数据的标准化管理。DW模型这里分为三类：动态模型、事件模型和时序模型，每种模型适用于不同的场景，需要合适的存储格式。动态模型：实时数据的汇总统计，适用于实时统计指标分析，比如实时业务处理量，一般可以存储在Kafka和Hbase中。事件模型：将实时数据抽象成一系列的业务事件，比如从位置日志轨迹记录用户的位置变化事件，可以触发LBS定位营销。下面是一个典型的位置事件模型设计，一般可以存储在MQ和Redis中：也可以设计一个滑动窗口模型，比如保存最近一个小时的分钟级滑动窗口位置信息：计时模型：主要保存用户在线时空位置等信息，并可以根据业务场景进行各种快速计算，比如计算停留时间，存储在Hbase或TSDB（时序数据库）中，非常方便：4.Real-实时服务对于实时模型是不够的。数据中心还需要提供图形化、流程化、可编程的数据开发工具，才能真正降低实时数据开发成本。但由于离线和实时数据处理的技术手段不同，这两类数据的开发和管理大多在不同的平台上进行。比如我们的离线数据模型过去是通过DACP平台来管理的，但是实时数据是从DACP平台上免费出来的，往往是应用本身的一部分。应用程序需要通过编写特定的脚本来消费和处理流处理引擎中的原始数据，这种处理的门槛不仅高，而且资源浪费严重。每个实时应用程序实际上都是一个流数据孤岛。从应用的角度来看，业务真正需要的是一个统一的数据开发和管理平台。将离线和实时的数据作为一个统一的对象来管理，比如具备混合排列、混合关联等能力，使用简单的类似SQL的自定义输出应用所需的各种数据，从而高效对外提供实时/离线数据服务。5、如果实时应用数据中心能够支持实时数据的快速编排，根据我们的测算，实时场景应用的数据开发、测试、部署周期将从0.5-1个月缩短到1-2天，收益会很大。高的。阿里处理的数据量已经达到艾字节级别，相当于10亿部高清电影的存储容量。2016年双十一当天，实时计算处理的数据量达到每秒9400万条。从用户生成数据的源头，到数据采集、整合、构建、提供数据服务、前台展示，仅需2.5秒。“友盟+”是阿里对收购的数家数据公司进行整合升级后组建的数据公司。这里仅举2017年“友盟+”披露的部分指标，数据涵盖14亿台活跃设备、685万个网站、135万个应用，每天处理约280亿条数据。它们都是基于阿里强大的数据处理技术基础。如果实时数据足够多，场景丰富，建立实时数据中心的必要性还是很高的。随着大数据内外部运营的深入，我们发现这种需求越来越大。你会惊奇地发现，很多时候需求是随着你技术能力的加强而增加的。在很多情况下，技术是第一生产力。我们很多负责变现的产品和运营经理应该深有体会。从那时起，我就在想，我们是否可以建立一个真正的实时数据中心，能够快速高效地创建海量实时应用，从而将大数据的管理和应用水平提升到一个新的阶段，终于我们现在来了在这条路上。
