从数据仓库到大数据平台再到数据中台
现在各种新名词层出不穷，顶层的有数字城市、智慧地球、智慧城市、城市大脑；企业层面的有数字化转型、互联网经济，数字经济、数字平台； 平台层面的有物联网，云计算，大数据，5G，人工智能，机器智能，深度学习，知识图谱；技术层面的有数据仓库、数据集市、大数据平台、数据湖、数据中台、业务中台、技术中台等等，总之是你方唱罢他登场，各种概念满天飞…
在比拼新经济的过程中，其实比拼的是流量也就是用户，但流量不等于用户，用户也不完全等同于流量；有了流量和用户，就等于比拼了对用户的话语权。各种互联网概念也是如此，单纯从传统的数据仓库或是大数据平台而言，金融或通信运营商在数据治理、数据管理、企业模型、应用效能、高可靠性上做的绝对不比BAT差的，但这些行业有着国企的内敛、同时承担了太多的安全、隐私、稳定要求，空有用户和数据，却很难对外发挥应有的作用，导致在整个信息技术行业内的话语权不高；互联网公司在对数据使用的灵活性、技术的前瞻性、经济效益的引导性、适度容错方面做的远远超出其他行业，所以行业之间的相互吸收和借鉴也是值得探讨的。
新名词的推出，要被大众所能接受，在背后是要有话语权支撑的，而目的当然只有利益了，也不排除个别技术人员自己美好的想法和初衷。
回到正文，不管怎么说，数据中台这个概念已逐步火了起来，但数据中台是什么？
1、数据中台是聚合和治理跨域数据，将数据抽象封装成服务，提供给前台以业务价值的逻辑概念。
2、数据中台是一套可持续“让企业的数据用起来”的机制，一种战略选择和组织形式，是依据企业特有的业务模式和组织架构，通过有形的产品和实施方法论支撑，构建一套持续不断把数据变成资产并服务于业务的机制。
3、数据中台连接数据前台和后台，突破数据局限，为企业提供更灵活、高效、低成本的数据分析挖掘服务，避免企业为满足具体某部门某种数据分析需求而投放大量高成本、重复性的数据开发成本。
4、数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。数据中台把数据统一之后，会形成标准数据，再进行存储，形成大数据资产层，进而为客户提供高效服务。
5、数据中台，包括平台、工具、数据、组织、流程、规范等一切与企业数据资产如何用起来所相关的。
以上概念是从互联网上搜索并拷贝出来的，总的来说中台也好，数据中台也好，还缺乏一个标准的定义，仅从字面上理解，数据中台是解决如何用好数据的问题，既然是概念，数据中台也被赋予了很多扩大的外延，也上升到了数据的采集、计算、存储、加工和数据治理等方面，这就和传统的大数据平台在功能和作用上产生了很大的重叠；而大数据平台又是从数据仓库发展起来的。那到底这三者的关系是怎么样的呢？
本人从事断断续续从事数据仓库行业约有五六年经验，完整的负责大数据平台的整体设计架构和项目实施也有四五年经验，见证了从传统数据仓库转型到大数据平台的全历程，包括第一个MPP数据集市、第一个Hadoop集群项目、第一个流式数据处理项目，第一个完整的大数据平台的融合和构建，混搭式大数据平台的融合构建，大数据平台的迁移等等，我所经历的大数据平台从规模说大不大说小不小，每天处理数据量将近20T（实时处理月10T左右），总集群约300台（其中Hadoop节点约200台），总容量约8P，实际使用容量约5P；包括了从数据仓库到大数据平台数据模型的重构，数据模型的拓展；也包括了大数据平台提供各种对内应用的规划，和向外提供大数据应用。因此对数据仓库和大数据平台的优缺点、各自存在的问题、疑惑、发展方向，也算有一定的认知，包括对新生的数据中台的发展方向，结合自己过往的经验，谈谈自己的一些想法。
按照传统的定义，数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。从数据角度，数据仓库更适合传统的数据库，离线采集，数据一般为结构化的，每天处理数据量不易超过TB集，数据仓库一般在数十T到几百T以内，数据仓库一般为满足内生的应用，满足内部决策支持分析需求，当然随着数据仓库数据采集的要求越来越高，数据仓库本身也在不断的改进，从单机的ETL到集群的ETL，从传统的小机+DB，向PC服务器+分布式DB拓展，数据治理也逐渐增强，从元数据管理到数据质量管理，再到数据运维管控和数据安全管控，但其实数据仓库给企业留下的最大财富是企业数据模型，这些模型随着前端业务系统的发展变化，不断变革，不断追加，不断丰富和完善，即使系统不再了，也可以在短期内快速重建起来，这也是大数据平台能够快速建设起来的一个重要原因。
大数据平台则是指以处理海量数据存储、计算及流数据实时计算等场景为主的一套基础设施，包括了统一的数据采集中心、数据计算和存储中心、数据治理中心、运维管控中心、开放共享中心和应用中心。大数据平台之所以能够建设起来，不外乎内因和外因，外因是棱镜门事件带来的去IOE要求、外部硬件的变革和分布式开源技术的涌现，另外一篇《去IOE or not》已有阐述，不再赘述；内因是非结构化、实时数据和海量数据的计算和存储压力，企业也寄希望从大数据平台除了满足对内需求，也能够实现一定的对外收益。大数据平台的建设出发点是节约投资降低成本，但实际上无论从硬件投资还是从软件开发上都远远超过数据仓库的建设，大量的硬件和各种开源技术的组合，增加了研发的难度、调测部署的周期、运维的复杂度，人力上的投入已是最初的几倍；还有很多技术上的困难也非一朝一夕能够突破，但无论如何大数据平台还是建设起来了，人员能力也在不断成长。大数据平台解决了海量数据、实时数据的计算和存储，也基于原来的企业数据模型实现了重构，但也面临着一系列的问题，首先是数据的应用问题，无论是数据仓库还是大数据平台，里面包含了接口层数据、存储层数据、轻度汇总层、重度汇总层、模型层数据、报表层数据等等，各种各样的表有成千上万，这些表有的是中间处理过程，有些是一次性的报表，不同表之间的数据一致性和口径也会不同，而且不同的表不同的字段对数据安全要求级别也不同，此外还要考虑多租户的资源安全管理，如何让内部开发者快速获取所需的数据资产目录，如何阅读相关数据的来龙去脉，如何快速的实现开发，这些在大数据平台建设初期没有考虑周全；另外一个问题是对外应用，随着大数据平台的应用建设，每一个对外应用都采用单一的数据库加单一应用建设模式，独立考虑网络安全、数据安全、共享安全，逐渐又走向了烟囱似的开发道路。
数据仓库实现了企业数据模型的构建，大数据平台解决了海量、实时数据的计算和存储问题，数据中台要解决什么呢？数据如何安全的、快速的、最小权限的、且能够溯源的被探测和快速应用的问题。
数据中台不应该被过度的承载平台的计算、存储、加工任务，而是应该放在解决企业逻辑模型的搭建和存储、数据标准的建立、数据目录的梳理、数据安全的界定、数据资产的开放，知识图谱的构建，通过一系列工具、组织、流程、规范，实现数据前台和后台的连接，突破数据局限，为企业提供更灵活、高效、低成本的数据分析挖掘服务，避免企业为满足具体某部门某种数据分析需求而投放大量高成本、重复性的数据开发成本。
厚平台，大中台，小前台；没有基础厚实笨重的大数据平台，是不可能构建数据能力强大、功能强大的数据中台的；没有大数据中台，要迅速搭建小快灵的小前台也只是理想化的。
我想这才是数据中台的初衷。
后文是对数据仓库、大数据平台、数据中台的一些总结性的架构材料，也是对自己这些年来的一些汇总和思考吧，看懂了前面的文字，后面的各种架构图也就无需赘述了。
数据仓库硬件架构
数据仓库功能架构
数据仓库技术架构
第一个Hadoop平台硬件架构
主要是为了解决海量离线数据的计算和存储，在Hadoop集群中实现明细数据、汇总数据存储，在mysql中实现报表数据存储。
第一个流式处理平台硬件架构
主要是为了解决海量实时数据的流式采集和计算，在Hadoop集群中实现明细数据、汇总数据存储，在mysql中实现报表数据存储；并通过实时事件处理集群实现流式事件的匹配。
大数据平台系统规划
对于大数据平台各种软硬件各种组件的规划
大数据平台系统定位
大数据平台逻辑部署架构
大数据平台功能视图
大数据平台数据流向
大数据平台对内硬件架构
大数据平台整体硬件架构
数据中台整体架构
QQ群号：763628645
QQ群二维码如下， 添加请注明：姓名+地区+职位，否则不予通过
订阅我的微信公众号“杨建荣的学习笔记”，第一时间免费收到文章更新。别忘了加星标，以免错过新推送提示。
7
近期热文
你可能也会对以下话题感兴趣。点击链接就可以查看。
我眼中的《庆余年》
使用Python分析北京积分落户数据，分析完我陷入了深思
MySQL的主键命名挺任性，就这么定了
华裔教授发现二次方程极简解法,我默默的做了下验算
回答:我不小心把公司的数据库给删了，该不该离职？
迁移到MySQL的业务架构演进实战
数据库修改密码风险高，如何保证业务持续，这几种密码双活方案可以参考
MySQL业务双活的初步设计方案
如何优化MySQL千万级大表，我写了6000字的解读
一道经典的MySQL面试题，答案出现三次反转
业务双活的数据切换思路设计（下）
业务双活的数据切换思路设计（一）
MySQL中的主键和rowid,看似简单,其实有一些使用陷阱需要注意
小白学MySQL要多久?我整理了10多个问题的答案
8
转载热文
你可能也会对以下话题感兴趣，文章来源于转载，点击链接就可以查看。
去IOE or Not?
拉里·佩奇（Larry Page）的伟大归来
《吊打面试官》系列-Redis基础
唯一ID生成算法剖析，看看这篇就够了
关于大数据运维能力的一些思考
DBA菜鸟的进化简史：不忘初心，记工作中踩过的三个坑
美女主持直播,被突发意外打断!湾区网友却高喊: 我懂!超甜