1、从互联到 To B 服务私有化部署对架构师的挑战张铎 神策数据席架构师职业涯简介豌荚基础架构，BI，消息推送14年-16年HBase，存储，数据库，云原，监控报警，研发效能16年-21年06年-14年易有道RSS 阅读器（前端后端都做过），分布式存储21年-今神策数据查询引擎，存储，中间件，数仓关于神策数据成 8 年+总部：北京 分公司：上海、深圳、合肥、武汉、成都、安等。业务辐射全国/全球企业客户成员 1200+总融资 19 亿+付费客户 2000+中国户为分析业技术与应标准定义者 成员规模业前列 创始团队均来百度，是国内第批互联数据践者，从 0 到 1 构建了百度数据分析平台 完成 2 亿

2、美元的 D 轮融资，由 Tiger Global、凯雷投资集团领投，明势资本、DCM、线性资本、红杉中国、华平投资、Bessemer Ventures、M31 资本、襄资本、五源资本、GGV 纪源资本跟投，凡卓资本担任本轮融资独家财务顾问 私有化案例占超70%覆盖业30+。融、互联、品牌零售、企业服务、科技、汽、融合媒体、互联+等。2018、19年连续两年荣获中国信通院评选的“最佳数据产品奖”与国家信息通信研究院联合发布中国户为分析业技术与应标准户为分析平台互联-To B 服务个的 SaaS 集群 上千个私有化部署集群为什么私有化部署123正常的架构师都会选 SaaS、集群商业模式、业务需求优

3、先于技术架构 除技术上做不出来不做私有化部署卖不出去 在国内，没有公司放把核数据给个创业公司 政策限制，有些业只能私有化部署Part 1 技术挑战混合部署使客户的 Hadoop 集群使客户的消息队列客户采集数据，再导神策客户 SDK 打点 nginx 仿照 SDK 转道，性能不理想 批量直接库，需要转换，不够实时 开发个 Flink 任务跑在客户集群上？怎么兼容？不让随便建 Topic各种版本，各种认证式减组件内存占内存不可压缩Java 程序 堆内存涨上去就不释放企业加资源 成本增加、很困难CPU 不够是慢，内存不够直接挂更精细的模块控制，客户不到的组件就不启动，节省资源 引新的 GC 算法，

4、让堆内存可以收缩(ZGC、Shenandoah GC)资源受限情况下的查询优化01020301针对户为分析场景定向优化 户为数据本身有序，重写 SQL，将 join 全排序变为归并排序 记录户最后活跃时间，过滤不活跃户 外连接消除 基数分组优化 查询资源预估 资源不够先等待，避免谁都查不出来 基于历史资源消耗预估，的越多越准确 神策数据数仓负载管理平台 让客户清楚的资源是怎么消耗的0203Part 2 （纯）技术挑战企业部署环境各种奇怪的限制和要求物理机，法按照要求挂载磁盘，扩容时候配置还不样 不给 sudo 权限，甚有把 sudo 这个命令的 binary 直接删掉的 多卡，不同机器组之间通

5、信不同的 IP 不通外，不让采集监控数据，服务挂了也不知道 开权限，但是不开认证；要加密，但是没有 KMS 如何兼容各种配置的机器前置检查，优先沟通，尽量推动客户改配置 在部署系统中抽象各种概念，例如随机盘，顺序盘，机器组，尽量确保在输机器配置之后，可以动成程序配置，需预 机器性能不达标？如果客户坚持就付费压测如何解决不让 root，不给 sudo的挑战安装时必须给 root，这个不能妥协，通常客户会接受运期可以不给 root 或者 sudoCDH 会不同户启动服务？研数据组件部署具，可以单户启动 为了兼容的 CDH 环境，部署系统需要持多户和单户两种模式 相对应的，各个服务不能假定的账号是什

6、么，需要由部署系统传 内部测试环境也不给 root，确保不会反复如何解决络环境复杂的挑战只有笨办法：使域名互相通信，配置/etc/hosts 来映射不同的 IP困难点：不同的组件 hack 法不致，操作成本很 Hadoop：增加配置强制使 hostname 来访问 datanode Kudu：配置 advertised_addresses Pegasus(skv)：只能 IP，没有办法 hack。正在推动社区持 FQDN更优解：和客户沟通，降低复杂度 有些特殊业没有办法，如融业，外部可访问的服务和内部服务必须放在不同的络分区，中间要有防墙 但具体哪些服务放哪边，还是可以谈的，谈的好能降低很多复

7、杂度如何解决不通外的挑战融客户常情况，政策要求，没有讨论的余地*没有政策限制的业，还是优先和客户沟通解决不通外，最的挑战就是监控和报警出不来监控可以本地看，报警必须想办法转出来 给报警机器增加 IP 名单，让客户可以请求神策的服务进报警 报警对接客户报警系统，让客户把报警邮件动转给神策 安排驻场专收报警（客户更倾向于这类属于免费增值服务）提前约定好，客户收到报警再通知我们，但处理时效就法保证了如何解决常规的认证加密先要搞清楚客户的真实需求 是真的要安全，还是“为了安全安全”提供各种兼容回退案 是不是开云硬盘加密就可以？提供模拟的 KMS 保存根密钥 如果是真的要安全，那么要坚持底线 安全不绝对

8、就是绝对不安全如何解决版本收敛上千家客户，数个组件，每个组件若版本跑在线上，乘起来是个天数字测试覆盖度够是保证复杂产品最终质量可控的必要条件不同组件版本绑定，升级起升 极降低 QA 作量 需要定位为软件公司，有统的开发和发布节奏设置中继版本，跨越版本较多时需要先升级到中继版本 任意两个版本都可以直接升级，版本多测试作量仍然较Part 3 变与不变架构师的职责业务可以正常运在可控的成本下运让技术架构 可以“撑”公司的业务互联 vs.私有化部署（业务场景挑战不同）规模，并发资源受限，场景复杂vs.案例：设计对象存储服务素材管理，需要个内部可以上传，外部可以访问并裁剪的存储服务 标准的对象存储服务，

9、最好直接云，但私有化部署如何确定哪个云？做个适配层，兼容各种主流云商的对象存储服务 客户不在云上怎么办？底层 HDFS，适配层需要持裁剪缩放 客户买了商对象存储要对接？就当 HDFS，不额外功能 库 VS 服务？还是需要服务，让使做各种配置不现实 但增加服务就要多耗资源，客户不愿意怎么办？做成标准的 HTTP 服务，提供嵌其他服务中的姿势 互联 vs.私有化部署（商业模式不同）运维成本相对不敏感运维成本直接决定死vs.案例：要不要加配置个后台合并 parquet 件的任务，同时合并太多容易 OOM，在个客户那跑不过去 最快的改法：加个配置，限制下单次合并的件数量，给这个客户配置 影响？配了影响合并速度，配了影响稳定性，不同客户配的还不样，需要培训运维和交付员，成本明显上升 结论：不要加配置。适应，能选的件全选上，代码动改成多轮合并，找个性能和稳定性的平衡点，减少运维成本写在最后不存在招鲜 业务需求变了，关注点然要变 要能搞清楚技术的极限 私有化部署到底能不能赚钱？最终归宿是不是仍然是 SaaS？谢谢