BDTC2017总结

发表于 | 更新于 | 评论数：

罗韩梅-资源调度

项目背景

  • 目标是整合集群硬件资源, 对外提供统一的标准接口, 海量任务的管理以及资源调配.

  • 自研 vs 开源. 开源主要是关注Yarn, Mesos, swarm, kubernetes. 使用开源, 减少用户迁移的成本.

  • 规模: 1.7亿container, 10000+资源,

  • 微服务

  • 介绍总体架构, 使用在线和离线混部, 利用不同任务的资源使用特点.

研发介绍

kernel方面

  • 增加了资源隔离的唯独, 包括了CPU, 内存, 磁盘容量, 网络出带宽, 网络入带宽, Disk IO, Buffer IO的控制.

  • 首先对于网络IO的控制, 主要是多个进程竞争网络带宽的时候, 需要提供带宽和时延的保证. 设计的时候, 希望能够设置弹性目标, 充分利用资源, 又保证配额不被占用, 并且支持优先级. 具体实现: ECN标记, 滑动窗口, 令牌桶…(tc+cgroups)

  • 对于Disk IO的控制: cgroup 通过识别pid控制磁盘IO. 但在buffer io中没有pid. 这方面做了修改. 并且解决了当前cgroups对io控制模式是hard(不会超过配额)的问题.以及解决io weight 通过cfq机制分割导致的数据波动我难题.

docker方面

  • bug fix
  • 热升级
  • 网络插件
  • 弹性内存控制
  • RBD插件

ceph

使用方便, 非hadoop 生态的东西, 用ceph比较多.

k8s

  • quota

  • APP
    引入Tapp

  • 网络模式

网络模式多种支持, 包括NAT, Host, Floating IP等.

  • 磁盘管理

  • GPU应用

  • registry: 做了相关的优化(P2P的分发等)

参考文献

原文slice

徐东-MaxCompute

max_compute 结构介绍

总体结构, metadata存储统计等信息. 底层使用分布式文件系统, kv等作为存储. 任务执行使用fuxi等调度系统. 上层提供了计算接口, 包括SQL, 图等.

SQL的软件层次

sql的三个层次, compiler(语法解析), optimizer(基于代价优化)以及runtime(用于执行具体的执行plan) (参考 llvm, hive)

数据分布

  • 做数据分布, 一方面是因为数据量的问题, 一方面是为了并行处理
  • 简单一致性模型, 认为多个分片的数据完全独立, 不考虑使用多个分片之间的关系.
  • 数据分布的方式有5种: hash, 排序按range, any(任意分), broadcast, singleton(类型spark中的collect, 集中到单机处理)
  • 多种数据分片方式之间可以通过一定的关系进行转化

  • 可以利用数据分布, 来对sql做查询优化, 举例来说:

这里, 下层先做table scan, 然后提供结构做join, 然后上层做aggregate. 如果使用的是sort merge join算法, 那么下层的数据就是排序好的, 在做aggregate的时候, 如果能够知道数据已经排序好, 就不用继续调用排序操作了. 这就是一个已知数据分布的优化方法. 这个优化要求各层操作之间能够互相传递消息.

  • 所以进行分布式计算过程中, 每个操作子可以选择算法, 可以选择数据分布的方式, 这些选择, 可以结合cost的预测, 做cost-based的优化

###分布特性搜集

做查询优化, 需要有统计信息, 需要数据分布的信息, 这些信息有两个来源:

  • 用户指定(也就是建表的时候, 通过sql语句指定分布方式)
  • 信息传递, 比如用了sort merge join, 后续可以记住这个sort的特点, 用起来

参考文献

slice 链接

曹龙-Hbase

阿里云三组件使用

组件 内部规模 公有云产品 主要功能
ODPS 7w MaxCompute 离线计算&机器学习
HBase 1.2+W 云Hbase 在线存储
Flink 数千 StreamCompute 实时计算

其中Hbase有几百个集群, 从4太到2000台都有, 数据量从几百G到10P.

Hbase使用场景

和各个系统搭配使用, 不同的场景有各自的需求.

Hbase部署模式

包括了线下物理机部署, 以及基于云的部署. 需要考虑售出价格机器使用率等因素.

最佳组合

下面的图展示了不同组件如何搭配, 以及数据流动.

常见的模型有

  • kafka => 流计算做实时ETL或者离线计算做ETL=>存储结果到HBASE
  • spark连接Hbase&Phoenix, 做HTAP, 进行一些spark方面的优化如谓词下推
  • Hbase 给MR提供数据. 或者通过消息中间件, 进一步导入ODPS&ES, 进行计算, 报表生成.

真实案例

  • 车联网公司, 上传数据, 通过流计算做数据清洗, 然后导入Hbase, 提供给spark做分析. 数据的特点: RowKey设计, 每辆车10s上传1K数据, 1年数据量3P, 100W台车

  • 安骑士: APP到HBase, 然后计算报表. 数据特点: 200T

  • soul社交: spark streaming 实时写入Hbase, Hbase用主备. 输入推荐结果到客户. 数据特点: 30T, QPS高峰 800w+

  • 金融公司: 导入Hbase做数据查询. 数据特点: 单表10000亿+. 数据量100T. 有多个字段的二级索引.

内核优化

  • 减少java的gc. 实现了ccsmap. 自己管理写缓存生命周期

  • jvm申请一块不用归还的内存自己管理

  • JVM的GC的优化

  • HDFS的串行pipeline 改为并发Quorum机制, 降低写抖动.

这边优化前后, YGCT 从120ms 降低到5ms.

  • 使用了ZSTD 压缩算法. 使用indexable delta encoding,

  • 添加了认证机制(user/password), 支持混合网访问

  • 使用bloom filter, 提高读性能. 减少写入量,提高写性能.

