企业官网建设流程全解析

简介：针对创业公司不同发展阶段的大数据平台选型与演进难题，这份PPT从产品验证、业务增长到成熟运营给出完整技术路线，适合技术负责人、架构师及数据工程师参考。内容以实际业务监测场景为例，对比了从简单Java应用搭配MySQL起步，到引入Nginx、Kafka、Spark+HDFS、Flume等组件的演进过程，并包含RDD优化、Spark参数调优、留存用户计算、Elasticsearch实时查询等落地经验。压缩包内共有1个pptx文件，文件大小仅406KB，为完整演示文稿，便于直接阅读和二次整理。已有113人学习下载，可帮助读者快速掌握大数据平台从零到一的搭建思路与关键技术取舍。

1. 大数据平台选型：创业公司先想清楚“当下要什么”，再谈技术栈

说实话，很多团队一上来就奔着 Hadoop、Spark 全家桶去，最后往往死在运维和迭代速度上。这篇《大数据平台选型与演进》的 PPT 分享了我当年在一家做移动端监测和 Deep Link 唤醒服务的创业公司，从零搭建数据平台的完整路径：先是一个包含采集、计算、展示的 Java 单体应用硬扛了三个月，再逐步演进到 Nginx + Kafka + Flume + Spark + HBase + Elasticsearch + CDH 的混合架构。它最有价值的不是最终那套技术栈，而是里面贯穿的选型逻辑——每个阶段选什么、为什么选、什么时候该升级，全部基于当时的业务数据量和团队资源来定。这份材料适合两类人：一类是创业公司刚准备搭数据平台的技术负责人，另一类是在成熟公司里想理解平台演进脉络、准备做技术方案汇报的工程师。它的核心关键词就两个：选型和演进，而这两件事的本质，其实是“在正确的时间做正确的事”。

2. 产品验证期的“反模式”架构：为什么单体 Java 应用反而是最优解

2.1 验证期的真实约束：成本是第一优先级

大家看 PPT 里那个阶段的技术选型原则，很多人会觉得“这也太简陋了，根本不是大数据平台”。但回到当时的业务场景就明白了：用户只有几十个种子用户，采集到的数据量根本撑不起“大数据”这三个字。同时，计算的统计指标是否对用户有真正帮助，完全无法确定——很可能整个功能会被市场反馈砍掉。这种情况下，唯一理性的选择是尽最大可能缩小验证成本：端到端跑通功能，设计和实现上越简单越好，不需要积累技术债务，被毙掉了也不可惜。我当时做的架构就是典型的 monolithic 应用，拆开来看只有三块：一个移动端 SDK 的数据采集接口、一组跑在 MySQL 上的统计脚本、一张管理后台的数据展示页面。

这个架构支撑了大约三个月。MySQL 在这里发挥了两个关键作用：一是结构化特性让计算脚本非常好写，日活、打开次数、流失用户、回流用户这些移动端常用指标，一条 SQL 加上几个 group by 就能搞定；二是一站式开发框架让业务修改极快，因为指标计算逻辑和业务逻辑耦合在同一个应用里，改一个接口、重启一次服务就完事了。这个阶段的决策其实只能用“划算”两个字来衡量，所谓架构先进性，在业务是否能活下来这个问题面前不重要。

2.2 验证期架构的边界：哪些信号告诉你必须升级

这套架构的缺点也很明显：它不是可水平扩展的，数据量一上来，MySQL 的连接数和查询性能会先出问题。我当时遇到的实际信号有两个：第一，采集数据时经常触发 MySQL 连接失效，需要不断优化服务器端和客户端的连接参数，比如 max_connections、wait_timeout、连接池的初始大小和最大上限；第二，当有流量稍大的种子用户进来后，实时计算和离线计算的需求开始分化，比如 Deep Link 短链的曝光和安装转化率需要较快看到结果，而留存分析更适合离线批量跑。当这两个信号同时出现时，就该启动下一阶段的架构改造了。

这里顺带说一个我后来反复用到的判断方法：每次准备做技术升级前，先把“当前架构最痛的三件事”写下来。写不出来，说明还没到升级的时候；写出来了，就按痛苦程度排序，逐个在下一版架构里解决。PPT 里后面的演进路径，本质上就是在解决“采集稳定性、存储可靠性、计算性能、运维效率”这四件事，每件事对应一个新组件的引入。

