数据系统全景图：从 MySQL 出发，看懂数据库、数仓与大数据技术

刚接触软件开发时，我对“数据存储”的理解几乎都来自 MySQL：建表、写 SQL、加索引，再配一个 Redis 做缓存。

后来接触 Neo4j，才知道数据不一定要组织成关系表；看到 Hadoop 和 Hive，又发现有些系统负责存文件，有些系统只是把文件抽象成表；再往后还有 Kafka、Flink、Spark、ClickHouse、Elasticsearch、数据湖、湖仓一体……

这些名字放在一起，很容易产生一种错觉：软件行业怎么有这么多“数据库”？

真正的问题不是技术太多，而是我们缺少一张地图。

MySQL、Redis、HDFS、Hive、Kafka 和 Spark 并不是同一种产品，也不处于同一个层级。它们分别在解决数据的保存、组织、查询、传输、计算和治理问题。一旦先分清这些职责，再遇到新技术，就不需要从零背概念了。

这篇文章不讲某个产品的底层实现，而是尝试建立一套数据系统认知框架。

目录

  1. 先别记产品，先看数据的一生
  2. 用四条轴定位一个数据系统
  3. 数据系统的完整技术图谱
  4. 底层存储：数据最终放在哪里
  5. 在线数据库：业务如何保存和查询数据
  6. 分析系统：如何从海量历史数据中得到结论
  7. 数据传输与计算：数据如何流动和加工
  8. 数据治理：系统如何知道有哪些数据
  9. 用一个电商系统串起整张图
  10. 遇到新技术时如何快速建立核心画像
  11. 初学者最容易混淆的概念
  12. 一条更合理的学习路线

先别记产品，先看数据的一生

一条数据从产生到被使用，通常会经历下面这些阶段：

产生
↓
保存
↓
传输与同步
↓
清洗和加工
↓
查询与分析
↓
归档、治理或删除

例如，用户在电商平台完成一次支付：

  • 订单服务先把支付结果写入业务数据库。
  • 缓存中可能同步更新订单状态。
  • 数据变化被发送到消息系统。
  • 实时计算系统更新销售大屏。
  • 原始记录进入数据湖或数据仓库。
  • 离线任务汇总日报、月报和用户画像。
  • 搜索、推荐、风控等系统消费加工后的数据。

这里没有一种技术能够完美承担所有职责。

业务数据库要求单笔读写快、事务可靠；分析系统需要一次扫描几亿行；消息系统关心事件能否持续传递；对象存储关心海量文件能否低成本长期保存。目标不同，设计自然不同。

所以，学习数据系统的第一原则是：

问“它处于数据生命周期的哪一段，替谁解决什么问题”。

用四条轴定位一个数据系统

面对任何陌生技术，可以先看四条轴。

它的主要职责是什么

它主要负责存储、查询、计算、传输，还是治理？

例如：

  • HDFS 主要负责分布式文件存储。
  • Hive 主要为分布式存储中的数据提供表和 SQL 抽象。
  • Spark 主要负责分布式计算。
  • Kafka 主要负责事件流的持久化、传递与订阅。
  • 数据目录主要负责描述、发现和管理数据资产。

它面向哪种工作负载

最重要的区别是 OLTP（Online Transaction Processing，在线事务处理）和 OLAP（Online Analytical Processing，在线分析处理）。

OLTP 面向日常业务交易，例如创建订单、修改地址、扣减库存。特点是请求多、单次涉及的数据少、响应时间要求高，并且经常需要事务。

OLAP 面向统计分析，例如计算全年销售趋势、地区转化率和用户留存。特点是查询次数相对少，但一次可能扫描大量数据并完成聚合。

可以粗略记成：

OLTP：处理正在发生的业务
OLAP：分析已经发生的业务

这不是绝对边界，但足以帮助初学者理解为什么 MySQL 和 ClickHouse 都能写 SQL，却不是同一种系统。

