strata+hadoop参会感想

发表于

写在前面的话：一直想搞一个公众号，但是总觉得自己学的还很浅，没什么可以分享的。今天参加了strata+hadoop的会议，做了一些笔记，决定将他作为第一篇文章。自己对于spark的知识了解有限，难免会有一些错误的地方，还请大家海涵。感谢百度孙垚光师兄和腾讯沈洪师兄对笔记中错误的订正和耐心的答疑。感谢宜人贷王婷师姐的赠票。顺便欢迎大家明天去听听王婷师姐明天13点50在报告厅的分享《金融反欺诈中，社交网络算法有用吗？》。

文中按顺序是这些talk的笔记：

  • 基于Spark平台的智能大数据网络反欺诈 Yinglian Xie (DataVisor)
  • 用人工智能驱动金融生活 Cheng Li (蚂蚁金服首席技术官 (Ant Financial Group))
  • 基于Apache Spark的金融欺诈检测 王奕恒 (Intel)
  • 基于Spark SQL构建即席查询平台 孙垚光 (百度)
  • 从TDW-Hive到TDW-Spark-SQL: 腾讯TDW数据引擎演进之路 Hong Shen (腾讯)
  • Presto在优步：千万亿字节规模的交互式查询 罗震霄 (Uber)

基于Spark平台的智能大数据网络反欺诈 Yinglian Xie (DataVisor)

互联网欺诈攻击的四大趋势

  • 多种欺诈行为
  • 复杂欺诈产业链：分工
  • 潜伏期长
  • 各种欺诈工具辅助

群组欺诈：单个用户没有特征，但是多用户分析时群组内用户的行为一致

  • 第一笔正常交易
  • 第二笔一定时间间隔，大额欺诈交易

2016-08-05-221234

促销欺诈群组

  • 分为测试期，大规模注册期，攻击期

2016-08-05-221245

欺诈检测的发展

  • 黑名单，信用库，设备指纹
  • 规则系统
  • 有监督学习
    • 局限性，面临不断变化的欺诈者，模型不容易检测将来的行为。当收集到大量数据时，意味着欺诈高峰已经过去
  • dataVisor
    • 架构：date-》spark-》es+hbase-》实时性分析模块
    • 无监督群组检测
      • 自动检测
      • 自动产生标签
      • 自动产生规则

用人工智能驱动金融生活 Cheng Li (蚂蚁金服首席技术官 (Ant Financial Group))

传统金融->创新链接->金融生活

区块链/生物识别：去中心化的安全(区块链的去中心化是一个非常好的安全发展方向)

2016-08-05-221258

2016-08-05-221312

案例1： 蚂蚁智能客服：问题发现，问题理解（知识库收集），问题解决（知识库识别）。85%覆盖率70%解决

案例2：蚂蚁安全大脑：通过理解用户行为来预警风险
2016-08-05-221817

案例3：芝麻信用：

  • 与银行互补。7%的审核通过率，0.3%的逾期率控制。
  • 生活服务：租车，免押金酒店

2016-08-05-221851

基于Apache Spark的金融欺诈检测 王奕恒 (Intel)

2016-08-05-221908

2016-08-05-221926

特征提取

  • 类别特征->distinct，group by，etc
  • 数值特征
  • 特征分析

特征生成：（异常金额，时间间隔等）

流程：补全缺失数据->不平衡数据降采样->特征类型转换（woe）->归一化->整合

算法：神经网络，GBDT

做了bagging（soft voting）

神经网络做了Grid search自动化训练流水，对于关键参数进行遍历（模型个数，隐藏层个数，训练参数）

2016-08-05-222127

经验总结

  • 自动化训练流程
  • 根据特征特点进行变换
  • 参数选择，利用iv值减少grid search的特征选择范围
  • 多个模型共同云测

#基于Spark SQL构建即席查询平台 孙垚光 (百度)

即席查询(ad-hoc)

查询模式相对不固定，数据接近原始数据

交互式，需要较高时效性(10s)

2016-08-05-135506

基于spark做了什么

