1、陌陌大数据平台在 SLA 驱动下的演进实践业务技术志源数据应数据资产1 数据产与保障2 数据使赋能3 基础能开放业务诉求离不开数据数据基础架构团队数据仓库|数据服务|数据平台团队介绍?HDFS Router Based FederationAlluxioHBaseKafkaYARN Federation With Node Label(Docker On Yarn)CPUMEMORYGPUMapReduceTezSparkFlinkTensorFlowK8SPyTorchMPIMorseHiveOozieDr.elephantKylinPhoenixDruid?团队技术栈 SLA:-科学量化合

2、理业务对数据产稳定性的诉求-持续提升系统迭代演进的客观衡量标准 保障 SLA 的盾:-主要盾:速增的业务诉求VS有限增的平台算-次要盾:平台算与服务复杂性VS服务运维管理能 我们的SLA定义:-核数据产出时间基础户属性|活跃情况|订单集成-数据就绪率基础数据|报表数据|产导出数据-数据就绪达标率,季度|SLA 稳定性SLA 问题需求增量(作业数量)算平(集群节点)SLA 表征(异常险)简单快速堆机器简单快速堆机器满需求增满需求增单机房容量与单集群性能限制算增机房与集群级平扩展能满算增多机房多集群复杂性引运维稳定性险1.01.0 阶段阶段2.02.0 阶段3.0阶段3.0 阶段4.0阶段4.0

3、阶段阶段需求规模需求规模(作业量:300 6000)作业量:300 6000)算规模算规模(集群节点:20 400)集群节点:20 400)需求规模(作业量:10000)算规模(集群节点:600)需求规模(作业量:40000)算规模(集群节点:1500)需求规模(作业量:100000)算规模(集群节点:2000)p 业务快速增:-数据仓库对外提供服务基础户属性|活跃情况|订单集成-直播业务速增基础数据|报表数据|产导出数据 解决思路:-服务扩容加机器计算节点|存储节点-需求优化数据流优化|作业参数优化-具与稳定性优重点环节具化1.0 阶段：2014 2016p 主要盾：速增的业务诉求与平台算V

4、S段简单的集群管理算扩展：平扩容算算挖掘：关键任务难以加机器解决稳定性：段简单，临时解决 特定任务节点单独优化:-数据模型与计算流优化中间表提取|JOIN 顺序调整-系统参数调优并度|数据倾斜优化 优化收益总结:-业务层改造成本低，但收益明显部分例 1完成|收益 90 分钟-50 分钟-边际效应同个作业难于持续获得收益-优化难于泛应，约束条件较多case by case 解决|Hive 本的 CBO 受限于版本 BUG1.0 阶段：算挖掘 特定任务优化 重点环节具化:-数据集成(DUMP)动重试|资源分配|数据校验-ETL 管理(COORD)结构规范|上下线 Review|屏蔽统调度系统配置-

5、数据导出(PUMP)降低为错误|快速恢复1.0 阶段：稳定性保证 具化需求增量(作业数量)算平(集群节点)SLA 表征(异常险)简单快速堆机器满需求增单机房容量单机房容量与单集群性能与单集群性能限制算增限制算增机房与集群级平扩展能满算增多机房多集群复杂性引运维稳定性险1.01.0 阶段2.0阶段2.0 阶段阶段3.03.0 阶段4.0阶段4.0 阶段阶段需求规模(作业量:300 6000)算规模(集群节点:20 400)需求规模需求规模(作业量:10000)作业量:10000)算规模算规模(集群节点:600)集群节点:600)需求规模(作业量:40000)算规模(集群节点:1500)需求规模(

6、作业量:100000)算规模(集群节点:2000)p 原 IDC 增瓶颈法扩容:-服务不能时间停服迁移存储服务|计算服务|流式任务-可现成运维具不服务监控指标采集不|资源管理混乱p 单集群出现性能压 SLA 不退化临挑战:-HDFS NN 法垂直扩容Memory:192 G-HDFS NN 启动耗时增加故障影响范围|影响时间 解决思路:-引擎升级(MR-Tez)整体作业计算效率提升-流式数据集成保证 SLA 在迁移与优化时间内不退化-机房平滑迁移数据量|时间紧-NN 启动优化启动模拟|参数优化|逻辑优化2.0 阶段：2017p 主要盾：业务诉求持续增VS平台算增遇到瓶颈算挖掘：满 1个季度需求

