本文将介绍大数据管理领域的演进历程，从原始的OLTP时代到如今的统一的数仓和数据湖架构。这块内容基于自身的理解划分为以下的阶段，其中有曾经看到过的引用的内容，也混有自己的理解。以下为演进的趋势 :
1. 原始的OLTP时代
传统的OLTP通常是基于关系数据库管理系统（RDBMS）的，采用了ACID（原子性、一致性、隔离性和持久性）事务处理模型。这种模型适用于需要高度一致性和数据完整性的场景。
比如：
- 电子商务：处理订单、支付和库存管理等业务。
- 银行和金融：记录和管理客户的交易和账户信息。
- 物流和供应链：跟踪和管理货物的运输和库存。
- 医疗保健：管理患者的电子病历和医疗订单。
- 在线游戏：处理玩家的游戏交易和虚拟物品管理。
2. 数据仓库的开始
一般企业在发展的过程中都会经历如下的三个阶段：
第一阶段：无分析需求阶段电商早期，基本不需要太多数据分析，先跑起来系统就行，这时候买一套电商系统，搞点服务器，加一两个研发就能跑起来了。这时候对数据的需求就是只需要有个数据库就行。最多就是看看营业额就够，不需要数据仓库。
第二阶段：简单统计需求阶段网站做大后流量来了，客户和订单都多起来了，普通查询已经有压力了，这个时候就需要升级架构变成多台服务器和多个业务数据库（量大+分库分表），这个阶段的业务数字和指标还可以勉强从业务数据库里查询。此时仍不太需数据仓库，数据库勉强够用，定时从从库里面统计数据就可以。
第三阶段：复杂统计需求阶段随着业务指数级的增长，数据量的会陡增，数据来源也越来越多样，这时已经不单单是交易类数据了，用户点击、和图片等数据都多了起来。同时公司角色也开始多了起来，开始有了 各种老板，各种运营、市场、产品的同学，大家需要面临的问题越来越复杂，越来越深入，对数据的需求也越来越复杂。而复杂的分析类计算势必会对线上的数据库造成影响。因为，业务数据库中的数据结构主要是为了完成交易而设计的，不是为了而查询和分析的便利设计的。业务数据库大多是读写优化的，即又要读，也要写。因此对于大量数据的读操作和复杂计算是支持不足。而怎么解决这个问题，此时我们就需要建立一个数据仓库了。
3. 大数据的兴起（Hadoop，Hive，Spark）
随着互联网和数字化时代的到来，数据量呈指数级增长，传统的数据处理方法变得不够高效和可扩展。大数据概念迅速兴起，以应对处理海量、高速和多样化数据的挑战。一个典型的案例是社交媒体平台，如Facebook和Twitter。
社交媒体平台每天产生大量的用户生成内容，如帖子、评论和分享。大数据技术的出现使得这些平台能够实时监测和分析用户行为、趋势和情绪，从而改进推荐系统、广告定向和用户体验。
Hadoop成为大数据处理的关键技术之一。它是一个分布式计算框架，基于可靠的、容错的分布式文件系统（HDFS）存储和处理大规模数据。Hive是建立在Hadoop之上的数据仓库基础架构，提供类似于SQL的查询语言。Spark是一个快速而通用的大数据处理引擎，支持批处理、交互式查询和流处理。
4. 数据湖的兴起
数据湖是一种用于存储和处理大量、多样化数据的大数据架构，它能够容纳结构化和非结构化数据，如JSON，CSV、Parquet等格式。数据湖的设计目的是支持广泛的分析需求，如商业智能（BI）、报表、数据挖掘、统计分析和机器学习模型训练。
数据湖的关键特性包括其灵活性，能够以原始格式存储数据，无需预先定义数据结构或模型；其成本效益，使用分布式文件系统如Hadoop或Amazon S3进行存储，实现大规模数据存储和处理，成本通常低于传统数据仓库；以及其支持高级分析和机器学习的能力，有助于组织从数据中发现模式和趋势。
数据湖与数据仓库的主要区别在于，数据湖可以快速摄取数据，并在用户访问时动态准备数据，而数据仓库要求用户首先进行数据准备。
5. 数仓和数据湖的融合架构
为了更好地利用数据仓库和数据湖的优势，出现了数仓和数据湖的融合架构。这种架构将数据仓库和数据湖进行整合，通过数据管道和元数据管理来实现数据的集成、可发现性和自助服务分析。
Source：当您开始使用数据时，您可能只有几个感兴趣的来源。 两个常见的早期来源是 Google Analytics 以及您的产品运行的 PostgreSQL 或 MySQL 数据库中的应用程序数据。 如果您公司中只有少数人需要使用这些来源，您可以将他们设置为直接访问； 对他们来说，直接处理数据更加简单和敏捷。
Lake ：当您开始依赖更多数据源，并且更频繁地需要混合数据时，您将需要构建一个数据湖 - 所有数据都存在于一个统一的高性能源中。
特别是当您需要处理来自 Salesforce、Hubspot、Jira 和 Zendesk 等应用程序的数据时，您需要为这些数据创建一个单独的主目录，以便您可以使用单一 SQL 语法（而不是许多 SQL 语法）一起访问所有数据。 不同的 API。
Warehouse：在Lake阶段，当你引入更多的人来处理数据时，你必须向他们解释每个模式的奇怪之处，什么数据在哪里，以及你需要在每个表中过滤的特殊标准以获得正确的结果。 这会成为一项繁重的工作，并且会让您经常与诚信问题作斗争。 最终，您需要开始将数据清理为单一、干净的事实来源。这个阶段（创建数据仓库）在历史上一直是一场噩梦，并且有许多书籍介绍如何最好地对数据进行建模以进行分析加工。 但如今，这并不困难，不仅使您不必向新团队成员解释所有模式的奇怪之处，而且还可以节省您个人重复、编辑和维护自己的混乱查询的时间 。
Mart：当您拥有干净的数据和良好的 BI 产品时，您应该开始注意到公司内的许多人能够回答自己的问题，并且越来越多的人参与其中。 这是个好消息：您的公司信息越来越丰富，业务和生产力成果也应该得到体现。 您也不太担心完整性问题，因为您已经对数据进行了建模，并且不断地维护它成为干净、清晰的事实来源。
然而，最终，您将在该事实来源中拥有数百个表，并且用户在尝试查找与他们相关的数据时会不知所措。 您还可能发现，根据团队、部门或用例，不同的人希望使用以不同方式构建的相同数据。 出于这些原因，您需要开始推出数据集市。数据集市是团队或调查主题的更小、更具体的事实来源。 例如，销售团队可能只需要主仓库中的 12 个左右的桌子，而营销团队可能需要 20 个桌子 - 其中一些相同，但有些不同。
6. 离线和实时的发展 Storm ，Flink
离线和实时计算是大数据处理的两个重要方向。离线计算通常用于对批处理数据进行分析和处理，而实时计算则用于对流式数据的实时处理和决策。一个典型的案例是智能城市的交通管理。
Storm是一个分布式实时计算系统，可以处理高吞吐量的实时数据流。Flink是一个流处理和批处理的统一计算引擎，提供低延迟和高吞吐量的数据处理能力。
7. 数仓和数据湖的统一 Lake House的产生 - iceberg等
数据仓库技术自1980诞生以来一直在发展，其在决策支持和商业智能应用方面拥有悠久的历史，而MPP体系结构使得系统能够处理更大数据量。但是，虽然数据仓库非常适合结构化数据，但许多现代企业必须处理非结构化数据、半结构化数据以及具有高多样性，高速度和高容量的数据。数据仓库不适用于许多此类场景，并且也不是最具成本效益的。
随着公司开始从许多不同源收集大量数据，架构师开始构想一个单一的系统来容纳不同分析产品和工作负载的数据。大约十年前，公司开始构建数据湖：各种格式原始数据的存储库。数据湖虽然适合存储数据，但缺少一些关键功能：不支持事务、无法提高数据质量、缺乏一致性/隔离性，导致几乎不可能混合处理追加（append）和读取，批处理和流处理作业。由于这些原因，数据湖之前的许多承诺尚未实现，在许多情况下还会失去数据仓库的许多好处。
公司对灵活、高性能系统的需求并未减少，如需要各类数据应用程序包括SQL分析、实时监控、数据科学和机器学习的系统。人工智能的大部分最新进展是有可用于更好处理非结构化数据（文本，图像，视频，音频）的模型，这些恰恰是数据仓库未针对优化的数据类型。一种常见的解决方案是使用多个系统，即一个数据湖、几个数据仓库以及其他专用系统（如流、时间序列、图形和图像数据库系统）。维护大量系统会引入额外的复杂性，更重要的是会带来延迟，因为数据专业人员需要在不同系统间移动或复制数据。
为了更好地管理和利用企业数据资产，越来越多的组织倾向于将数仓和数据湖进行统一。通过建立一致的数据模型、元数据管理和数据治理，统一的数据架构可以提供更多关于企业数据的全局视图和洞察。 通过数仓和数据湖的统一，组织可以实现更高效的数据管理和分析，提高决策的准确性和效率，同时探索新的业务机会和创新。
LakeHouse有如下关键特性:
- 事务支持：企业内部许多数据管道通常会并发读写数据。对ACID事务支持确保了多方可使用SQL并发读写数据。
- 模式执行和治理（Schema enforcement and governance）：LakeHouse应该有一种可以支持模式执行和演进、支持DW模式的范式（如star/snowflake-schemas）。该系统应该能够推理数据完整性，并具有健壮的治理和审计机制。
- BI支持：LakeHouse可以直接在源数据上使用BI工具。这样可以提高数据新鲜度，减少等待时间，降低必须同时在数据湖和数据仓库中操作两个数据副本的成本。
- 存储与计算分离：这意味着存储和计算使用单独的集群，因此这些系统能够支持更多用户并发和更大数据量。一些现代数据仓库也具有此属性。
- 开放性：使用的存储格式（如Parquet）是开放式和标准化的，并提供API以便各类工具和引擎（包括机器学习和Python / R库）可以直接有效地访问数据。
- 支持从非结构化数据到结构化数据的多种数据类型：LakeHouse可用于存储、优化、分析和访问许多数据应用所需的包括图像、视频、音频、半结构化数据和文本等数据类型。
- 支持各种工作负载：包括数据科学、机器学习以及SQL和分析。可能需要多种工具来支持这些工作负载，但它们底层都依赖同一数据存储库。
- 端到端流：实时报表是许多企业中的标准应用。对流的支持消除了需要构建单独系统来专门用于服务实时数据应用的需求。
典型实现：Delta Lake , Apache Iceberg , Apache Hudi
8. 公有云&私有云 ，政策，混合云，数据安全
在例如Amazon公有云为主的各大云厂商创立，利好了无数的中小企业，无需管理运维基础设施，仅需关注在自身的应用开发来快速适应市场。但随之后来的，也不乏一些国有企业，对于数据隐私的关注，需要建立自己的私有云，因此也催生了云原生的发展。
政策方面，许多国家和地区都制定了针对云计算的监管政策，以确保数据安全和隐私保护。这些政策通常涉及数据存储地点、数据传输加密、合规性要求和审计要求等方面。
例如，欧洲联盟的《通用数据保护条例》（GDPR）规定了对个人数据的处理和保护要求，包括数据存储在何处、如何传输数据以及如何保护数据的安全性。类似地，中国的《网络安全法》要求个人信息和重要数据在国内存储，并制定了网络运营者的责任和义务。
混合云也是各方利弊的产物，一方面是政策影响比如国外使用亚马逊，国内需选择类似腾讯云、阿里云；另一方面在如今经济下行周期，降本增效的大环境下，企业也可自主选择成本更低的云厂商来部署自己的应用；最后，在资源上，比如日益紧缺的GPU资源也能有更多的选择。
9. AI和BI的统一 ，计算和存储的分离 ，统一的计算语言，MQL？
数据架构的核心在于使用场景和使用群体。以 BI（商务智能）为主要使用场景的数据仓库一直是数据架构的核心。而过去十年，通过大数据驱动的 AI（人工智能）渐渐从新贵变成了主流。高效支持 AI 的数据使用也成为数据架构设计的必选项。因此，数据架构的设计必须考虑到 AI 和 BI 的不同需求。数据架构的用户也不再仅仅是主攻 SQL 来做报表的数据分析师，而是扩展到了数据工程师和数据科学家。数据工程师要设计和维护大量的数据 Pipeline（比如 ETL/ELT）来实现数据清理和管理。数据科学家则需要做数据的探索、建模、部署、修正。如何满足以上不同需求并简化架构，变成了数据架构设计的核心指标。
统一 AI 和 BI 是否意味要统一语言？有不少传统的 BI 系统（尤其是数据库和数据仓库的厂商）正在尝试扩展 SQL 语言来给数据科学家和数据工程师提供相关的功能。可是，这个努力正在被 SQL 语言的表达力所限制，而打破标准的形形色色的扩展也牺牲了应用的可迁移性。更为致命的缺陷是，这些 SQL 扩展很难融入 AI 的生态圈。AI 的应用不仅仅局限在若干 API 的调用或数据查询。AI 系统包含一系列复杂的数据操作，包括数据探索、可视化、清理、融合、建模、部署、修正。整个过程中经常需要调用大量的第三方库，而这些库往往又使用不同的语言。幸运的是，随着人工智能、机器学习和数据科学的爆发扩展，Python 逐渐成了这个领域的官方默认语言。拥抱和支持 Python 已经逐渐成为必选项。SQL 不会是数据架构的唯一语言，反而多语言的支持会是主流。
数据拷贝？为了同时支持 AI 和 BI 的使用场景，常见的方法是简单地将数据拷贝成多份，但这也会带来相当深远的危害。不单大幅增加了存储的费用，而且降低了数据的实时性和一致性，进而影响正确性和准确性。更重要的是，多拷贝会给数据安全带来重大隐患。任何数据的泄露都是影响公司品牌和用户隐私的重大事故。存储和计算的分离是数据架构当前的发展趋势。数据将以开放标准的数据格式（比如，Delta Lake 就选择了开源的 Apache Parquet 格式）来存储和管理，从而避免不必要的数据迁移和拷贝；数据查询、处理和使用则基于用户的具体需求来选择最合适应用程序和计算平台。
10. 盲目求新是大忌，企业如何选择，以及完成数字化转型，驱动，可以期待下一篇文章
参考文档
版权声明：自由转载-非商用-非衍生-保持署名
comments powered by Disqus