2016-08-05-135819

  • 易用：
    • Paas:用户不需要关心部署升级等
    • API
    • 概念抽象
    • Query粒度的资源消耗统计
  • 稳定
    • query持久化
    • 接入层无节点
    • 多维监控
    • 多租户
  • 安全/资源隔离
    • 多租户
    • 基于JVM沙箱层
    • 计算/存储框架层的安全认证
  • 性能提升
    • 查询与储存结合，解决IO瓶颈
      • 翻译优化
        • limit及时截断
        • filter配合索引使用
        • 列裁剪：嵌套字段内只load需要的列
        • 隐含等值条件
      • 规避慢节点（最重要，最优先考虑的问题）
        • 更合理的预测执行
        • 分发写（同时写hdfs的三个块，对比pipeline写）
        • 读写慢节点的切换
        • 控制集群压力
      • 增加索引（见图，索引作为文件单独存储）
      • 有选择的缓存数据
      • shuffle（见图）
        • 原生shuffle，基于磁盘的shuffle
        • 优化，基于内存的push
        • 对于即席查询，聚合效应明显，越往后数据量越少，更适合内存级的shuffle
        • 实现shufflerManager即可
        • 这个方案和不改变原生shuffle而将后面的存储映射为内存的优势在于：第一次持久化就可以持久化shuffle后的数据。
    • 减少框架开销
      • Map partition数目，reduce Partition数目预估
      • 根据query大小选择复用AppMaster或者重启AppMaster

2016-08-05-142037

2016-08-05-142701

后续规划

  • 批量query，流式query，ETL结合的一站式服务
  • 流式append数据

#从TDW-Hive到TDW-Spark-SQL: 腾讯TDW数据引擎演进之路 Hong Shen (腾讯)

Hive的瓶颈

缺乏对DAG（这里指的是hive on mr， hive on tez是选型的时候测试过，性能不如spark-sql）

基于MR，不支持cache

hive社区活跃度低

sparkSQL

DAG

基于RDD的内存计算

DataFrame可以和spark ml/streaming结合

2016-08-05-160026

功能增强

  • 兼容Oracle语法，支持窗口函数
  • 支持python udaf，udtf
  • 其他（抱歉没记全）

python udaf/udtf

通过编译成pyspark支持

2016-08-05-160059

我不太懂pyspark，这里找到了个参考文献，讲了一下pyspark的基本原理：

在python driver端，SparkContext利用Py4J启动一个JVM并产生一个JavaSparkContext。Py4J只使用在driver端，用于本地python与java SparkContext objects的通信。大量数据的传输使用的是另一个机制。
RDD在python下的转换会被映射成java环境下PythonRDD。在远端worker机器上，PythonRDD对象启动一些子进程并通过pipes与这些子进程通信，以此send用户代码和数据。

不过这里如果udf有外部依赖的包，是不是需要所有worker环境都预先装好这个包？

性能优化

调度策略改进

  • 问题：大任务长时间占用资源池，使得小任务难以占用资源
  • 原因：以executor为调度单位，调用粒度粗，资源释放慢
  • 优化：修改资源释放策略，有任务等待并且没有资源时大任务释放资源
    2016-08-05-160126

shuffle分区自动设置

  • 追溯输入，自动计算stage并行度
  • 自动调整cube，distinct等数据膨胀操作的并行度调整
  • 合并小文件（监控输出文件大小，如果平均文件大小低于阈值或者符合其他config设置，则增加一个stage将小文件合并）

sortMergeJoin优化

2016-08-05-160211

2016-08-05-210959

  • fetch大文件时直接写磁盘，减少序列化
  • 增加fetch线程，增加网络带宽利用
  • join sort排序移到map端

##稳定性优化

  • sparkDriver分散化

2016-08-05-160238

  • AM的OOM：减少AM的Accumulators，降低AM的内存
  • 推测执行的改进，推测成功后kill了正在运行的Task
  • 调度相关问题的bug（比如调度失败无限重试等）

效果：大约一半能在50%以上，同时节约20%的资源消耗

未来计划：

  • 多表join
  • 数据倾斜处理
  • 结合spark streaming提供流式服务

Presto在优步：千万亿字节规模的交互式查询 罗震霄 (Uber)