7、增算扩展：满算持续平增稳定性：扩容后的集群出现挑战 计算引擎升级(MR-Tez):-同任务引擎切换可以获得计算速度提升 20%30%计算 DAG 越复杂,迭代轮数越多提升越明显 Tez VS MR 收益来源:-计算作业直接翻译成 DAG VS 多个由 Map-Reduce 组成的 Stage更可控的 FailOver 节点-Stage 之间 HDFS 交互开销Shuffle 后续可插拔优化-动态 Container 申请更灵活的资源利效率Stage 4(Output ORDER BY)Stage 2(GROUP BY group.owner_id)Stage 1(GROUP BY vip.us

8、er_id)?HDFS?HDFS?HDFS?Stage 3(JOIN ON vip.user_id=group.owner_id)?GROUP BY vip.user_idJOIN(vip,group)GROUP BY group.owner_idOUTPUT ORDER BY2.0 阶段：算挖掘 引擎升级DBA-Redis-ServersDBA-MySQL-ServerRedis Instance ARedis Instance BRedis Instance CMySQL Instance AMySQL Instance BMySQL Instance C?Warden?Warden Re

9、plicationWarden ReplicationWarden ReplicationWarden ReplicationAOF logBinlogSpark StreamingParsing Change LogSpark StreamingParsing Change LogDataWarehouseHBase On HiveHBaseOn HiveHBaseOn Hive解决的问题解决的问题:数据集成完成时间(3:00-00:15)-技术重点:技术重点:-数据库 Change Log 向 HBase 数据操作转化-Change Log 的出错后回放修复-避免数据丢失的致性保证DBA-

10、Redis-ServersRedis Instance ARDB BackUp File ABackUp TransferDBA-Redis-ServersRedis Instance BRDB BackUp File BDump IntegraterRDB BackUp File ARDB BackUp File BRDB BackUp File ARDB BackUp File BDataWarehouseRDB BackUp File ARDB BackUp File BBackUp 2?Translate 2?Integrated 3?Load 3?2.0 阶段：算挖掘 流式集成 迁移

11、的关键点:-标:DataNode 迁移过程不停服-难点:节点多(600)|数据量(20P)|时间有限(60天)直接 Decommission 的问题:-耗时法接受场景下单节点耗时20时|并节点迁移下耗时更-Block 安置策略可能落回旧机房单个 Block 多次迁移造成浪费IDC-DX?.IDC-BX?.200G?迁移案(Fast Migrating):-DataNode 增加 Freezing 状态该状态下节点可读不可写-点对点镜像复制 DataNode 具(Rsync 数据同步)时间缩短到 8时每机柜|整个机柜并迁移2.0 阶段：算扩展 集群迁移 HDFS动态拓扑:-遇到问题:遇到问题:D

12、N 镜像节点注册后量报 Block Under-Replicated 触发件块复制-原因:原因:HDFS 机柜拓扑启动时加载|新节点所属机柜信息缺失|触发副本放置策略(本机|机柜|其他机柜)-解决法:解决法:Dynamic Topology CLI 命令动态加载拓扑配置 其他问题:p 迁移流量造成 Flume 写 HDFS 件关闭超时出现租约未释放现象p NameNode 内存紧张情况下迁移启动时间较甚异常退出p 迁移流量在交换机层合理分配，切换卡bond充分利络结构提升迁移效率2.0 阶段：算扩展 迁移遇到的问题 资源拆分隔离:-YARN 队列拆分当时运维段简单-HDFS Quota 拆分固

13、定拆分2.0 阶段：稳定性保证p挑战：集群规模，NN启动耗时较-1500 DN|6亿 Block|10亿 INODE，重启耗时 60分钟(多轮 Full GC)-运维管理低效，出现故障后恢复成本 HDFS启动耗时问题p挑战：测试环境规模太，产环境不能拿来做验证-海量 DN 块汇报不好复现-产 NN 法 Debug34%16%1%49%Loading FsimageLoading EditsSaving CheckPointSafe ModeStartServing能不能模拟出产环境？2.0 阶段：稳定性保证 单集群性能优化TestNodeNameNode(Active)NameNode(Sta

14、nby)Mock DataNode(MultiThreading)FsimageCopy FsimageParseBlock ReportsMockDN 阶段:测试 NN 启动，MockDN 模拟产块汇报-解析 FSimage分配每个DN归属 Block 信息(id,length,timestamp)-多线程模拟 DataNode单机可以模拟 1500+DN 阶段:性能优化-参数调优-JVM 参数调优-NN参数调优-多线程模拟 DataNode-块汇报优化(限速,合并 IBR,独线程 RPC Queue)-锁优化(IBR 合并后的写事务合并)，减少锁争-Protobuf 协议优化提序列化和反序

