文章标题

Hadoop平台的优化

• 解决计算节点内存泄露的问题。因为每个计算任务在计算的时候，会产生大量的metrics数据，我们使用的Hadoop版本是CDH版本，如果在开启metrics信息收集的时候，会导致任务计算完毕后无法正常回收每个任务的信息，导致内存泄漏。Hadoop官方公布了该BUG，并在Hadoop 2.7及之后版本对该BUG进行了修复。

• Sqoop 抽取数据优化。Sqoop在抽取数据的时候，会根据主键对数据进行分布式抽取，开源sqoop版本对根据数据主键，进行均匀的数据切割，并分段抽取。但是平安的用户ID数据分布不均匀，大量的用户ID分布在某一两个抽取数据的任务上，出现长尾问题。通过修改开源代码，采用通过数据主键Hash来把数据分配到对应的数据抽取任务，实现任务数据的均匀分配，实际测试效果有一倍的效率提升。

• 引入新的计算框架。现有的分布式计算框架采用的是Hadoop的MapReduce，该框架目前是非常成熟稳定。但是最近目前大数据计算有Tez，Spark等产品对原有计算方式进行了改进，官方测试效率较MapReduce方式有了较多的性能提升。我们目前已经对Tez框架进行了相关测试，并在推进和DSP调度系统的集成。预计上线后，会对原有计算任务有30%的性能提升。

• 数据存储优化。优化分区表设计，对历史数据将小时分区合并为天分区。减少Avro数据表的使用，将部分avro表存储迁移到orcfile文件存储。

• ORC文件优化。ORC文件在证券数据具有超过的压缩比（千万级数据只有几M的存储空间），所以需要对传统的Hadoop和Hive参数进行调优。

DSP调度系统的优化

• 对各大数据平台使用方进行存储和资源的规范化管理。现在平台已经接入了理财，投顾，安全，APP，E行销等各个团队。各个团队可以通过DSP平台自由的使用自己团队的计算资源和存储空间，通过使用平台现有的资源，极大的提高了各团队开发效率。
• 对DSP上没用的任务进行了清理。删除了每天都失败的任务，已经离职无人管理的任务。对平台上经常出现报错的任务进行报表关注和进行邮件预警。方便了任务创建者的任务维护，也节约了任务重复运行导致的集群资源的浪费。把BI的计算任务改到单独的队列后，集群的负载大大降低。
• 跑历史数据任务管理。任务在没有控制之前，一个小任务如果并发的跑历史数据，很容易就把平台资源跑满，导致正常的任务得不到资源，无法正常调度执行。目前已经隔离跑历史数据任务和正常生产任务的资源池。
• DSP 任务监控报表
  每天执行时间大于平均值20分钟
  执行collect2的时间大于30分钟
  当前运行时间是以前的平均一个月的时间的2倍
  RS_DSP_JOB_EXCEPTIONS 历史表
  执行collect2 关键路径的job被禁用或者被删除
  每天job 比昨天延迟超过30分钟
  监控每天重复记录
  监控数据总量超过最近7天中间值的15%
  UI队列等待超过5的JOB

平台计算任务优化

• 调整任务的内存使用，为任务分配合理的计算内存，优化平台资源使用。

Hadoop平台的监控

• 接入Detector，对平台资源进行监控。接入监控后，在对每天任务执行过程中，可以很清晰的看到平台的整体负载情况，放表了后续的任务执行情况分析，进而有针对性的对任务调度进行优化。
• 配合运维对机器磁盘等硬件进行维护。

数据服务

• 互联网报表
• 集团个金风险相关指标
• 任意门数据，包括寿险保单开户、融e贷和灵活宝理财
• 两融分摊成本
• 证券收入数据
• 银行零售数据取用
• ES 外部数据支持