和“大数据实践”死磕的路上这些坑我必须记下来熟悉我的朋友都知道我一直在以“实践笔记”的方式记录自己做大数据项目的全过程。这篇“大数据实践笔记2”是我最近从重新规划集群、到动手跑数据任务、再到做大屏可视化、甚至去啃遥感卫星轨道数据之后攒下来的大量一手经验。这篇内容不打算写成教材更不是什么“从入门到放弃”的鸡汤文就是把我踩过的坑、验证过的方案、以及真正能提效的细节一条条摊开来说清楚。这篇笔记适合谁看我觉得是这样一群人正在用大数据做毕业设计的学生刚入行一到两年、准备系统梳理自己知识体系的数据开发工程师以及接到数据大屏、数据平台类项目、正愁技术选型和落地路线的朋友们。你可以把这篇东西理解成一份“个人实践复盘”里面没有什么平台套话只有我试过、用过的真实操作以及我事后反思出来的为什么。1. 开局先聊集群部署策略决定了你后面要不要加班1.1 部署前先回答三个问题规模、组件、数据量我不是第一次搭集群了但每次搭之前都会强迫自己先回答三个问题。第一个问题是“这套集群到底要跑什么”不只是“我要装Hadoop”而是具体到“我的数据量大概是每天几GB计算任务是以离线批处理为主还是需要支撑交互式查询或者还要跑模型训练”。这三个细分场景对硬件和组件的要求完全不一样。第二个问题是“节点规模多大”。很多人在部署时最常见的毛病就是照着网上教程一口气搭五个节点起步。但实际上如果你只是个人学习、做毕设或者给一个小团队的内部平台做支撑三节点甚至两节点都能跑得很舒服。盲目堆节点只会增加调优难度和运维成本。第三个问题是“要不要上高可用”。学习环境完全没必要搞HA因为HA意味着要多几台机器、多几个进程资源不够的时候反而拖慢任务。但生产环境必须保证NameNode、ResourceManager这些核心角色有主备否则一旦单点故障整个集群就等着通宵恢复吧。1.2 我从一台8G内存的笔记本开始的部署顺序我自己最开始做实验的时候手上的笔记本只有8G内存跑三台虚拟机都很勉强。后来我总结出了一套从轻到重的部署顺序现在推荐给朋友也都说好用。第一步先装单机版Hadoop把HDFS、YARN跑起来强制自己熟悉配置文件里每个参数的含义。第二步升级到伪分布式或者三节点真分布式把HDFS的副本机制、YARN的资源调度策略跑通。第三步再叠加Hive或者Spark。如果一上来就全套Hadoop、Hive、Spark、HBase、Flink全装上出了问题你根本不知道到底是哪个环节坏了。参数方面我多说几句这是经常被忽略但很关键的部分。yarn.nodemanager.resource.memory-mb决定了每个节点上YARN能使用的总内存如果你的机器是16G内存给系统预留4G剩下12G可以分配给YARN。yarn.scheduler.maximum-allocation-mb控制单个容器最大内存我一般会设置成4G左右避免某个任务把资源全占满。HDFS的dfs.replication如果只是测试环境设置为2就够用了三副本反而增加磁盘压力。1.3 部署过程中我踩过的三个大坑第一个坑是JAVA_HOME路径问题。很多版本对Java版本有要求比如Hadoop 3.3.x推荐Java 8或Java 11。我前期就在这上面卡了一整天反复报找不到类、连不上节点最后发现是Java版本不匹配。第二个坑是SSH免密登录配置不对导致启动DataNode时一直失败检查了很久才发现是authorized_keys权限设置了777。第三个坑是内存参数设置太低导致NameNode启动后不断Full GC整个集群假死最后调大了HADOOP_HEAPSIZE才恢复正常。2. 数据开发里的“N1问题”不只是数据库的专利2.1 大数据任务为什么也会遇到类似N1的困境做后端的朋友对“N1问题”应该很熟——先查一次主表得到N条记录再循环每条记录查一次关联表最后产生N次额外查询。这个思路放在大数据场景一样成立只是表现方式不同。最常见的一种情况就是拉取HDFS上大量小文件。比如你从业务库同步数据时上游疯狂生成小文件任务处理的时候就需要反复跟NameNode做元数据交互。NameNode每处理一次元数据请求都有开销文件数量一多整个集群的其他任务全部跟着卡顿。这本质上就是大数据场景的N1问题——数据量没多大但文件数量成了瓶颈。还常见于Hive任务里。一个SQL外面套个循环每天跑几十个定时任务每个任务都重复扫描某张全量表做过滤。表面上看只是个简单的WHERE条件实际上底层把几TB的数据反复读取了N次时间全耗在扫描上。2.2 我在实际项目中怎么定位和解决这类问题解决小文件问题主要有三个方向。一是合并源头从数据写入端控制生成文件的数量和大小比如用Spark写数据的时候设置合理的分区数。二是定期合并通过任务把已存在的小文件重写成少量大文件比如设置一个每天深夜执行的合并任务。三是合理设置Hive参数比如hive.merge.smallfiles.avgsize、hive.merge.size.per.task让查询引擎自动合并小文件。定位重复扫描问题需要多看看任务日志。我习惯的做法是先看任务读取的总字节数和任务运行时间的比例。如果读取了几个TB的数据但只输出几十MB结果那大概率是过滤下推没做好或者任务本身就有问题。还可以看看执行计划的Stage数量如果一个简单查询生成几十个Stage多半有数据倾斜或者笛卡尔积的问题。2.3 一套我常用的调优自查思路先看数据倾斜有没有个别Task运行时间明显比其他Task长如果有对热点key做加盐或者重分区。再看小文件查看目标目录文件数量和大小分布如果大量文件小于32MB就该考虑合并。然后看Executor资源配置看CPU和内存是否匹配vcore数和内存比例是否合理。最后看Shuffle如果Shuffle数据量特别大优先优化JVM内存和Shuffle分区数。这套流程我每次排查任务卡顿都会快速过一遍能省下不少时间。3. 数据可视化大屏实战当ReactTS遇到大数据平台3.1 大屏项目技术选型我为什么选ReactTS数据大屏展示类项目近两年特别火尤其是很多高校和企业都在做。我参与的项目里前端技术栈选了ReactTypeScript原因有几个方面。TypeScript带来的类型约束在大屏项目里特别有价值因为大屏涉及的数据结构通常非常复杂可能是嵌套了几层的JSON如果没有类型约束任何一个接口返回字段改了排查问题的成本都很高。React的组件化模型也很适合大屏开发。我把整个页面拆分成顶部标题区、左侧指标卡、中间地图、右侧排行榜、底部实时动态等独立组件每个组件接收自己的数据互不影响。团队协作的时候每人负责一个区域开发效率和后期维护都明显好过一整个文件硬写。3.2 完整走一遍大屏开发流程从接口到动效第一步是设计数据接口。后端返回的数据结构需要事先约定好比如每个图表需要的数据格式、哪些字段是必需、时间粒度是什么。我会要求后端同事统一返回code、message、data这种结构这样前端处理异常会方便很多。第二步是开发基础骨架。用React创建项目后先搭好网格布局把每个图表组件的占位区域规划出来。这里推荐使用CSS Grid或者flex布局宽度百分比自适应保证不同分辨率下不错位。第三步是图表渲染。大屏项目最常用的图表库是ECharts配合echarts-for-react封装开发效率非常高。每个图表的配置项要改成接收外部props这样不同数据源可以复用同一个图表组件。第四步是动效与数据刷新。大屏最常见的是定时轮询比如每5秒拉一次最新数据。这里记得要在组件卸载的时候清除定时器不然页面切走之后后台还在反复请求白白浪费资源。第五步是部署上线。通常有两种方式一种是把构建后的静态文件放到Nginx下另一种是整合进大数据平台内部。我习惯用Nginx配置一个location指向静态目录再设置好Gzip压缩和缓存策略。3.3 说说那些好用的免费数据可视化大屏工具如果是自己学习或者快速出效果不一定全要手写代码。我平时会关注的免费可视化工具包括Apache ECharts虽然它是一个图表库但配合模板和社区示例也能拼出一个不错的大屏页面DataV的免费版本阿里出品拖拽式操作内置很多大屏模板帆软的FineReport社区版在报表领域很能打还有开源的Meta2tr可以快速生成数据可视化面板。但要提醒一句这些低代码工具适合快速验证原型和内部展示。如果项目需要深度定制、需要跟复杂业务逻辑交互还是老老实实基于ReactVue这种框架来写自由度完全不一样。4. 遥感卫星大数据当TLE数据遇到轨道动态可视化4.1 TLE数据到底是什么为什么适合做成大数据实践项目卫星遥感大数据高效精细处理技术这个词看着挺高端但拆解下来核心就是如何把海量卫星数据变成有价值的信息。而TLETwo-Line Element双行根数数据是描述卫星轨道的一组经典格式数据。每行TLE数据都包含卫星编号、轨道倾角、升交点赤经、偏心率、近地点幅角、平近点角等参数通过这些参数可以预测任意时刻卫星在天空中的位置。为什么我把它当成一个极好的大数据实践项目因为TLE数据文件本身虽然不大但如果你要做长时间段、多颗卫星的轨道动态可视化就要对大量轨道参数做解析、计算、比对这就涉及数据清洗、批量计算、空间索引和可视化多个环节正好能把大数据技术栈完整串起来。4.2 我做的轨道动态可视化与分析覆盖分析思路数据层面我会先从公开渠道获取TLE数据集通常是包含了数千颗卫星的TLE文件。处理流程是先做数据解析把TLE每行字段转换成结构化数据这一步可以用Python的skyfield库也可以自己按格式解析然后根据任务需要对特定时间段内的卫星位置进行轨道传播计算得到连续的轨迹点接着做覆盖分析也就是计算某颗卫星或某组卫星在目标区域上空的过境时间窗口和重访周期这一步本质上是大量空间几何计算。可视化层面我用了Cesium或者Mapbox GL来做三维地球场景把计算得到的轨道轨迹点渲染成动态线条同时用时间控制器来播放卫星的运行过程。效果很直观也很有冲击力适合做项目展示。4.3 我总结的高效精细处理套路遥感数据处理特别讲究效率我总结下来有三条值得注意的实践经验。第一条是计算之前先做数据裁剪不要全量算。大范围遥感影像处理的时候先用经纬度边界把无关区域裁掉计算量能下降一个数量级。第二条是善用并行计算轨道传播计算天然是数据并行任务每颗卫星之间没有依赖关系可以用Spark或者多进程直接提速。第三条是分层存储热数据放HDFS或本地SSD冷数据归档到对象存储查询的时候只加载需要的那部分。这套思路其实可以复用到大数据的很多场景“先裁剪、再并行、再分层”本质上就是一种处理海量数据的通用方法论。5. 面试、毕设和学习路线给正在准备的人一份实用清单5.1 面试常考的那些大数据点考官到底在考什么大数据面试题翻来覆去就是那几个核心方向。分布式原理必考HDFS读写流程、YARN资源调度过程、MapReduce的Shuffle机制这些不只是背概念更重要的是能讲清楚“为什么这样做”。比如面试官问HDFS为什么不适合存大量小文件你要能回答出两个层面元数据压力大以及文件块太小导致Map任务启动开销远大于处理时间。框架源码也是高频考点Spark的宽窄依赖、Flink的Checkpoint机制、Kafka的消费组和分区分配策略几乎每轮都有。我的建议是自己画一遍执行流程图尝试给不懂的人讲明白讲得通就说明真掌握了。还要注意项目描述。面试官特别反感候选人把项目讲得像个功能列表。正确的姿态是这个项目要解决什么问题我设计了什么方案为什么这样设计踩过什么坑最终效果如何。这样一条线拉下来才算是一个完整的项目叙事。5.2 大数据毕业设计选题怎么选才能兼顾好做和出彩大数据毕业论文选题方向很多但真正好的选题要满足三个条件数据可获取、技术栈能覆盖、结果可展示。数据可获取排在第一位如果你选题选了一个内部数据才有的方向后面会非常被动。我比较推荐的几个方向是数据可视化大屏类项目结合公开数据集做区域经济分析、疫情数据展示、电商销售分析前端大屏后端接口数据库存储一套全做展示效果好也容易出论文图表基于云平台的大数据应用开发用云厂商的托管集群做数据处理和分析不用自己折腾运维可以更多关注算法和业务逻辑遥感数据的处理与分析类项目就是前面我提到的TLE数据轨道可视化这种比较新颖资料也公开容易形成亮点。想做出彩还要想办法加一点模型或者算法的部分比如对未来的数据做预测、对用户做聚类哪怕只是用简单的回归或者K-Means论文的难度和档次都会不一样。5.3 数据科学与大数据技术的学习路线怎么走才不迷茫数据科学与大数据技术就业方向很广包括大数据开发工程师、数据分析师、数据仓库工程师、数据平台工程师等。岗位不同学习侧重点也不同但底层知识体系是一致的。我建议的学习路线分四阶段走。第一阶段打好编程和数据库基础重点掌握Python和SQL。第二阶段学习分布式计算框架先啃Hadoop生态再学Spark理解作业提交和执行的基本流程。第三阶段深入数据仓库建模和实时计算学习Hive、Doris、Flink这些常用组件理解数仓分层的设计思路。第四阶段根据目标岗位定向深入。想做数仓就往建模和SQL优化方向努力想做实时计算就深挖Flink和Kafka想做数据平台就多学习调度系统、元数据管理、权限平台这些工程化内容。学习过程中一定要多做笔记把自己“为什么这样配置”“为什么这样优化”记录下来。时间久了这些笔记就是你面试时最宝贵的项目素材。写在最后的话大数据这个东西入门容易精通很难难就难在它是一条很长的链路从数据采集、存储、计算、调度到应用展示每一环都有无数细节。我写这些实践笔记初衷就是把我踩过坑、撞过墙之后的真实感受记录下来如果能帮正在这条路上摸索的朋友少走一点弯路那就再好不过了。最后再分享一个小技巧做任何大数据项目先定好数据规模和衡量指标再做技术选型。我见过太多同学用企业级方案做课设或者用小作坊方式接生产需求结果都特别痛苦。对着自己的实际场景选方案才是真正省时间的路。