企业官网建设流程全解析

Big Data大数据这五个字，落在招聘网站上金光闪闪，落在生产环境里往往是一地鸡毛。我做大数据平台开发这些年，最常被问的一句话是：你们到底在做什么？我的回答一般很短：把散落在各个业务系统的数据收进来、洗干净、算明白、存得住，最后让产品和运营能随时查。听起来不复杂，真正把这条链路跑稳定，踩过的坑比写过的代码还多。

这篇文章就围绕我这边实际落地过的一套大数据处理平台来说，不聊那些PPT里的概念，只讲从选型到上线、从采集到查询、从质量到排查的具体做法。适合正在搭平台、或者刚接手大数据项目不久的朋友参考。哪怕你现在团队只有两三个人，这套思路也能直接搬过去用。

1. 项目整体规划与技术选型

1.1 需求边界：别一上来就整湖仓一体

很多团队一说要做大数据，第一反应就是把市面上所有热门组件全上一遍，数据湖、湖仓一体、流批一体、实时数仓全堆上去。结果集群开了一堆，每天处理的数据量还没日志量大，运维成本倒是先上去了。

我刚做这个项目时，第一步不是选技术，而是拉着业务方把需求边界划清楚。核心就三个问题：

• 数据量到底多大？日增量是百万级还是亿级？
• 时效性要求多高？是T+1报表，还是分钟级大屏，还是秒级实时推荐？
• 查询场景是什么？是固定报表、明细查询，还是多维分析？

当时业务方的回答是：日增数据千万级，离线报表T+1可以接受，但有一个核心大屏需要分钟级延迟，还要支持运营自助查数。明确了这三点之后，架构方案就清晰了：离线链路负责T+1报表和宽表加工，实时链路只接最核心的几条流，查询层单独上OLAP引擎。没有去做全链路实时化，因为没必要。

1.2 技术栈选型的底层逻辑

选型不是看谁火，而是看团队能不能扛住。我当时的判断标准有三条：社区活跃度、团队熟悉度、运维成本。基于这个标准，最终选了这样一套组合：

• 采集层：业务库用Debezium做CDC实时同步，离线历史数据用DataX批量拉取，日志类数据走Kafka接入。
• 存储层：HDFS做离线数仓底座，Kafka做实时消息缓冲。
• 计算层：离线加工用Hive和Spark，实时计算用Flink，调度用DolphinScheduler。
• 查询层：Doris做OLAP查询引擎，覆盖大屏和自助分析。

有人会问，为什么不用更时髦的组件？原因很简单：这套组合在网上随便一搜就能找到大量踩坑经验，团队里每个人都至少能上手两个组件。技术选型最怕的不是“不够先进”，而是出了问题没人能解决。等业务量真到了需要升级架构那一天，再引入新的组件不迟，前期先用最稳的组合把链路跑通。

1.3 为什么没有一开始就上湖仓一体

湖仓一体听起来很美，但落地时对存储、元数据、权限体系的复杂度要求很高。小团队贸然上手，很容易陷入“湖不是湖、仓不是仓”的尴尬局面。我的做法是：先把离线数仓的分层模型做好，再把实时链路复用同一套主题模型，等到后续确实需要数据湖的灵活性了，再逐步演进。

这个选择让项目前两个月就能交出可用结果，而不是半年过去还在搭底座。

2. 数据采集与存储层搭建

2.1 业务数据入仓的三种方式

数据进数仓，绕不开三种来源：业务数据库、日志文件、第三方接口。我当时的处理方式是这样的：

业务库实时同步用Debezium监听binlog，解析成统一格式后写入Kafka，再由Flink消费到Doris和HDFS。这里有个细节：Debezium的schema变更要提前处理，否则上游加一列，下游解析就会报错。我在同步任务里加了schema版本字段，消息体里带版本号，下游根据版本号做兼容解析，避免上游变更直接打挂任务。

离线历史数据用DataX做批量同步，这个工具胜在稳定，什么库都能接，而且限流参数很好用。我习惯在同步任务里设置channel为3到5，speed控制在每秒3000条左右，既不会压垮源库，也能在合理时间内完成同步。

日志类数据走Filebeat收集到Kafka，这里最容易被忽略的是日志编码和时区问题。之前遇到过日志里时间字段是UTC，下游统计却按本地时间算，结果每天的数据都偏了8个小时。后来统一在采集端就把日志时间转换成标准格式，并且显式带上时区信息，才算彻底解决。

2.2 离线数仓的分层与分区策略

离线数仓我按经典的四层来建：ODS、DWD、DWS、ADS。ODS存原始数据，保持和源系统一致，不做任何加工；DWD做清洗、去重、维度退化，形成明细事实表；DWS按业务主题做汇总，比如用户主题、订单主题；ADS面向具体报表需求，比如大屏指标、运营看板。

存储格式上，ODS层可以保留原始格式便于排查，DWD及以上统一用Parquet列式存储，配合Hive分区表。分区字段的选择直接影响查询效率，我通常按天分区加业务维度分区，比如订单表用dt做天分区，再用region_id做二级分区。这样查询时能直接裁剪分区，避免全表扫描。