它如何组织数据

常见的数据模型包括：

  • 关系表：行、列、主键和表间关系。
  • 键值：通过 key 找到 value。
  • 文档：把一组相关字段组织成 JSON 风格文档。
  • 图：节点、关系和属性。
  • 宽列：围绕分区键组织大量、灵活的列。
  • 时序：围绕时间和指标组织数据。
  • 搜索索引：围绕词项与文档之间的映射组织数据。
  • 向量：围绕高维向量的相似度组织数据。
  • 文件与对象：保存字节内容及其位置、名称和元数据。

模型没有高低之分。它表达的是“系统希望你怎样看待和访问数据”。

它是权威数据源，还是派生系统

订单数据库通常是订单状态的权威来源；Redis 中的订单缓存只是副本；Elasticsearch 中的商品索引也是为了搜索而生成的副本；报表宽表则是从业务数据加工出来的分析结果。

这个问题非常关键：

系统里的数据发生冲突时，究竟以谁为准？

能回答这个问题，才算真正理解一个组件在架构中的位置。

数据系统的完整技术图谱

下面这张图不是严格的学术分类树，而是一张帮助入门者定位技术的工程地图。同一个产品可能横跨多个区域。

数据系统
│
├── 底层存储
│   ├── 本地与网络文件系统
│   ├── 分布式文件系统：HDFS
│   ├── 对象存储：S3、OSS、COS、MinIO
│   └── 数据文件格式：CSV、JSON、Parquet、ORC
│
├── 在线数据库与专用查询系统
│   ├── 关系数据库：MySQL、PostgreSQL
│   ├── 键值数据库：Redis
│   ├── 文档数据库：MongoDB
│   ├── 图数据库：Neo4j
│   ├── 宽列数据库：Cassandra、HBase
│   ├── 时序数据库：TimescaleDB、InfluxDB
│   ├── 搜索引擎：Elasticsearch、OpenSearch
│   └── 向量数据库：Milvus、Weaviate
│
├── 分析、数仓与湖仓
│   ├── 分析型数据库：ClickHouse、Druid、Pinot
│   ├── 数据仓库：Hive、BigQuery、Snowflake、Redshift
│   ├── 数据湖：HDFS 或对象存储上的开放数据
│   ├── 湖仓表格式：Iceberg、Delta Lake、Hudi
│   └── 查询引擎：Spark SQL、Trino
│
├── 数据传输与计算
│   ├── 消息与事件流：Kafka、Pulsar
│   ├── 数据同步与CDC：Debezium、各类同步工具
│   ├── 批处理：Spark
│   └── 流处理：Flink
│
└── 数据治理
    ├── 元数据与数据目录
    ├── 数据血缘
    ├── 数据质量
    ├── 权限与审计
    └── 生命周期与成本管理

这张图真正想表达的不是产品数量，而是五类职责：

存在哪里
如何组织和查询
怎样分析
如何流动和加工
怎样被发现、约束和管理

底层存储：数据最终放在哪里

本地文件系统

本地文件系统管理目录、文件名、权限和磁盘位置。它知道 orders.csv 是一个文件，却不知道第三列是不是订单金额。

数据库、搜索引擎和消息系统最终也要把数据写进磁盘，但它们在文件系统之上增加了数据模型、索引、事务、查询和恢复等能力。

核心画像：

本地文件系统负责在一台机器上组织字节和文件，是大量上层数据系统共同依赖的基础。

HDFS

HDFS 是分布式文件系统。它把文件拆成数据块，分散到多台 DataNode，并由 NameNode 管理文件系统元数据和块位置。客户端查询位置后，通常直接与 DataNode 传输数据。

它擅长海量大文件、高吞吐顺序访问和集群扩容，不擅长大量小文件、频繁修改单条记录和低延迟随机查询。

核心画像：

HDFS 把多台服务器的磁盘组织成一个分布式文件系统，重点解决大文件的分块、定位、副本和容错。

