日志数据导入大数据平台需按采集、传输、清洗、入库链路设计，匹配实时性、结构化与成本需求：依来源选采集方式（Filebeat/K8s CRD/Winlogbeat/ES直连/OTel），依场景选路径（Kafka-Flink实时、HDFS-Hive离线、DataHub双写），清洗强调字段提取、编码统一、空值治理与会话关联，存储分热（ES/Doris）、温（Hive ORC/Parquet）、冷（OSS/S3）三层。
日志数据导入大数据平台，关键不是“一次性搬进去”，而是按采集、传输、清洗、入库的链路设计，匹配业务对实时性、结构化程度和存储成本的要求。
根据日志来源选采集方式
源头不同，接入路径差异明显：
- 服务器文件日志（如Nginx、Java应用log）：用轻量采集器（Filebeat / Logtail / LoongCollector）监听目录，自动发现新文件并增量读取，支持JSON、分隔符等格式解析
- Kubernetes容器日志：优先通过CRD配置采集规则，统一收集stdout/stderr或挂载卷中的文本日志；标准输出可直接结构化，文件日志需额外做行首时间戳识别
- Windows事件日志：用专用采集器（如Winlogbeat）订阅Event Log API，避免轮询开销
- 已存ES的日志：跳过采集层，直接配置ES作为数据源，通过Logstash或Flink CDC读取索引快照或变更日志
- 自研应用日志：集成OpenTelemetry SDK，在代码中打点上报结构化日志（含trace_id、span_id），天然适配流式处理
按处理需求选传输与写入路径
不是所有日志都走同一条路，要区分场景：
- 需要实时分析（如告警、大促监控）：日志 → Kafka/DataHub → Flink/Spark Streaming → 实时数仓（如Doris、StarRocks）或ES
- 离线分析为主（如用户行为归因、月度报表）：日志 → HDFS/S3（原始层）→ Hive/Spark SQL清洗 → ODS/DWD分层表
- 兼顾实时+离线：用DataHub或SLS LogHub统一接入，下游分别投递到实时计算引擎和MaxCompute/OSS
- 已有ELK体系想对接大数据平台：Logstash或Logstash JDBC output插件，将Elasticsearch查询结果导出为Parquet，再Load进Hive
结构化与清洗是入库前提
原始日志多数是非结构化的，直接入库会极大增加后续分析难度：
- 字段提取：用正则或Grok模式从文本中抽时间、IP、状态码、耗时等；JSON日志可直接映射为Schema
- 编码与乱码处理：统一转UTF-8，过滤控制字符，替换不可见符号
- 空值与异常值治理：补全缺失字段（如默认user_id=“unknown”），剔除明显错误行（如时间戳为0001-01-01）
- 会话/事务关联：基于session_id或trace_id聚合多条日志，生成宽表（如pageview + visit + user_profile拼接）
存储层适配要考虑冷热与成本
大数据平台不等于“全存HDFS”，要分层管理：
- 热数据（7天内高频查询）：存ES或Doris，支持毫秒级全文检索与聚合
- 温数据（1–90天明细分析）：存Hive ORC/Parquet格式，按date、app、region分区，配合压缩（ZSTD推荐）
- 冷数据（90天以上归档）：转为LZ4压缩后存OSS/S3，保留元数据供必要时回溯
- 高价值指标（如错误率、转化率）：预计算后存MySQL或Redis，供BI系统直连