15、列化效率-统调度类调度 SendHearBeat 和 Block Report时间降低时间降低 40%40%（同产配置）（同产配置）2.0 阶段：稳定性保证 HDFS NN 启动优化需求增量(作业数量)算平(集群节点)SLA 表征(异常险)简单快速堆机器满需求增单机房容量与单集群性能限制算增机房与集群级机房与集群级平扩展能平扩展能满算增满算增多机房多集群复杂性引运维稳定性险1.01.0 阶段阶段2.02.0 阶段阶段3.03.0 阶段阶段4.04.0 阶段阶段需求规模(作业量:300 6000)算规模(集群节点:20 400)需求规模(作业量:10000)算规模(集群节点:600)需求规模需求

16、规模(作业量作业量:40000):40000)算规模算规模(集群节点集群节点:1500):1500)需求规模(作业量:100000)算规模(集群节点:2000)p 单集群瓶颈逼近:-NN 优化收益成本增加内存容量|RPC 队列容量|RPC 响应速度-SLA 故障隔离域问题不同业务之间 SLA 不同|降低业务互相影响p 单机房依旧存在瓶颈(2000):-业务场景更加丰富需求持续增多业务线与团队使数据 解决思路:-分治拆分HDFS Federation|YARN Resource Model-计算优化Kylin 降低需求固化模型|Alluxio 内存件加速3.0 阶段：2018p 主要盾：需求场景

17、更多复杂度上升VS算受限于单集群红线与机房瓶颈算扩展：满算持续平增算挖掘：新技术解决更多问题Federation(New)Ns1Ns2Ns3Ns4FileNum(Million)2762966738BlockNum(Million)4222964043Memory(GB)1171081815 关键点:-NN 单集群红线(件数 6亿 件块数 10亿)-切分后的数据迁移会有量的存储与络开销FastMV:并创建 Block 硬链接避免真正的件拷|标:-平扩容 NN 撑更的业务场景-故障隔离域-更近细化的参数调优3.0 阶段：算扩展 HDFS Federation Kylin 应:-业务场景稳定的报表

18、类需求持维度固定|稳定需求|降低开发成本 解决的问题：-抽象动 Build 组件打通 ETL 调度系统依赖检查|动重试|失败与产出延迟报警-集成公司可视化报表系统拖拽维度筛选|透视表构建3.0 阶段：算挖掘 OLAP场景应场景1：数据态的存储访问缓存层，加速 Ad-hoc 查询以及ETL产场景2：分布式计算的中间存储引擎，优化Shuffle、SavePoint等IO性能 陌陌场景 集群部署单机配置部署模式CPU：32 核内存：72G(总196 G)硬盘：HDD层Alluxio Worker 混合部署HDFS DataNode&YARNNodeManager&SparkExecutor根据场景需

19、求 HDD 层交给 HDFS，并避免 Alluxio内部内存与硬盘间数据换换出各服务组件分别使 Locality 能保证 整体收益 较原案实际产情况，时间开销优化 35 倍-不同输数据量级下性能提升程度不同-例如，任务场景下由于 Spark 内存缓存管理机制Alluxio优化不明显3.0 阶段：算挖掘 Alluxio 内存件系统需求增量(作业数量)算平(集群节点)SLA 表征(异常险)简单快速堆机器满需求增单机房容量与单集群性能限制算增机房与集群级平扩展能满算增多机房多集群复杂性多机房多集群复杂性引运维稳定性险引运维稳定性险1.01.0 阶段阶段2.02.0 阶段阶段3.03.0 阶段阶段4.

20、04.0 阶段阶段需求规模(作业量:300 6000)算规模(集群节点:20 400)需求规模(作业量:10000)算规模(集群节点:600)需求规模(作业量:40000)算规模(集群节点:1500)需求规模需求规模(作业量作业量:100000):100000)算规模算规模(集群节点集群节点:2000):2000)p 主要盾：更的服务标准与运维复杂度 VS 团队成员资源有限之间的盾p 多集群多机房精细化管理-轻客户端户感知升级迁移-统资源管理 解决思路：-DPW 研服务运维平台基础户属性|活跃情况|订单集成-多机房多集群统管理HDFS Router|YARN Router-Tez-Spark

21、引擎升级&优化引擎升级|查询复|Spark AE-流式计算计算负载打散|实时批处理错峰p 集群算的更充分利:-在离线峰资源错配？4.0 阶段：2019算挖掘：持续优化提算效率稳定性：多机房多集群下运维复杂性上升Agents(Deployed On Cluster Node)?Collecters(AggravationsThe Metrics)?解决问题:-区分多服务与多集群常运维管理操作服务启停|滚动升级|集群扩容|节点上下线-异构化配置管理持基于标签异构|配置版本管理|快速配置回退-集群服务节点元信息管理服务分布|业务分布信息-服务指标采集仪表盘与报警规则HDFS|YARN|HBase|K