对象存储

对象存储用 bucket + key 标识对象，每个对象包含内容和元数据。S3、OSS、COS 与 MinIO 都属于这一类。

它不像传统文件系统那样强调真实目录和原地修改，更适合通过网络 API 保存图片、视频、备份、日志和数据湖文件。现代云数据平台常把计算与对象存储分离：文件长期留在对象存储，计算资源按需要启动。

核心画像：

对象存储是通过网络 API 使用的海量对象仓库，强调规模、持久性、成本和计算存储分离。

CSV、JSON、Parquet 和 ORC

它们不是数据库，而是文件内部的数据组织格式。

  • CSV 简单直观，但类型、嵌套结构和压缩能力有限。
  • JSON 灵活可读，适合交换半结构化数据，但体积和解析成本通常较高。
  • Parquet、ORC 面向分析场景，按列组织数据，便于只读取需要的列并获得更好的压缩效果。

需要分清三个层次：

对象存储或HDFS：文件放在哪里
Parquet或ORC：文件内部怎么组织
Hive或Iceberg：哪些文件共同组成一张表

在线数据库：业务如何保存和查询数据

关系数据库

代表技术是 MySQL 和 PostgreSQL。

它们用表、行、列、主键、约束和关系组织数据，擅长事务、精确查询和复杂业务规则，常用来保存用户、订单、商品、支付等核心业务数据。

核心画像：

关系数据库适合结构清晰、关系明确、需要事务与一致性的在线业务，是多数业务系统的权威数据源。

不要把“关系模型”和“行式存储”混成一件事。关系模型描述逻辑结构，行式或列式描述物理布局。一个系统可以使用关系表模型，同时采用列式存储服务分析。

键值数据库

代表技术是 Redis。

它通过 key 快速定位 value，适合缓存、会话、验证码、计数器、排行榜和短期状态。Redis 的 value 还可以是字符串、哈希、列表、集合、有序集合等结构。

核心画像：

键值数据库把访问路径收敛为“通过 key 找值”，用更简单的查询模型换取速度和可扩展性。

Redis 能持久化，不代表它天然适合作为所有核心数据的唯一来源。是否能承担权威存储，要看持久化、部署、恢复和业务一致性要求，而不是只看“它会不会落盘”。

文档数据库

代表技术是 MongoDB。

文档数据库把一组经常一起读取的数据放进同一个文档。文档可以嵌套对象和数组，同一集合中的字段也可以较灵活地演进。

它适合内容、商品属性、用户配置和结构变化较快的数据。灵活 Schema 不等于不需要设计 Schema；访问模式、嵌入还是引用、文档大小和一致性仍然需要认真考虑。

核心画像：

文档数据库适合天然以完整对象出现、结构可能变化、经常整体读写的数据。

图数据库

代表技术是 Neo4j。

图数据库把节点和关系都当成一等公民，擅长沿关系进行多跳遍历，例如社交网络、知识图谱、风险关系和路径查询。

它的物理实现带有邻接结构的思想，但不能简单等同于代码里的邻接表，更不能认为一定是邻接矩阵。数据库还要处理属性、索引、事务、并发、缓存和持久化。

核心画像：

图数据库不是为了“存更复杂的表”，而是为了让关系本身成为主要查询对象。

宽列数据库

代表技术是 Cassandra 和 HBase。

宽列数据库通常围绕分区键组织数据，适合超大规模、分布式、按明确访问路径进行读写的场景。它不像关系数据库那样鼓励任意 JOIN，往往需要根据查询提前设计数据分区和表结构。

它和 ClickHouse 这类“列式分析数据库”不是一回事：

  • 宽列强调分区键、稀疏列和横向扩展。
  • 列式分析数据库强调按列读取、压缩和大规模聚合。

核心画像：

宽列数据库面向可预测的键范围访问和大规模分布式读写，用受约束的查询方式换取扩展能力与可用性。