为何要引入presto

2015年的老架构

2016-08-05-212237

现在的架构，小数据跑presto，大数据跑hive

2016-08-05-212310

问题：HIVE实在太慢了->尝试presto。选型考虑了下面几点

  • presto比spark SQL快3到5倍（个人猜测可能和使用场景有关）。
  • drill和impala稳定性不好。
  • presto使用标准的sql
  • 开源

presto快的原因

  • all in memory
  • pipelining和streaming(几乎全程不写硬盘)
  • 列存储和执行模式（presto的执行模式是列模式，这是比tez等快的原因，这一条需要好好研究一下）
  • bytecode generation
    • inline virtual function calls
    • inline constants
    • rewrite inner loops
    • rewrite type specific branches（知道col的类型则省去代码中的switch判断）

2016-08-05-213346

资源管理

  • cpu
    • priority queues
    • short running querires higher priority
  • memory
    • query max memory pre node
    • query fails on hitting memory limit, prosto process continue running
  • Concurrency Management
    • queue: pre user max concurrent running queries

Limitations

  • 没有容错(针对秒级应用，任务失败重跑代价小，牺牲容错提高性能)
  • join 超过内存时会提示并且不能跑。设计的时候就是大join去hive
  • single coordinater（在uber场景中不影响）

uber的运行情况

  • 200node
  • 4000query
  • ad hoc sql query和real time application

选型

uber买的商业数据库 presto sparkSQL Hive
performance 很快 很快 较快 一般
Warehouse size 百TB级别 PB PB PB
SQL sport ANSI sql ANSI sql HiveQL HiveQL
NestedSchema NO YES YES YES
UDF 有自己的udf，支持地理相关的函数 有自己的udf，支持地理相关的函数 支持自定义函数，有第三方的地理相关函数 支持自定义函数，有第三方的地理相关函数
Memory limit 超过内存限制则终止query 不能操作过大的超过内存的join 大的join spill到disk 大的join spill到disk

注：因为uber自身的特点，他们很关注地理相关的udf的支持

parquet

文件格式，简单的说先横着切(row group)，再竖着切（column rack）。parquet最低端有个footer，是各种schema。

2016-08-05-212405

parquet improvement

select A,B from t where c=10;

延迟加载。footer里面有一个column rack的值的范围和dictionary，可以提前判断每个column rack里面有没有c=10，如果没有就跳过这个row group

columnar read： build prestp blcoks for each column, not reading row by row

一些正在做的事

  • schema evolution:处理嵌套。
  • 地理相关的支持
  • 性能优化：
    • 比如s.a这种嵌套结构优化为只读a不用读s整个
    • preedicate pushdown & dictionary pushdown
    • Lazy Reads & columnar Reads

另外我听speaker说：parquet默认的读取器居然是按行的，然后再拼成列交给parquet engine。但是这里我不是很确认我听得对不对，所以就大家需要自己验证

公开slides下载

写在后面的一些东西

今天主要是听了sql on hadoop的一些东西，有这么几个感受：

  1. spark sql他有一个巨大的优势就是因为基于spark，所以和spark streaming，spark mllib啊之类的都有很强的结合空间，至少是结合的想象空间。同时技术栈上的通用我感觉让学习成本和运维成本都降下来了。至少对于小公司，同时需要流式计算和sql on hadoop的话，感觉spark streaming+spark sql比storm+presto要容易一些。
  2. 每个开源软件都有自己的特定使用场景。之前我们测试的时候，我们对于presto不能handle大的数据集上的query这个事觉得囧囧的（师兄的测试报告）。但是今天uber的罗师兄表示presto就是要处理所有数据能放入内存的秒级别的query，为此甚至牺牲了容错，所以说选择开源软件一定要了解他产生时的特定场景和特定需求。
  3. 要学的东西还有很多。。。。

本文采用创作共用保留署名-非商业-禁止演绎4.0国际许可证，欢迎转载，但转载请注明来自http://thousandhu.github.io，并保持转载后文章内容的完整。本人保留所有版权相关权利。

本文链接：http://thousandhu.github.io/2016/08/06/strata-hadoop参会感想/