一口气说穿数据中台-给你架构师的视角

最新推荐文章于 2024-11-01 12:20:35 发布

大数据架构师Evan

最新推荐文章于 2024-11-01 12:20:35 发布

阅读量199

点赞数

文章标签：数据库数据仓库大数据编程语言 java

本文链接：https://blog.csdn.net/weixin_52346300/article/details/116021662

版权

这是我的第36篇原创

之前分享过中台，前两天又分享了数据治理的相关内容。有个同学嚷嚷着让我说一下数据中台。虽然我做过数据中台，但是不算成功，写起来总觉得不太自信。

既然朋友盛情邀请，那就把我的理解整理一下，给大家分享一下。

OK，Let's GO！

数据行业的演变

在数据领域，从业务方向上可以分为OLTP（联机事务处理）和OLAP（联机分析处理）两个领域。这个名字很拗口，但是也很有意思。

OLTP就是你在本地操作，相对于单机而言，数据记录在本地，就叫单机事务处理，在本机操作，数据记录在服务器上，这叫联机事务处理。

OLAP就是数据存在服务器上，你在本地调用数据进行在线分析，这叫联机分析处理。

OLTP的发展路径其实就是数据库的不断演进，从关系型数据库从单机数据库到高可用版本，到现在的分布式关系型数据库。另外为了满足各种场景下的数据存储和查询，还诞生了NoSQL、MPP、时序数据库等一系列的数据库，大数据行业就此拉开序幕。

OLAP的发展路径也很有意思。一开始只是在业务数据库中建个表，统计一下各种固定报表。后来需要分析的内容越来越多，就开始不断的向前发展，这样也迎来了大数据分析师的黄金发展期。

蛮荒时代

最早的时候，是没数据仓库什么事情的，OLAP的内容也少，只有少量的固定报表，那时候都是开发人员在业务库直接存储的。

现在很多系统仍然是这样的，比如你采购一个erp、电商平台等，自带的绝大部分报表都与业务系统在一个数据库中的。其实这个时候正式对应系统架构中的“单体架构”。

数据仓库时代

随着信息系统的不断建设，管理者开始不太满足于固定的寥寥几张报表，他们期望看到更多细节，找到异常，发现问题。这时候，就必须要有一个信息系统去满足他们的需求，DSS/BI系统就顺应而生，几乎同时，数据仓库的概念也一并被提出。

1990年前后，现代化的BI和数据仓库几乎同时诞生。这也无可厚非，这俩天生一对啊。BI就是OLAP的业务应用体系，数仓就是为了支撑BI而生的。数据仓库之父比尔·恩门（Bill Inmon）在1991年写了一本书《建立数据仓库》。对，就是那个inmon、kimball建仓方法论的inmon。

这时候，业务数据和分析数据开始分道扬镳，走上了不一样的道路。业务数据处理(OLTP)向准确、及时、一致的方向不断迈进；分析数据操作(OLAP)向历史静态、聚合、关联、多维的方向发展。

一个典型的问题就是在业务数据库中，你无法回答类似于一个订单的选购、下单、支付、发货、完成的全流程各用了多少时间的问题。当然，你可以通过冗余N个时间戳来解决，但是你无法将所有状态变化的数据统统记录下来。因为OLTP是反应当前的情况。

而OLAP就可以通过全量表、拉链表等方式保存历史状态数据，从而对每个对象进行历史分析。

tips：除了拉链表之外，通常还有全量快照表、增量表和流水表，一共四种形式收集历史数据，这四种情况下次开单篇聊。

数据仓库建设的目的就是为了进行数据分析用的。原则上来说数据仓库中的数据是不允许修改的。所以你看HIVE根本就没有update和delete的功能，很多人非常不理解其中的原因，其实这就是因为HIVE就是为了数据仓库而生的。

数据仓库解决的核心问题其实就是上面说到的，解决历史情况追踪，解决数据分析能力、解决业务频繁变化等一系列问题。

拿inmon老爷子的话来总结一下：

数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making Support)。

我有一篇文章，详细解释了数据仓库的完整建设路径和细节，可以移步了解一下：《点击查看：如何搭建一个数据仓库》

这个像什么？是不是很像系统架构中的微服务？对不对？横向分层，竖向切分领域。跟微服务的理念一样一样的。

数据湖时代

数据仓库很好用，多维分析简直能满足老板的一切需要。它能让决策者从公司总体情况，一直下钻到每个业务员的贡献，极大的满足了决策者的掌控欲，同时也给企业的决策带来了坚实的数据基础。

但是，数据仓库也有其非常致命的弊端：所有数据必须经过定义之后才能被使用，所有数据都经过了ETL处理，所有数据都被聚合。

作为数据工作者的你，肯定能理解其中的含义。一旦数据被动过，那就会造成信息丢失。

而在算法时代，这是不可接受的。

因此，在数据仓库发展了20年之后的2010年，Pentaho的创始人James Dixon提出了一个“数据湖”的概念。简单来说，数据湖其实可以理解为一个巨大的ODS层。

任何使用数据的同学都可以直接到数据湖中自由提取数据：

在多维分析报表中钻取到最细颗粒度之后仍然不能解决问题的，就到数据湖中查看最原始的数据，查找根因。
在进行算法设计的时候，数仓中处理的数据已经损失了一部分信息，那就去数据湖中找更详尽、更丰富的底层数据，没准可以找到最佳特征。

数据中台时代

数据湖貌似非常完美，能解决一切问题，但是肯定哄不住专业的你。是的，数据湖说的好听，是一个原生态的，任由你汲取的巨型数据源，说的不好听，就是一个数据垃圾堆。不管你管理的多么好都无法改变这个事实。

你现在已经找到了一个异常客户，想找到这个客户在公司业务流中的表现。我们应该会通过CRM与其进行沟通和跟进；通过交易平台与其发生交易；货物是通过ERP进行采购的，通过WMS记录货物存储信息的，通过TMS记录货物运输过程信息的。最后你是在微博中收到了他的抱怨信息，在客服中心的CallCenter接到投诉电话的。

这个时候，你想怎么办？各个系统都是独立建设的，所有数据都在数据湖中，你就是没办法把他们串起来！而且，这还是一条业务线。公司通常都会有N条业务线，每个业务线的系统都统统单独建立一遍，一个客户与公司发生关系的系统越来越多。

这个时候，数据中台就出现了。