时序数据库

时序数据总带有时间，例如服务器 CPU、接口延迟、设备温度、股票价格和传感器指标。

时序数据库通常围绕时间分区，并提供时间窗口、降采样、保留策略和连续聚合等能力。TimescaleDB、InfluxDB 是常见代表。

核心画像：

时序数据库针对“某个指标如何随时间变化”优化，擅长高频写入、时间范围查询和按时间聚合。

搜索引擎

代表技术是 Elasticsearch 和 OpenSearch。

搜索引擎通过倒排索引等结构，将词项映射到文档，擅长全文检索、分词、相关性排序、模糊匹配、高亮和日志检索。

常见架构是 MySQL 保存权威商品数据，Elasticsearch 保存可搜索的商品副本。搜索索引短暂不同步通常可以修复，但订单真相不能因此改变。

核心画像：

搜索引擎把“精确找一条记录”扩展为“从大量文本和文档中找最相关的结果”。

向量数据库

文本、图片和音频经过模型处理后，可以变成向量。向量数据库根据距离或相似度寻找最接近的向量，常用于语义搜索、图片检索、推荐和 RAG 知识召回。

向量数据库解决的是“含义是否接近”，关系数据库解决的是“字段是否满足条件”，搜索引擎更擅长“词是否匹配”。现代产品正在互相吸收能力，所以实际选型还要看数据规模、过滤条件、更新频率和已有技术栈。

核心画像：

向量数据库保存和检索高维向量，让系统能按语义相似度而不只是关键词查找内容。

分析系统：如何从海量历史数据中得到结论

分析型数据库

代表技术是 ClickHouse、Druid 和 Pinot。

它们面向 OLAP，擅长对大量记录进行过滤、分组和聚合。ClickHouse 等系统采用列式存储，让查询只读取需要的列，并让相同类型的数据更容易压缩。

核心画像：

分析型数据库用列式存储和面向扫描聚合的执行方式，为报表、监控和交互式分析提供较低延迟。

数据仓库

数据仓库首先是一种面向分析的数据组织体系，不等于某一个软件。

它把多个业务系统的历史数据清洗、统一并分层，常见的 ODS、DWD、DWS、ADS 表示从原始数据到明细、汇总和应用数据的逐步加工。

Hive 是经典的数据仓库 SQL 系统。它为 HDFS 等分布式存储中的文件施加表结构，借助 Metastore 保存表、列、分区、位置等元数据，再通过执行引擎完成查询。

因此，Hive 更接近：

表与元数据
+ SQL解析和查询计划
+ 分布式执行协作

它不是 HDFS 的“索引引擎”。

核心画像：

数据仓库把分散的业务历史转化为口径统一、可复用、适合分析的数据资产。

数据湖

数据湖通常建立在 HDFS 或对象存储上，可以保存结构化表、JSON、日志、图片、音频和模型文件。它强调开放格式、原始数据保留和低成本扩展。

但“把文件全扔进对象存储”并不会自动形成数据湖。缺少目录、Schema、质量、权限和生命周期管理时，它更可能变成难以理解的“数据沼泽”。

核心画像：

数据湖用开放、低成本的存储承载多种形态的数据，为后续计算保留灵活性。

湖仓一体与表格式

Iceberg、Delta Lake、Hudi 不是新的硬盘，也不是另一个对象存储。它们在 Parquet 等数据文件之上维护表级元数据，管理一张表由哪些文件组成，并提供快照、Schema 演进、分区演进和事务语义等能力。

可以这样理解：

对象存储：保存文件
Parquet：定义文件内部结构
Iceberg：管理一张表及其版本
Spark、Flink、Trino：读取或计算这张表

核心画像：

湖仓表格式给开放文件补上可靠的表管理能力，让多个计算引擎可以围绕同一份数据协作。

Spark SQL 与 Trino

