一、大数据全流程
（一）数据采集（Ingestion）与接入
目标：从多源异构系统中获取原始数据。
实时性：离线采集（T+1）、近实时（分钟级）、实时（毫秒级）
数据规模：小流量（GB/天）、大流量（TB/天）、超大规模（PB/天）
来源：传感器、日志、数据库、社交媒体、IoT设备等。
批量采集：ETL工具（如Informatica、Kettle）、Sqoop（数据库导入）、日志解析（Flume、Logstash）。
实时采集：消息队列（Kafka、RocketMQ）、API接口、IoT设备协议（MQTT）。
数据源类型：结构化（数据库）、半结构化（JSON/XML、日志）、非结构化（文本、图像、视频）。
挑战：数据格式标准化、传输延迟控制、断点续传。
1、批量采集（离线）
| 技术 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|
| Sqoop | 关系型数据库到HDFS/Hive | 成熟稳定，简单易用，支持增量导入 | 仅支持结构化数据，性能瓶颈明显 |
| DataX | 多数据源离线同步 | 支持多种异构数据源，插件化扩展 | 配置复杂，实时性差 |
| Kettle | ETL流程可视化开发 | 图形化界面，适合非技术人员 | 性能较低，大规模场景不适用 |
2、流式采集
| 技术 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|
| Flume | 日志收集（如Web服务器日志） | 高可靠，支持多级聚合，支持多种sink | 仅支持单向流，配置复杂 |
| Kafka | 高吞吐量消息队列，实时数据管道（如日志→Flink→ClickHouse） | 高吞吐（百万级/秒）、低延迟（毫秒级）、持久化存储、Exactly-Once语义 | 需配合消费者实现业务逻辑，运维复杂（需管理Broker、Zookeeper） |
| Pulsar | 金融级日志流处理（如交易流水） | 统一消息与流、多租户、分层存储、支持无状态扩容 | 生态成熟度低于Kafka、社区活跃度一般 |
| Kinesis | AWS环境实时数据处理 | 全托管服务，易扩展 | 仅限AWS生态，成本较高 |
| NiFi | ETL/ELT，CDC（变更数据捕获），实时流处理，数据归档与备份 | 可视化、多数据源、实时与批量结合、数据溯源 | 性能瓶颈，资源消耗较高，社区与文档支持有限，不适合超大规模数据处理 |
3、日志采集
| 技术 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|
| Filebeat | 服务器日志文件采集（如Nginx、Tomcat） | 专为文件日志设计、低延迟、支持断点续传、与Logstash/Kafka无缝集成 | 功能单一（仅文件采集）、过滤能力弱 |
| Logstash | ELK栈（Elasticsearch+Logstash+Kibana） | 功能全面（支持解析、过滤、转换）、与Elasticsearch深度集成 | 资源消耗高（JVM）、启动慢、性能瓶颈明显 |
| Fluentd | 容器化环境（K8s）、边缘设备日志采集 | 低资源占用（内存/CPU）、支持200+插件（如Kafka、S3）、统一日志层 | 社区规模较小、复杂场景需自定义插件 |
| Vector | 高性能日志采集（如IoT设备、CDN日志） | 超低资源占用（CPU/内存）、支持多种源/目标（如Kafka、S3）、动态重载配置 | 生态较新（插件较少）、社区支持有限 |
3.1 技术选型指标
1）实时性要求
毫秒级：Kafka（低延迟消息队列）、Pulsar（计算存储分离）。
秒级：Fluentd/Filebeat（轻量级Agent）+ Kafka。
分钟级：Logstash（批量处理）、AWS CloudWatch Logs（依赖云服务调度）。
2）数据量规模
小规模（<10GB/天）：Filebeat + Logstash + Elasticsearch。
中规模（10GB-1TB/天）：Fluentd + Kafka + Flink/Spark。
大规模（>1TB/天）：Kafka/Pulsar集群 + 分布式处理框架（如Flink）。
3）资源消耗
低资源：Vector（Rust）、Filebeat（Go）。
高资源：Logstash（JVM）、Splunk Forwarder（专有引擎）。
4）协议支持
文件日志：Filebeat、Fluentd、Logstash。
网络协议：Syslog（Fluentd/Logstash）、HTTP/TCP（Kafka/Pulsar）。
云服务：AWS CloudWatch Logs、Datadog Agent。
5）运维复杂度
简单：Filebeat（配置文件驱动）、Datadog Agent（全托管）。
复杂：Kafka（需管理Broker/Zookeeper）、Pulsar（分层存储配置）。
3.2 场景选型
1）K8s容器日志采集
方案：Filebeat（DaemonSet部署） → Kafka → Flink → ClickHouse。
理由：Filebeat轻量级，Kafka缓冲日志，Flink实时处理，ClickHouse存储分析。
2）高吞吐IoT设备日志
方案：Vector（边缘设备） → Pulsar → 实时告警系统。
理由：Vector低资源占用，Pulsar支持百万级QPS，适合设备日志流。
3）安全审计日志分析
方案：Splunk Universal Forwarder → Splunk Enterprise。
理由：Splunk提供预定义安全规则、合规性报告，企业级支持。
4）云上多服务日志整合
方案：AWS CloudWatch Logs Agent → CloudWatch Logs → OpenSearch。
理由：全托管服务，减少运维成本，适合AWS生态。
5）低成本开源日志栈
方案：Filebeat/Fluentd → Kafka → Loki/Grafana（监控） + Trino/Doris（分析）。
理由：Loki替代Elasticsearch降低成本，Trino支持多数据源查询。
4、数据库变更捕获(CDC)
| 技术 | 适用数据库 | 典型场景 | 优势 | 劣势 |
|---|---|---|---|---|
| Debezium | MySQL、PostgreSQL、MongoDB、Oracle | 实时数据仓库、微服务同步 | 全量+增量同步、Exactly-Once语义、支持多种数据库 | 配置复杂、需Kafka存储变更事件、资源消耗较高 |
| Flink CDC | MySQL、PostgreSQL、Oracle、SQL Server | 实时风控、用户行为分析 | 纯流式计算、支持Checkpoint、低延迟 | 仅支持部分数据库、依赖Flink生态 |
| Canal | MySQL | MySQL到Kafka/Redis的同步 | 轻量级、社区活跃、支持MySQL全量+增量 | 仅支持MySQL、功能单一、无分布式能力 |
| Maxwell | MySQL | 小规模MySQL变更采集 | 输出JSON格式、支持Kafka/RabbitMQ、简单易用 | 单点故障、性能瓶颈、不支持DDL事件 |
| BottledWater | PostgreSQL | 历史遗留项目（不推荐新用） | 低延迟、支持全量+增量 | 已停止维护、仅支持PostgreSQL |
4.1 技术选型指标
1）实时性要求
毫秒级：Flink CDC（流式计算）、Debezium + Kafka（低延迟管道）。
秒级：Canal、Maxwell。
分钟级：AWS DMS、DataX CDC。
2）数据库兼容性
多数据库支持：Debezium（MySQL、PostgreSQL、MongoDB等）、Oracle GoldenGate。
MySQL专用：Canal、Maxwell。
3）资源消耗
低侵入性：Debezium（基于日志解析）、Flink CDC（JDBC模式）。
高侵入性：触发器模式（如部分商业工具）可能增加源库负载。
4）数据一致性
Exactly-Once：Debezium（配合Kafka事务）、Flink CDC（Checkpoint机制）。
At-Least-Once：Canal、Maxwell（需下游去重）。
5）运维复杂度
简单易用：Maxwell（JSON输出）、AWS DMS（全托管）。
复杂配置：Debezium（需Kafka/Zookeeper）、Oracle GoldenGate。
4.2 场景方案
1）实时数据仓库（如ClickHouse/Doris）
方案：Debezium + Kafka + Flink → ClickHouse。
理由：Debezium提供全量+增量数据，Kafka缓冲变更事件，Flink保证Exactly-Once语义。
2）微服务数据同步
方案：Flink CDC + Kafka → 目标服务。
理由：Flink CDC支持低延迟流式处理，Kafka解耦生产者与消费者。
3）MySQL到Redis缓存更新
方案：Canal + Kafka → Redis。
理由：Canal轻量级，适合MySQL专用场景，Kafka保证数据不丢失。
4）云上跨数据库同步
方案：AWS DMS（如MySQL → Aurora PostgreSQL）。
理由：全托管服务，减少运维成本。
5、分布式文件采集
| 技术 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|
| DistCp | HDFS集群间大规模数据迁移 | Hadoop原生工具，高效稳定 | 仅支持HDFS，功能单一 |
| Alluxio | 内存级分布式缓存 | 加速数据访问，支持多存储层 | 部署复杂，运维成本高 |
6、Web数据采集
| 技术 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|
| Scrapy | 结构化网页爬取 | 框架完善，支持分布式扩展 | 需编写代码，反爬机制需处理 |
| Apache Nutch | 大规模网页爬取 | 基于Hadoop，支持分布式 | 配置复杂，学习曲线陡峭 |
| Selenium | 动态网页渲染采集 | 支持JavaScript渲染页面 | 性能低，资源消耗大 |
7、技术选型
1）离线批量采集
小规模数据：DataX（简单易用）或Sqoop（传统数据库适配）。
大规模数据：Spark + HDFS（计算存储一体化，避免数据搬运）。
关系型数据库迁移：Sqoop + 增量调度
日志文件采集：Flume/Filebeat + HDFS
2）实时流式采集
数据库变更：Flink CDC（无侵入，支持多种数据库）、Canal（MySQL专用）、Debezium/Maxwell。
通用消息队列：Kafka（核心中间件，支持多消费者）/Pulsar
AWS环境：Kinesis
3）日志收集
云原生环境：Fluentd/Fluent Bit
传统环境：Logstash（过滤转换能力强）/Filebeat、Flume（高可靠）
阿里云环境：Logtail
4）特殊场景
Web爬虫：Scrapy（结构化数据） + Selenium（动态页面补充）。
跨集群迁移：DistCp（Hadoop原生）或NiFi（可视化流程管理）。
极低延迟：Kafka + 内存计算
高可靠性：Kafka + 多副本
简单易用：云服务商提供的托管服务
5）混合架构
Lambda架构：离线层（Hive/Spark） + 实时层（Flink/Kafka）。
Kappa架构：纯流式处理（Flink + Kafka），适合低延迟场景。
（二）数据存储（Storage）与管理
目标：构建可扩展、低成本的存储体系。
分布式文件系统：HDFS（Hadoop）、Ceph（支持块/对象/文件存储）。
NoSQL数据库：HBase（列式）、MongoDB（文档型）、Cassandra（宽列）。
云原生存储：AWS S3、阿里云OSS（对象存储）、Azure Blob Storage。
数据湖：Delta Lake、Iceberg（支持ACID事务的表格式）。
挑战：冷热数据分层、存储成本优化、数据生命周期管理。
1、分布式文件系统
| 技术 | 架构设计 | 核心优势 | 适用场景 |
|---|---|---|---|
| HDFS | 主从架构（NameNode+DataNode） | 成熟生态（Hadoop/Spark原生支持） | 大数据批处理、离线分析 |
| Ceph | 分布式对象存储（RADOS）+ 文件接口 | 统一存储（块/对象/文件） | 云原生、多协议存储、混合负载 |
| GlusterFS | 无中心节点（弹性哈希） | 简单扩展，线性性能提升 | 媒体存储、备份归档 |
| Alluxio | 内存优先的分层存储（计算存储分离） | 加速计算层，缓存热点数据 | AI/机器学习、内存计算加速 |
| Lustre | 对象存储+元数据服务器集群 | 高性能并行文件系统（HPC场景） | HPC、科学计算、高性能需求 |
| MooseFS | 主从架构（Master+ChunkServers） | 轻量级，易部署，支持动态扩容 | 中小规模企业存储、Web应用 |
| JuiceFS | 客户端层，元数据服务层，对象存储层分层设计 | 成本效益显著，弹性与可扩展，高性能与低延迟，跨云与混合云支持 | 大数据分析与AI训练，容器化应用数据持久化，跨云与混合云数据管理 |
1.1 技术选型
1）传统大数据
HDFS：成熟稳定，适合Hadoop/Spark批处理，Hadoop生态，但需考虑NameNode单点问题。
Alluxio：作为缓存层加速计算，尤其适合AI训练（如TensorFlow on Alluxio）。
2）云原生/混合云
Ceph：支持S3接口/块/文件，统一存储后端，适合私有云/公有云混合部署。
3）性能需求
低延迟：Alluxio（内存缓存）或Ceph（块存储优化）。
高吞吐：Lustre（并行文件系统）或HDFS（顺序读写优化），并行I/O优化，科学计算、金融风控等场景，需配合InfiniBand网络。
4）扩展性
超大规模：Ceph（百万级对象）或HDFS（千节点级）。
动态扩容：GlusterFS（无中心节点）或MooseFS（在线扩容）。
5）成本
开源免费：所有选项均开源，但运维成本差异大（如Lustre需专业团队）。
硬件依赖：Lustre需高性能网络，HDFS依赖本地磁盘。
GlusterFS：媒体存储、备份归档，简单易维护。
MooseFS：中小企业文件共享，支持动态扩容。
轻量级部署：MooseFS或GlusterFS（简单易用）。
6）生态兼容性
Hadoop生态：HDFS或Alluxio。
Kubernetes：Ceph（Rook项目）或GlusterFS（Heketi）。
2、云原生对象存储
| 技术 | 扩展性 | 多租户支持 | 运维复杂度 | 成本 |
|---|---|---|---|---|
| AWS S3 | EB级（全球节点） | IAM策略 | 低（全托管） | 按使用量计费 |
| MinIO | PB级（集群扩展） | 命名空间隔离 | 中（K8s集成） | 自建硬件成本 |
| Ceph RGW | EB级（分布式） | 需额外配置 | 高（需管理Ceph集群） | 自建硬件成本 |
| 阿里云OSS/腾讯云COS | EB级（国内节点） | RAM策略 | 低（全托管） | 按使用量计费 |
3、NoSQL非关系型数据库
| 数据库 | 类型 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|---|
| Redis | 键值存储 | 缓存、会话管理、实时排行榜 | 内存计算、毫秒级延迟、支持持久化 | 数据量受内存限制，持久化影响性能 |
| DynamoDB | 键值/文档存储 | 云原生应用、无服务器架构 | 全托管服务、自动扩展、低延迟 | 成本较高，复杂查询需额外索引 |
| MongoDB | 文档存储 | 内容管理系统、用户画像、物联网数据 | 灵活模式、强一致性、聚合查询 | 集群分片配置复杂，写入吞吐量有限 |
| Cassandra | 列族存储 | 时序数据、日志存储、消息队列 | 高可用、线性扩展、多数据中心支持 | 查询语言复杂，无原生事务支持 |
| HBase | 列族存储 | 大数据实时分析、海量数据存储 | 集成Hadoop生态、强一致性 | 依赖HDFS，运维成本高 |
| Neo4j | 图数据库 | 社交网络、欺诈检测、推荐系统 | 原生图存储、Cypher查询语言、可视化 | 分布式扩展性差，不适合超大规模图 |
| ArangoDB | 多模型（文档/图/键值） | 混合负载场景（如文档+关系查询） | 支持多种数据模型、统一查询语言 | 社区规模较小，功能迭代较慢 |
3.1 技术选型因素
1）一致性与可用性
强一致性：MongoDB、HBase（适合金融交易等场景）。
最终一致性：Cassandra、DynamoDB（适合高可用优先的场景）。
图数据库：Neo4j支持ACID事务，适合需要严格一致性的关系查询。
2）扩展性需求
垂直扩展：Redis（单机性能强，但受内存限制）。
水平扩展：Cassandra、MongoDB（分片集群支持PB级数据）。
多数据中心：Cassandra、DynamoDB（跨区域复制能力）。
3）查询复杂度
简单查询：键值存储（通过键直接访问）。
复杂查询：
文档存储：MongoDB支持聚合管道、全文索引。
图数据库：Neo4j支持Cypher语法，高效遍历关系。
列族存储：Cassandra需预先设计查询模式（CQL限制较多）。
4）生态与集成
云原生：DynamoDB（AWS）、Cosmos DB（Azure）、Firestore（Google Cloud）。
开源生态：MongoDB、Cassandra、Neo4j（支持K8s部署）。
大数据集成：HBase（与Hadoop/Spark深度整合）、Cassandra（支持Spark Connector）
3.2 场景选型
1）实时缓存与会话管理
推荐方案：Redis（内存计算+持久化）或Memcached（纯内存缓存）。
理由：低延迟、高并发，支持数据过期和发布订阅模式。
2）物联网（IoT）数据存储
推荐方案：Cassandra（时序数据写入优化）或MongoDB（灵活模式存储设备元数据）。
理由：Cassandra支持高吞吐写入和分布式查询，MongoDB适合嵌套的传感器数据。
3）社交网络与推荐系统
推荐方案：Neo4j（图数据库）或ArangoDB（多模型）。
理由：原生支持关系查询，可高效计算用户相似度或推荐路径。
4）云原生应用
推荐方案：DynamoDB（全托管+自动扩展）或Cosmos DB（多模型+全球分发）。
理由：无需运维，与云服务深度集成，支持多区域复制。
5）大数据分析平台
推荐方案：HBase（Hadoop生态）或Cassandra（Spark集成）。
理由：HBase适合与Hive/Spark协同处理PB级数据，Cassandra支持实时分析。
4、NewSQL分布式事务数据库
1）基于共识算法的分布式架构
CockroachDB、YugabyteDB、TiDB（部分模块）
核心原理：
数据分片（Range Partitioning）：将数据按主键范围划分为多个分片（Range），每个分片存储在多个节点上形成副本集（Replica Set）。
共识协议（Raft/Paxos）：通过多副本同步确保数据强一致性，写入需多数节点确认（如3副本中2个成功）。
全局时钟（HLC）：解决分布式事务中的时间戳分配问题（如CockroachDB的Hybrid Logical Clock）。
优势：
强一致性：支持跨分区ACID事务，满足金融级要求。
自动扩展：动态分片分裂与迁移，无需手动干预。
多云兼容：支持跨区域部署，容忍网络分区。
2）基于两阶段提交（2PC）的优化架构
Google Spanner、OceanBase、TiDB（Percolator算法）
核心原理：
分布式事务协议：通过两阶段提交（2PC）或其变种（如Percolator的乐观锁）协调跨节点事务。
全局唯一时间戳（TrueTime/TSO）：为事务分配全局有序时间戳，解决冲突（如Spanner依赖GPS+原子钟，TiDB使用中心化TSO服务）。
列式存储引擎：部分产品（如OceanBase、TiFlash）集成列存引擎支持HTAP。
优势：
严格串行化：提供外部一致性（External Consistency），确保事务全局顺序。
高并发：通过乐观锁减少锁竞争（如Percolator的写写冲突检测）。
混合负载支持：OLTP+OLAP一体化（如Spanner的F1查询引擎）。
3）共享存储架构（计算存储分离）
AWS Aurora、阿里云PolarDB、华为云GaussDB(for MySQL)
核心原理：
存储层共享：多个计算节点共享同一份存储（如Aurora的日志即存储设计）。
无状态计算节点：计算节点故障时，其他节点可快速接管，无需数据迁移。
读写分离：主节点写，多个只读副本提供读扩展。
优势：
极低延迟：存储计算分离减少数据复制开销。
弹性扩展：计算节点秒级扩容，存储按需扩展。
高可用：存储层多副本同步，计算节点无单点。
| 数据库 | 一致性模型 | 事务支持 | 扩展性 | 典型场景 |
|---|---|---|---|---|
| CockroachDB | 严格串行化（External Consistency） | 跨分区ACID | 自动分片分裂/迁移 | 全球化应用、SaaS平台 |
| TiDB | 严格串行化（依赖TSO） | 跨分区ACID（Percolator） | 自动分片（PD组件调度） | 金融核心系统、互联网业务 |
| OceanBase | 严格串行化（Paxos+TSO） | 跨分区ACID（Paxos） | 手动分片（支持自动扩展） | 银行核心系统、高并发OLTP |
| Google Spanner | 严格串行化（TrueTime） | 全球分布式事务 | 自动分片Directory-Based | 谷歌内部核心业务 |
| AWS Aurora | 强一致（MySQL兼容） | 本地事务（跨可用区2PC） | 计算节点弹性扩展 | 云原生企业应用 |
4.1 业务场景方案
1）全球化部署
优先选择支持多区域同步的NewSQL（CockroachDB、Spanner、YugabyteDB），避免跨区域2PC性能瓶颈。
2）混合负载（HTAP）
选择集成列存引擎的产品（TiDB+TiFlash、OceanBase+OBServer），避免ETL延迟。
3）云原生环境
托管服务优先（Aurora、PolarDB），降低运维复杂度；自建环境可选TiDB（Kubernetes友好）。
4）跨境支付系统
需求：多区域低延迟、强一致性、反洗钱复杂查询。
推荐：CockroachDB（跨区域同步） + TiFlash（实时风控分析）。
5）证券交易平台
需求：微秒级延迟、高并发订单处理、审计合规。
推荐：OceanBase（蚂蚁集团实测P99延迟<10ms） + 列存引擎加速报表。
核心交易系统需严格串行化，OceanBase（蚂蚁集团生产验证）或TiDB（银行案例丰富）。
6）SaaS多租户数据库
需求：资源隔离、弹性扩缩容、多租户SQL隔离。
推荐：TiDB（资源组隔离） + Aurora Serverless（按需付费）。
7）物联网设备管理
需求：高吞吐写入、时序数据优化、设备状态实时查询。
推荐：YugabyteDB（PostgreSQL兼容） + TimescaleDB扩展（时序数据处理）。
5、大数据仓库
5.1 传统大数据仓库
| 技术 | 典型场景 | 优势 | 劣势 |
|---|---|---|---|
| Teradata | 超大规模数据仓库（PB级），需极致并行处理能力。 | 分布式架构，MPP（大规模并行处理）设计，线性扩展，优化器强大 | 封闭生态，依赖Teradata专用硬件和软件，成本高 |
| Exadata | 金融、电信等对事务一致性要求极高的行业，需兼容传统OLTP与OLAP。 | 高性能，硬件加速（如Infiniband网络、SSD缓存）。成熟生态 | 成本高，扩展性有限，依赖专用硬件，横向扩展复杂。 |
5.2 开源大数据仓库
| 技术 | 典型场景 | 优势 | 劣势 |
|---|---|---|---|
| Hive | 离线数仓（T+1报表） | 生态成熟（与Spark/Presto集成）、支持复杂SQL | 查询延迟高（分钟级）、不适合实时分析 |
| Druid | 实时OLAP，低延迟分析（秒级） | 实时摄入：支持Kafka、Kinesis等流数据源，列式存储+索引，分布式架构，自动分片。 | 功能有限，配置复杂，需理解Rollup和Segment管理。 |
| ClickHouse | 用户行为分析、广告投放效果监测 | 极速分析查询（比Presto快10-100倍）、支持实时更新 | 事务支持弱、高并发写入性能差 |
5.3 云原生数据仓库
| 技术 | 典型场景 | 优势 | 劣势 |
|---|---|---|---|
| Snowflake | 企业级数据分析（如Salesforce数据整合） | 全托管、弹性扩展、按需付费、支持多云、云原生数据仓库 | 成本高（数据导出收费）、云锁定风险 |
| Amazon Redshift | AWS生态内数据仓库，需深度集成云服务 | 性能优化：列式存储、压缩编码、查询优化器，与S3集成，成本可控 | 扩展性有限，锁入AWS， |
| Google BigQuery | 无服务器架构，需极致弹性和机器学习集成 | 完全无服务器，实时分析，AI集成 | 成本不可预测，生态局限 |
| Azure Synapse Analytics | 微软生态内数据仓库，需统一批流处理 | 混合架构，Power BI集成，安全性 | 性能一般，生态封闭 |
5.4 技术选型
1）传统行业（金融、电信）
优先选择Teradata或Oracle Exadata，满足高并发、低延迟和事务一致性需求。
2）互联网公司（实时分析）
离线批处理：Hive/Spark SQL + HDFS/S3。
实时OLAP：Druid/ClickHouse + Kafka。
全托管方案：Snowflake/BigQuery（降低运维成本）。
3）初创公司/中小企业
云原生数据仓库（Snowflake/Redshift）按需付费，快速启动。
4）成本敏感型
开源方案（Hive/Spark）自建集群，但需投入运维资源。
6、数据湖
| 技术 | 典型场景 | 优势 | 劣势 |
|---|---|---|---|
| Delta Lake | 高并发写入、历史版本回溯 | 完整ACID、时间旅行、Z-ordering优化 | 依赖Databricks生态，社区活跃度稍低 |
| Iceberg | 跨引擎查询、元数据集中管理 | 开源标准、多引擎支持、行级更新 | 社区成熟度待提升，功能迭代较慢 |
| Hudi | 实时数仓、CDC数据同步 | 增量处理、快照隔离、流式更新 | 学习曲线陡峭，配置复杂 |
| StarRocks | 高并发OLAP、低延迟查询 | 向量化执行、物化视图、实时分析 | 对非结构化数据支持有限 |
| Doris | 实时分析、用户行为分析 | 列式存储、CBO优化、多表关联加速 | 社区规模较小，功能迭代较慢 |
6.1 选型参考
1）优先开放生态
选择Delta Lake/Iceberg/Hudi等开放表格式，避免厂商锁定，支持多引擎协同。
若需同时使用Spark和Trino查询，优先选Iceberg。
2）实时性需求
流式更新场景选Hudi（如金融交易、物联网数据）。
微批处理选Delta Lake（如日志分析、用户行为数据）。
3）查询性能优先
复杂分析查询选StarRocks/Doris等MPP引擎，结合物化视图优化。
简单查询可依赖Trino+Iceberg的组合。
4）成本敏感型
云上选Snowflake（按需付费）或AWS Redshift Spectrum（结合S3）。
自建环境选Iceberg+Spark/Flink，降低许可证成本。
5）企业级需求
需完整ACID、细粒度权限控制选Databricks Lakehouse。
多云部署选Snowflake或StarRocks（支持K8s部署）。
7、时序数据库（时间序列数据）
| 技术 | 典型场景 | 优势 | 劣势 |
|---|---|---|---|
| InfluxDB | 监控告警（如Prometheus替代方案） | 高压缩比、支持连续查询（CQ）、内置可视化 | 集群版商业授权、分布式能力弱 |
| TimescaleDB | 金融时序数据（如股票行情） | SQL兼容、支持事务、时间分区优化 | 资源消耗高（PostgreSQL内核）、水平扩展需分片 |
| IoTDB | 工业设备监控（如风电场传感器数据） | 低存储成本（压缩率高）、支持复杂时序查询 | 生态局限（主要面向物联网场景）、社区规模小 |
| M3DB | 监控系统，大规模时序数据，日志分析，物联网（IoT），金融风控，A/B测试 | 高可扩展，低延迟查询，生态兼容，企业级功能 | 写入性能瓶颈，生态成熟度低，资源消耗，冷启动问题 |
物联网数据存储
存储：IoTDB（设备时序数据） + MinIO（图片/视频） + Flink（实时处理）。
理由：IoTDB针对物联网优化，MinIO兼容S3协议。
专用时序数据库：InfluxDB/TimescaleDB
大规模场景：OpenTSDB + HBase
8、技术选型指标
1）数据规模与增长速度
PB级：HDFS、Ceph、Snowflake（云原生弹性扩展）。
TB级：ClickHouse、Doris（单机性能强，集群成本低）。
高速增长：Cassandra（无单点瓶颈）、TiDB（自动分片）。
2）查询模式
实时点查：Doris（MPP架构）、TiDB（行存+索引）。
复杂分析：ClickHouse（列存+向量化）、Snowflake（分布式并行计算）。
全文检索：Elasticsearch（倒排索引）、Milvus（向量检索）。
3）一致性要求
强一致性：TiDB（Raft协议）、CockroachDB（分布式事务）。
最终一致性：Cassandra（多副本异步写入）、Ceph（CRUSH算法）。
4）成本敏感度
低成本开源：Hive（离线）、ClickHouse（实时）、MinIO（对象存储）。
全托管服务：Snowflake（数据仓库）、AWS S3+Glue（数据湖）。
5）生态集成
Hadoop生态：HDFS、HBase、Hive。
云原生生态：Snowflake、AWS Redshift、Google BigQuery。
实时流生态：Flink+Kafka+ClickHouse（实时数仓）。
（三）数据计算与处理（Processing）
目标：通过批处理或流计算提取价值。
批处理：MapReduce、Spark（DAG优化）、Hive（SQL-on-Hadoop）。
流处理：Flink（状态管理）、Spark Streaming（微批）、Storm（实时低延迟）。
混合处理（Lambda/Kappa架构）：结合批流一体化（如Flink）。
机器学习：Spark MLlib、TensorFlow on Spark（分布式训练）。
挑战：计算资源调度、状态一致性、反压机制（流处理）。
1、批处理框架（离线计算）
| 技术 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|
| Hadoop (MapReduce) | 超大规模数据离线处理（TB/PB级） | 高容错性、成熟生态（HDFS、Hive） | 延迟高（分钟级）、开发复杂 |
| Spark | 中大规模批处理（GB/TB级） | 内存计算（快10-100倍）、统一API | 内存消耗大、Shuffle成本高 |
| Flink (Batch模式) | 批流一体处理 | 统一批流API、低延迟 | 批处理优化不如Spark成熟 |
2、流处理框架（实时计算）
| 技术 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|
| Storm | 低延迟实时处理（毫秒级） | 真正实时、容错性强 | 状态管理复杂、资源利用率低 |
| Flink | 复杂事件处理（CEP）、有状态流计算 | 精确一次语义、状态后端优化 | 学习曲线陡峭 |
| Kafka Streams | 轻量级流处理（与Kafka集成） | 低延迟、无额外集群依赖 | 功能较基础、扩展性有限 |
| Spark Streaming | 微批处理（秒级延迟） | 与Spark生态无缝集成 | 延迟较高、状态管理较弱 |
3、AI机器学习计算
| 技术 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|
| Spark | 批处理、迭代计算（如机器学习训练） | 内存计算加速，支持SQL、流处理、图计算；生态丰富（MLlib、GraphX） | 实时性不足（微批处理）；内存消耗大，小数据场景效率低 |
| Ray | 分布式训练、强化学习、超参优化 | 原生支持Python，低延迟调度；适合动态计算图（如深度学习） | 生态较新，社区规模较小；大数据集成能力弱（需依赖其他工具） |
| Dask | Python生态的并行计算 | 与NumPy/Pandas无缝集成；适合中小规模数据并行化 | 分布式调度效率低于Spark；生产环境稳定性待验证 |
4、交互式查询引擎（OLAP分析）
| 技术 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|
| Hive (LLAP) | 离线SQL查询（TB级以上） | 与Hadoop集成、支持复杂SQL | 延迟高（分钟级） |
| Impala | 实时SQL查询（PB级） | 低延迟（秒级）、MPP架构 | 资源占用高、仅支持HDFS |
| Presto/Trino | 多数据源联邦查询 | 分布式执行、支持多种数据源 | 内存敏感、复杂查询不稳定 |
| Druid | 时序数据实时分析 | 列式存储、预聚合、低延迟 | 写入性能一般、不支持完整SQL |
| ClickHouse | 高并发实时分析（OLAP） | 列式存储、向量化执行、高性能 | 事务支持弱、生态较新 |
| Kylin | 固定维度报表、BI工具对接 | 查询延迟毫秒级，适合高并发报表。 | 预计算成本高，维度爆炸问题。不支持动态维度和实时更新。 |
交互式分析优先 Presto 或 ClickHouse
时序数据场景 → Druid 或 TimescaleDB
已有Hadoop生态 → Impala 或 Hive on Spark
5、搜索与分析
Elasticsearch
1）搜索引擎： 基于Lucene构建，提供全文检索、模糊匹配、相关性排序等能力。
2）典型场景：网站搜索、日志检索、日志分析、文档管理、实时监控、用户行为分析、安全事件分析、电商搜索。
3）分析引擎： 支持聚合查询（Aggregation）、时间序列分析、地理空间分析等OLAP功能。
大数据组件：分布式架构，可横向扩展至PB级数据。
4）实时性： 比Hadoop/Spark更接近实时，支持近实时（NRT, Near Real-Time）数据摄入与查询（延迟通常在1秒内），适合需要快速响应的场景。
5）灵活数据模型： 无需预定义Schema，支持动态字段，适合半结构化数据（如日志、JSON）。
6）高可用性： 内置副本与分片机制，支持跨数据中心部署。
7）生态集成： 与Logstash（数据采集）、Kibana（可视化）、Beats（轻量级传输）组成ELK栈，覆盖数据全生命周期。
8）局限性： 不适合复杂事务，高基数维度聚合性能下降，深度聚合查询成本高，存储成本较高
6、资源管理与调度
| 技术 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|
| YARN | Hadoop生态资源管理 | 成熟、支持多框架 | 配置复杂、静态资源分配 |
| Kubernetes | 云原生容器化调度 | 弹性伸缩、多租户支持 | 学习成本高、需适配大数据组件 |
| Mesos | 混合负载调度（大数据+AI） | 高效资源利用、支持多框架 | 生态较弱、维护成本高 |
云原生环境 → Kubernetes
传统Hadoop集群 → YARN
混合负载 → Mesos（或K8s替代）
7、图计算技术
7.1 分布式图处理框架（大规模图计算）
| 技术 | 适用场景 | 优势 | 劣势 | 算法支持 |
|---|---|---|---|---|
| Giraph | 超大规模图迭代计算（PB级） | 基于Hadoop/YARN、高容错性 | 开发复杂、仅支持BSP模型 | PageRank、连通分量、最短路径 |
| Pregel（Google） | 原始BSP模型提出者 | 模型简单、适合大规模迭代 | 闭源、依赖Google内部生态 | 同Giraph |
| Spark GraphX | 中大规模图计算（TB级） | 与Spark生态无缝集成、API丰富 | 内存消耗大、性能弱于专用框架 | 社区发现、图嵌入、标签传播 |
| Gemini（清华） | 超大规模图计算（万亿边） | 分布式优化、混合计算模型 | 学术性质强、商业支持弱 | 随机游走、图神经网络 |
| PowerGraph（GraphLab） | 高性能图计算（不规则图） | GAS模型优化、顶点切割技术 | 开发复杂、社区较小 | 矩阵分解、推荐系统 |
超大规模图（万亿边以上）：优先 Gemini 或 PowerGraph（需自研优化）
中大规模图（亿级顶点）：Spark GraphX（易用性优先）或 Giraph（低成本）
已有Spark生态：直接使用 GraphX 或 GraphFrames（SQL接口）
7.2 原生图数据库（实时图查询与更新）
| 技术 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|
| Neo4j | 中小规模实时图查询（亿级边）、金融反欺诈、知识图谱 | Cypher查询语言、ACID事务 | 分布式扩展性差、成本高 |
| JanusGraph | 分布式图数据库（千亿级边）、社交网络、推荐系统 | 支持多种存储后端（HBase、Cassandra）、开源生态 | 查询性能弱于专用数据库 |
| Nebula Graph | 超大规模实时图（万亿级边）、金融风控、物联网关系分析 | 分布式架构、共享内存优化、OLAP/OLTP混合 | 社区较新、学习成本高 |
| ArangoDB | 多模型数据库（图+文档+键值）、混合数据场景（如用户+订单关系） | 统一查询语言（AQL）、灵活模式 | 图功能不如专用数据库强大 |
| Dgraph | 高性能分布式图数据库、实时推荐、内容关联 | GraphQL-like查询、低延迟 | 生态较小、功能较基础 |
实时查询优先：Neo4j（单机）或 Nebula Graph（分布式）
低成本分布式：JanusGraph（基于HBase）
多模型需求：ArangoDB
7.3 图计算专用引擎（高性能迭代计算）
| 技术 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|
| Galois（Intel） | 异构计算加速（CPU/GPU） | 优化内存访问、并行图算法库 | 硬件依赖强、移植成本高 |
| Gunrock（NVIDIA） | GPU图计算（亿级边） | CUDA优化、高性能图遍历 | 仅支持NVIDIA GPU、算法覆盖有限 |
| Plato（腾讯） | 超大规模图计算（万亿级边） | 异步计算模型、分层压缩存储 | 闭源、定制化强 |
| HugeGraph（百度） | 分布式图计算与查询 | 兼容TinkerPop、低延迟查询 | 迭代计算性能一般 |
GPU加速需求：Gunrock（需NVIDIA GPU）
超大规模异步计算：Plato（需腾讯技术栈适配）
开源通用方案：HugeGraph（兼容TinkerPop生态）
7.4 技术选型
1）图规模与增长速度
万亿级边：优先分布式框架（Gemini/Nebula Graph）或专用引擎（Plato）
亿级边：图数据库（Neo4j/JanusGraph）或Spark GraphX
2）计算模式
迭代计算（如PageRank）：选择BSP/GAS模型框架（Giraph/PowerGraph）
实时查询（如路径查找）：选择图数据库（Neo4j/Nebula Graph）
混合负载：考虑OLTP+OLAP混合引擎（Nebula Graph）
3）硬件环境
GPU集群：Gunrock（图遍历）或Galois（异构计算）
CPU集群：Spark GraphX或Gemini
4）算法复杂度
简单遍历：通用框架均可支持
复杂图神经网络：需专用引擎（Plato）或深度学习框架集成（PyG+DGL）
5）团队技能
Java/Scala：Spark GraphX/JanusGraph
C++/Python：Gemini/Gunrock
Cypher/Gremlin：Neo4j/HugeGraph
8、选型因素
1）数据规模与增长速度
PB级超大规模：Hadoop/Spark + 对象存储（如S3）、Hadoop生态(HDFS+MapReduce/Hive)
GB级实时数据：Flink/Kafka Streams
TB-PB级：Spark/Flink + Parquet/ORC
TB级以下：可以考虑ClickHouse、Druid等专用OLAP引擎
2）延迟要求
实时(秒级以下)：Flink/Storm
准实时(分钟级)：Spark Streaming/Kafka Streams
分钟级以上：Hadoop/Hive
纯离线批处理：MapReduce/Spark
交互式分析：Presto/ClickHouse/Druid
3）团队技能
熟悉Java/Scala → Spark/Flink
偏好SQL → Presto/ClickHouse
云原生经验 → Kubernetes + Spark/Flink
4）成本
开源方案：Hadoop/Spark（需自运维）
托管服务：AWS EMR、Google Dataproc、阿里云MaxCompute
5）使用场景
ETL/数据清洗：Spark/Flink
机器学习：Spark MLlib/Flink ML
实时监控：Flink + Druid
用户行为分析：ClickHouse
图数据分析：Neo4j/GraphX
（四）数据治理（Governance）与质量控制
目标：确保数据可用性、合规性与安全性。
元数据管理：Apache Atlas（Hadoop生态）、DataHub（追踪数据血缘）、Collibra（商业工具）。
数据血缘：追踪数据来源与转换路径。
数据质量：校验规则、异常检测，规则引擎（Great Expectations）、数据清洗（OpenRefine）。
安全合规：Kerberos认证、数据脱敏（ProxySQL）、Ranger/Sentry（细粒度权限控制）、GDPR合规。
挑战：跨系统元数据同步、质量规则动态更新。
1、工作流编排
| 工具 | 类型 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|---|
| Airflow | 批处理/轻量流 | 离线ETL、机器学习流水线 | Python原生支持、插件生态丰富、社区活跃 | 资源调度依赖外部（如Celery/K8s）、实时性较弱 |
| Oozie | 批处理（Hadoop） | 传统Hadoop生态离线任务 | 与Hadoop深度集成、XML配置稳定 | 配置复杂、学习曲线陡峭、社区萎缩 |
| Azkaban | 批处理 | 小规模Hadoop任务调度 | 轻量级、依赖管理简单、Web界面友好 | 功能单一、扩展性差、社区不活跃 |
| Workflows | 云原生（K8s） | 云上机器学习、复杂批处理 | 原生K8s支持、声明式编排、强类型检查 | 学习成本高、需K8s基础、实时任务支持有限 |
| Step Functions | 云原生（AWS） | AWS生态内的复杂工作流 | 全托管、与AWS服务无缝集成、可视化设计 | 厂商锁定、成本较高、非AWS服务支持差 |
| NiFi | 可视化流处理 | 实时数据管道、简单ETL | 拖拽式界面、数据血缘追踪、实时流处理 | 性能瓶颈明显、批处理能力弱、集群管理复杂 |
| Kubeflow Pipelines | 机器学习专用 | ML模型训练与部署流水线 | 与K8s/TFX集成、实验跟踪、可复现性 | 仅聚焦机器学习、学习曲线陡峭 |
1.1 技术选型
1）数据规模与实时性
小规模离线：Airflow/Azkaban（低成本、易上手）。
大规模实时：NiFi（流处理） + Flink（计算） + Airflow（调度）。
云原生环境：Argo/Step Functions（弹性资源利用）。
2）技术栈兼容性
Hadoop生态：Oozie（若已深度使用）、Airflow（替代方案）。
Python/ML：Airflow、Kubeflow Pipelines。
K8s环境：Argo、Kubeflow。
3）运维复杂度
低运维需求：云原生服务（Step Functions、Glue）。
高可控性：自托管Airflow/Argo（需投入运维资源）。
4）成本考量
开源免费：Airflow、Argo、NiFi（需自建集群）。
按需付费：Step Functions、Glue（适合波动负载）。
1.2 参考方案
1）传统大数据团队
方案：Airflow（调度） + Spark（计算） + HDFS/S3（存储）。
理由：平衡功能与成本，Python生态支持机器学习扩展。
2）实时数据处理场景
方案：NiFi（数据采集） + Flink（流计算） + Airflow（批处理补数）。
理由：NiFi简化实时管道搭建，Flink处理低延迟需求。
3）云原生机器学习
方案：Kubeflow Pipelines（训练） + Argo（批处理） + Step Functions（事件驱动）。
理由：利用K8s弹性资源，避免厂商锁定（可混合使用开源工具）。
4）快速原型开发
方案：NiFi（可视化） + AWS Glue（Serverless ETL）。
理由：降低开发门槛，快速验证业务逻辑。
2、数据治理工具
| 工具 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|
| Atlas | Hadoop/Spark环境下的数据治理 | 开源、与Hadoop生态深度集成，支持元数据管理和血缘分析 | 社区支持为主，企业级功能需二次开发 |
| Collibra | 金融、医疗等强合规行业 | 商业化产品，提供数据目录、血缘、权限管理，用户界面友好 | 成本较高，定制化需额外服务 |
| Alation | 数据资产盘点、数据文化培育 | 基于AI的元数据管理，支持自然语言查询，自动化数据发现 | 对非结构化数据支持较弱 |
| Amazon Glue | AWS云环境下的数据治理 | 云原生服务，与AWS生态无缝集成，支持数据目录和ETL | 依赖AWS，迁移成本高 |
| Informatica | 已使用Informatica生态的企业 | 端到端解决方案、与ETL工具集成好 | 功能臃肿、学习曲线陡 |
2.1 数据目录
开源方案：DataHub(LinkedIn)、Amundsen(Lyft)、Marquez
优点：成本低、可定制
缺点：需要技术团队维护
商业方案：Alation、Collibra、IBM Watson Knowledge Catalog
优点：功能全面、支持完善
缺点：许可成本高
3、数据质量控制工具
| 工具 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|
| Great Expectations | 实时/批量数据质量校验 | 开源、轻量级，支持Python规则编写，可集成到数据管道 | 规则配置需编码，学习曲线较陡 |
| Informatica DQ | 企业级数据质量监控，支持多数据源 | 商业化产品，提供可视化规则配置、数据剖析、质量评分 | 成本高，部署复杂 |
| Deequ (AWS) | 批处理数据质量校验 | 基于Spark的开源库，支持自动化数据质量测试，适合大规模数据处理 | 需Spark环境，流处理支持有限 |
| Talend | 数据清洗与质量监控一体化 | 商业化ETL工具，集成数据质量模块，支持可视化规则配置 | 社区版功能有限，企业版成本较高 |
| Monte Carlo | 金融衍生品定价，风险评估，投资决策，机器学习，计算机图形学，药物试验设计，游戏AI | 通用性强，处理高维问题，并行化友好，直观易实现，不确定性量化 | 收敛速度慢，随机性依赖，计算资源消耗，方差控制困难 |
3.1 技术选型
1）按场景选择
Hadoop/Spark生态：Apache Atlas（治理） + Deequ（质量）、Airflow + Great Expectations
实时数据场景：流式架构+Deequ或Monte Carlo、Flink + Deequ + Prometheus
云环境：AWS Glue（治理） + Great Expectations（质量）。
金融/医疗行业：Collibra（治理） + Informatica DQ（质量）、Collibra+Informatica，满足合规要求
互联网企业：开源组合Atlas+Great Expectations，适应快速变化
传统企业：SaaS化解决方案如Alation，降低技术门槛
2）成本与扩展性平衡
初创企业：开源工具（Atlas + Deequ）降低成本，但需投入开发资源。
大型企业：商业化工具（Collibra + Informatica）快速落地，但需评估长期成本。
3）技术栈整合
优先选择与现有技术栈（如Spark、Flink、Kafka）兼容的工具，减少集成成本。
例如：若使用Databricks，可结合Delta Lake的ACID特性与Great Expectations进行质量校验。
4）合规与安全
涉及敏感数据时，选择支持数据脱敏、审计日志的工具（如Collibra、Informatica）。
4、认证技术
| 技术 | 类型 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|---|
| Kerberos | 传统协议 | 传统大数据集群（CDH/HDP） | 与Hadoop生态深度集成（如HDFS、Hive）、单点登录（SSO） | 配置复杂、密钥管理困难、不支持细粒度授权 |
| OAuth 2.0/OIDC | 现代协议 | 微服务架构、跨域认证 | 标准化、支持第三方登录、JWT令牌轻量级 | 需结合其他工具实现授权、令牌泄露风险 |
| LDAP/Active Directory | 目录服务 | 企业内部用户目录 | 集中管理用户/组、与Windows生态无缝集成 | 扩展性差、不支持动态策略 |
| SPIFFE/SPIRE | 服务间认证 | 云原生环境（K8s） | 为容器/微服务提供自动化的身份颁发、支持mTLS | 学习曲线陡峭、社区较小 |
| AWS IAM/Azure AD | 云原生身份管理 | 云上大数据服务（EMR、Databricks） | 全托管、与云服务深度集成、支持细粒度策略 | 厂商锁定、成本较高 |
5、授权技术
| 技术 | 类型 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|---|
| Ranger | 集中式授权 | HDFS、Hive、HBase等组件的权限管理 | 与Hadoop生态集成、支持RBAC/ABAC、审计日志 | 仅限Hadoop生态、性能瓶颈 |
| Sentry | 组件级授权 | 遗留Hive环境（需替代时建议迁移至Ranger） | 为Hive/Impala提供细粒度SQL权限控制 | 功能单一、已停止维护 |
| Open Policy Agent (OPA) | 策略引擎 | 云原生大数据（K8s上的Spark/Flink） | 声明式策略、支持多环境（K8s、大数据）、动态授权 | 需自行集成、策略编写复杂 |
| Keycloak | 身份与访问管理 | 中小规模大数据平台的认证授权中心 | 开源替代Okta/Auth0、支持OAuth 2.0/OIDC、RBAC/ABAC策略 | 需自行运维、大数据生态集成较弱 |
| AWS Lake Formation | 云数据湖授权 | AWS数据湖（S3+Athena） | 与AWS Glue/S3无缝集成、基于标签的动态访问控制 | 仅限AWS生态、成本高 |
6、加密与审计
| 技术 | 类型 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|---|
| HDFS Transparent Encryption | 存储加密 | 传统Hadoop集群数据加密 | 透明加密、与Kerberos集成 | 仅限HDFS、性能损耗 |
| KMS（HashiCorp Vault/AWS KMS） | 密钥管理 | 跨平台密钥管理 | 集中管理密钥、支持自动轮换、审计日志 | 需与存储/计算层集成 |
| Atlas | 数据血缘与分类 | 数据分类与合规审计 | 与Ranger集成实现基于标签的授权、元数据管理 | 配置复杂、需结合其他工具使用 |
| ELK Stack | 日志审计 | 访问日志审计与安全分析 | 集中化日志分析、可视化告警、支持合规报告生成 | 需自行配置存储周期、大数据量下性能优化 |
6.1 技术选型
1）生态兼容性
Hadoop生态：优先选择Ranger（授权）+ Kerberos（认证）+ Atlas（审计）。
云原生环境：OPA（策略）+ SPIRE（服务认证）+ KMS（加密）。
混合云：Keycloak（统一认证） + OPA（跨云授权）。
2）合规要求
GDPR/CCPA：需支持数据最小化、动态脱敏（如Ranger标签策略）。
金融行业：强制多因素认证（MFA）+ 细粒度审计（ELK+Atlas）。
医疗行业：端到端加密（KMS） + 基于角色的强制访问控制（RBAC）。
3）性能与扩展性
高并发场景：避免Kerberos（单点瓶颈），改用OAuth 2.0/JWT。
大规模策略：OPA（策略引擎）优于Ranger（数据库存储策略）。
4）运维成本
全托管服务：AWS IAM/Lake Formation（降低运维负担，但成本高）。
开源自研：Ranger+OPA（需投入开发资源，但灵活可控）。
6.2 参考方案
1）传统Hadoop集群（CDH/HDP）
认证：Kerberos（基础认证） + LDAP（用户目录）。
授权：Apache Ranger（RBAC/ABAC策略）。
加密：HDFS透明加密 + KMS（密钥管理）。
审计：Ranger审计日志 + ELK（可视化分析）。
理由：深度集成Hadoop生态，满足等保2.0三级要求。
2）云原生大数据（K8s+Spark/Flink）
认证：SPIRE（服务间mTLS认证） + OAuth 2.0（用户认证）。
授权：Open Policy Agent（OPA，动态策略）。
加密：云KMS（如AWS KMS） + 传输层TLS。
审计：Fluentd（日志收集） + ELK（分析）。
理由：支持动态扩缩容，避免单点故障。
3）混合云多数据源
认证：Keycloak（统一身份中心） + SAML（跨域SSO）。
授权：OPA（统一策略引擎，覆盖HDFS/S3/Snowflake）。
加密：HashiCorp Vault（跨云密钥管理）。
审计：Atlas（数据血缘） + ELK（合规报告）。
理由：避免厂商锁定，满足跨云合规需求。
4）金融行业高安全场景
认证：Kerberos（强认证） + MFA（短信/OTP）。
授权：Ranger（细粒度SQL权限） + 动态脱敏（基于标签）。
加密：HSM（硬件安全模块） + 传输层国密算法。
审计：实时告警（Splunk） + 司法取证链。
理由：满足PCI DSS、银保监会等严苛要求。
（五）数据分析（Analysis）与挖掘
目标：从数据中提取洞察并支持决策。
可视化：Tableau、Power BI、Superset、Grafana（实时监控）
交互式分析：Presto、Impala（MPP架构）、Druid（OLAP）、ClickHouse（列式数据库）。
预测性分析：时间序列预测（Prophet）、回归模型（Scikit-learn）。
规范性分析：优化算法（线性规划、遗传算法）。
机器学习AI/ML：Spark MLlib、深度学习（PyTorch、TensorFlow）分布式训练、AI模型服务MLflow/Kubeflow。
挑战：模型可解释性、特征工程自动化、A/B测试验证
1、AI机器学习
| 技术 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|
| Scikit-learn | 传统机器学习（分类、回归、聚类） | 简单易用，API统一 | 不支持分布式训练；大数据场景性能差 |
| TensorFlow | 图像、NLP、序列模型等复杂任务 | 生产级深度学习，支持分布式训练 | 调试复杂，动态图模式性能较低；移动端部署需优化 |
| PyTorch | 快速原型开发、研究实验 | 动态计算图，研究友好 | 生产部署工具链不如TensorFlow成熟 |
| XGBoost/LightGBM | 结构化数据建模（如CTR预测、风控） | 高性能梯度提升树，支持并行化 | 需预处理数据为特征矩阵；对类别特征支持有限 |
| H2O.ai | 企业级自动化建模，支持SQL集成 | 自动机器学习（AutoML），分布式支持 | 深度学习支持较弱；开源版功能受限 |
| Spark MLlib | 大规模机器学习（如推荐系统） | 与Spark无缝集成、支持分布式训练 | 算法覆盖有限、性能不如专用框架 |
| Hugging Face | NLP预训练模型（如BERT） | 开箱即用、模型库丰富 | 依赖GPU资源、定制化成本高 |
| MLflow | 端到端的机器学习模型管理平台，中小规模模型开发，模型实验与对比 | 轻量级与灵活性，模型管理闭环，生态兼容 | 分布式训练支持有限，流水线自动化不足，生产级部署需额外工具 |
| Kubeflow | 基于Kubernetes的云原生机器学习平台，大规模分布式训练，复杂工作流编排，生产环境高可用 | 云原生与弹性，端到端自动化，企业级特性，生态整合 | 学习曲线陡峭，资源消耗大，灵活性受限 |
1.1 技术选型
1）数据规模与类型
小数据（<1TB）：Scikit-learn + Pandas
大数据（>1TB）：Spark MLlib + HDFS/Delta Lake
结构化数据：XGBoost/LightGBM + Featuretools（特征工程）
非结构化数据：TensorFlow/PyTorch + Horovod（分布式训练）
2）模型复杂度
传统ML：Scikit-learn/XGBoost
深度学习：TensorFlow/PyTorch + Ray/Horovod
AutoML：H2O.ai/TPOT
3）成本与团队技能
Python生态优先：Dask/PyTorch
Java/Scala生态：Spark/Flink
云原生：AWS SageMaker/Google Vertex AI
4）实时性
批处理：Spark
微批处理：Spark Streaming
真流处理：Flink + Kafka
离线批处理：S3/HDFS → Spark ETL → Delta Lake（训练） → Spark MLlib/XGBoost → 模型服务（Flask/TF Serving）
实时流处理：Kafka（实时特征）→ Flink Streaming（特征计算） → Flink ML/TensorFlow Serving → 实时决策
模型更新：Airflow调度周期性重训练
2、数据可视化与报表
| 技术 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|
| Tableau | 交互式商业分析、业务报表、仪表盘 | 拖拽式操作、可视化效果好 | 成本高、定制化能力有限 |
| Power BI | 微软生态集成、企业内部数据分析 | 与Excel/Azure无缝衔接 | 复杂分析支持较弱 |
| Superset | 开源可视化、初创公司、数据探索 | 免费、支持多种数据库 | 功能较基础 |
| Metabase | 轻量级自助分析、中小团队、快速原型 | 部署简单、支持SQL查询 | 高级图表类型少 |
| D3.js | 高度定制化可视化、复杂数据叙事、交互式图表 | 灵活性极高 | 开发成本高 |
（六）数据服务与应用（Application）
目标：将数据价值嵌入业务场景，推荐系统、风控模型、实时大屏、BI报表。
API服务：RESTful API、GraphQL（灵活查询）。
实时推荐：协同过滤、嵌入向量检索（FAISS）。
风险控制：规则引擎（Drools）、实时决策（Flink CEP）。
挑战：服务高可用、API版本管理、性能监控。
1、大数据监控
1.1 日志监控
| 技术 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|
| ELK Stack (Elasticsearch + Logstash + Kibana) | 日志分析、全文检索、可视化探索 | Elasticsearch：分布式搜索引擎，支持近实时检索和聚合分析。Kibana：强大的可视化工具，支持自定义仪表盘。生态成熟，社区活跃。 | 资源消耗高（尤其Elasticsearch的JVM和内存）。实时性有限，复杂查询可能影响性能。 |
| Splunk | 企业级日志管理、安全信息与事件管理（SIEM） | 全功能一体化平台，开箱即用。强大的关联分析和机器学习告警。 | 商业软件，成本高，扩展性依赖硬件资源。 |
参考方案：
EFK Stack：用Fluentd替代Logstash（轻量级、插件丰富）。
Loki + Grafana：轻量级日志聚合（基于标签索引，适合K8s环境）。
1.2 时序数据（指标监控）
| 技术 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|
| Prometheus + Grafana | 云原生监控、K8s指标采集、告警 | 多维数据模型（标签化指标），灵活查询（PromQL）。主动拉取模式（Pull-based），适合动态环境。集成Alertmanager实现告警管理。Grafana提供丰富可视化。 | 长期存储需依赖TSDB（如Thanos、VictoriaMetrics）。不适合高基数指标（如大量唯一ID） |
| OpenTelemetry + Jaeger/Zipkin | 分布式追踪（Trace）、链路监控 | 统一标准（OpenTelemetry合并OpenTracing和OpenCensus）。Jaeger/Zipkin提供可视化链路分析 | 需配合指标监控（如Prometheus）形成完整可观测性 |
参考方案：
InfluxDB + Telegraf + Grafana：InfluxDB支持高吞吐写入，Telegraf轻量级采集。
TimescaleDB：PostgreSQL的时序扩展，适合需要SQL的场景。
1.3 监控告警系统
| 技术 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|
| Alertmanager | 与Prometheus集成的告警管理 | 支持分组、抑制、静默等高级路由策略。通知渠道丰富（邮件、Webhook、Slack等） | 依赖Prometheus生态 |
| Zabbix | 传统IT基础设施监控（服务器、网络设备） | agent-based采集，支持自动发现。内置告警和可视化 | 扩展性有限，不适合大规模分布式系统 |
1.4 云服务监控
AWS CloudWatch
Azure Monitor
Google Cloud Operations Suite
2、技术选型
1）数据类型
日志监控： ELK Stack/EFK或Loki；或Splunk(如有预算)
指标监控： Prometheus+Grafana或InfluxDB方案
链路监控： OpenTelemetry + Jaeger。
混合监控(日志+指标)： ELK + Prometheus组合 或 商业云服务
2）实时性要求
毫秒级：Flink或Kafka Streams。
秒级：Prometheus或Spark Streaming。
3）规模与成本
小规模：Prometheus + Grafana（开源免费）。
企业级：Splunk或Datadog（商业支持）。
4）云原生环境
优先选择K8s原生工具（如Prometheus Operator、Thanos）；Prometheus+Grafana或对应云服务商方案。
3、架构示例
1）日志监控
Fluentd/Filebeat → Kafka → Logstash → Elasticsearch → Kibana
2）指标监控
Prometheus (Pushgateway/Node Exporter) → Alertmanager → Grafana
3）链路追踪
OpenTelemetry SDK → Jaeger Collector → Jaeger Query + UI
二、大数据架构分类
（一）Lambda分层架构（批流一体过渡方案）
1、层级划分
1）批处理层（Batch Layer）
使用HDFS 、Hive、 Spark处理历史数据，生成批视图。
2）速度层（Speed Layer）
使用Flink/Kafka处理实时数据，生成流视图。
3）服务层（Serving Layer）
合并批流结果（如通过Druid或Redis、HBase/Cassandra），供应用查询。
优势：兼顾准确性与实时性。
缺陷：代码重复、维护复杂。
2、架构示例
案例一：用户转化漏斗分析
案例二：电商实时用户行为分析
（二）Kappa架构（纯流式处理）
仅依赖流处理（如Flink），通过重放日志（Kafka）替代批处理。
数据湖仓一体化（Lakehouse）：
结合数据湖的灵活性和数据仓库的管理能力（如Databricks的Delta Lake）。
优势：简化架构、避免数据同步问题。
挑战：历史数据回溯需依赖消息队列的持久化存储。
案例一：电商实时推荐系统
案例二：金融风控实时反欺诈
（三）云原生+开源
采集：Kafka + Debezium（CDC变更数据捕获）。
存储：S3/GCS/OSS（对象存储）+ Iceberg/Hudi（数据湖表格式）。
计算：Serverless计算（AWS Lambda）、弹性Spark/Flink集群（EMR/Dataproc）、Trino交互查询。
治理：Amundsen（元数据） + Great Expectations（质量）。
编排：Kubernetes（Spark on K8s）、Airflow（工作流调度）。
服务：GraphQL API + Prometheus（监控）。
优势：弹性扩展、成本优化、生态开放。
案例1：实时风控系统
数据流：
用户行为日志 → Kafka → Flink（实时规则引擎） → Redis（风险名单） → 微服务拦截。
技术栈：
Kafka + Flink + Redis + Prometheus（监控QPS/延迟）。
案例2：用户画像分析
数据流：
多源数据（MySQL/Hive）→ Spark（ETL）→ Iceberg（数据湖）→ Presto（交互查询）→ Superset（可视化）。
技术栈：
Debezium + Spark + Iceberg + Presto + Superset。
案例3：AI模型训练与部署
数据流：
训练数据（MinIO）→ Spark（特征工程）→ Kubeflow（分布式训练）→ MLflow（模型管理）→ Triton（推理服务）。
技术栈：
MinIO + Spark + Kubeflow + MLflow + Triton。
三、不同场景组合
1、传统大数据平台
采集：Flume/Sqoop + Kafka
存储：HDFS/HBase
计算：Spark/Flink
2、离线数仓（T+1报表）
方案：Hive（存储） + Spark（ETL） + Presto（交互查询）。
3、实时数仓（秒级响应）
方案：Kafka（数据源） + Flink（实时计算） + Doris/ClickHouse（存储分析）。
理由：Doris支持高并发点查，ClickHouse擅长复杂聚合。
4、实时分析平台
采集：Kafka Connect + Debezium
处理：Kafka Streams/Flink
存储：ClickHouse/Druid
5、实时推荐系统
采集：Kafka
流处理：Flink（状态管理+CEP）
存储：Redis（实时特征） + HBase（用户画像）
查询：Presto（交互式分析）
6、云原生数据湖
采集：Kinesis/Firehose (AWS) 或 EventHub (Azure)
存储：S3/ADLS + Delta Lake/Iceberg
计算：EMR/Databricks
7、电商交易系统
订单存储：MongoDB/MySQL分库分表
商品缓存：Redis
用户推荐：图数据库
数据分析：数据仓库+BI工具
8、电商实时用户行为分析
采集：Flume（日志） + Flink CDC（MySQL订单数据） → Kafka
处理：Flink/Spark Streaming实时计算 + ClickHouse/Druid(OLAP)存储。
服务：Redis(热数据缓存)
9、用户行为分析
组合1：ClickHouse（事件数据） + Elasticsearch（全文检索） + Superset（可视化）。
组合2：S3 + Spark + Presto + Superset。
组合3：
数据采集：Flume/Logstash
存储：HDFS（原始日志） + Druid（时序聚合）
查询：ClickHouse（高并发点查）
10、实时风控系统
Kafka + Flink + Cassandra + Redis
11、金融风控
采集：Canal（MySQL交易数据）
流处理：Flink（精确一次语义）
规则引擎：Drools
存储：Kafka（实时事件） + HBase（风控规则）
12、金融交易系统
方案：TiDB（核心交易） + Cassandra（日志存储） + Flink（实时风控）。
理由：TiDB强一致性，Cassandra高可用写入。
13、金融反欺诈（实时关联分析）
存储：Nebula Graph（万亿级关系图）
查询：Cypher或Gremlin（多跳路径查询）
批处理：Spark GraphX（定期风险模型计算）
14、海量日志分析
存储：HDFS + Parquet/ORC
计算：Spark/Hive
检索：Elasticsearch(如需全文检索)
15、AI推荐引擎
HDFS + Spark MLlib + TensorFlow + Kubernetes。
16、社交网络推荐（大规模图计算）
迭代计算：Plato（异步PageRank）或Gemini（随机游走）
实时推荐：JanusGraph + Elasticsearch（近似最近邻搜索）
图嵌入：PyG（PyTorch Geometric）集成Spark
17、生物信息学（蛋白质折叠预测）
图神经网络：Gunrock（GPU加速分子图遍历） + DGL（深度学习）
分布式训练：Horovod + Spark（多节点同步）
