原生并行图助力机器学习和可解释性 AI 林选磊

2020-03-01 161浏览

9.图数据库计算效率的优势 Caller Callee 105 103 105 UserID Phone 122 123 ... ... 112 109 User001 101 101 123 ... ... 102 155 User001 102 ... ... .. ... ... ... User001 103 102 111 … ... ... ... 103 122 ... ... 两表关联要做全表检索，执行效率低，在没有索引时复杂度为 O(MxN) User001 © 2019 TigerGraph Inc. All Rights Reserved 101 123 102 155 1. 只取相关的数据 2. 并行执行 103 111 122
11.图特征提取和可解释性AI 特征 1：面积特征 2：房间数特征 3：卫生间数结果：价格训练数据 1 80平方 2 1 200万训练数据 2 120平方 3 2 300万预测数据 100平方 2 2 ? 任务训练数据基于图的特征计算全新机器学习方法可解释的接口通过图的可视化、数据探查和特征，使得模型可解释性增强 © 2019 TigerGraph Inc. All Rights Reserved = 我懂了
18.常见社区发现算法算法无向边有向边 GSQL代码行数 Connected Components Yes N/A 44 Strongly Connected Components N/A Yes, with reverse edges 169 Label Propagation Yes N/A 49 Louvain Modularity Yes N/A 301 Triangle Counting Yes N/A 20https://docs.tigergraph.com/graph-algorithm-library© 2019 TigerGraph Inc. All Rights Reserved
23.时间消耗 ● 5000条数据拆分为两部分，测试集 ● 神经网络按固定的学习率进行训练 ● 当经过225次迭代后，对验证集的预测准确率达到90%，此时验证集的成本函数值最小 cost function 4000条数据，验证集1000条数据 Accuracy reaches 90%, after 225 iterations. ● 每一次迭代消耗0.77秒，225次迭代不超过3分钟 number of iterations © 2019 TigerGraph Inc. All Rights Reserved
25.了解更多 • • • • • 软件、硬件要求：https://docs.tigergraph.com/admin/admin-guide/hw-and-sw-requirements下载开发者版本：https://www.tigergraph.com.cn/developer/安装指南：https://docs.tigergraph.com/admin/admin-guide/installation-and-configuration/installation-and-configuration安装指南Docker：https://info.tigergraph.com/docker-tigergraph技术论坛：https://community.tigergraph.com.cn© 2019 TigerGraph Inc. All Rights Reserved
26.
27.大数据分析与存储实践专场
28.如何构建“正确”的云平台存储系统王为 wei.wang@zstack.io
29.自我介绍 • 上海云轴(ZStack)核心架构师。负责 ZStack 私有云的网络、存储领域多个产品特性的研发。 • 在 ArchSummit、PyCon 等大会中做过技术分享。 • 向 OpenStack、MidoNet、Buildbot 等多个开源项目做过贡献。在 Linux 的网络、存储领域有着丰富的经验。
30.目录 • 一个云厂商的存储之路 • 将存储做正确有多难 • 形式化验证是银弹吗 • 混沌工程：我想和云存储谈谈 • 存储错误注入
31.一个云厂商的存储之路
32.ZStack 的存储之路 • ZStack 是一个极致产品化、高性能、智能的私有云平台 • 在做云平台的前几年，我们一直借助开源存储：OCFS2、XFS、NFS…… • 因为所有做过基础架构的人都会因存储诡异的报错信息、可怕的调试难度、惊人的破坏力而敬而远之
33.ZStack 的存储之路 • 2015~2018 Ceph Community + OCFS2 + Local Storage + … • 2018 SharedBlock 接管 SAN Storage • 2019 Mini Storage
34.SharedBlock • 完整发挥物理性能 • 极低延迟 • 快速部署 • 对 SAN 厂家、品牌无要求
35.Mini Storage • 近乎完整物理性能 • 低成本 • 快速部署 • 高稳定性
36.将存储做正确有多难
37.PostgreSQL vs fsync() • PG 使用 writeback 的机制，这样系统可能在后台默默 writeback 时出错 • 此时 IO layer/XFS 会对脏页做 AS_EIO 标记，调用 fsync() 时返回 EIO • 但 fsync() 实际上存在一个未文档化的、clear-error-and-continue 的机制 • 也就是你下一次再调用 fsync() 时如果没有新的标记的脏页，可能就返回成功了！https://archive.fosdem.org/2019/schedule/event/postgresql_fsync/
38.All File Systems Are Not Created Equal • 上层开发者往往认为崩溃一致性是最基础的保证 • 实际上崩溃一致难度也是很高的 • 从文件系统到数据库，已经被大家找出无数 Bughttps://www.usenix.org/system/files/conference/osdi14/osdi14-paper-pillai.pdf
39.离散碎片的环境 • 与互联网厂商解决的问题不同，但难度一样不小： • 不同厂商的存储设备 • 不同厂商的多路径配置 • 不同的服务器硬件
40.参差不齐的客户运维水平 • 客户升级条件不同有的客户希望部署完再也不要升级…… • 联网条件不同一些客户机房连手机都不允许进 • 运维水平不同客户说：我觉得……
41.漫长的路径 • 平台 API、Agent 下命令、DM 设备操作、分布式锁、多路径、SCSI、HBA…… • 控制平面和数据平面同样重要 • 甚至控制面具有更可怕的破坏力
42.形式化验证是银弹吗
43.TLA+ 的发展之路 • 2002 年 Specifying Systems • 2015 年 How Amazon Web Services Uses Formal Methods • 2018 年 TLA Workshop • 被 MongoDB, Elasticsearch 等应用
44.形式化验证所不能解决的问题 • State Space Explosion • 无法转换成代码，因此在翻译时可能出错 • Spec 的正确性如何验证 • 外部依赖的正确性 • 但涉及算法正确性的证明，形式化证明依然是不可替代的
45.未来的形式化验证：可视化https://github.com/will62794/tlaplus_animation
46.未来的形式化验证：易读http://tla2018.loria.fr/contrib/liu.pdf
47.未来的形式化验证：可执行https://github.com/UBC-NSS/pgo
48.混沌工程：我想和云存储谈谈
49.为什么现在都在说混沌工程 • 单机应用向集群应用 • 基于系统编程向基于服务编程 • 对于基础设施软件可以借鉴吗？
50.不谈方法说概念都是耍流氓 • MTBF 长时间运行，随机动作 • DPMO 反复迭代测试 • Woodpecker 数以万次的调用 API
51.注入什么错误？ • 传统方法： poweroff tc ifconfig • 传统方法的缺点：对复杂场景无法模拟不够灵活
52.云厂商面临的存储路径
53.存储错误注入
54.用户态错误注入：libfiuhttps://blitiri.com.ar/p/libfiu/
55.内核错误注入：systemtap • 优点相对灵活函数级别易于安装 • 缺点速度慢达不到 IO 级别
56.故障块设备模拟：device-mapper • dm-flakey 周期性故障 • dm-delay 增加延时
57.故障块设备模拟：NBD
58.总结 • 设计阶段形式化验证可以减少设计的 Bug 但并不是银弹，有成本，有局限 • 开发阶段开发可测试代码注重测试注重错误注入
59.总结⼿手段层⾯面便便利利程度灵活程度模拟特定模式 libfiu ⽤用户态很⽅方便便限制较多不可以 scsi_debug 内核态比较⽅方便便限制较多不可以 systemtap 内核态比较复杂比较灵活可以 device mapper 内核态比较⽅方便便限制较多不可以 nbd - 复杂非常灵活可以
60.总结
61.
62.