Spark SQL 是 Spark 中处理结构化数据的模块，可以用 SQL 或 DataFrame 表达计算，再由 Spark 执行。

Trino 是分布式 SQL 查询引擎，擅长通过连接器查询多个异构数据源。它可以让一条 SQL 同时访问湖仓、关系数据库和其他存储，但它本身主要负责查询，不等于底层数据仓库。

核心画像：

查询引擎负责把 SQL 转换成跨机器、跨数据源的执行计划；数据通常仍保存在外部系统中。

数据传输与计算：数据如何流动和加工

Kafka

Kafka 经常被叫作消息队列，但“分布式事件流平台”更能体现它的完整定位。

生产者把事件写入 Topic，Topic 划分为多个 Partition；消费者按照 Offset 读取数据。事件可以保留一段时间，因此不同消费者能够独立处理，也可以在需要时重放。

它适合连接业务服务、实时计算、搜索、数仓和日志系统。

核心画像：

Kafka 是可持久化、可订阅、可重放的事件日志，让生产者和多个下游消费者解耦。

CDC 与数据同步

CDC 是 Change Data Capture，即捕获数据库中已经发生的数据变化。以 Debezium 为例，它可以读取 MySQL binlog 或 PostgreSQL 逻辑复制流，把插入、更新和删除转换成变化事件。

CDC 和“定时全表查询”不同：前者围绕增量变化构建数据流，后者按周期重新扫描数据。CDC 常用来同步搜索索引、缓存、分析库和数据湖。

核心画像：

CDC 把数据库内部的行级变化转换成可消费的事件，是业务数据库通往其他数据系统的重要出口。

Spark

Spark 是分布式计算引擎，主要负责把一个大任务拆成多个分区和阶段，让多台机器并行处理，再汇总结果。

它常用于离线清洗、数仓加工、机器学习和大规模 SQL。Spark 能读取 HDFS、对象存储、Hive、Kafka 和数据库，也能把结果写回这些系统。

核心画像：

Spark 是面向大规模数据的通用计算工厂，重点是计算，不是长期保存业务数据。

Flink

Flink 是面向有状态流处理设计的分布式计算引擎，也支持有边界的数据流。

实时销售额、最近五分钟失败率、异常交易检测都需要系统持续接收事件，并记住中间状态。流没有天然终点，因此 Flink 还要处理窗口、事件时间、迟到数据、状态和故障恢复。

核心画像：

Flink 持续处理不断到来的事件，并可靠维护跨事件的计算状态，适合实时指标和事件驱动业务。

批处理和流处理

批处理先确定一批数据，再开始计算；流处理面对的是持续到来的数据。

批处理：昨天的数据到齐后，凌晨统一生成日报
流处理：每一笔订单到达后，几秒内更新实时大屏

现代 Spark 和 Flink 的能力边界并非完全互斥。初学阶段更应该抓住工作负载差异，而不是背“谁只能做批、谁只能做流”。

数据治理：系统如何知道有哪些数据

当系统只有一个 MySQL 时，开发者可能靠表名和文档就能理解数据。进入多数据库、数仓、数据湖和实时链路后，新的问题会出现：

  • 公司到底有哪些表和指标？
  • 订单金额 在不同系统中是不是同一个口径？
  • 这张报表来自哪些源表和计算任务？
  • 某个字段包含个人敏感信息吗？
  • 数据质量下降时影响了哪些下游？
  • 一份数据应该保存多久，由谁访问？

因此，完整的数据平台还需要治理能力。

元数据与数据目录

元数据是“描述数据的数据”，包括表名、字段、类型、负责人、更新时间、存储位置和业务含义。数据目录则让人能够搜索、理解和使用这些数据资产。

数据血缘

数据血缘记录数据从哪里来、经过哪些任务、最终流向哪里。它像一张加工关系图，帮助定位错误影响和变更范围。

数据质量

数据质量关注完整性、唯一性、及时性、准确性和一致性。例如订单主键是否重复、金额是否为空、日报是否按时产出。

