开头先交代一句这篇文章源自我的真实项目笔记整理不是教科书式的架构科普。整篇内容围绕一个从零搭建的中型大数据平台项目展开覆盖立项评估、集群规划、数仓构建、实时链路、质量保障、可视化大屏和面试复盘七个核心段落。如果你正在准备数据开发岗位的面试或者刚接手一个大数据项目不知道从哪下手这篇笔记应该能帮你把思路理顺。我和团队做过好几个大数据项目从早期的 Hadoop 生态到后来的实时数仓踩过的坑和沉淀下来的方法都不少。这篇文章里的内容大概是2023年下半年到2024年上半年我们做的一个电商数据分析平台项目的真实记录。平台本身不复杂但麻雀虽小五脏俱全涉及了离线数仓、实时计算、数据质量监控、数据大屏展示等完整链路。下面我按项目的实际推进顺序把关键决策和实操过程写下来。1. 立项阶段最容易忽略的事先搞清楚数据从哪来、要到哪去很多大数据项目失败不是技术不行而是需求阶段就没把数据的来龙去脉摸清楚。我们项目启动时第一件事不是什么技术选型、集群规划而是花了两周时间做数据源盘点。1.1 数据源盘点怎么做才不漏项电商平台的数据源大概分三类业务库MySQL、PostgreSQL、日志文件Nginx、App 埋点、第三方接口支付回调、物流状态。我们当时做了一个数据源清单表格每个数据源至少记录以下字段数据源存储类型数据量级日增更新频率重要级别对接负责人订单库MySQL约 80GB实时写入P0后端 A用户库MySQL约 5GB实时写入P0后端 B埋点日志文件约 200GB每小时滚动P0前端 C支付回调API 接口约 10GB实时推送P1后端 D这个表格是后面所有工作的基础。团队里经常出现的情况是业务方说“数据都在库里”但等你要同步时才发现库表结构天天变、没有更新时间字段、源库是跨机房访问的。这些坑都是盘点阶段能提前暴露的。做盘点时有一个容易被忽略的细节必须确认每个源表是否有主键或唯一键、是否有更新时间字段modify_time。这直接决定了后面用 Sqoop 还是 DataX、用增量同步还是全量同步。我们遇到过一个用户表三年没加过 modify_time全量同步跑了七个小时还把业务库压垮了。后来是找 DBA 加了字段才解决。1.2 数据量评估与算力预估的简易公式从零做规划数据量不要往大了吹按未来半年的增长量估就够了。估算公式大致是每日增量数据 Σ(各业务表日新增行数 × 单行平均大小) Σ(各日志文件日新增条数 × 单条日志平均大小) 全量存储需求 每日增量 × 存储周期 × 副本数 × (1 压缩率节省空间系数)我们当时的估算结果是每日新增原始数据约 300GB订单日志接口计划存储周期原始数据 180 天清洗后数据 365 天汇总数据永久保留HDFS 采用 3 副本数据压缩LZO后约为原始大小的 40%算下来整个集群需要的裸存储约 300GB × 180 × 3 × 0.4 ≈ 64TB。再加上 NameNode 元数据、临时计算空间等最终配了 12 台物理机每台 8TB 存储。这个量级后面跑起来基本没出现过磁盘告警。提示如果公司的数据规模每天不足 100GB不建议一上来就上 ClickHouse、Doris 这类分析型数据库直接用 Hive 数仓 MySQL 报表就够了。很多团队犯的错是用导弹打蚊子最后运维复杂度远超收益。1.3 需求侧梳理SLA 和数据消费方盘点完数据源下一步是梳理数据消费方。谁会用到这些数据是实时大屏、报表系统、算法团队还是老板的数据看板不同消费方对数据的时效性、准确性要求完全不同。我们总结了一个需求矩阵的简版数据产品数据时效允许延迟数据准确性下游实时大屏秒级≤ 15 秒高99.9%运营、管理层经营日报T1次日上午 8 点高100%财务、经营分析个性化推荐小时级≤ 1 小时中等算法团队临时取数无要求可容忍 2 小时高数据分析师这个矩阵的价值在于它决定了你要不要上实时链路、实时链路的可靠性要求有多高、离线任务必须在几点前跑完。如果所有需求都是 T1那就不用花大力气搞 Flink如果大屏要求秒级准确那就要考虑 Lambda 架构或者实时数仓的投入产出比。2. 集群规划与部署不追求豪华追求够用和稳定集群怎么搭网上教程很多。这里我不讲标准安装步骤重点分享几个真正影响后续稳定性的决策点。2.1 硬件选型与组件版本组合大数据组件版本兼容性是大坑不要随便选最新版。我们最终使用的组合如下跑了一年多没出过严重兼容问题组件版本说明JDK1.8.0_202不要用高版本 JDK 跑 Hadoop 生态坑多Hadoop3.3.4HDFS YARN 一体ZooKeeper3.7.13 节点Hive3.1.3元数据存 MySQL使用 Tez 引擎Spark3.3.0主要做离线清洗Flink1.16.2实时计算配合 KafkaKafka3.3.1消息队列3 节点DataX3.0离线同步阿里开源Doris2.0.3实时 OLAP兼报表查询DolphinScheduler3.1.8任务调度替代 Airflow硬件配置方面我们用了 12 台 DataNode同时承担 NodeManager3 台 NameNode其中 1 台 Active、1 台 Standby、1 台做备用的 QJM 节点3 台 Kafka ZooKeeper复用。每台机器内存 128GBCPU 32 核系统盘 480GB SSD数据盘 8TB × 4。注意不要为了省钱把 NameNode 和 DataNode 混布在一个节点上。NameNode 的内存占用和 GC 问题会直接影响集群稳定性尤其当日元数据量超过千万级文件时混布会导致频繁 Full GC。2.2 NameNode 元数据管理最容易忽略的隐患HDFS 的 NameNode 元数据是放在内存里的文件数越多内存占用越大。我们的集群跑了大半年后文件数涨到了 1.2 亿NameNode 堆内存一度飙到 90GB。这个问题的触发点是小文件过多——上游 Flink 的 checkpoint 文件、Spark 的临时输出、Hive 分区表日增分区都在不断制造小文件。解决方案有三个层面合并小文件离线任务输出时强制用distribute by进行分区内合并Hive 设置hive.merge.smallfiles.avgsize268435456把平均小文件大小合并到 256MB 以上。定期清理临时文件写脚本每天清理/tmp、/user/hive/warehouse下超过 7 天的临时目录。监控告警对 NameNode 堆内存、文件总数设置监控超过阈值的 80% 就告警提前做扩容或清理。这些事看起来很简单但“不炸不修”的团队十有八九会在这里翻车。2.3 YARN 资源调度的三种队列划分方案YARN 资源分配不合适集群就会出现“任务排队但 CPU 空闲”的奇怪现象。我们经过三次调整后采用了以下队列方案队列名容量占比最大资源用途优先级root.etl50%60%离线清洗、数仓构建高root.realtime20%30%Flink 实时任务中root.adhoc15%20%临时查询低root.default15%20%默认队列未归类的任务低一点经验Flink 实时任务如果和离线任务混在一个队列很容易出现离线任务把集群资源占满导致实时任务 checkpoint 超时失败。所以我们后来把 realtime 队列单独拎出来并且配置了yarn.scheduler.capacity.maximum-am-resource-percent0.4防止 AM 占用过多资源。特别提醒一下跑数仓任务时尽量用 Spark 的spark.dynamicAllocation.enabledtrue同时配合队列容量限制否则一个大的 ETL 任务会把整个集群的资源抢完其他任务全部卡死。3. 离线数仓的分层设计每一层解决一个具体问题数仓的分层设计看着是老生常谈但真正能讲清楚每一层为什么要这么分的人不多。下面我用我们项目中的订单主题为例把每层的职责和实现细节写清楚。3.1 ODS、DWD、DWS、ADS 的定位误区很长一段时间里我对分层停留在“分层就是为了好管理”这种模糊认知上。实际做完一个项目后我理解每一层都有明确的职责ODS操作数据存储层只做原样接入保留完整的历史痕迹不做任何业务清洗。它的作用是确保“源头可追溯”出问题随时能回补。DWD明细数据层做清洗、去重、标准化、维度退化形成业务过程的事实明细。核心是“一行代表一个业务事实”多宽都行但不能有重复。DWS汇总数据层按主题做轻度汇总比如按天、按小时、按商品、按用户等维度预先聚合减少重复计算。ADS应用数据层面向具体报表和应用的数据宽表或者预计算的结果尽可能保证查询性能。用订单来举例。ODS 表里可能有多张表ods_order_info订单主表、ods_order_item订单明细、ods_user_pay支付流水。DWD 层会把这些表通过订单号关联清洗掉撤销单、测试订单、异常状态形成一张dwd_order_detail分区表。DWS 层则按“天 商品 店铺”维度聚合出dws_sku_sales_1d这样的汇总表。ADS 层直接关联店铺维度、价格带维度输出给报表系统。3.2 维度建模与缓慢变化维的取舍维度建模我们用的是 Kimball 的星型模型没有搞复杂的雪花模型。事实表用事务事实表一个订单对应一行维度表只处理了用户维度、商品维度、店铺维度、时间维度。缓变维度的处理值得单独说一下。比如用户所在城市用户搬家后维度表更新历史事实该怎么办我们的处理策略是策略适用场景实现方式拉链表用户地址、会员等级记录历史版本用生效日期和失效日期覆盖更新与业务无关的修正UPDATE 原记录新增行需要留历史事实新开一行记录我们最终只对用户维度的关键属性做了拉链表地址、等级其他属性直接覆盖。做太多版本管理会显著增加查询复杂度不值当。拉链表的 ETLSQL 其实不复杂核心就是“上一版本失效 新增最新版本”每天一个 20 分钟的增量任务就能搞定。3.3 数据倾斜问题SUM 都能算错数据倾斜是离线计算最容易踩的坑也是大数据面试最高频的考点之一。我们遇到过一个典型的倾斜场景统计 TOP 100 商品的销售额商品维度的 join 时一个大爆款商品的数据量占了全表的 60%单个 Reduce 任务跑了 2 小时其他 Reduce 几分钟就结束了。当时做了三个优化大小表 Join 的 MapJoin如果小表不超过 100MB用/* MAPJOIN(b) */提示小表加载到内存里大表在 Map 端直接关联不走 Reduce。我们商品维表就一百多 MB很适合这种方式。热点 Key 加盐对于无法避免倾斜的大表关联给热点 Key 加随机前缀把一条大 Key 拆分成多个子 Key 去计算最后再合并结果。代码实现大概是把 join 条件改成if (sku_id 10001, concat(sku_id, _, rand()%10), sku_id)两边保持一样的逻辑。两阶段聚合先按 key 随机前缀做一次聚合再去掉随机前缀做第二次聚合。经典写法WordCount 升级版。优化后那个任务从 2 小时降到 20 分钟。这类问题的排查工具就是看 Spark UI 的 Stage 耗时分布有经验的工程师一眼就能判断是不是倾斜。3.4 离线任务调度DolphinScheduler 的几个实用配置调度我们用 DolphinScheduler替代了 Cron Shell 的老方案。几个非常有用的配置分享下任务超时配置每个工作流设置超时时间比如 120 分钟超时自动杀掉并告警。没有超时保护的任务挂起时非常耗资源。上游依赖检测用 Shell 任务去查询前一天的分区数据是否存在、是否有预期行数不存在则直接失败并重跑。比如# 检查分区是否存在 hive -e select count(*) from dws.dws_sku_sales_1d where dt${yesterday} if [ $? -ne 0 ]; then exit 1; fi失败重试策略重试次数设为 3重试间隔 5 分钟。不要无限重试否则遇到数据源故障会导致任务一直抢占资源把整个集群拖垮。事件先后顺序要严格ODS 同步任务完成后再跑 DWDDWD 完成后再跑 DWS。我们通过 DolphinScheduler 的 DAG 依赖关系解决了这个问题再也不需要人肉等着看日志。4. 实时链路的选择什么时候该上 Flink什么时候不该上实时计算被吹得神乎其神但真实场景里很多“实时需求”其实是“伪实时”。这里说说我们踩过的坑和最终的选择。4.1 实时需求评估用一份收益矩阵来决定要不要做实时凡是业务方提“实时”需求我都先问三个问题你需要多准你能容忍多少延迟数据量是多大需求类型延迟要求数据量建议方案实时大屏秒级中等Kafka Flink Doris实时风控毫秒级大单独做 Flink CEP 或专用引擎会员积分变动秒级小直接用服务端算 Redis指标环比同比分钟级中Kafka Flink 窗口聚合当时业务方一上来就说要“实时经营报表”要看到每一分钟的 GMV。后来我们拉了下数据量每分钟订单只有几百条实时和 T1 的数据差距极小。最后我们用了折中方案Kafka 同步业务 binlog 到 DorisDoris 的 Aggregate 模型做分钟级聚合完全满足需求不需要上 Flink。真正上 Flink 的只有两个场景实时大屏和小时级个性化推荐的数据预处理。这两个场景数据量大、逻辑复杂需要真正的流式计算。4.2 Flink 实时任务的 checkpoint 与状态后端配置一旦决定用 Flink第一件事就是要把 checkpoint 调稳。我们遇到过不少“任务不报错但数据就是不对”的情况绝大多数和 checkpoint 配置不当有关。一个比较实用的配置是execution.checkpointing.interval: 60s execution.checkpointing.min-pause: 30s execution.checkpointing.timeout: 10min state.backend: rocksdb state.checkpoints.dir: hdfs:///flink-checkpoints execution.checkpointing.externalized-checkpoint-cancel: RETAIN_ON_CANCELLATION几点说明state.backend: rocksdb适合状态大的任务状态超过 1GB 不要用内存后端GC 会把你搞疯。checkpoint 间隔 60 秒、超时 10 分钟保证不会频繁失败。RETAIN_ON_CANCELLATION是任务停掉后保留 checkpoint 的关键配置否则任务重启后从无状态开始可能导致数据重复或丢失。实时任务的监控也必须有。我们用的 Prometheus Grafana 监控 Flink 的numRecordsInPerSecond、numRecordsOutPerSecond、checkpointDuration等指标。一旦吞吐量掉到历史均值的 50% 以下或 checkpoint 失败次数超过 3就触发告警。4.3 实时数仓的写入链路Kafka → Flink → Doris实时写入 Doris 的方式是用 Flink Doris Connector通过 Stream Load 协议批次写入。它的特点是延迟低秒级、吞吐高、支持去重。我们的链路大致是业务库 Binlog - Canal - Kafka(topic: ods_order_rt) - Flink(清洗/维度关联) - Doris(明细表/聚合表)注意几个细节Kafka 分区数不要试图通过增加分区来提升消费吞吐分区数超过 12 后收益很低反而增加 ZooKeeper 压力。Flink 消费 Kafka 时建议使用setStartFromLatest()或setStartFromGroupOffsets()不要每次从 earliest 消费否则任务重启时会积压大量重放数据可能压垮下游 Doris。Doris 写入的批次大小建议 10 万行或 20MB超过这个阈值往往不是吞吐瓶颈而是下游聚合和 Compaction 压力的来源。Doris 的模型选择也要注意。明细类数据用 Unique 模型带主键去重聚合类指标用 Aggregate 模型写入时直接 SUM/MAX/MIN。我们的大屏数据用的是 Aggregate 模型字段是sku_id date hour的粒度聚合。5. 数据质量保障比算法更重要的工程底线热搜词里有句话说得特别对“对于大数据而言最基本、最重要的要求就是减少错误、保证质量。”这句话从项目第一天起就要刻在团队文化里。数据质量有问题再漂亮的报表都是废纸。5.1 数据质量校验的“六性框架”我们做了一套数据质量校验体系主要分为六个维度维度说明检查方式示例完整性数据是否有缺失、空值非空校验、数量校验订单表 id 不允许为空唯一性主键是否唯一去重校验订单号不重复及时性数据是否按预期时间到达分区最大时间校验昨天分区必须在 08:00 前就绪有效性数据是否符合业务规则值域校验、枚举校验订单状态必须是合法枚举准确性数据是否与源一致总量比对、抽样比对订单总额与源库一致一致性跨表、跨口径是否一致指标交叉校验当日成交额 订单 × 单价两套口径对比每个数据表在建表时就要配套一张质量校验规则表每天调度跑完都执行校验失败就触发布线任务。DolphinScheduler 里可以很方便地配置“数据质量”任务节点。5.2 总量比对与抽样校验的实际案例总量比对是最实用的一种校验。管道清洗完的数据行数应该和源数据基本一致有合理差值范围。我们常见的一个校验 SQL 长这样-- ODS 层与源库行数比对 SELECT ods_order_info AS table_name, count(1) AS target_cnt, (SELECT count(1) FROM source_db.order_info WHERE create_time 2024-01-01 AND create_time 2024-01-02) AS source_cnt, abs(count(1) - (SELECT count(1) FROM source_db.order_info WHERE create_time 2024-01-01 AND create_time 2024-01-02)) AS diff_cnt FROM ods.ods_order_info WHERE dt 2024-01-01;如果diff_cnt / source_cnt 0.1%说明清洗逻辑有问题或同步丢失了数据立刻告警并停止下游任务。这种做法虽然土但比任何智能监控都可靠。抽样比对则是随机抽取 1000 行明细手工或脚本比对几个关键字段金额、状态、用户ID。我们在开发阶段每天做上线后每周做一次。真实案例是曾发现 ODS 层某个字段在同步时串列了导致几天的数据全部错位如果不是抽样比对这个问题可能要在周报阶段才被发现那时候的修复成本就高太多了。5.3 数据血缘与影响分析数据血缘是很多人都知道、但项目做到后期才知道其重要性的东西。我们用的是 Apache Atlas 来做血缘追踪配合 Hive 元数据。血缘的核心价值在于当上游一张表字段变更时能快速找出所有受影响的下游任务和报表评估影响范围做针对性的修改。没有血缘管理的项目出一次上游变更事故就要全团队排查两天。有了血缘一分钟定位到所有下游任务。尤其是 Flink 实时任务往往清洗逻辑很复杂一旦源表结构字段变了实时任务不会立刻挂反而会静默出错血缘能帮你在第一时间发现。6. 数据大屏的另一种思路后端聚合与前端展示的配合数据大屏是很多大数据项目的“门面”也是老板最爱看的东西。热搜词里出现了“avue-data 数据大屏前端是怎么部署的”说明不少人在纠结大屏技术选型。这里说说我的观点和实操方案。6.1 大屏方案选型开源组件、自研、商业产品怎么选大屏技术方案有三条路方案优点缺点适用场景开源组件DataV 开源版、avue-data、GoView上手快、免费、图表丰富定制化能力弱、性能遇到大数据量会卡追求快速出效果、数据量不大自研 ECharts 前端框架Vue/React灵活、可控、可定制开发量大、图表交互需要自己写对效果和交互要求高商业产品帆软 BI、FineReport功能完善、报表能力强贵、黑盒有预算且有复杂报表需求我们选了自研 ECharts Vue 的方案原因有两个一是大屏要展示的内容比较定制化地图下钻、3D 翻牌、自定义旋转动画开源组件模板改起来反而费劲二是后端接口本身就能做聚合前端不需要承载复杂逻辑。6.2 后端聚合接口设计一次查全量还是分批查大屏数据接口的核心问题是前端需要的数据往往不是明细而是多维度的聚合结果。如果每次刷新都让前端逐个请求几十个指标性能和体验都差。我们的做法是设计一个聚合响应接口一次返回大屏所有组件的数据{ code: 0, data: { gmv_total: 12567890.00, gmv_today: 356789.00, order_cnt_today: 12345, user_active_today: 67890, top_sku: [ { sku_name: 手机, sales: 123456 }, { sku_name: 电脑, sales: 98765 } ], hourly_trend: [ { hour: 00:00, gmv: 123 }, { hour: 01:00, gmv: 139 } ] } }后端处理逻辑分两步从 Doris 预聚合表查按小时、按主题聚合的数据比如dws_gmv_hourly_1d。在服务端拼装成组件需要的数据结构做字段名映射和格式转化。这个接口用 Java Spring Boot 实现只有约 200 行核心代码。每次大屏刷新走一次接口响应时间稳定在 50ms 以内。不要直接在接口里跑 Hive 或 Spark延迟不可控。6.3 大屏前端部署的兼容性与性能优化avue-data 这类组件在部署时有一个常见的坑静态文件部署到 Nginx 后WebSocket 或轮询接口要配好跨域CORS否则大屏能打开但数据不刷新。我们的自研方案没这个问题因为接口和前端同域部署。性能优化方面大屏页面的几个关键点按需加载ECharts 的按需引入非常重要完整引入 ECharts 会导致首屏加载多 1MB 以上。我们只引入 LineChart、BarChart、MapChart、PieChart 这几个类型。数据缓存短时间内的轮询数据做缓存比如 10 秒内的请求直接返回上次结果减少后端压力。定时刷新与 WebSocket 的取舍数据变化频率低于 10 秒的用轮询就够了如果要求秒级同步再考虑 WebSocket。大多数大屏的需求轮询完全能满足。部署时我们把大屏项目构建为纯静态文件Vue 打包后的 dist部署在独立的 Nginx 服务上反向代理配置/api路径转发到后端服务。整个大屏从开发到上线两个前端工程师两周完成后端接口开发加联调一周成本可控。7. 面试复盘项目笔记里最有价值的部分项目做完后最大的副产品就是面试时可以把整个项目的技术决策和踩过的坑讲得很清楚。我个人认为面试官最看重的不是你用了多先进的技术栈而是你对技术选型背后的权衡和教训有没有深入的理解。7.1 高频追问数据倾斜、小文件、拉宽表技术面试时几乎必问的问题集中在几个方向问题一数据倾斜你是怎么发现和解决的这是考察频率最高的问题。我的回答会按“发现-定位-解决-预防”四步展开发现靠 Spark UI 看 Stage 耗时定位靠看数据分布找出 Key 占比异常高的解决手段看具体场景是 MapJoin 还是加盐还是两阶段聚合预防靠平时的数据探查对大 Key 提前做处理。把 3.3 节的实际优化过程讲一遍面试官基本会满意。问题二数仓怎么处理小文件问题这个问题考察对 HDFS 元数据压力的理解。我们的方案是减少源头产生小文件Flink 的 checkpoint 文件不要写入数仓 ODS独立目录存储。定期合并小文件对 Hive 表执行INSERT OVERWRITE TABLE xxx SELECT * FROM xxx DISTRIBUTE BY rand()把小文件合并成大文件。控制分区大小hive.exec.dynamic.partitiontrue时注意手动合并分区防止每小时的 Tiny 分区产生过多文件。关注 NameNode 内存和文件总数监控提前发现风险。问题三宽表和窄表怎么选宽表怎么拉我的经验是分析场景用宽表统计加工场景用窄表。宽表拉取就是把星型模型的维表属性退化到事实表一般在 DWD 层做。建宽表时注意字段冗余度要可控不是所有维度都退化进去只退化那些高频使用的维度和枚举值。否则一张宽表一两百个字段开发和维护都很难受。7.2 项目笔记应该记录什么一句话的提炼才是精华最后分享一个关于“项目笔记”本身的心得。很多人记录项目就是记流水账今天部署了 Flink明天写了一个 SQL。这种笔记没什么用。我记录项目笔记的原则是每个模块只记三件事——为什么这么做、怎么做的、踩了什么坑。举个例2024-01-15订单实时指标采用 Doris Aggregate 模型而不是 Flink 聚合后写 MySQL。原因大屏的查询模式是多维度 ad-hocDoris 可以满足秒级查询且支持任意维度组合Flink 的聚合结果相对固化不够灵活。踩坑Doris 聚合模型对 REPLACE 字段的更新有严格顺序要求同一批数据重复导入会导致结果不稳定后来通过在 Flink 侧统一按业务主键去重解决了。这样一段笔记面试时可以直接变成很好的技术交流素材。面试官听到的不是“我用了 Doris”而是“我为什么用 Doris以及遇到什么坑、怎么解决的”这才是资深工程师和初级工程师的分水岭。7.3 给正在做大数据项目的你三个诚恳建议项目收尾阶段结合我和团队的实际感受给读者三个建议第一技术选型一定要回到资源和业务成熟度上。不要因为某个开源项目热门就强行引入。我们的集群规模其实并不大但通过合理的队列划分、数据分层和计算引擎选择十二台机器做到了离线加实时混合负载而且稳定运行了大半年。第二数据质量监控的优先级高于功能开发。很多团队把大屏、报表做得花团锦簇但底层数据经常延迟或出错。功能再漂亮用户问的第一句永远是“这个数据准不准”。从项目第一天开始搭建质量监控体系后面能省无数事。第三用文档记录代替口头沟通。每次任务调优、集群改动、数据结构变更都记录下来不管是对自己还是对后来接手的同事都是宝贵的资产。我这份笔记最初就是随手记在本地后来整理成体系后才真正发挥价值——既帮我理清了项目得失也让面试时的表达有了清晰的主线。大概就是这样。大数据项目没有业界公认的标准答案每个团队都是在摸索中前进。希望这份笔记能给你提供一些可以复用的经验少走几步弯路。如果你在项目里遇到过类似的问题或者有更好的解法欢迎交流讨论。