这里要强调一个坑：小文件问题。如果每五分钟跑一次写入任务，一天下来会产生大量几十KB的小文件，NameNode内存会被撑爆，查询性能也会直线下降。解决思路是在写入后做一次文件合并操作，或者控制任务产出频率，尽量让每个分区的文件数量保持在合理范围。我的经验是：离线表单个文件控制在128MB到256MB之间，查询性能和存储利用率最平衡。

2.3 Kafka的Topic规划和分区数设置

Kafka是整个实时链路的主动脉，Topic规划不好，后面全乱。我给Topic命名的规范是业务线_数据域_主题_格式，比如order_dwd_detail_json，一眼就能看出是订单域明细数据、JSON格式。分区数不是越大越好，我按消费端的并行度和生产速率来定，一般一个Topic分区数是3到6之间。分区数太少，消费并发上不去；分区数太多，rebalance和元数据压力都会变大。

写入Kafka时，key的选择也要讲究。需要保证同一订单ID的变更消息有序，就用订单ID作为key；如果只是日志类数据，就不需要key，轮询写入即可。这块经验是，key设计直接影响Flink消费时状态是否正确，尤其做累计统计时，乱序会导致结果对不上。

3. 离线与实时计算链路详解

3.1 离线ETL：Hive和Spark怎么配合

离线链路里，Hive和Spark不是替代关系，而是各干各的活。简单的SQL加工、数据模型开发，我会用Hive跑，写起来快，排查也方便。复杂的多表关联、大数据量清洗、自定义UDF逻辑，用Spark跑，性能能提升一个量级。

举个例子，DWD层的事实表加工涉及订单、支付、退款三张表关联，数据量上亿，用Hive跑要四十分钟，换Spark之后十分钟出头。Spark SQL基本兼容Hive的语法，改造工作量不大，但要注意小文件问题，因为Spark写入时的task数量多，很容易写出几百个小文件。我的做法是写完后执行一次INSERT OVERWRITE ... SELECT ... DISTRIBUTE BY，让数据重新打散成合理数量的文件。

另外，离线任务最怕数据倾斜。之前遇到过一个join任务，某个热点用户的订单量占了全表的30%，导致单个reduce任务跑几个小时。排查方法是看Spark UI里某个stage的task耗时差异明显，然后定位到key分布不均。解决办法是把热点key加随机前缀打散，再在关联时去掉前缀，或者用广播变量把小表分发到每个executor上。

3.2 Flink实时作业的状态与检查点

实时链路的核心是Flink，但Flink用得好不好，关键看两点：状态管理和检查点配置。

我接手过一个实时统计任务，需求是按用户维度累加订单金额。这个场景Flink天然适合，用keyBy(userId)分组后，用ValueState保存累计值，窗口触发时输出结果。这里有个容易犯的错：状态没有设置TTL。用户量一大，状态只增不减，内存迟早被撑爆。我在状态描述符上设置了TTL为24小时，过期数据自动清理，任务稳了很多。

检查点的配置也踩过不少坑。刚开始用默认配置，每条消息都做checkpoint，结果Kafka消费延迟飙高。后来调整为每60秒做一次checkpoint，同时开启exactly-once语义，延迟降到合理范围。这里要注意，checkpoint间隔太短会影响吞吐，太长会导致恢复时重复数据太多，一般建议在30秒到60秒之间，具体根据业务容忍度调整。

水位线这个概念对新手不太友好，我习惯用快递类比：水位线就是快递员允许包裹晚到多久。假设事件时间比处理时间晚最多5秒，那就把水位线设为当前最大事件时间减5秒，这样晚到5秒内的数据还能被正确统计，超过5秒的只能算迟到数据。

3.3 调度与血缘：任务编排不能省

离线任务多了之后，手动跑肯定不现实。DolphinScheduler我用下来最顺手的地方是支持DAG编排，一个完整的数仓任务可以画成一条依赖链：ODS同步完成之后自动触发DWD加工，DWD完成之后触发DWS汇总，最后通知业务方报表已出。每个任务单独设置超时时间和失败重试次数，重试间隔给5分钟比较合适。

血缘关系虽然不直接影响任务运行，但排查数据问题时能救命。一次数据口径对不上，业务方来问这个数怎么算的，我打开血缘图，从ADS层一路往上追到ODS层，几分钟就定位到是某个过滤条件写错了。如果没有血缘记录，就得靠人肉翻代码，效率完全不一样。

4. 查询引擎与数据服务

4.1 OLAP选型：Doris与ClickHouse的取舍

查询层我最后选了Doris，没选ClickHouse，原因是Doris对join的支持更友好，而且支持标准MySQL协议，业务方用BI工具连上来不需要改配置。ClickHouse的单表查询确实快，但多表join、数据更新场景要绕不少弯子，运营自助分析这种灵活查询场景不适合。

Doris的模型选择也有讲究。明细查询用Duplicate模型，汇总指标用Aggregate模型，需要更新用Unique模型。我最常用的是Unique模型，订单状态变更会实时更新，大屏查出来的数永远是最新的。建表时要显式指定分桶数和副本数，分桶数一般按数据量估算，保证每个桶在100MB到1GB之间。