权限、审计和生命周期

数据不是能查到就应该随便查。平台还要回答谁能访问、访问过什么、数据保存多久、何时归档或删除，以及怎样控制存储和计算成本。

核心画像：

数据治理不负责替业务产生数据，而是让数据可发现、可理解、可信、可控和可追责。

用一个电商系统串起整张图

假设用户搜索咖啡、点击商品、下单并完成支付。

在线业务

MySQL / PostgreSQL
├── 用户
├── 商品
├── 订单
└── 支付

Redis
├── 登录状态
├── 热门商品缓存
└── 临时计数

Elasticsearch
└── 商品全文搜索

Neo4j
└── 用户、商品、兴趣和风险关系

关系数据库通常是订单真相；Redis 和 Elasticsearch 更多是为了速度与查询体验生成的派生数据。

数据进入流动链路

业务数据库
   ↓ CDC
 Kafka
  ├──→ Flink → 实时指标 → Redis / ClickHouse
  ├──→ Elasticsearch → 更新搜索索引
  └──→ 对象存储 → 保存原始事件

Kafka 不是最终报表系统，Flink 也不是永久数据仓库。它们分别负责事件传递和持续计算。

历史分析

对象存储中的 Parquet 文件
            ↓
      Iceberg 管理表
            ↓
  Spark 批量加工 / Trino 查询
            ↓
   明细层、汇总层、应用层
            ↓
 ClickHouse / BI 报表 / 用户画像

一条完整链路中，每个系统只承担自己擅长的职责。大型系统的复杂，并不主要来自“用了很多技术”，而是来自数据在多个系统之间存在复制、延迟、失败、重放和口径变化。

遇到新技术时如何快速建立核心画像

以后再遇到一个陌生名字，不要先背它的组件列表。先回答下面八个问题：

  1. 它解决什么问题？ 是存储、查询、计算、传输还是治理？
  2. 它服务谁？ 是在线业务、分析人员、数据工程还是 AI 应用？
  3. 它的数据模型是什么？ 表、键值、文档、图、时序、向量还是文件？
  4. 它最擅长什么访问模式？ 点查、事务、全文搜索、关系遍历、范围扫描还是聚合？
  5. 数据实际存在哪里？ 内存、本地磁盘、分布式文件系统还是对象存储？
  6. 它保存的是权威数据还是副本？ 冲突时以谁为准？
  7. 它最不擅长什么？ 哪些代价是设计时主动接受的？
  8. 它与上下游怎样协作？ 数据从哪里来，处理后去哪里？

可以把答案压缩成一张技术画像卡：

技术：
类别：
核心问题：
数据模型：
典型工作负载：
权威源或派生系统：
擅长：
不擅长：
常见上游：
常见下游：

如果一项技术还无法填完这张卡，说明我们记住的可能只是名词，还没有建立认知。

初学者最容易混淆的概念

数据库不等于存储

HDFS 和对象存储负责保存文件；数据库还提供数据模型、查询、索引、事务或一致性等能力。

能写 SQL 不等于关系数据库

Hive、Spark SQL、Trino、ClickHouse 都能使用 SQL，但它们的存储位置、执行方式和工作负载差异很大。SQL 是交互语言，不是产品类别。

列式数据库不等于宽列数据库

ClickHouse 的“列式”主要描述物理存储与分析读取方式；Cassandra 的“宽列”主要描述按分区组织的稀疏、灵活数据模型。

Hive 不等于 HDFS 的索引

HDFS 负责文件和数据块；Hive 负责表结构、元数据、SQL 与查询计划，并协调执行引擎读取底层数据。

Kafka 不等于长期数据仓库

Kafka 可以持久化和重放事件，但它的核心职责是连接生产者与消费者。长期分析数据通常仍会进入数据库、数仓或数据湖。

数据湖不等于一堆文件