3. 采集与暂存链路重构：Nginx 参数调优和 Kafka 的取舍逻辑

3.1 采集端选 Nginx：高吞吐不是说出来的，是调出来的

采集端选了 Nginx，这个基本没争议。异步非阻塞模型天然适合高并发写入场景，但很多工程问题恰恰出在默认参数上。我记得当时整理过一份需要重点调的参数清单：

这里的核心思路是：给 Nginx 一个足够的并发基座，再让每个连接的生命周期尽量短，保证采集接口的吞吐量能稳定抗住流量峰值。调完后建议用简单的并发脚本压一下，比如用 ab 或 wrk 发几万请求，观察 worker_connections 是否被耗尽、有没有报 502 或连接超时。我当时压测后调整过两轮参数，才把采集端的稳定性拉起来。

3.2 数据暂存区用 Kafka 而不是日志：3 个决定性的理由

PPT 里专门提到了一个和传统监测架构的区别：没有把 Nginx 日志当数据暂存区，而是直接上 Kafka。这个决策我后来在很多场合都推荐过，理由有三点。第一是吞吐量和及时性：比起磁盘 IO，Kafka 的吞吐量高得多，而且生产者提供异步写入方式，Nginx 采集到的数据能第一时间进入暂存区，不需要等日志落盘再扫描。第二是分布式特性自带的高可用：消息队列本身支持 Failover，数据可以存放多份，Partition 机制让写入和加载更高效，而且天然能解决不同监测数据的区分问题——比如曝光、点击、安装转化这些不同类型的事件，分别用不同的 Topic 隔离，下游消费互不干扰。

第三点是最容易被忽略但实际最值钱的：数据续传问题。如果下游存储节点崩溃了，纯日志方式很难知道该从哪条记录开始续传；而 Kafka 客户端可以把自己的 Offset 保存在 Zookeeper 里，崩溃恢复后直接从上次的 Offset 继续消费，一条不多一条不少。我当时踩过日志采集的坑，日志文件被 rotate 后丢了一批数据，排查了整整一天才发现是续传位置算错了。换到 Kafka 之后，这种问题基本绝迹了。这里补充一个参数经验：Kafka 的 log.retention.hours 我会按业务需求设成 24~72 小时，太短会导致凌晨补数时数据已过期，太长会白白占用磁盘；如果对乱序敏感，可以把 max.in.flight.requests.per.connection 设成 1，但吞吐会略有下降，需要自己权衡。

4. 离线计算与实时链路：Spark 参数优化和 Elasticsearch 的定位

4.1 Spark 离线计算：从“能跑”到“跑得快”的 6 个调整习惯

离线计算选了 Spark + HDFS，这部分大家都很熟，重点在优化细节。PPT 里总结了 6 条心得，我逐条展开说明，因为这些每一条都是实际踩过的坑换来的。

第一，应用里要了解 RDD 的 partition 和执行中的 stage 情况。常见做法是打开 Spark UI 看每个 stage 的 task 数量和 shuffle 数据量，如果出现大量极小的 task，说明 partition 切得太碎，需要适当增大每个 partition 的数据量。第二，尽可能复用 RDD。如果同一个 RDD 要被多次 action 触发，一定要做 cache，并根据数据量和内存情况选择持久化策略——默认 MEMORY_ONLY 适合纯内存能放下的场景，MEMORY_AND_DISK 适合数据量大于内存但还能接受落盘的场景。

第三，必要时候用 broadcast 和 accumulator。小维度表用 broadcast join 代替 shuffle join，能省掉一大截网络传输；accumulator 适合做全局计数器，比如统计过滤掉的事件总数，避免用 collect 把数据拉回 driver。第四，资源类参数要按作业情况调，不是公式化地照抄：

spark-submit \ --master yarn \ --deploy-mode cluster \ --num-executors 20 \ --executor-memory 8g \ --executor-cores 4 \ --conf spark.default.parallelism=80 \ --conf spark.shuffle.file.buffer=64k \ --conf spark.reducer.maxSizeInFlight=96m \ --conf spark.yarn.executor.memoryOverhead=2g \ --class com.example.MobileReportJob \ your-app.jar

逻辑说明：num-executors 决定总并发度，executor-memory 和 executor-cores 决定单个 executor 的资源配额。一个经验值是单个 executor 的 cores 不超过 5，因为超过 5 后 HDFS 读写吞吐会碰到瓶颈；spark.default.parallelism 我一般设为 num-executors × executor-cores 的 2~3 倍，让 task 数略多于核心数，避免最后几个 task 拖慢整体。

