数据中台与企业架构
张靖笙
现在各行各业，大家都非常关心数字化转型该怎么转，数据中台该怎么建。最近看来，不管主动还是被动，越来越多企业感受到数字化转型的迫切压力，于是数据中台的概念越炒越热。
关于数字化转型和数据中台，业界的声音不绝于耳，但当我听到有人把这两件事混为一谈的时候，我的感觉是异样的，我不否认两者有很大交集，但绝不能等同，毫无疑问，数字化转型是一个远比数据中台的内涵更宏大的命题，如果仅用数据中台的概念、方法和工具套用到数字化转型，这是一个片面得很明显的生搬硬套。
结合我自己的职业经验，企业架构（Enterprise Architecture，简称EA）可以说是更贴切数字化转型的方法工具，自上世纪八十年代以来，企业架构这个概念就在国际上日益流行，虽然架构师这个职业在我国也非常吃香，可就我自己的体会，意识和理解到企业架构重要性的企业组织在中国还不是太多。这种局面正日益成为中国企业信息化普遍的瓶颈，联系到今天很多人争着要建的数据中台，没有企业架构的支撑，数据中台在企业将是怎样一个职能定位？要怎么发挥作用？与企业其他业务和管理工作是怎样的关系？如何有效衔接？这些问题就很难得到让大家都信服的回答。
自然很多人都会问企业架构到底是什么？简单来说，就是把企业看成一个信息系统的建模工具。企业架构理论的提出和发展的确和信息系统有很深的历史渊源，20世纪80年代中期，当时还是IBM员工的John Zachman率先提出了“信息系统架构框架”的概念，从信息、流程、网络、人员、时间、基本原理等6个透视角度来分析企业，也提供了与这些视角每个相对应的6个模型，包括语义、概念、逻辑、物理、构件和功能等模型。由于其杰出的开创性工作成果，Zachman被公认为是企业架构领域的开拓者。但在当时，Zachman并没有明确的使用“企业架构”的概念。
虽然企业架构早期思想雏形来自信息技术领域的建模理论，20世纪80年代中期之前，虽然使用的理论和模型已经逐渐流行于各种信息系统的设计和开
发，几乎只有学术界对企业再造或企业建模的思想感兴趣。而让企业架构逐步在国际上得到广泛采纳的历史背景就是被称为第三次工业革命（工业3.0）的信息化与工业化相融合（在我国简称为两化融合），特别是在国际上，以美国和欧盟为首的发达国家已经为企业架构的推行制定了一系列强制性的法律法规，例如美国的Clinger-Cohen 法案、Sarbanes-Oxley 法案、欧盟授予公共合同的指令等等。从世界先进国家的发展经验和示范作用来看，企业架构的采纳和推行，是经济、社会、商业发展到一定阶段的必然产物。
随着经济社会信息化程度的加深，企业如何建立有效机制使IT与业务融合，即通过更好的IT运营，产生相应的业务价值，提高核心竞争力成为企业迫在眉睫的商业问题。数字化转型的实质是第三次工业革命以来，包括今天正在发生的第四次工业革命，社会经济的发展需要每一个企业融合数字化技术所做的持续组织变革，要确保组织变革的成功，首先就要建立一整套有效管理变革的方法体系，而这种方法体系又离不开数字化信息技术的融入和支撑，正是这些历史发展规律的客观要求导致融合了战略发展、业务以及IT 系统的企业架构（EA）应运而生。
我们可以看到，今天无论是服务于打赢信息化条件下战争的国防建设，服务于智能制造的数字孪生(Digitaltwin)、基于模型的企业(MBE)，服务于教育体制改革的教育信息化2.0，服务于政务流程再造的数字政府，服务于银行4.0的金融科技，包括本文所论述的数据中台，背后都有企业架构的影子，企业架构为什么能做到这点？在笔者看来，简单来说就是有效地使用了纸上谈兵的方法（架构），帮助各种形态的组织（企业）打赢高度变化的环境中的各种斗争（变革）。TOGAF（开放组体系结构框架）将“企业”定义为有着共同目标集合的组织的聚集。例如，企业可能是政府部门、一个完整的公司、公司部门、单个处/科室，或通过共同拥有权连接在一起的地理疏远的组织链。在“企业架构”上下文中，“企业”这一术语不仅可用来表示整个企业（包含所有信息和技术服务、流程和基础设施），而且可以表示企业内的一个特定领域。
自古以来，战场上令行禁止纪律严明的军队才有战斗力，强调军人对上级命令的绝对服从，而今天任何一个组织都处在一个内外部高度变化的环境之中，特别是信息化条件下的企业内部活动常常要扩展到包含伙伴、供应商和客户的参与，组织边界已经越来越模糊，还依赖传统行政指令手段已经越来越难
以管好理顺新时代企业内部各种复杂的利益关系，如何依赖信息技术建立新的组织秩序，定义共同目标、建立价值共识，在这个基础上组织协调各种要素和资源采取一致行动，这样的组织的工作安排才有执行力。打赢信息化条件下的战争与办好数字经济市场条件下的企业，都需要高效及时的运筹帷幄，只有融合运用各种资源和要素才能达到组织的目标，这样以来，基于数据的纸上谈兵（架构建模）功夫还真不能少，否则还没动起来就乱套了，或者根本不知道该从何开始动。
企业有效使用信息技术和其中的数据资源，不但是重要的生产力要素，更是构筑新型生产关系不可或缺的载体，从这个角度我们就可以看清楚企业架构为今天数字化组织变革所发挥的不可取代的中枢和桥梁作用。如果说企业架构是战略层面的调兵遣将，那么所谓的前、中、后台就是要落到战术层面的具体系统方案设计工作了。
那具体到数据中台，到底和企业架构是怎么一个关系呢？如上所述，两者是企业整体战略布局和具体战术制定的关系，定位上不一样，概念上当然不能等同，我们特别需要注意一点，每一个企业组织的战略发展道路是不一样的，所以每个企业的企业架构都是不一样的，但数据中台里面很多方案内容具备技术手段上的通用性，所以我们看到很多雷同的数据中台架构图就不奇怪了。最近我在业界看到有把数据中台定位成数字化转型中枢这样的言论，由于我不认同把企业架构和数据中台混为一谈，所以对于这样的说法也不敢苟同。根据笔者的理解，数据中台更像是把企业架构中数据架构规划的主体内容，从运营和管理数据资源的角度采纳部分业务架构、应用架构和技术架构的内容和建模方法，向系统建设实施更进一步的落地设计方案
从这个角度我们理解数据中台和企业架构的关系和相互作用就比较明白了，如果我们没有企业架构的支撑就去张罗搞数据中台，最后数据中台会沦为企业各种信息系统的其中一个，很多关于数据治理和运营的想法缺乏推动有关组织变革的执行力，必然造成这个系统与企业现实业务流程和工作环境的脱节，时间长了数据中台作为一个信息系统的效力和价值也将大打折扣，逐渐沦为鸡肋摆设，严重的会成为矛盾丛生的问题中心，这样又如何还有能力推动数字化转型？
而翻过来说，今天我们任何一个组织再搞企业架构如果不考虑数据中台的要求，那么数字化转型所强调的“组织从业务数据化到数据业务化”也就缺乏了关键一招的落地方案，再漂亮的企业架构都极有可能变成高高挂起的纸上谈兵！
（此稿完成于2020年3月13日，如需引用请注明出处）
近来数据中台概念大火，大家对它的定义也五花八门，不一而足。但无论怎么定义，一个完善的数据技术架构必不可少。了解这些架构里每个部分的位置，功能和含义，不仅能让我们更好了解数据产品的范围和边界，知道技术能帮我们实现什么，能怎么实现得更好，另一方面，很多技术的设计理念对我们认知世界，了解复杂系统也会有所裨益。因此这篇文章旨在梳理市面上常见的开源技术方案，背后原理及应用场景，帮助产品经理对大数据技术体系有个大致全面的了解。 一般来说，我们将数据整个链条区分为四个环节，从数据采集传输，到数据存储，再到数据计算&查询，到后续的数据可视化及分析。框架图如下： 1. 数据采集传输 这个一般对应于公司的日志平台，任务是将数据采集后缓存在某个地方，供后续的计算流程进行消费使用。 针对不同的数据来源有各自的采集方式，从 APP/服务器日志，到业务表，还有各种 API 接口及数据文件等等。其中因为日志数据有数据量多，数据结构多样，产生环境复杂等特点，属于「重点关照」的对象。 目前市面针对日志采集的有 Flume，Logstash，Filebeat，Fluentd ，rsyslog 几种常见的框架，我们挑应用较广泛的前两者介绍下： 1.1 Flume 和 Logstash Flume 是一款由 Cloudera 开发的实时采集日志引擎，主打高并发，高速度，分 布式海量日志采集。它是一种提供高可用、高可靠、分布式海量日志采集、聚合和传输的系统。Flume 支持在日志系统中定制各类数据进行发送，用于采集数据；同时，它支持对数据进行简单处理，并写到各种数据接收方。目前有两个版本，OG和NG，特点主要是： 1.侧重数据传输，有内部机制确保不会丢数据，用于重要日志场景 2.由java开发，没有丰富的插件，主要靠二次开发 3.配置繁琐，对外暴露监控端口有数据
数据中台与企业架构 张靖笙 现在各行各业，大家都非常关心数字化转型该怎么转，数据中台该怎么建。最近看来，不管主动还是被动，越来越多企业感受到数字化转型的迫切压力，于是数据中台的概念越炒越热。 关于数字化转型和数据中台，业界的声音不绝于耳，但当我听到有人把这两件事混为一谈的时候，我的感觉是异样的，我不否认两者有很大交集，但绝不能等同，毫无疑问，数字化转型是一个远比数据中台的内涵更宏大的命题，如果仅用数据中台的概念、方法和工具套用到数字化转型，这是一个片面得很明显的生搬硬套。 结合我自己的职业经验，企业架构（Enterprise Architecture，简称EA）可以说是更贴切数字化转型的方法工具，自上世纪八十年代以来，企业架构这个概念就在国际上日益流行，虽然架构师这个职业在我国也非常吃香，可就我自己的体会，意识和理解到企业架构重要性的企业组织在中国还不是太多。这种局面正日益成为中国企业信息化普遍的瓶颈，联系到今天很多人争着要建的数据中台，没有企业架构的支撑，数据中台在企业将是怎样一个职能定位？要怎么发挥作用？与企业其他业务和管理工作是怎样的关系？如何有效衔接？这些问题就很难得到让大家都信服的回答。 自然很多人都会问企业架构到底是什么？简单来说，就是把企业看成一个信息系统的建模工具。企业架构理论的提出和发展的确和信息系统有很深的历史渊源，20世纪80年代中期，当时还是IBM员工的John Zachman率先提出了“信息系统架构框架”的概念，从信息、流程、网络、人员、时间、基本原理等6个透视角度来分析企业，也提供了与这些视角每个相对应的6个模型，包括语义、概念、逻辑、物理、构件和功能等模型。由于其杰出的开创性工作成果，Zachman被公认为是企业架构领域的开拓者。但在当时，Zachman并没有明确的使用“企业架构”的概念。 虽然企业架构早期思想雏形来自信息技术领域的建模理论，20世纪80年代中期之前，虽然使用的理论和模型已经逐渐流行于各种信息系统的设计和开
中台技术架构概述
目录 1. 什么是中台 (3) 2. 中台和微服务的区别 (5) 3. 为什么要做中台 (6) 4. 深入中台架构 (8) 5. 总结 (10)
这两年中台很火，已经代替微服务成为架构首选，涌现出各种各样的中台名词，业务中台、数据中台、技术中台、算法中台等，让人眼花缭乱，稍微大点的互联网公司都号称在做中台。 1. 什么是中台 既然讲中台，必然还有前台和后台。前台很好理解，指的是面向 C 端的应用，包括前端(如App/ 小程序) 和对应的服务端。至于后台，很多人把它等同于管理后台，比如商品管理后台，负责商品定义/ 上下架等，提供给内部运营人员使用，这可能不够准确。 简单来说，对于一个交易系统，前台对应用户能看到的部分，如商品浏览和下单，属于接单的部分；后台对应履单部分，如仓库拣货/ 配送/ 财务结算/ 采购补货等，属于实际干活的，由企业内部人员负责，处于一个交易处理流程的后端。 在传统企业，没有在线的前台，基本是线下手工接单，内部信息管理系统基本都属于履单范畴，例如ERP、CRM、采购系统、仓库管理系统，财务系统等，这些系统属于一般意义上的后台概念。 在互联网企业，因为系统一般是自己开发，管理后台既包含面向前台销售的功能，如商品上下架和促销管理，也包含面向履单部分，比如配送、采购、财务结算，所以互联网企业的管理后台并不简单等同于履单后台。 接单和履单之间还有一系列事情要做，包括生成订单时的优惠计算/ 创建实际的订单/ 支付/ 库存扣减等, 这部分功能属于交易逻辑的核心。在简单场景下，前台应用包含这部分功能，在复杂的场景下，就有必要把这部分独立出来，构成独立的中台，为前台减负。 一些文章笼统地介绍中台是用来连接前台和后台的，这个值得商榷。如果管理后台就是后台，那没有连接的必要，因为管理后台本身就是系统的附属部分，和前台属于一体两面。至于履单
数据中台的技术架构和方法论 建设企业的数据化引擎
目录 1.前言 (3) 2.为什么大家开始建设数据中台？ (3) 3.什么是数据中台？ (5) 4.数据中台包含什么？ (9) 4.1. 数仓体系 (9) 4.2. 数据服务集 (10) 4.3. BI 平台 (11)
1.前言 数据中台最早是阿里提出的，但真正火起来是2018 年，我们能感受到行业文章谈论数据中台的越来越多。大量的互联网、非互联网公司都开始建设数据中台。为什么很多公司开始建设数据中台？尽管数据中台的文章很多，但是一千人眼里有一千个数据中台，到底什么是数据中台？数据中台包含什么？2017 年开始，当网易严选有了一定量的数据，我们就开始规划建设我们的数据中台，目前我们已经完成了数据中台体系的搭建，我将根据我们建设数据中台的经验和方法论试图解答上面这些问题。 2.为什么大家开始建设数据中台？ 2018 年开始，朋友圈里讲数据中台的文章开始逐渐变多，当然拿着手机看世界并不一定看到真实的世界。我也跟各个行业的一些大公司的CIO 交流，发现很多行业的大公司都开始组建大数据团队，建设数据中台。结合文章和交流获取的信息，我切身感受到宏观经济对技术的影响。2018 年开始经济下行，生意不好做了，粗放的经营已经不行了，越来越多的企业想通过数据驱动来进行精细化的运营和数据化转型。
如上图所示，企业需要数字化转型，需要更多的触点去跟自己的用户/ 客户建立联系，很多企业就需要做自己的公众号、小程序(各家的小程序) 甚至app。我们希望用户更容易找到我们的商品/ 服务，我们就需要搜索。我们希望用户更多的浏览/ 使用我们的商品/ 服务就需要推荐。我们维护用户/ 客户的生命周期，根据生命周期采取不同的营销动作，就需要CRM。我们需要拉来更多的新用户，就需要投放广告，为了更好的投放效果，我们需要建设我们的DMP。当我们生意做大，我们需要对抗黑产(羊毛党)，让我们的优惠能让真正的用户享受，我们需要风控。这一切都需要底层大数据的支持。企业需要精细化运营，就需要不断的提升运营的频次(如下图所示) 和粒度。我们需要把运营的节奏提升到周级、天级甚至实时。我们随时随地了解我们企业经营状况，需要不断的更精细(细粒度) 的分析我们的业务，快速做出业务决策。我们就需要能够快速地构建大量的BI 报表，在一些重要的节点(大促) 时，甚至需要盯着数据大屏。如果我们有能力，还可以建设场景化的数据产品来支持业务的决策。这一切都需要底层大数据的支持。 如何快速地利用底层大数据的支持，让我们的数据化转型、精细化运营能够高频的迭代，这就需要我们的数据中台提供强有力的支持。这里也提醒一点，当我们需要大规模的数据应用时(搜
数据中台技术架构解读
目录 前言 (3) 一当前关于“中台”问题研究存在诸多问题 (3) 二科学界定“数据中台”问题的基本原则 (7) 三小数据是理解数据中台的关键 (11)
前言 数据中台最近特别火，之前还在炒概念，现在突然就看到有的企业已经宣传自家的数据中台了，有的企业向外介绍如何构建自己的数据中台，利用数据中台打造数据驱动的经营能力。大家热衷于讨论什么是“数据中台”，并且还有“有一千个企业，就有一千个数据中台”的说法，但大家真的都理解了什么是数据中台了吗？ 本文基于笔者的个人思考，首先介绍了当前关于“中台”问题研究存在的3个主要问题，然后从3个方面说明了科学界定数据中台的基本原则，最后指出小数据是理解数据中台的关键，以更加科学合理的角度使读者更加清晰、全面的认识数据中台。” 一当前关于“中台”问题研究存在诸多问题 Supercell，芬兰移动游戏巨头，成立于2010年，拥有《部落冲突》、《卡通农场》、《海岛奇兵》、《皇室战争》和《荒野乱斗》等全球热门游戏。据说，2015年12月马云亲自率队到Supercell公司进行商务拜访，马云对Supercell的高效运营无比感慨，将其经营秘密概括为中台战略，要求阿里巴巴按照“大中台、小前台”的组织原则进行公司架构改革。 不管上述“中台”的马云说是否属实，但“中台”的概念确实在近年来不断发酵并从去年开始流行起来，日益成为行业共识，但大家对如何认识这个共识还没有达成一致意见，同时当前关于“中台”问题的研究还存在诸多问题。 1.1对数据中台的定义不清目前关于数据中台的定义很多，笔者根据网上数据中台相关著作或文章，搜集了一些对数据中台的定义，供读者参考，如下表所示。 表1 网上关于数据中台的定义
阿里中台技术架构介绍
目录 1.阿里业务中台架构图 (3) 2.业务中台化-产品形态 (4) 3.业务中台化-全局架构 (4) 4.业务中台化 - 业务创新和智能化 (5) 5.阿里核心业务架构 (6) 6.阿里数据中台架构 (7) 7.阿里技术全栈全景图 (8) 8.阿里技术平台底座 (9) 9.阿里中台组织架构 (10) 10.业务中台建设路径 (11) 11.企业中台战略升级的4个方面 (12) 12.阿里中台的能力开放 (13) 13.阿里业务中台建设方法论 (13) 14.小结 (15)
1.阿里业务中台架构图 基础设施服务，即IAAS层，提供硬件底层支持。 基础服务层，即PAAS层，包括分布式服务框架、分布式数据库、分布式消息、分布式存储、分布式事务、实时监控服务等等。 互联网业务中台，包括各服务中心的抽象出来的各种业务能力，包括交易中心、支付中心、营销中心、结算中心、用户中心、账户中心等等。也包括非业务类服务，如日志分析中心、配置中心、序列中心、基础中心。 业务应用，经过调取业务中台，组装形成独立业务服务能力的业务应用，如 交易来源，就是前台用户使用的各个端，如淘宝App、PC站等。
2.业务中台化-产品形态 阿里的电商生态，就是要根据对商业的理解，把一些基础逻辑梳理出来。例如什么是业务？什么是业务身份？各个业务领域的边界是什么？每个领域提供的基础服务是什么？领域服务和领域服务之间的流程链接标准是什么？再在这些思想的指导下去建立业务平台化的实施标准和业务管控标准。 电商业务中台由一系列：业务能力标准、运行机制、业务分析方法论，配置管理和执行系统以及运营服务团队构成的体系，提供各业务方能够快速，低成本创新的能力。 3.业务中台化-全局架构
数据中台组成及技术架构设计 随着大数据与人工智能技术的不断迭代以及商业大数据工具产品的推出，数据中台的架构设计大可不必从零开始，可以采购一站式的研发平台产品，或者基于一些开源产品进行组装。企业可根据自身情况进行权衡考虑，但无论采用哪种方案，数据中台的架构设计以满足当前数据处理的全场景为基准。 以开源技术为例，数据中台的技术架构如图所示，总体来看一般包含以下几种功能：数据采集、数据计算、数据存储和数据服务；在研发、运维和公共服务方面包括离线开发、实时开发、数据资产、任务调度、数据安全、集群管理。 1.数据采集层 按数据的实时性，数据采集分为离线采集和实时采集。离线采集使用DataX和Sqoop，实时采集使用Kafka Connect、Flume、Kafka。 在离线数据采集中，建议使用DataX和Sqoop相结合。DataX适合用在数据量较小且采用非关系型数据库的场景，部署方式很简单。Sqoop适合用在数据量较大且采用关系型数据库的场景。 在实时数据采集中，对于数据库的变更数据，如MySQL的binlog、Oracle的OGG，使用Kafka Connect进行数据的实时采集。对于其他数据，先将数据实时写
成文件，然后采用Flume对文件内容进行实时采集。将实时采集后的数据推送到Kafka，由Flink进行数据处理。 2.数据计算层 数据计算采用YARN作为各种计算框架部署的执行调度平台，计算框架有MapReduce、Spark及Spark SQL、Flink、Spark MLlib等。 MapReduce是最早开源的大数据计算框架，虽然现在性能相对较差，但它的资源占用比较小，尤其是内存方面。因此在部分数据量过大，而其他计算框架由于硬件资源的限制（主要是内存限制）而无法执行的场景，可以将MapReduce作为备选框架。 Spark及Spark SQL是在批处理方面拥有出色性能的成熟技术方案，适合大部分的离线处理场景。特别是在离线数据建模方面，建议使用Spark SQL进行数据处理，既能保证易用性，又能保证处理的性能。Flink是实时数据处理方面的首选，在处理的时效性、性能和易用性方面都有很大优势。 而机器学习一般采用Spark家族的Spark MLlib为技术底座。Spark MLlib内置了大量的常规算法包，如随机森林、逻辑回归、决策树等，可以满足大部分数据智能应用场景。 同时，数据中台不断进化，也逐渐融入A I能力。如人脸识别、以图搜图、智能客服等能力的实现就需要A I平台。目前较为成熟的A I平台有T en so rFl ow及PyTo rc h。为实现物体的检测和识别，可使用SS D、Y O L O和Re s Ne t等深度学习模型，而在人脸检测和识别中则主要使用M TC NN、Re t inaNe t和Re s Ne t，人脸检索可使用Faceb oo k开源的针对人脸检索的Fai ss框架。 3.数据存储层 数据存储层所有的存储引擎都基于H ad oo p的HD FS分布式存储，从而达到数据多份冗余和充分利用物理层多磁盘的I/O性能。在HD FS上分别搭建H i v e、HB a s e
搜索推荐整体架构（AI·OS）
ABFS：基础特征服务 iGraph：图引擎 BE/DII：召回引擎 RTP：Rank Service HA3：搜索引擎 AOP：一站式机器学习平台 TPP：灵活业务平台 标准化：从搜索到推荐
TPP: 搜索推荐业务平台 支持算法及业务的快速迭代，让用户真正专注自己的核心逻辑 集团最大业务规模serverless平台：服务集团62+BU，万级别场景 集团最大的JAVA单体应用之一 峰值QPS 阿里在线水位最高的JAVA应用之一 双11百万级QPS，万级别容器 2015201620172018
搜索推荐中台?目标 AI OS Serverless 图化算子化
新业务创建成本过高 场景/团队爆发式增长 资源调配太难，水位极低 双11挑战巨大 逼出来的Serverless 过万 2011 2013 2014 2015 2016 2017 2018 2019 场景 我的集群 我的集群 我的集群
Serverless 的开始：FAAS 传统应?用 Faas 新业务成本git/aone/应?用分组/vip/服务框 架/业务逻辑 git/业务逻辑 监控ALL ?自建平台提供细粒度多维度监控流量量治理理ALL ?自建平台提供限流/降级/负载均衡/ 容灾/切流 资源?手动 全时快速弹性 迭代 ?无统?一实验体系/协作成本?高 灵活实验/快速发布/敏?捷协作 专注业务逻辑 关注业务逻辑 剥离业务开发不关心的问题 基于JVM Runtime 面向JAVA高度性能优化 面向在线 百万级低延迟在线服务 快速弹性 全时秒级弹性 快速迭代 快速实验和反馈
通用数据中台体系架构
数据中台的目标是让数据持续用起来，通过数据中台提供的工具、方法和运行机制，把数据变为一种服务能力，让数据更方便地被业务所使用。 下图为数据中台总体架构图，数据中台是在底层存储计算平台与上层的数据应用之间的一整套体系。数据中台屏蔽掉底层存储平台的计算技术复杂性，降低对技术人才的需求，让数据的使用成本更低。通过数据中台的数据汇聚、数据开发模块建立企业数据资产。通过资产管理与治理、数据服务把数据资产变为数据服务能力，服务于企业业务。数据安全体系、数据运营体系保障数据中台可以长期健康、持续运转。 一个通用的数据中台架构应该如何构建？
1.数据中台总体架构图数据汇聚 数据汇聚是数据中台数据接入的入口。数据中台本身几乎不产生数据，所有数据来自于业务系统、日志、文件、网络等，这些数据分散在不同的网络环境和存储平台中，难以利用，很难产生业务价值。数据汇聚是数据中台必须提供的核心工具，把各种异构网络、异构数据源的数据能够方便地采集到数据中台进行集中存储，为后续的加工建模做准备。数据汇聚方式一般有数据库同步、埋点、网络爬虫、消息队列等；从汇聚的时效性来分，有离线批量汇聚和实时采集。数据开发 通过数据汇聚模块汇聚到中台的数据，没有经过什么处理，基本是按照数据的原始状态堆砌在一起的，这样业务还是很难使用。数据开发是一整套数据加工以及加工过程管控的工具，有经验的数据开发、算法建模人员利用数据加工模块提供的功能，可以快速把数据加工成对业务有价值的形式，提供给业务使用。数据开发模块主要是面向开发、分析人员，提供离线、实时、算法开发工具以及任务的管理、代码发布、运维、监控、告警等一些列集成工具，方便使用，提升效率。 2.数据资产体系 有了数据汇聚、数据开发模块，中台已经具备传统数仓平台的基本能力，可以做数据的汇聚以及各种数据开发，就可以建立企业的数据资产体系。之前说数据资产体系是中台的血肉，开发、管理、使用的都是数据。大数据时代，数据量大，增长快，业务对数据的依赖也会越来越高，必须考虑数据的一致性和可复用性，垂直烟囱式的数据和数据服务的建设方式注定不能长久存在。不同的企业因业务不同导致数据不同，数据建设的内容也是不同的，但是建设方法可以相似，数据要统一建设，笔者建议数据按照贴源数据、统一数仓、标签数据、应用数据的标准统一建设。