没有元数据、表管理、质量、权限和生命周期的数据湖，最终可能只是一个没人敢删、也没人理解的文件仓库。

专用系统不一定必须独立部署

PostgreSQL 可以扩展时序、JSON、全文和向量能力；Elasticsearch 也在扩展向量检索；不少数据库正在融合多种模型。

是否引入专用系统，不应该只看“它能不能做”，还要看数据规模、性能目标、可靠性、团队能力和运维成本。

一条更合理的学习路线

刚入门时，不建议沿着产品热度横向收集名词。更好的顺序是从稳定概念走向具体系统。

建立数据基础

先理解：

  • 内存、磁盘、文件和网络
  • 数据模型与物理存储的区别
  • 索引、事务、并发与持久化
  • 单机、分片、副本和故障恢复

吃透在线业务

以 MySQL 或 PostgreSQL 为主线，理解关系模型、SQL、索引和事务；再学习 Redis，理解缓存、短期状态和数据一致性。

扩展数据模型

依次了解文档、图、搜索、宽列、时序和向量。重点不是学会六套命令，而是理解每种模型让什么查询变得更自然。

建立分析认知

理解 OLTP 与 OLAP、行式与列式、数据仓库分层、Parquet、对象存储、Hive、Spark SQL 和 ClickHouse。

理解数据流动

学习 Kafka、CDC、批处理和流处理，再理解 Spark 与 Flink 为什么会出现在数据链路中。

补全现代数据平台

最后再看数据湖、Iceberg 等湖仓表格式、Trino、元数据、血缘、质量和权限治理。

走到这里，再遇到一个新产品，你大概率已经能判断：

  • 它是不是一个真正负责持久化的系统。
  • 它面向在线业务还是分析。
  • 它提供的是数据模型、计算能力还是查询入口。
  • 它与已有系统是替代关系还是协作关系。

写在最后

数据系统看起来庞杂，是因为我们经常把不同层级的名词放在一起比较。

MySQL 决定核心业务数据如何以关系表被可靠地读写；Redis 用键值访问加速热点与状态；MongoDB、Neo4j、Elasticsearch、时序数据库和向量数据库分别围绕不同的数据形态与查询方式优化；HDFS 和对象存储承载海量文件；Hive、Iceberg 和查询引擎把文件组织成可管理、可查询的表；Kafka 让事件持续流动；Spark 和 Flink 负责批量或持续计算；治理体系则让数据最终可理解、可信和可控。

真正值得记住的，不是每个产品的口号，而是一套判断方法：

先看它解决哪一类问题，再看它如何组织数据、服务哪种工作负载、是不是权威来源，以及它在整条链路中与谁协作。

当这套骨架建立起来以后，新技术只是在地图上多了一个坐标，而不会再变成一个孤立的新名词。

延伸阅读

# 数据库 # mysql # 大数据
Logo
亚马逊云科技技术品牌专区

更多推荐

cover

基于STM32的全屋环境智能监测与预警终端设计

avatar 亚马逊云科技技术品牌专区

Keras：面向人类的深度学习库

Keras3支持多后端（TensorFlow、PyTorch、JAX），通过设置环境变量切换，兼容指定版本。pip安装后可用Sequential API快速构建CNN模型，如MNIST分类示例，实

avatar 亚马逊云科技技术品牌专区

AI行业日报｜2026-09-25：5个热点事件

本期行业动态聚焦于端侧算力重构、自主智能体工作流、开发工具经济模型、网络隔离架构设计与公共部门合规审查。以下结合一线技术场景进行结构化梳理，供 AI 研究员与软件工程团队参考。 PrismML 正将其轻量级语言模型适配至搭载高通处理器的智能眼镜终端 1 。该平台的核心战略指向开源权重模型的本地化运行，旨在最大化挖掘穿戴设备现有算力的利用效率 1 。对于嵌入式与边缘计算开发者而言，此类微型模型向低功

avatar 亚马逊云科技技术品牌专区