平台能力

未来

  • 现在是行存,OLAP不好, 增强分析的支持(如kudo,列存储, 索引)
  • hbase+spark
  • htap
  • 计算和存储分离

参考文献

原始slice链接

推荐学习资料

金海-内存计算

背景以及为什么会出现内存计算

  • 淘宝的例子, 每秒12w到25w笔交易, 数据量大以及实时性的要求, 需要低延迟的系统.
  • 使用内存计算, 相比基于disk的系统, 延迟从秒级到纳秒
  • 内存计算最早80年代就有, 现在兴起原因: 64位系统, 以及1T的内存的机器可以搭建了. 并且内存价格下降(今年变成4倍), 促进内存计算的发展.
  • 内存计算的好处: 比如SAP HANA, 以及内存文件系统为例子说明

内存计算的挑战

主要有四点:

  • DRAM介质易失性
  • DRAM的存储密度低, 要一个T就比较大了
  • DRAM的功耗高(数据:容量增大的时候,占系统功耗的46%, 其中用于刷新的静态功耗又占DRAM功耗的50%)
  • 内存子系统成本高(??)//查找IBM power 7子系统能耗比例

NVM相关

  • international technology roadmap for semiconductor

里面给出了集中存储介质的比较.

比如Memristor, PCM, STT-RAM,DRAM,FLASH, 以及HD. 现有的实际产品是Intel的3D xPoint.

  • SCM具有如下的特性: 字节寻址, 持久存储, 写比读高10倍延迟. 读延迟和DRAM接近. 比flash快1000倍, 存储密度以及耐久性都比NAND的flash高1000倍.并且0静态功耗. 使用这种器件, 有可能可以解决内存计算的 易失性, 存储密度低, 功耗高的问题. 很容易构建一台上T内存的机器.
  • SCM的存在, 从计算机的存储结构上来看, 有可能可以替代DISK, 从而改变整个存储层次.

另外一种可能的情况就是, 把PCM放在和DRAM一样的层次上, 出现计算和数据相结合的情况(也就是存储设备有计算能力)

一个使用NVM的内存计算的例子是HP:The Machine. 40个节点共享160T的内存, 是一个内存为中心的计算系统, 在各方面性能测试都很牛x.

NVM带来的挑战

对编程模型的影响

https://www.snia.org/forums/sssi/nvmp

有一个SNLA NVM Programming TWG这样的组织. 出了一个NVM Programming Model 这样的手册. HP 的工程师也做了相关的报告, 在这里

从例子来看, 就是传统的应用IO路径发生了变化, 比如绕过了文件系统层, 或者针对NVM做的文件系统优化.

混合架构带来的几个影响和挑战

对体系结构, 操作系统, 编程模型, 数据管理都有影响.

  • 体系结构: 1. 大内存与多和的内存带宽问题(带宽瓶颈, 做内存并行?). 2. 异构存储的管理问题, 比如NVM和DRAM是层次化组织, 还是采用并列的方式组织.

  • 操作系统: 1. 大内存, 页表大, 需要大页. 但是页太大, 有并发锁粒度大的问题. 2. 混合内存的情况下, 系统如何做任务的调度

  • 数据管理: NVM中的数据放置问题,用什么样的结构, 比如KV, 文件系统

  • 编程模型: 不再需要考虑磁盘IO以及数据持久化的问题

另外, 数据非易失, 存在安全性的问题, 有相关的攻击方式.

自己的一些工作.

混合内存模拟器

  • HME: A Lightweight Emulator for Hybrid Memory
  • Memory equalizer for lateral management of heterogeneous memory
  • hardware/software cooperative caching for hybrid dram/nvm memory architectures
  • MALRU: Miss-penalty aware LRU-based cache replacement for hybrid memory systems
  • Lifetime-based memory management for distributed data processing systems
  • mammoth gearing hadoop towards memory-intensive mapreduce applications(这里给出一些常见系统的分类统计)

分别是基于DRAM, NVM, 以及DISK的系统.

  • 认为发展趋势是存算一体, 也就是NVM本身有计算功能.

原始slice链接

舒继武-文件系统

背景等

  • 磁盘的局限, 包括能耗和体积. 出现了flahs, 以及SCM.
  • 对DRAM, PCM, NAND Flash, HDD的性能比较
  • 带来的挑战: 1. 存储设备访问变快, 软件的相对开销变大. 2. 现有的软件基于老的硬件做设计, 不能充分发挥当前新硬件的特性:

  • 所以, 对于大数据处理, 以及新硬件这块, 主要有两点变革: 1. 硬件方面存储结构的变革 2. 系统软件的变革.

  • 对于存储结构的变革, 主要是集中flash, pcie, sata接口等. 以及NVM的相关技术指标的介绍. 这些改变了存储层次结构.

  • 对于软件的变革, 主要:1. 硬件变快, 软件相对开销占比变大. 2. 硬件提供了新的接口给软件使用.

相关工作

  • 基于flahs的kv store(WiscKey,NVMKV,FlashKv)
  • 基于flash的文件系统(DFS,F2FS)
  • 基于flahs 的事务管理
  • 分布式闪存

NVM相关研究

  • 大数据,实时要求. 以及大内存, NVM的出现, 开始做内存计算
  • 相关的方向有: NVM的编程模型, NVM的内存空间管理, NVM的文件系统.

分布式存储的研究

  • 基于RMDA而不是以太网做互联. 速度更快, 软件的相对开销占比例更大. 代表的有Octopus 分布式文件系统

相关资料

slice链接