Workflow
湖仓一体架构
icon
搜索文档
从业务系统到数据智能:数据分析系统的完整演进
36氪· 2025-12-16 08:07
文章核心观点 - 数据系统在过去五十年经历了从处理日常交易到支持智能分析的演变,其核心驱动力是解决记录事件与理解其意义之间的根本张力 [1] - 技术架构的演进路线图是从OLTP系统发展到AI驱动的OLAP平台,目标是使数据转化为洞察变得更加便捷、快速和经济高效 [1][45] OLTP与OLAP的根本区别 - **OLTP系统** 专注于处理企业的日常运营事务,如在线订购、转账,需要快速、准确且始终可用,优化目标是快速写入大量小事务并即时读取特定记录 [2] - **OLAP系统** 专注于分析和报告,旨在通过汇总海量历史数据来揭示模式、趋势和洞察,优化目标是读取、聚合数据并进行跨维度的复杂计算 [2] - 这两种系统需求截然相反,一个系统无法高效同时完成两项任务,这推动了数十年的架构创新 [2] OLAP与数据立方体的兴起(20世纪90年代) - 专用OLAP系统引入了**数据立方体**概念,通过预先聚合多个维度的数据来加速分析查询 [3] - 数据立方体类似于多维电子表格,例如结合时间、产品和地理位置维度来预计算销售额,使原本需要数小时的查询在几秒内完成 [3] - 出现了三种主要架构:**MOLAP**(如Hyperion Essbase)使用多维数组实现高速查询但预处理量大;**ROLAP**(如MicroStrategy)在关系数据库上构建,更灵活但性能较慢;**HOLAP**(如Microsoft Analysis Services)尝试混合两者优点 [4] - 商业驱动因素是高管和分析师需要仪表盘和报表来做出数据驱动的决策,Business Objects、Cognos等工具成为前端界面 [5] 数据仓库时代(20世纪90年代末至21世纪初) - 数据仓库作为面向主题、集成化、时变且非易失性的集中式存储库出现,旨在支持商业智能 [7] - 规范架构采用**ETL管道**从多个源系统提取、清理、转换并加载数据 [7] - **星型模式**和**雪花模式**是两种主导的数据组织方式,用于优化读取性能 [8][9] - Teradata、Netezza、Vertica等企业级数据仓库引入了**列式存储**和**大规模并行处理架构**,显著提高了数据压缩率和查询速度,并支持通过添加机器实现水平扩展 [9] - 局限性在于模式必须预先定义,添加新数据源成本高,硬件扩展性有限,且系统成本高达数十万甚至数百万美元 [9] 大数据与Hadoop时代(2000年代末至2010年代) - 互联网公司面临海量非结构化或半结构化数据(如网络日志、点击流),传统数据仓库在经济和技术上均无法处理 [13] - 受谷歌GFS和MapReduce论文启发,开源**Hadoop生态系统**兴起,其核心是**HDFS**(用于低成本分布式存储)和**MapReduce**(用于分布式计算) [13][14] - Apache Hive、Impala、Presto(现Trino)、Spark等项目提供了更友好、更快的查询和计算能力 [14] - 引入了**数据湖**概念,采用“读取时模式”,允许先以原始形式存储数据,再决定如何使用 [14] - 局限性在于查询延迟高(需数分钟至数小时),不支持事务或更新,且运维复杂度极高 [14][15] 云数据仓库时代(2010年代) - Snowflake、Google BigQuery、Amazon Redshift等云原生数据仓库实现了**计算与存储的完全分离** [17] - 数据存储在廉价、持久的对象存储中,计算集群按需启动和伸缩,用户只需为运行查询支付计算费用,存储成本低廉 [17] - **Snowflake** 提出了“多集群共享数据”的弹性架构;**BigQuery** 采用无服务器模型,自动分配资源 [18] - 优势包括:按需付费的云经济学、几秒内实现弹性伸缩、零硬件管理负担、以及轻松的数据共享能力 [19][20][21][22] - 凭借列式格式、高级压缩和智能查询优化,这些系统能在几秒钟内扫描TB级数据 [23] - Snowflake在2020年IPO时估值超过700亿美元,成为标志性事件 [24] 开放表格式与湖仓一体时代(2010年代末至2020年代) - 云数据仓库的专有格式可能导致**供应商锁定**,而传统数据湖缺乏ACID事务、高效更新等功能 [26][27] - **开放表格式** 为数据湖带来了类似数据库的功能: - **Apache Iceberg** 提供ACID事务、模式演化、隐藏分区和时间旅行 [27] - **Delta Lake** 与Spark生态系统紧密集成,支持流式写入和批量读取 [27] - **Apache Hudi** 专用于高效的增量数据处理和upsert操作 [27] - 这些格式以Parquet等标准列式格式存储数据,并维护丰富的元数据 [28] - 新一代查询引擎如 **Trino**、**Dremio**、**DuckDB** 以及托管服务如 **AWS Athena**,能够在这些开放格式上提供高速SQL查询 [29][30][31] - **开放元数据目录**(如AWS Glue、Unity Catalog)提供了集中的元数据管理和治理 [32] - 这些技术融合催生了 **Lakehouse架构**,结合了数据湖的灵活开放性与数据仓库的性能和功能 [32] AI驱动的分析时代(2020年代至今) - AI原生分析平台正在模糊数据仓库、机器学习和商业智能之间的界限 [35] - 主要趋势包括: - **语义层和AI驱动的指标** 抽象了SQL复杂性,允许用户定义业务指标而非编写复杂查询 [35] - **由大型语言模型驱动的自然语言界面** 允许业务用户用简单语言提问,系统自动生成并执行SQL [35] - **向量搜索和嵌入技术** 使得能够结合传统SQL分析对非结构化数据进行语义搜索 [35] - 统一分析平台涌现,例如: - **Databricks** 整合了湖仓存储、协作笔记本、ML管道和交互式仪表板,并通过收购MosaicML集成LLM训练 [35] - **Snowflake Cortex** 将AI功能直接嵌入SQL [36] - **Dremio Reflections** 利用AI自动优化查询聚合 [36] - **MotherDuck** 将DuckDB高性能带入云端 [36] - **流式OLAP** 兴起,系统如Apache Pinot、ClickHouse能基于最新数据以亚秒级延迟运行分析查询,模糊了OLTP与OLAP的界限 [36] - 愿景是实现**自助式分析**,让领域专家无需依赖数据团队即可探索数据 [36] 技术演进时间线总结 - **1970s-1980s OLTP时代**:关键技术为关系型数据库,架构为单体、行式存储,用例是交易处理,局限性是分析性能差且仅支持垂直扩展 [41] - **1990s OLAP革命**:关键技术为数据立方体,架构为预聚合多维数组,用例是快速商业智能和报告,局限性是缺乏灵活性、预处理量大且规模有限 [41][42] - **1990s末-2000s初 数据仓库时代**:关键技术为企业数据仓库,架构采用ETL、列式存储、MPP集群,用例是集中式分析存储库,局限性是成本高、方案僵化、硬件扩展受限 [42] - **2000s末-2010s 大数据时代**:关键技术为Hadoop生态系统,架构基于通用硬件的分布式存储计算,用例是大规模数据湖和批量处理,局限性是延迟高、操作复杂、无事务支持 [42] - **2010s 云仓库时代**:关键技术为云原生数据仓库,架构实现计算存储分离、弹性无服务器,用例是可扩展、经济高效的分析即服务,局限性是专有格式可能导致供应商锁定 [42] - **2010s末-2020s 湖仓一体时代**:关键技术为开放表格式与现代查询引擎,架构是基于开放数据湖的ACID事务与通用目录,用例是开放、灵活的高性能分析,局限性是仍需SQL专业知识 [42] - **2020s至今 AI原生分析**:关键技术为具备语义层和LLM接口的AI驱动平台,架构统一数据、ML和BI并嵌入智能,用例是自助分析、自然语言查询和实时机器学习 [42] 未来展望 - 数据系统正从工具演变为能理解意图并适应需求的平台 [43] - 新兴领域包括:**自主优化**(系统自动学习并优化)、**实时智能**(运营与分析系统界限消失)、**联邦学习和隐私保护分析**,以及**自然语言作为主要交互界面** [44][45] - 未来成功的公司和系统将拥抱开放、优先考虑智能嵌入,并致力于让组织中的每个人都能做出数据驱动的决策 [45]