22、afka etc.4.0 阶段：稳定性保证 DPW 集群管理平台p问题：户不清楚属于哪个集群-HDFS 9（Federation：6）|YARN 4|-统 Schema URI|统 ACLSp问题：集群升级与迁移，需要业务更新客户端配置-业务需求：透明感知集群运维Multi-ClustersNameService1NameService2NameService3ClientWhich One Should I Use?Multi-ClustersNameService1NameService2(Old)NameService2(New)ClientGet From Ns2 Migration4

23、.0 阶段：稳定性保证 多机房&多集群管理 HDFS Router:-状态的访问组服务，兼容 NN 访问协议(HA,Fail Over)-持多种外部状态存储，配置访问策略(Local File,ZooKeeper,DBMS,HDFS)NS1NameNode(Active)NameNode(Stanby)NS2NameNode(Active)NameNode(Stanby)NSnNameNode(Active)NameNode(Stanby)DataNodeDataNodeDataNodeDataNodeState StoreLocalFileZooKeeperHDFSDBMSRouterRou

24、terRouterMemberShipMountTableRouterRouterRouterQuotaUpdateServiceRouterSafeModeServiceHttpServerAdminServiceRouterMetricsServiceRouterHeartbeatServiceRouterRpcServiceNameNodeHeartbeatServiceStateStoreServiceClientXauthorizeadd auditlogadd client ip YARN Router With Kerberos:-YARN-6539|YARN-9811IDC-B

25、XNameService1NameService3RoutersResourceManager1(The Old One)ResourceManager2(Kerberosed)NameService7?(Kerberosed)?IDC-RZ?4.0 阶段：稳定性保证 HDFS Router&YARN Router4.0 阶段：算挖掘 引擎升级 计算引擎升级(Tez-Spark):-同任务引擎切换参数调优可获得计算平均 35%使默认参数迁移优化不明显，需要针对作业调参 Spark VS Tez 收益来源:-资源重Executor 次申请多轮 Stage 可复-计算流程数据本地化Spark 轮本

26、地化但后续 Stage 数据本地化 VS Tez相反-CodegenSpark 由 SQL 成原代码|Tez 根据成 pb 件反序列化成-更丰富的动优化策略COUNT(DISTINCT)动改写|EXIST/IN 动优化|字节对 ETC.Spark 查询复:-集群存在很多相同查询重复计算较多旧查询复制修改|仓库建模不合理让业务频繁 JOIN 基础表4.0 阶段：算挖掘 查询复&Spark AE算Fragment占作业占复段次数 57.88%16.98%查询深度 23.57%8.22%解决的案:-查询缓存阿的 Relation Cache|Hive 3.0 Materialized View|Ca

27、lcite-数据查询中提供查询集市增加查询重复占|统计算径-结果：Ad-hoc 作业平均时间降低 30%，查询时90分位数降低 25%Spark AE:-资源动态调整(INTEL 案)SPIP|Runtime Skewed Join 解决的案:-优化 Spark 查询引擎性能Shuffle 合并多线程|BroadcastJoin-合理分配各查询任务资源利率分Stage独申请计算资源-结果：复杂性查询能带来就计算时间 10%主要技术点:-Flink SQL 化持开发中|Schema DDL 管理|Hive MetaStore 集成-Kafka Manager动成迁移计划|TImeMachine|

28、Traffic Control-Flink 优化Auto Rescaling(FLIP-53|FLIP-56|FLINK-12002)解决问题:-负载在时间维度分摊计算引擎升级(MR-Tez)-数据时效性提升业务价值（时间就是钱）实时推荐与模型在线训练|活动效果及时评估策略优化-避免数据线EventDrived Arch|Reatime DataWarehouse4.0 阶段：算挖掘 流式计算1.02014 20162.020173.020184.02019需求规模户组数5104080作业量级60001W4W10W算规模节点规模40060015002000部署机房1112集群数量11存储:4|计算:2存储:9|计算:4挑战业务快速增IDC与单集群性能瓶颈多IDC多集群架构改造精细化透明化管理解决思路快速加机器与特定作业优化机房迁移算扩张与引擎升级算挖潜分治之更程度平扩展分久必合与流式消峰填总结(a)图a:核数据产出时间(三年)图b:数据就绪率(两年)总结(b)