AI智能总结
平安银行大数据云原生实践(云数仓StarRocks) 孙钊 平安银行大数据运维架构师 目前负责平安银行大规模的大数据集群、消息中间件、搜索引擎和相关生态系统的技术运营管理工作,负责大数据信创体系建设,推动平安银行大数据云原生转型、降本增效等方向的工作。 01大 数 据现 有 架 构 02挑 战 及 创 新 03业 务赋 能 04未 来 展 望 大数据现有架构 大数据现有架构 挑战及创新 选型维度 选择StarRocks的原因 结合行内现状,针对主流OLAP引擎,调研了ClickHouse、Apache Kylin、Presto/Trino、StarRocks,优劣势如下: StarRocks &Clickhouse StarRocks1.x与Clickhouse差异不大StarRocks2.x的是Clickhouse的1.71倍 StarRocks & Presto/Trino TPC-H 100G StarRocks2.x的基于Hive外表查询总耗时为92.6s,Trino总耗时为298.9s,查询提升约3倍。 TPC-DS 500G StarRocks 2.x在1/3的计算资源情况下,查询性能已经超过Trino。 Worker数相同的情况下,和TPC-H的查询提升结果相近,都有约3倍的提升。 StarRocks &Kylin 基于不同维度及分区数的关联查询测试,在忽略Kylin构建时间成本情况下: StarRocks在无预热的情况下,部分查询kylin会有较大优势; 查询预热后,StarRocks查询命中Cache,对查询加速有非常大提升。 StarRocks存算一体架构 2022年引入基于StarRocks 2.x版本 FE(Frontend) 负责元数据管理、客户端连接,查询规划、查询调度工作 BE(Backend) 负责数据存储,SQL执行等工作数据存储:完全对等,负责导入数据并生成相关的索引SQL执行:SQL的物理执行单元会就近分派给数据存储节点,提供查询性能 弹性 资源隔离 成本 升级 •计算资源无法灵活扩展 •租户计算资源无法保证,容易抢占•同 一 份 数 据 不 可 以 在 多workflow中共享 •存算一体扩容节点,存储计算资源绑定•数据副本可能带来的浪费 •升级运维成本比较高•需要额外的工具进行滚动操作 StarRocks存算分离架构 2023年引入基于StarRocks 3.x版本 FE(Frontend)•将woker及shard调度工作移 交到了StarManager•FE只负责库表元数据及查询规划 CN(ComputeNode)•无状态,只负责Query的计算执行 •通过本地SSD提供缓存加速•BE的所有数据存储都交给下层存储 2023年配合全行云原生转型,采用StarRocksOperator 采用Kubernetes作为StarRocks底座。 •Operator负责监控k8s集群内的自定义资源的创建、改动、销毁等事件,并触发相应的逻辑。 •CRD用来定义CN的资源类型,通过声明式进行节点部署与管理。 •Controller会根据声明的信息创建Deployment,帮助我们管理集群的状态。 •利用Kubernetes HPA资源对象,使CN pod可以根据资源指标实现流量变化的自适应,自动弹性地扩充新节点或者销毁不需要的节点。 StarRocks计算弹性扩缩容实践 在创建Starrocks Cluster的时候,指定了HPA规则,基于CPU的使用率进行弹性的扩容,在查询高峰期CN节点自动弹性伸缩容。 策略:最小15个副本,最大25个副本 CN会在容器启动的时候,自动在FE中注册,容器销毁前,会主动在FE中删除 由于需要访问Hive外表,访问开启KerberosHadoop集群,对镜像进行以下改造 •镜像文件调整:部署Kerberos客户端、通过configmap将依赖配置文件(Hadoop、KDC)集成•修改FE和CN的entrypoint.sh脚本,启动crond进程,定时通过Kinit生成和更新krb5 cache StarRocks监控、自动化部署 •多维度集群监控 业务赋能 业务赋能-指标平台 构建指标“一处定义、多处使用”,数据团队一次定义指标口径,指标应用用户基于指标场景来使用指标,平台通过应用场景进行物化调度,来达到指标应用服务SLA指标需求 业务赋能-CDP 基于Starrocks的一站式湖仓融合的架构方案,实现准实时的秒级OLAP分析场景,为策略投放提供灵活、便捷的客群圈选、画像分析等能力,支持营销精准投放 未来展望 未来展望 混部调度引擎 Presto/Trino全面替换 通过Koordinator实现精细化调度,提升K8s资源利用率。 全面替换Presto/Trino,提升效率。 高效运维社区DevOps时代 荣誉出品 感谢大家观看