第五，如果允许，尝试官方推荐的 Kryo 序列化。默认 Java 序列化对象体积大、速度慢，换成 Kryo 后 shuffle 数据量能降低 30%~50%，对作业耗时改善非常明显。第六，通过打印 GC 信息了解内存使用情况，在 spark-submit 里加--conf "spark.executor.extraJavaOptions=-XX:+PrintGCDetails -XX:+PrintGCTimeStamps"，观察 Full GC 频率和耗时，如果频繁 Full GC，优先调整 executor-memory 或内存Overhead，而不是盲目加大整个 executor 内存。

4.2 Elasticsearch 引入的动机：为什么离线平台之外还需要一个“实时查询层”

这里有个容易被忽略的点：Spark 离线计算再快，也是分钟级到小时级的延迟。像 Deep Link 短链这种业务，运营投放后需要较快看到曝光和转化情况，所以还需要一条实时计算链路。我们选 Elasticsearch 而不是直接流式处理全量数据，原因是它本身是一个近乎实时索引的分布式搜索引擎，查询响应时间基本随节点增长线性下降，而且结构化数据基于 JSON，天然是半结构化的，计算方式很灵活。配合查询模板化能力，可以把查询条件和客户端代码解耦，运维上所有功能都是 API 化的，非常便于自动化管理。插件生态也够丰富，支持从 HDFS、Kafka 等数据源双向导入数据。

这个架构的定位不是替代 Spark，而是在离线之外做一个“近实时查询层”。离线链路负责深度加工和批量聚合，ES 链路负责“刚发生的事件能不能马上看到”。我一般在数据写入环节用 Kafka 直连 Logstash 再进 ES，或者在代码里直接用 Bulk API 批量提交，单批次建议控制在 1MB~5MB 之间，太大容易触发 ES 的内存压力，太小吞吐上不来。

5. 存储计算选型避坑：Flume、HBase 流式计算和 CDH 的边界

5.1 为什么选了 Flume 而不是 Spring XD：能被托管比功能丰富更重要

在 Nginx 到 Kafka 这个环节，我们有两种可选方案，一个是 Flume，另一个是 Spring XD。最终选了 Flume，核心原因有两条：第一，使用足够简单，Source、Channel、Sink 的组件化模型非常清晰，各种现成的 source 和 sink 可以直接拼装；第二，它能被 CDH 托管，而 Spring XD 只能被 Yarn 托管。CDH 的托管意味着监控、配置、告警都能统一走 Cloudera Manager，这对一个只有两三个人的数据团队来说，节省的运维成本是无可估量的。一个反直觉的结论是：在资源有限的小团队里，可运维性经常比功能丰富度更值得优先考虑。功能再强大，如果没人能长期维护，也是无效资产。

5.2 用 HBase 做留存计算：不引入 Storm，靠 CAS 和行键设计解决问题

留存计算这类指标，回溯历史数据去做非常困难，更好的思路是边采集边算。我们没有引入 Storm 或 Spark Streaming，而是直接在 Flume 传输数据的链路中用一个 HBase 表做增量计算。原理是这样的：HBase 表以 DeviceId 为行键，维护首次访问时间和上次访问时间；每条新事件进来时，先判断是不是新设备——是就插入新行，不是就计算距离上次访问的时间间隔，更新时间戳，然后通过 CAS(Compare And Set) 操作递增对应留存区间的计数器。比如一条事件tenant1|deviceId1|timeStamp1|action1，如果距离上次访问 2 天，就跨了 1 天，说明 1 日留存用户加 1；如果跨 7 天，就是 7 日留存。周的留存逻辑类似，只看上次访问时间是否跨周。

这个方案的边界在于它只适合“单设备单次事件驱动”的留存场景，如果单事件同时触发多个指标更新，CAS 操作会变复杂，需要自己设计行键或加列。这里有一个关键参数：HBase 的hbase.client.retries.number默认是 10，在网络抖动时会导致耗时翻倍，我会把它调到 3；hbase.client.write.buffer默认 2MB，批量写入场景调到 5MB 可以显著减少 RPC 次数。rowkey 设计上尽量把 tenant 和日期前缀放前面，避免把所有写入压力打在同一个 region server 上。

