基于Spark与NoSQL的实时数据处理实践

1、基于Spark与NoSQL的实时数据处理实践技术创新 变革未来概要关于我（们）数据、流程和架构业务诉求技术和架构挑战和方案未来展望数据流程和架构主要数据来源AppAnalyticAddTrackingGameAnalytic数据流程和架构数据内容设备信息业务信息上下文信息设备ID设备软件信息设备硬件信息业务事件会话信息行为状态网络位置传感器数据流程和架构数据体量2.5/6.5亿+日/月活跃智能设备活跃设备370亿每天处理事件事件(日志)数17T+每天新增日志量存储大小数据存储离线数据处理Data CollectorJenkinsSpark Core/SQLYARNAlluxioHDFSGree

2、nPlum数 据 流 向Kafka实时数据处理JenkinsSpark StreamingYARNHDFS数据流程和架构数据收集数据接入智能App数据采集MySQLHDFSAlluxioHBaseScyllaDBMCDataCloudDataATM数据应用OpCenterSDMK概要关于我（们）数据、流程和架构业务诉求技术和架构挑战和方案未来展望业务诉求新的数据处理、服务诉求数据修正时序数据事件数据时间修正（离线计算：数据到达延 迟）面向实体或者指标的时序数据需求（离线计 算：时间断面）面向实体，实时数据处理位置数据丰富实时处理面向实体，多维度、多值、多版本的查询实时查询业务诉求面向实体，多维

3、度、多值、多版本的查询实体智能设备、位置（GeoHash、网格）、wifi、基站单个实体多个维度信息：ID、软/硬件信息、环境多维度信息单个维度信息多个值：wifi1、wifi2多值多版本 单个值多个版本：wifi1-ts1、wifi1-ts2举个例子概要关于我（们）数据、流程和架构业务诉求技术和架构挑战和方案未来展望技术和架构选型因可扩展高吞吐高容错较成熟与其他组件好集成原不保证数据有序管理工具不够完善主要 劣势数据接入-Kafka技术和架构因可扩展高吞吐高容错支持窗口函数支持SQL技术统一调度、资源管理统一原微批、延迟高主要劣势实时数据处理-Spark Streaming选型技术和架构选型

4、因可扩展高吞吐高容错较成熟低延迟 (vs HDFS)Free Schema原运维成本相对较高(compact、split、flush)延迟不稳定(GC、缓存命 中)主要劣势数据存储-HBase技术和架构选型因可扩展高吞吐高容错低延迟延迟稳定原项目较新Bug、使用坑多主要劣势数据存储-ScyllaDB技术和架构ScyllaDBHDFS（Bitmap）中间件规则引擎Data CollectorKafkaSpark Streaming智能AppHBaseSDMK用户应用概要关于我（们）数据、流程和架构业务诉求技术和架构挑战和方案未来展望挑战和方案可降级至HBase集群热备？成 本较高HFile备份基

5、于容器 快速重建集 群热备：可 切换至业 务线集群KafkaSpark&Yarn整体原则：故障告 警，人工介入切换、 重启、重建HBaseScyllaDB服务稳定性挑战和方案Region数量扩容Region数量扩容Streaming并发数、CPU、内存Docker实例 扩容容量预估Topic分区数量扩容KafkaSpark&Yarn整体原则：根据同 比、环比数据量情 况，预估下月/下 季最大容量HBaseScyllaDB挑战和方案数据正确性&一致性让批次幂等：针对每个partition的数据产生一 个uniqueID，只有这个uniqueID 相关所有数据都被完全计算，才算 成功，否则失败回滚

6、。如果重复执 行到uniqueID，会跳过。一些建议使用HBase的version特性去重， 保证数据没有重复Spark Streaming + Kafka保证 “at last once”根据业务定方案没有银弹挑战和方案Spark Streaming-性能稳定性问题方法大存储SSD盘推测执行Kafka topic 个数 Spark reblanceSpark反压Spark控量数据量突增慢节点问题Yarn不稳定(Docker容器)将Docker宿主盘从系统盘迁移至1T 的SSD盘1.操作是幂等情况下才可开启推测执行。 spark.speculation=true2.将量比较大的topic分区数

7、加大3.使用spark的reblance算子1.通过spark控制每秒的量:saprk.streaming.kafka.maxRat ePerPartition|spark.streaming.re ceiver.maxRate，2. 开 启 spark 的 反 压 机 制 ： spark.streaming.backpressure.e nable， spark.streaming.backpressure.initialRate（Direct模式不行）Docker宿主盘使用服务器系统盘，Spark作业大的shuffle爆盘数据不均衡或者节点负载高等原因 导致某节点作业处理相对较慢应用故障恢

8、复后、流量新高峰等原 因导致spark处理淤积挑战和方案Spark Streaming-优雅的停止在独立线程事件触发调用ssc.stop(true, true)1.定义事件，比如HDFS上标识文件、 监听socket、启动RESTfull服务等，并调用ssc.stop(true, true)；2.触发事件。其他事件触发发送SiGTERM信号给作业的Driver1.设置 spark.streaming.stopGracefullyOnShutdown为true；2.在Spark UI上找到Drive所在节点；3.登陆节点找到Driver进程ID；4.执行kill -SIGTERM 。发送SIGT

9、ERM信号挑战和方案Spark Streaming-其他建议spark.streaming.kafka.maxRetriesspark.yarn.maxAppAttemptsspark.yarn.am.attemptFailuresValidityIntervalspark.yarn.max.executor.failuresspark.yarn.executor.failuresValidityInterval挑战和方案HBase-性能稳定性问题方法自控策略预分区持续监控&优化Major CompactRegion SplitMemStore FlushFlush Queue大小、频次，HF

10、ile大 小、个数磁盘、网络IO，堆内存使 用波动等根据数据情况估算分区大小及分区 个数，并预分区建表关闭 MChbase.hregion.majorcompaction=0。单rs每次处理region个数(根据期望 执行的时间长度定)可能会阻塞客户端请求，占用服务 器资源Region Split导致region短暂下线， 如果有数据热点情况会恶化Major Compact会消耗大量的磁盘、 网络IO，引发原因有：挑战和方案HBase-其他建议paction.large/smallhbase.hstore.flusher.counthbase.regionserver.optionalcach

11、eflushintervahbase.hregion.memstore.flush.sizehbase.hregion.memstore.block.multiplierhbase.hregion.percolumnfamilyflush.size.lower.boundhbase.regionserver.global.memstore.sizehfile.block.cache.sizehbase.regionserver.global.memstore.size.lower.limit（hbase.regionserver.global.memstore.lowerLimit）挑战和方案面向实体 VS HBase数据模型多版本多值多维度实体TableColumn FamilyColumn Family QualifierVersion值作为HBase的列名维度作为HBase的列族名:imei，wifi相对时间作为HBase的version，HBase列不赋值挑战和方案大时间窗口查询及整体存储量tdid1 , imei1 , bitmap1,2,3,5 tdid1 , imei2 , bitmap4 tdid1 , wifi1 , bitmap1,2,3 tdid1 , wifi2 , bitmap4,5多版本多值多维