用户在搜索结果页停留了十几秒接连点开了三个商品详情页但最后没有下单。三天后他收到一条推送恰好是他收藏品类的优惠券。做增长的人看到这种场景第一反应是“召回策略”而真正让这个策略跑起来的是Hadoop里沉淀下来的用户行为数据。这篇文章不聊商业理念只讲我作为一线大数据开发怎么用Hadoop生态把“精准营销”从一句业务口号变成一条可运行、可归因、可迭代的数据链路。内容偏实战适合正要接营销需求的数据开发、数据产品以及准备大促前做用户圈选的运营同学参考。1. 为什么精准营销的项目最终绕不开Hadoop从业务问题反推技术选型我刚转到数据团队时接到的第一个需求就是帮营销部门做“高价值用户识别”。当时业务方抛过来的问题很简单但背后全是硬骨头。后来做得多了才发现精准营销的本质无非是回答三个问题而这几个问题恰恰是Hadoop生态最擅长处理的场景。1.1 业务方问的“三个问题”到底在向数据平台要什么第一个问题是“哪些人最可能买”。这句话翻译成技术语言就是需要把用户的历史订单、浏览记录、搜索词、收藏夹、优惠券领取记录全部拉出来加工成特征。比如“最近30天加购次数”“近90天客单价”“品类偏好Top3”。这些特征来自多张表、多种格式的数据而且量级是千万级用户乘以百级字段。没有分布式存储和批量计算这个特征工程根本跑不动。第二个问题是“什么时候触达他”。用户昨天半夜加了购物车和三个月前加过购物车营销策略完全不同。前者要的是“准实时唤醒”后者只需要“日常召回”。也就是说数据平台要能提供不同新鲜度的数据既有T1的离线标签又要能感知最近几小时的关键行为。Hadoop生态里离线的Hive/Spark负责T1流处理组件负责近实时两边共享同一套数据底座业务方不用关心数据到底存在哪里。第三个问题是“这次活动到底赚不赚钱”。一场短信营销发出去曝光、点击、下单、归因、ROI计算每一步都要能追溯。如果没有完整的行为日志链路运营只能拿着“最终订单数”讲结果而说不清楚是哪个渠道、哪个人群包带来的增量。这个问题要求数据平台具备全链路日志存储和离线分析能力HDFS恰好提供了这种廉价、可靠的原始数据沉淀场所。1.2 从T1到准实时Hadoop生态为什么依然是性价比最高的底座我见过不少团队一上来就要上Flink把所有链路都改成实时流。但冷静算一笔账就明白了大部分营销场景的决策周期是小时级到天级比如每日更新一次的优惠券人群包、每周跑一次的流失预警模型。真正需要秒级响应的是用户刚加购就弹优惠券这种场景它不是全部业务的主流。所以我的选型建议是以Hadoop生态为核心底座用Flink/Kafka做补充。理由有四条。第一HDFS是统一存储层离线训练、报表分析、临时探查都在同一份数据上不会出现“实时一份、离线一份”的口径打架。第二YARN统一调度资源批任务和流任务混布比每套系统单独建集群省一半机器成本。第三Hive和Spark的生态成熟度高网上能搜到的踩坑经验一大把招人也容易团队不至于被单一技术栈绑死。第四Hadoop周边工具链完整从DataX同步、Hue查询到Sqoop导入导出基本覆盖了数仓开发的日常需求。做个简单的选型对照你就明白了业务需求数据新鲜度要求常用技术部署成本用户画像离线标签T1Hive/Spark低大促人群圈选小时级Hive HBase中加购实时唤醒秒级Kafka Flink Redis高投放效果归因小时级/天级Hive/Spark低一句话总结不是Hadoop替代所有组件而是让Hadoop做最擅长的事——把海量历史数据存下来、算得动让实时系统去处理真正需要低延迟的那一小撮流量。1.3 技术选型时容易犯的两个错误第一类错误是“为了实时而实时”。有个同事接手过一个项目业务方说要“实时营销”产品经理把需求写成了“用户点击后10秒内收到推送”。结果架构组上了Flink、CEP、Redis全链路折腾了两个月最后发现真正要吃10秒时效的只有“加购未支付”一个场景日活不到几千人。大部分流量还是走T1更划算。我先问了业务方一个关键问题这条链路如果延迟半小时用户会流失吗对方沉默了于是我们把架构砍掉一半成本降了60%。第二类错误是“完全抛弃Hadoop只靠MySQL和Elasticsearch”。用户量在三百万以内时MySQL宽表加ES索引确实能撑住圈选。但当用户量涨到三千万、标签上千个的时候宽表行数爆炸、索引重建慢、ES集群调优能扒掉你一层皮。与其等到那个阶段再迁不如一开始就把数据和计算放在Hadoop生态里MySQL和ES只做结果集的查询服务。2. 数据管道先行埋点、采集与营销数仓的分层设计精准营销的数据基础远比模型算法重要。我见过太多项目死在“数据不准”上运营按标签圈了一百万人短信发出去退订率飙升一查发现埋点漏传了渠道参数。所以第一步不是写SQL而是把数据管道和数仓分层设计扎实。2.1 业务数据、行为日志、商品目录三类数据怎么进Hadoop营销分析离不开三类数据业务数据、行为日志和维表数据。业务数据包括用户表、订单表、优惠券表存在业务方的MySQL或PostgreSQL里。做法是用DataX或Sqoop每天增量同步到Hive ODS层。需要注意增量字段的选择最好用update_time而不是create_time否则用户改手机号、订单退款这类变更就漏了。调度上建议错峰执行别跟业务库高峰期撞车。行为日志包括曝光、点击、加购、收藏、下单这些埋点事件一般先打到Kafka再由Flume或Spark Streaming写入HDFS。这里最容易被忽视的是埋点字段的统一。一个事件至少要包含event_id、user_id、device_id、timestamp、page_id、item_id、campaign_id、channel_id这几个字段。campaign_id尤其重要没有它后面做活动归因就是无源之水。维表数据包括商品目录、门店信息、渠道映射表体量小但变化频繁建议每天从主数据系统全量拉一份放到Hive里并保留历史版本。这样以后做“商品类目变更导致的统计口径变化”这类回溯分析还能找到当时的真实维度。2.2 营销数仓的四层模型ODS、DWD、DWS、ADS里分别放什么很多做营销的同学不愿意搞分层觉得直接查原始表方便。实际上在Hadoop上做报表和圈选不分层就是灾难原始日志里一个字段改动所有下游脚本全部要改。我的习惯是严格按四层建模。ODS层保存原始数据业务数据库的表、行为日志的JSON都原样放进去只做最简单的分区通常按日期分区不做清洗、不合并字段、不改变结构。这一层的作用是“留底”出问题可以回溯。DWD层做明细清洗把JSON里嵌套的字段拆出来统一字段命名和类型过滤掉刷量、爬虫这类无效行为生成扁平的事件明细表。比如ODS里的原始日志到DWD层就变成了一个标准化的用户行为事件表包含user_id、behavior_type、item_id、amount等字段。营销分析里最常用的“用户行为宽表”就是从这一层开始加工的。DWS层做汇总以user_id为粒度把用户的行为聚合成宽表。比如“近30天浏览商品数”“近7天加购次数”“历史累计消费金额”每天都覆盖更新。这一层是画像标签的主要数据源也是圈选系统扫描频率最高的表。ADS层是应用层直接服务营销平台。比如活动人群包表、渠道效果报表、实时触发规则配置表。这一层的数据量不大但查询频率高通常会同步到HBase或MySQL供业务系统使用。2.3 用一份HiveSQL演示“用户行为宽表”的加工过程看一个具体例子。假设DWD层有张行为明细表dwd_user_event_detail我每天要跑一次任务生成用户最近30天的行为汇总。INSERT OVERWRITE TABLE dws_user_behavior_30d PARTITION (dt ${biz_date}) SELECT user_id, SUM(IF(event_type view, 1, 0)) AS view_cnt_30d, SUM(IF(event_type cart, 1, 0)) AS cart_cnt_30d, SUM(IF(event_type order, 1, 0)) AS order_cnt_30d, SUM(IF(event_type order, amount, 0)) AS order_amount_30d, MAX(ts) AS last_active_ts FROM dwd_user_event_detail WHERE ts ${start_ts} AND ts ${end_ts} GROUP BY user_id;这段SQL看起来简单但有几个关键点一是扫描范围必须用时间条件做分区裁剪否则全表扫描几亿行跑半小时很正常二是dt业务日期和事件时间ts要分开避免凌晨跑批时把今天的数据漏掉三是聚合粒度提前确定宽表里一个用户一行下游所有标签任务都复用这一份结果避免每个任务都重新扫一遍明细表。我在这里踩过一次很大的坑最早图省事在ADS层直接关联了明细表导致每个圈选任务都把几十亿行翻一遍YARN队列天天告警。后来严格做了DWS汇总任务耗时从40分钟降到3分钟集群压力小了一半。3. 用户画像与标签体系精准营销真正的分水岭数据管道通了下一步是画像和标签。这一步直接决定营销的“准”字怎么落地。很多项目的数据平台修得像高速公路但上面跑的车只有几张原始表没有真正有价值的标签体系那精准营销就无从谈起。3.1 事实标签、规则标签、模型标签的划分和落地口径做标签体系先别急着写代码先和业务方坐下来讨论“你要什么标签”然后分成三类来建。事实标签是直接从数据里读出来的比如性别、注册时间、所在城市、会员等级。这类标签最可靠但维度单一只能做基础筛选。规则标签是由业务定义、通过规则计算出来的比如“高活跃用户”“高购买力人群”“沉睡用户”。这里最大的坑是口径不统一。营销部说的“高活跃”可能是“近30天登录10次以上”运营部说的却是“近30天有5次有效加购”。同一个标签名两套计算逻辑最后圈出来的人完全对不上。模型标签来自机器学习预测比如“购买意愿分”“流失概率”“偏好品类标签”本质上是概率分和聚类结果。这类标签的更新需要跑模型任务周期通常是天级甚至周级不能像规则标签那样实时改规则。我习惯把三类标签放到同一张表里用tag_code区分标签类型计算方式更新频率示例事实标签直接读取维度表每天性别、城市、会员等级规则标签SQL规则计算每天/小时高活跃、高购买力模型标签机器学习预测每天/周购买意愿分、流失概率表结构可以做成长表user_id、tag_code、tag_value、business_line、version、update_time。长表的好处是新增标签不用改表结构但查询起来要行转列所以一般会再物化一张用户画像宽表给圈选系统用。3.2 三类标签的计算链路离线Hive、准实时Spark、在线特征不同标签对时效性的要求不一样计算链路也要分开。离线T1标签是主力每天凌晨通过Hive或Spark任务跑批把几千万用户的规则标签和事实标签全量更新一遍。推荐用Hive做基础聚合因为有现成的调度和血缘管理模型标签用Spark MLlib训练和预测因为算法库更丰富。给标签加version字段是个好习惯每次跑批写入新的version分区线上查询只读最新版本这样即使跑批失败也能回滚到上一版。准实时标签用于关键场景比如“近1小时加购”“正在浏览商品”通过Flink或Spark Streaming消费Kafka的行为日志实时滑窗计算后写入HBase或Redis。这里有个取舍不是所有行为都要实时化通常只处理对营销触达最关键的那几个事件比如加购、收藏、支付失败。在线特征则是供推荐或广告系统实时打分的轻量特征从离线特征表导出后缓存在Redis里key是user_idvalue是一个特征JSON。我见过一个典型错误是把几亿用户的全量特征一次性加载到Redis导致内存撑爆。正确做法是按活跃度分层只缓存近30天有活跃行为的用户其余用户特征落入冷存储。3.3 ID打通cookie、设备ID、手机号怎么在Hadoop里串成一个人用户画像最大的难题不是怎么算标签而是怎么确定“这是同一个人”。一个典型场景用户用手机App登录前系统只能拿到设备ID登录后拿到了user_id跨设备访问时又带上了另一个设备ID。如果这些ID串不起来你的“用户画像”其实是“设备画像”和“登录账号画像”的混合体圈人群时漏掉一半人。在Hadoop上做ID打通先做规则合并再做图计算。规则合并比较简单以登录user_id为主键凡是同一user_id下出现过的设备ID、cookie ID都挂到这个人名下。未登录行为先用device_id暂存等下一次登录行为出现后把device_id和user_id关联上。更健壮的做法是用图计算的连通分量。把每个可以关联的ID对看成图中的一条边比如{device_id, user_id}、{phone, user_id}然后用Spark GraphX或开源的图计算框架跑连通分量每个连通子图分配一个统一虚拟ID。实际跑下来效果很好但要小心一个坑如果某个设备ID是公用设备比如门店展示台的iPad它会把几十个真实用户串成一个人。所以规则里要加“活跃度过滤”设备ID关联用户数超过阈值就断开或者降级为弱关联。顺带提醒ID打通直接涉及用户隐私所有处理必须在数据安全规范下进行脱敏、权限管控、全链路审计都必须跟上这不是技术问题是底线问题。3.4 画像质量怎么验证不能只看“覆盖率”标签建完了不代表能用。我见过报表上写着“高价值用户覆盖率80%”结果点开人群一看一半人是纯新注册用户根本没产生过订单。原因就是没有做质量验证就直接上了线。验证标签质量我的经验是看四个维度。一是覆盖率标签非空用户数占全体用户的比例太低说明计算逻辑有问题太高说明标签没区分度。二是指标合理性高购买力标签下的用户客单价中位数应该显著高于全量用户如果不显著说明规则或模型没学到东西。三是时间稳定性同一个标签在连续两周的分布应该基本平稳如果波动超过30%大概率是上游数据质量抖动。四是和业务结果交叉验证比如“加购未支付”标签圈出来的人短信触达后的转化率是否真的比随机人群高。我日常工作里会把标签质量巡检做成一个定时任务每天输出一份异常报告覆盖率和分布突变直接钉到工作群。这样一来运营用标签做活动时心里有底数据团队也能及时发现问题。4. 人群圈选与触达链路从千万级用户里把目标人群捞出来画像和标签算好了接下来就是实战运营点几下鼠标从几千万用户里圈出一批人去做营销触达。这一步最考验工程实现因为运营等不了半小时脚本也不能拖垮集群。4.1 为什么直接写SQL扫宽表圈人会失败预计算与位图索引先还原一个真实场景大促预热期间运营想圈“近30天加购≥3次、客单价200、且不是近7天已触达用户”的人群。如果按照常规思路写一条HiveSQL去扫画像宽表会发生什么宽表几千万行几十个标签字段每个圈选请求都要启动一个MapReduce任务或Spark任务。启动YARN容器需要30秒扫描全表需要几分钟。运营在界面上调条件每调一次等五分钟基本就放弃使用了。更麻烦的是高峰期同时有二三十个圈选请求Hive连接池瞬间被打满还会影响正常数仓任务。正确做法是预计算加位图索引。把每个标签值映射成一个位图所有用户预先编号成0到N-1的整数ID每个位图里某位为1表示该用户命中这个标签。圈选“近30天加购≥3次且客单价200”时只需要对两个位图做AND操作千万级用户的位图合并压缩后几百KB单机内存里几十毫秒就能完成。位图在Hadoop生态里的落地思路是先建一张用户数字ID映射表再用Spark离线批量生成每个标签值的RoaringBitmap序列化后存到HBase或对象存储里。RoaringBitmap是业界用得最多的压缩位图库稀疏位图压缩比很高内存占用可控。这样圈选服务本身不再需要跑分布式任务变成一个轻量查询服务。4.2 RowKey与预分区HBase支撑触达系统高并发读取的实践圈选结果要落地成“人群包”支撑触达系统高并发查询用户列表。这类场景非常适合用HBase来承接。以我做过的一个方案为例HBase表设计成marketing:campaign_usersRowKey由人群包ID和用户数字ID拼接而成例如campaignId_reverse(userId)。这里关键的一步是用户ID反转因为HBase按字典序存储顺序递增的数字ID会导致写入全部打在最后一个Region上形成热点。反转后ID分布会被打散读写压力均匀很多。建表时如果不做预分区同样会遇到Region热点问题。我习惯按reverse(userId)的首位数字做预分区把表预先切分成10个Region。HBase Shell片段如下create marketing:campaign_users, info, {SPLITS [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]}实际写入人群包时每条记录就是一行Put列info:user_id、info:tag_version、info:campaign_id。触达系统查询时按campaign_id前缀scan每次调用都能在毫秒级返回一批用户ID。要注意给每行设置TTL营销活动最多保留60天不用手动清理数据。4.3 一次真实营销任务的后端全链路走读把上面的组件串起来看一次完整链路。假设现在是双11预热期运营在后台配置了一个人群包条件是“近30天加购但未购买的高活跃用户”。第一步运营在UI上勾选条件圈选服务读取HBase里的位图数据做合并计算这一步在200毫秒内出结果返回人数规模。第二步运营确认人数后点击“生成人群包”后端把人群包ID写入位图存储对应的独立表同时把该人群包的用户ID列表批量写入HBase的marketing:campaign_users表。第三步人群包调度系统读取HBase里的用户ID按每天可触达频控规则过滤一遍再分发给短信通道、Push通道和广告DSP平台。第四步当天所有触达行为通过埋点回流到Kafka最终落进HDFS供后面的效果归因使用。整个过程从运营点确认到人群包可投放耗时控制在5分钟以内。如果没有预计算位图和HBase这套组合靠运营直接跑Hive任务半小时起跳而且会把集群压得喘不过气。顺带说一句人群包结果必须存快照。因为后续ROI计算需要知道“这次活动到底发给谁了”如果人群包是动态口径过了两周再回算人数对不上归因就是一笔糊涂账。5. 效果回流与迭代循环归因、漏斗和模型再训练很多团队做完圈选和触达就算完成项目了。在我看来这只做了一半。精准营销要越做越准必须把投放结果回流到数仓再做归因和模型迭代。5.1 曝光、点击、转化如何关联成一条完整转化路径用户从看到广告到最终下单中间往往隔了好几个动作。要算清楚“这次营销到底贡献了多少订单”前提是把这串动作串起来。关键在于每次曝光和点击事件都要带上campaign_id、plan_id、material_id这些渠道标识并且在session维度上把行为黏连起来。举个实际例子用户在晚上8点收到一条Push点了商品链接但没买第二天上午搜索同类商品从搜索广告再次点进详情页这次下单了。如果只按最后一次点击归因这笔订单算在搜索渠道头上如果按首次曝光归因则算在Push渠道头上。这两种口径下的ROI差异非常大。所以我在数仓里专门维护一张渠道归因配置表由业务确认归因窗口期和归因方法。归因窗口期一般是7天也就是说用户在触达后7天内的转化都可以算作这次营销的功劳。5.2 在Hadoop上做简化版路径归因的SQL实现思路有了干净的DWD事件明细表路径归因可以用SQL来实现。我的常用做法是先把同一用户在同一session内的行为按时间排序再拼接成路径。SELECT user_id, session_id, campaign_id, CONCAT_WS(-, COLLECT_LIST(event_type)) AS path FROM ( SELECT user_id, session_id, campaign_id, event_type, ts, ROW_NUMBER() OVER ( PARTITION BY user_id, session_id, campaign_id ORDER BY ts ) AS rn FROM dwd_user_event_detail WHERE dt ${biz_date} AND campaign_id IS NOT NULL ) t GROUP BY user_id, session_id, campaign_id;拿到路径后再根据业务选择的归因规则做统计。如果是末次点击归因就取路径里最后一个带渠道标记的事件归属如果是首次曝光归因就取路径里第一个曝光事件归属。实际项目中还有一种简单的漏斗统计直接按“曝光数→点击数→订单数”做三层汇总能快速看出哪一层流失最严重。这里有个容易踩的坑session的划分标准。用30分钟无动作切分是常见做法但不同业务可能更适合15分钟或1小时。这个阈值必须在数仓设计阶段跟业务确认清楚不然后面所有归因结果都会存在系统性偏差。5.3 回流数据反哺模型和策略的闭环设计效果回流不只是做报表更关键的是让数据回到模型和策略里去。营销触达产生了结果数据包括送达、打开、点击、转化、取消订阅。这些结果回到数仓后和用户特征表合并就形成了一份带标签的训练样本。正样本是触达后转化的用户负样本是曝光未转化的用户。下一轮训练购买意愿模型时用这批新样本做增量训练模型的预测效果会比冷启动时好很多。策略侧的逻辑也一样。比如频控策略如果用户7天内已经被触达3次且没有转化就要把他加入“防打扰名单”限制后续投放。这个名单本身就是一趟Hive任务产出的依赖回流数据里的触达记录。没有回流策略永远是拍脑袋。我建议把这部分做成一个闭环调度串成每日工作流行为日志回流-效果统计-漏斗分析-策略规则更新-模型增量训练-人群包刷新。我见过不少团队在“圈选-触达”后就停了模型半年不更新、频控规则靠手工维护那精准营销就慢慢退化成了“大批量群发”跟精准两个字没什么关系了。6. 生产环境里最常踩的坑数据倾斜、小文件与资源抢占前面讲的是方法论和链路设计最后一个章节说说我在真实生产环境里反复踩过的坑。这些坑不会出现在官方文档里但只要你跑的量级上来几乎都会遇到。6.1 用户行为长尾导致的数据倾斜定位思路和两种解法营销数仓里最常见的数据倾斜源自用户行为的天然长尾分布。少数头部用户贡献了绝大部分行为在按user_id做聚合或join时这几个热点用户的key把绝大多数数据拉到同一个reduce任务里。具体表现是一个跑了10分钟的任务其他reduce两分钟跑完有一个reduce卡了半小时还在转。定位方法很简单看YARN上task的执行时间分布出现“中位数很低、最大值极高”的情况基本就是发生倾斜了。再看那个卡住的task处理的数据量通常远大于其他task。另外Hive的日志里会出现maxReducer耗时异常。解决办法有两种。第一种是加盐针对热点key做二阶段聚合。先给热点用户ID加一个随机后缀把数据拆散到多台机器上做局部聚合然后再去掉后缀做汇总。代码逻辑如下-- 第一步检测热点用户行为量超过阈值的user_id SELECT user_id FROM dwd_user_event_detail WHERE dt ${biz_date} GROUP BY user_id HAVING COUNT(*) 10000; -- 第二步热点用户加随机后缀打散非热点用户原样输出 SELECT user_id, salt_id, COUNT(*) AS cnt FROM ( SELECT user_id, IF(is_hot, CONCAT(CAST(user_id AS STRING), _, CAST(FLOOR(RAND()*100) AS STRING)), CAST(user_id AS STRING)) AS salt_id FROM dwd_user_event_detail_detail ) t GROUP BY salt_id; -- 第三步对加盐结果去掉后缀再聚合一次第二种方式更简单如果倾斜来自“用户表和小维表join”直接让小表走map join也就是broadcast避免shuffle阶段的倾斜。实践里需要用/* MAPJOIN(小表) */提示或者调高hive.auto.convert.join的阈值。判断用哪种方式我的标准是先看倾斜发生在聚合还是join聚合多数用加盐维表join多数用map join。6.2 营销标签表的小文件失控动态分区与合并策略做标签更新时最常见的手法是INSERT OVERWRITE动态分区写入每天按标签版本号写一个新的分区。动态分区一旦打开很容易产生海量小文件。我们曾经有一个标签表每天新增几百个分区每个分区里又有上千个几KB的小文件NameNode被几百万个文件压到报警。根因是动态分区的作业在写入时每个reduce会往每个分区写一个文件。一个任务有200个reduce、100个分区瞬间生成2万个小文件。解决方法有三个层面。第一控制写入并行度。在写入前对数据按分区键做一次DISTRIBUTE BY partition_key让同一个分区的数据尽量集中到同一批reduce里减少文件数。INSERT OVERWRITE TABLE tag_result PARTITION (tag_version) SELECT user_id, tag_code, tag_value, 20240101 FROM source_table DISTRIBUTE BY tag_version;第二用Spark的coalesce或repartition在写出前控制分区数量目标是一个分区一个文件如果数据源不大甚至可以把整个分区数据合并成一个文件。第三跑定期的合并任务例如每周对超过一定小文件阈值目录执行一次Hive的ALTER TABLE ... CONCATENATE或者用独立的Spark作业重写一遍分区。合并任务本身也会产生资源消耗所以我的原则是“尽量从源头控制合并作为补救手段”。6.3 YARN队列隔离营销临时任务不该挤占核心数仓任务营销任务有个特点平时安静大促前突然爆发。运营会临时跑大量圈选、预计算、人群包刷新任务如果不做资源隔离很容易把核心数仓的报表任务挤垮第二天早上老板看不到昨日销售数据那场面相当酸爽。所以要提前在YARN上把队列划分好。我常用Capacity Scheduler配置三个队列核心数仓队列占70%、营销队列占20%、实时任务队列占10%。营销队列的容量上限固定即使营销任务把20%吃满也不会影响核心业务。property nameyarn.scheduler.capacity.root.queues/name valuedefault,marketing,realtime/value /property property nameyarn.scheduler.capacity.root.marketing.capacity/name value20/value /property property nameyarn.scheduler.capacity.root.default.capacity/name value70/value /property property nameyarn.scheduler.capacity.root.realtime.capacity/name value10/value /property除了队列隔离还要做两件事。一是给营销任务设置提交白名单只有营销应用组的账号能提交到marketing队列防止开发同学手滑把任务提交到核心队列。二是大促前做任务预热圈选、标签、人群包这些重任务提前跑好结果别等当天临时抱佛脚。事实上大促当天最忙的往往不是队列而是沟通成本一群人在抢资源不如提前把活儿干完。最后说个我个人的体会精准营销项目能不能成很多时候不是模型多高级、实时组件多新而是数据口径和数据质量有没有先捋清楚。先和业务方把“活跃”“高价值”“可触达”这些词的定义写进数据字典再动手搭Hadoop管道能少走很多弯路。如果你正要接这类需求我建议先花一周时间把埋点字段梳理一遍再决定是不是要上实时链路。