5.3 发行版选型的避坑记录：CDH 确实是运维最优解，但代价要知道

针对 Hadoop 发行版，我们对比过 CDH、IDH（Intel）、HAWQ（Pivotal）、Hortonworks 四家。IDH 的特点是 HBase 提供 LOB 类型，对二进制存储有帮助，也优化了 Hive 让相关数据尽量落在同一 region，但这些和我们的业务需求毫无关系，而且 Intel 已经战略投资 Cloudera，IDH 的功能会逐步移入 CDH。HAWQ 本质是 MPP 架构的数据库，基于 HDFS 之上的 SQL 支持在 3 个 DataNode 的情况下，上亿级别的 group by 聚合加子查询能在 10 秒左右返回，适合异步近实时查询，但我们没这个场景。Hortonworks 各方面和 CDH 很像，但管理工具不如 CDH 强。所以最终选了 CDH，因为它的管理工具提供了安装、维护、监测、预警等一系列运维能力，是最适合小团队的。

这里整理几个 CDH 使用中的实际踩坑记录，每条都是亲历：

• 现象：Cloudera Manager 里 HDFS 容量告警，但实际业务数据并不多。原因：默认开启了 HDFS 回收站，删除的文件在.Trash里保留 N 天没清理。解决：按业务需求调短fs.trash.interval，比如从默认 6 小时调到 1 小时，并定期跑hdfs dfs -expunge强制清空。
• 现象：Spark 作业在 CDH 上频繁报Container killed on request. Exit code: 143。原因：executor 内存超过 Yarn 容器上限，被 ResourceManager 主动杀掉。解决：确认spark.yarn.executor.memoryOverhead是否被默认值低估，按 executor 内存的 10%~20% 手动调大。
• 现象：Flume 在 CDH 托管下频繁重启。原因：默认 agent 堆内存太小，source 到 channel 的并发一高就 OOM。解决：在 Flume Agent 的配置里把flume.child.heap.memory调到 1G 以上，并关闭无关的 source 和 sink。
• 现象：Kafka Offset 存储压力大，Zookeeper 线程飙高。原因：客户端默认每 1 秒自动提交一次 offset。解决：调大auto.commit.interval.ms到 10 秒，并改成手动提交，降低 ZK 写压力。
• 现象：HAWQ 试用时发现聚合查询确实快，但运维成本高。原因：它是一个独立 MPP 数据库，需要单独维护一套元数据和资源组，和 HDFS 的整合不像 CDH 那样开箱即用。解决：没有实际引入，只在文档里留有评估记录，结论是“能力很好，但不匹配当前阶段”。

6. 架构验证与技术债清理：一套可持续演进的健康度检查方法

不管选型多合理，演进多次后架构一定会有隐性债务。我后来养成一个习惯：每季度强制做一次“架构健康度检查”，用的是从这套选型经验沉淀出来的标准动作。

最核心的动作是压测验证：先用wrk或ab对 Nginx 采集接口做一次基线压测，记录吞吐量和 P99 延迟；然后停掉 HBase 的 region server 节点，观察 Kafka 消费者是否按 Offset 续传、数据有没有丢；接着重跑一次离线聚合任务，对比 Spark UI 里每个 stage 的 shuffle 数据量和耗时有没有异常增长。这套动作的优点是它不测“系统能不能跑”，而是专门测“故障时数据会不会丢、恢复后是否一致、性能是否随时间退化”。从那次以后，我每接手一个数据平台，第一件事就是跑这三项检查。

另一件值得做的事是给每个组件写清“选型前提条件”。比如 Kafka 需要 Zookeeper 保持奇数节点，ES 需要保留至少一个副本，HBase 的 region split 策略依赖 rowkey 设计；如果业务变了，前提不成立，那对应的组件也应该重新审视。而不是因为当年选了它，就一直默认它是对的。这种“写清楚为什么选它”的习惯，对我们这种需要持续演进的小团队尤其有用，因为新人接手时，能直接看到当时的决策边界，而不是把现状当作理所当然。

从那次项目之后，我每次做数据平台选型，都会先回答三个问题：当前阶段最痛的点是什么、为了这个点愿意付出多少运维成本、这个方案在半年后还能不能继续迭代。这三个问题的答案，比任何技术栈的优劣对比都重要。希望这份演进思路能帮你在选型时少走一段弯路。

本文还有配套的精品资源，点击获取