这里提一个查询调优的经验：常用过滤条件里如果有时间字段，必须放到分区分桶键里。之前有个报表查询，没把时间放进分桶键，每次查都是全桶扫描，SQL优化半天也没用，改成时间分桶之后，查询耗时从秒级降到百毫秒级。

4.2 数据服务层的统一出口

数仓建好了，不能让业务方直接连Doris，那样并发一上来，什么查询都会被拖垮。我的做法是在Doris前面加一层统一查询服务，对外提供HTTP接口，内部做SQL模板管理、结果缓存、权限校验。

接口设计上，每个查询接口必须带超时阈值，一般指定500毫秒到2秒不等。大屏接口要求高，就单独走短查询路径，报表类接口允许相对慢一点。缓存策略也分两种：不变的基础维度数据缓存10分钟，实时指标只缓存30秒，确保大屏数据接近实时。

这一层还能统一做数据脱敏，手机号、身份证号这类敏感字段在接口层自动打码，避免业务方自己处理漏掉。

5. 数据质量与链路稳定性

5.1 质量校验规则怎么定

数据质量是数据平台最容易翻车的地方。我这边建了一套校验任务，每天跑完离线加工后，自动对结果表做校验。校验规则分几类：

• 完整性：今天的数据量和昨天比，有没有大面积缺失？
• 唯一性：订单表的主键有没有重复？
• 波动率：核心指标环比波动超过20%的，自动告警。

完整性校验最简单的方式是统计每个分区的记录数，和源表或前一天做对比，偏差超过阈值就触发告警。唯一性校验跑一个group by就能实现，但要注意在数据量大时控制扫描量，只查当天分区。波动率校验需要历史数据做基底，我一般是把前七天同一天的均值作为基准，这样可以规避节假日周期波动的影响。

5.2 踩过的三个坑和排查过程

第一个坑是Kafka consumer频繁rebalance。现象是实时任务时不时停止消费，日志里全是rebalance日志。排查下来发现是消费线程处理速度太慢，超过了max.poll.interval.ms的默认值，被判定为死亡。解决办法一是调大该参数到5分钟，二是优化下游写入逻辑，批量写入Doris，减少单条处理耗时。改完之后rebalance基本消失。

第二个坑是HDFS小文件把NameNode内存吃满。现象是整个集群响应变慢，NameNode GC频繁。当时统计了一下，某个Hive分区下居然有几十万个小文件，元数据占了几G内存。处理方式是把小分区合并重建，同时给所有离线写入任务加上文件合并逻辑。现在每天跑完都会检查文件数量，发现异常立即处理。

第三个坑是Flink checkpoint持续超时。现象是任务正常跑，但checkpoint一直失败，重启后数据重复严重。排查发现是状态太大，默认的RocksDB配置不够用。调大了RocksDB的block cache，同时把checkpoint间隔从30秒调成60秒，问题解决。这个经验是：不要盲目追求频繁checkpoint，状态量大的任务，间隔和存储配置必须一起调。

5.3 监控告警体系按什么标准搭

没有监控的大数据平台等于裸奔。我这边监控分三层：第一层是机器和集群，用节点监控看CPU、内存、磁盘；第二层是任务运行，调度平台自带失败告警；第三层是数据指标，就是上面说的质量校验告警。

告警渠道我统一走企业微信机器人，消息里带上任务名、失败原因、负责人。这里提醒一句，告警不是越多越好，全量告警会导致大家麻木。我把告警分成P0和P1两级，P0是链路挂了必须马上处理，P1是数据质量波动可以上班后处理。

6. 常见问题速查表与调优建议

6.1 高频问题排查速查表

6.2 三类最值得做的调优

第一类是并行度调优。很多人习惯把Flink和Spark的并行度调得很大，觉得并行越多越快。实际上并行度过大导致的是资源碎片和网络开销。我的经验是从数据量和单task处理能力来反推，一个task每秒处理几千条，那1万QPS的数据给三到四个并行度就够了。离线Spark任务executor内存给4G到8G比较合适，core数给2到4个，太多反而浪费。

第二类是存储格式调优。按时序写入的数据优先考虑分区裁剪，列式存储优先选Parquet或ORC，压缩格式选Snappy或Zstd。我这边统一用Parquet加Snappy，压缩比和查询性能比较均衡，而且各种引擎都能读。

第三类是SQL写法调优。尽量避免在join时用函数包裹关联字段，否则索引和分区裁剪全部失效；尽量用广播join处理小表，避免shuffle；尽量不要在where条件里对分区字段做运算，比如dt = date_sub(now(), 1)，这个写法会导致无法裁剪分区，改成先算好日期变量再传进去。

最后再分享一个经验：做大数据项目，最忌一口气吃成胖子。先跑通链路，再慢慢优化性能，先保证数据能算出来，再去考虑算得快。监控和告警一定要从第一天就顺手搭起来，不要等问题暴露了才回头补救。数据平台这行，稳比快更重要。