基于Spark-Streaming的实时计算服务平台.pdf

基于Spark-Streaming的实时计算服务平台廖晓辉@京东Agenda•技术要点•运行和监控•Logging•示例展示•典型问题•性能调优实践实时计算服务是？•目的：–将通用的功能或可公用的资源平台化服务化，让用户专注实时业务处理逻辑的开发，用SQL或SDK，要简单高效。•相关的计算环境：–便捷的数据导入/流式数据接入–稳定可靠的流数据–多租户资源隔离，处理能力弹性扩容(吞吐量及响应时间)，容错机制(考虑恢复成本和运行时成本)，数据的严格有序到达和无序，及消费的有序无序……–结果数据获取WhySpark-Streaming?•用SparkStack解决Batch以及Streaming处理问题，不需维护多套Framework。•YARNintegration•长期演进考虑项目背景•京东云数据开放服务—云海•实时计算需求–提供实时交易、实时流量等指标–有等价的T+1离线计算指标•需将T+1离线计算的指标转化为实时指标•T+1离线计算复杂SQL转化为实时增量计算模式，并提供低延迟的实时结果–数据源为订阅线上关系库实时变更以及过滤后的结构化流式数据–计算过程需关联历史数据：事实表关联，维表数记录数多数据量大–低延迟、准确和可靠性–……实时计算处理流程AppSQLConfigurationOutputFields<FA,FB,FC,…>TableAJoin&FilterTableBJoin&FilterProcessJoin&FilterTableBAggregation,DistinctCount,…<Expr(…)asFA,Expr(…)asFB,…>……Spark-StreamingApponYarnDataSourceConnInfoKafka,RocketMQTableJoins->HBaseintermmediateTableHBaseGetwithrowkeyHBaseResultTablecoprocessorMySQLKafkaRESTfulAPIAppRedis实现技术要点•24/7StreamingApp–ContinuousRunning–Failover处理–每天处理~10B消息–秒级延迟•实时Metric，异常监控报警–上下游监控•限流及异常恢复–位点重置，故障预案•完善日志–帮助尽快TroubleShooting，缩短异常到恢复时间•实时应用开发配置化、SQL化LaunchApponYarnAppConfigurationSample监控示例实时应用效果展示Logging典型问题•Block还未进行计算就因ttl的设置而删除，导致notfound错误典型问题Cont.•HBase读写速度优化–解决办法：•RowKey设计•并发附：用HBaseIncrement的原子性做汇总计算，做到一个指标可拆解为多个App，结果叠加，简化计算逻辑，提高并发。•INFOAMRMClientImpl:Waitingforapplicationtobesuccessfullyunregistered.–一般是由于配置文件不正确引起，比如线上环境与配置环境打包是混淆。典型问题Cont.性能调优•问题1：建立一个数据接收流进行数据接收，数据会存放于接收work及备份work上。在任务调度时考虑到数据本地性，task调度到接收流和副本所在两个work上，其他work空闲，形成计算不均解决：1）设置多个接收流2）通过repartition调节RDD中partition数量，将task调度分散，使得计算均匀。•问题2：reducetask数目不合适解决：默认为8，需根据实际情况进行调节。可调节参数spark.default.parallelism。通常，reduce数目设置为core数目的2---3倍。数量太大，造成很多小任务，增加启动任务的开销；数目太少，任务运行缓慢。性能调优-Cont.•问题3：shuffle磁盘IO时间长解决：可以设置spark.local.dir为一组磁盘，并尽量设置磁盘为IO速度快的磁盘。通过增加IO来优化shuffle性能。•问题4：map/reduce数量大，造成shuffle小文件数目多，default:shuffle文件数目为maptasks*reducetasks解决：通过设置spark.shuffle.consolidateFiles为true，来合并shuffle中间文件，文件数为Cores*Reducetasks数目。性能调优-Cont.•问题5：GC或OOM问题严重解决：调整spark.storage.memoryFraction。Default:0.6。Further，观察app运行过程中的GC实际情况，进行其他调节。•问题6：blocknotfound解决：调整spark.clea