01-从互联网到 ToB 服务 - 私有化部署对架构师的挑战-张铎

从互联⽹到ToB服务 私有化部署对架构师的挑战 张铎神策数据⾸席架构师 职业⽣涯简介 神策数据 ⽹易有道 RSS阅读器（前端后端都做过），分布式存储 06年-14年 豌⾖荚 基础架构，BI，消息推送 14年-16年 ⼩⽶ HBase，存储，数据库，云原⽣，监控报警，研发效能 16年-21年 查询引擎，存储，中间件，数仓 21年-⾄今 关于神策数据 成⽴8年+ 成员1200+总融资¥19亿+付费客户2000+中国⽤户⾏为分析⾏业技术与 应⽤标准定义者 •总部：北京 •分公司：上海、深圳、合肥、武汉、成都、⻄安等。业务辐射全国/全球企业客户 •成员规模⾏业前列 •创始团队均来⾃百度，是国内第⼀批互联⽹⼤数据践⾏者，从0到1构建了百度 ⼤数据分析平台 •完成2亿美元的D轮融资，由TigerGlobal、凯雷投资集团领投，明势资本、DCM、线性资本、红杉中国、华平投资、BessemerVentures、M31资本、襄⽲资本、五源资本、GGV纪源资本跟投，凡卓资本担任本轮融资独家财务顾问 •私有化案例占超70% •覆盖⾏业30+。⾦融、互联⽹、品牌零售、企业服务、⾼科技、汽⻋、融合媒体、互联⽹+等。 •2018、19年连续两年荣获中国信通院评选的“最佳⼤数据产品奖” •与国家信息通信研究院联合发布中国⽤户⾏为分析⾏业技术与应⽤标准 ⽤户⾏为分析平台 互联⽹->ToB服务 ⼏个⼤的SaaS集群上千个私有化部署⼩集群 为什么私有化部署 1 正常的架构师都会选SaaS、⼤集群 2 商业模式、业务需求优先于技术架构 •除⾮技术上做不出来 3 不做私有化部署卖不出去 •在国内，没有公司放⼼把核⼼数据给⼀个创业公司 •政策限制，有些⾏业只能私有化部署 Part1技术挑战 使⽤客户的 Hadoop集群 使⽤客户的消息队列 客户⾃⼰SDK打点 客户⾃⼰采集数据， 再导⼊神策 • • • ⾛nginx仿照SDK转⼀道，性能不理想 ⾛批量直接⼊库，需要转换，不够实时 开发⼀个Flink任务跑在客户集群上？ • 怎么兼容？ • 不让随便建Topic • 各种版本，各种认证⽅式 混合部署 减⼩组件内存占⽤ 内存不可压缩 Java程序 堆内存涨上去就不释放 企业加资源 成本增加、很困难 •CPU不够是慢，内存不够 直接挂 •更精细的模块控制，客户⽤不 到的组件就不启动，节省资源 •引⼊新的GC算法，让堆内存可以收缩(ZGC、ShenandoahGC) 01 02 03 资源受限情况下的查询优化 针对⽤户⾏为分析场景定向优化 01•⽤户⾏为数据本身有序，重写SQL，将join全排序变为归并排序 •记录⽤户最后活跃时间，过滤不活跃⽤户 •外连接消除 •⾼基数分组优化 02查询资源预估 •资源不够先等待，避免谁都查不出来 •基于历史资源消耗预估，⽤的越多越准确 03神策数据数仓负载管理平台 •让客户清楚⾃⼰的资源是怎么消耗的 Part2⾮（纯）技术挑战 企业部署环境各种奇怪的限制和要求 •物理机，⽆法按照要求挂载磁盘，扩容时候配置还不⼀样 •不给sudo权限，甚⾄有把sudo这个命令的binary直接删掉的 •多⽹卡，不同机器组之间通信⽤不同的IP •不通外⽹，不让采集监控数据，服务挂了也不知道 •开权限，但是不开认证；要加密，但是没有KMS •…… 如何「兼容各种配置的机器」 •前置检查，优先沟通，尽量推动客户改配置 •在部署系统中抽象各种概念，例如随机盘，顺序盘，机器组，尽量确保在输⼊机器配置之后，可以⾃动⽣成程序配置，⽆需⼈⼯⼲预 •机器性能不达标？如果客户坚持就⾛付费压测 如何解决「不让⽤root，不给sudo」的挑战 安装时必须给root，这个不能妥协，通常客户会接受 运⾏期可以不给root或者sudo •CDH会⽤不同⽤户启动服务？⾃研⼤数据组件部署⼯具，可以单⼀⽤户启动 •为了兼容⽼的CDH环境，部署系统需要⽀持多⽤户和单⽤户两种模式 •相对应的，各个服务不能假定⾃⼰的账号是什么，需要由部署系统传⼊ •内部测试环境也不给root，确保不会反复 如何解决「⽹络环境复杂」的挑战 只有笨办法：使⽤域名互相通信，配置/etc/hosts来映射不同的IP Hadoop：增加配置强制使⽤hostname来访问 datanode Kudu：配置advertised_addressesPegasus(skv)：只能⽤IP，没有办法hack。正 在推动社区⽀持FQDN • • • ⽅法不 hack 困难点：不同的组件 ⼀致，操作成本很⾼ 但具体哪些服务放哪边⼉，还是可以谈的，谈的好能降 低很多复杂度 • 有些特殊⾏业没有办法，⽐如⾦融⾏业，外部可访问的 服务和内部服务必须放在不同的⽹络分区⾥，中间要有 防⽕墙 • 更优解：和客户沟通，降低复杂度 如何解决「不通外⽹」的挑战 不通外⽹，最⼤的挑战就是监控和报警出不来 ⾦融客户常⻅情况，政策要求，没有讨论的余地 *没有政策限制的⾏业，还是优先和客户沟通解决 给报警机器增加IP⽩名单，让客户可以请求神策的服务进⾏报警 报警对接客户报警系统，让客户把报警邮件⾃动转给神策 安排驻场专⻔收报警（客户更倾向于这类属于免费增值服务） 提前约定好，客户⾃⼰收到报警再通知我们，但处理时效就⽆法保证了 • • • • 监控可以本地看，报警必须想办法转出来 如何解决「⾮常规的认证加密」 •⾸先要搞清楚客户的真实需求 是真的要安全，还是“为了安全⽽安全” •提供各种兼容回退⽅案 是不是开云硬盘加密就可以？提供模拟的KMS保存根密钥 •如果是真的要安全，那么要坚持底线 安全不绝对就是绝对不安全 如何解决「版本收敛」 上千家客户，数⼗个组件，每个组件若⼲版本跑在线上，乘起来是个天⽂数字…… 测试覆盖度⾜够是保证复杂产品最终质量可控的必要条件 极⼤降低QA⼯作量 需要定位为软件公司，有统⼀的开发和发布节奏 • • 不同组件版本绑定，升级⼀起升 任意两个版本都可以直接升级，版本⼀多测试 ⼯作量仍然较⼤ • 设置中继版本，跨越版本较多时需 要先升级到中继版本 Part3变与不变 架构师的职责 业务可以正常运⾏ 在可控的成本下运⾏ 让技术架构 可以“⽀撑”公司的业务 互联⽹vs.私有化部署（业务场景挑战不同） ⼤规模，⾼并发 vs. 资源受限，场景复杂 案例：设计对象存储服务 •素材管理，需要⼀个内部可以上传，外部可以访问并裁剪的存储服务 •标准的对象存储服务，最好直接⽤云，但私有化部署如何确定⽤哪个云？ •⾃⼰做⼀个适配层，兼容各种主流云⼚商的对象存储服务 •客户不在云上怎么办？底层⽤HDFS，适配层⾃⼰需要⽀持裁剪缩放 •客户⾃⼰买了商⽤对象存储要对接？就当HDFS⽤，不⽤额外功能 •库VS服务？还是需要服务，让使⽤⽅⾃⼰做各种配置不现实 •但增加服务就要多耗资源，客户不愿意怎么办？做成标准的HTTP服务，提供嵌⼊其他服务中的姿势 •…… 互联⽹vs.私有化部署（商业模式不同） 运维成本相对不敏感 vs. 运维成本直接决定⽣死 案例：要不要加配置 •⼀个后台合并parquet⽂件的任务，同时合并太多容易OOM，在⼀个客户那⾥ 跑不过去 •最快的改法：加⼀个配置，限制⼀下单次合并的⽂件数量，给这个客户配置 •影响？配⼩了影响合并速度，配⼤了影响稳定性，不同客户配的还不⼀样，需要培训运维和交付⼈员，成本明显上升 •结论：不要加配置。⾃适应，能选的⽂件全选上，代码⾥⾃动改成多轮合并，找 ⼀个性能和稳定性的平衡点，减少运维成本 写在最后 •不存在⼀招鲜 业务需求变了，关注点⾃然要变 •要能搞清楚技术的极限 私有化部署到底能不能赚钱？最终归宿是不是仍然是SaaS？ 谢谢