聚水潭云原生OLAP架构的最佳实践
演讲人：溪竹、星毛 目录Contents 业务介绍 未来展望 OLAP最佳实践 数仓架构 01业务介绍 业务介绍聚水潭 SaaS ERP 聚水潭成立于2014年，以电商SaaS ERP切入市场，凭借出色的产品和服务，快速获得市场领先地位。发展至今，聚水潭已对接300+线上平台渠道，累计服务商家超过100W+。2020双11季全网处理订单总量达8.52亿，全国每发出5-6个包裹中就有1个来自聚水潭系统。 业务介绍数据智能 一款将“数据”融入业务，服务于“团队”的协同型产品 业务介绍数据智能 业务介绍数据智能 02数仓架构 数仓演进发展历程 升级期（2021年7月~至今）1.引入Dataworks+MaxCompute，启动统一数仓建设，简化运维、 强调模型规范，同ADBfor PostgreSQL形成双数仓架构2.引入Flink+Hologres，构建云原生实时数仓，试点HSAP业务架构，支持商家大屏、业务预警等实时场景3.基于Hologres持续探索实时数仓分层、计算资源统一调度、多租户、智能运维等 05 成熟期（2018年3月~2021年7月） Greenplum升级为阿里云数仓产品AnalyticDB forPostgreSQL，同时满足ETL+数据查询，后期为优化超大商家的查询体验，引入AnalyticDB for MySQL。 04 自建期（2016年9月~2018年3月） 基于开源Greenplum自建数仓，先期探索了大数仓模式，但由于商家众多，且增长速度快，最终选择了多数仓架构，采用同业务库相同的物理分库的方式。 03 探索期（2016年4月~2016年9月） 02 伴随沉淀，商家开始有数据统计分析的需求，业务数据库压力增加 01 公司初创期间，数据库以服务业务系统为主 数仓演进数仓架构 03 OLAP最佳实践 OLAP最佳实践预警产品能力 同1个Hologres集群，对外提供在线/分析两类服务场景 OLAP最佳实践物流预警技术链路 数据链路 当前量级日均处理数据量：18亿告警定时器量级：2亿+外置状态数据量：25亿/5TB OLAP最佳实践物流预警模型设计 CREATE TABLE public.dwd_jst_erp_lgst_alarm_test (co_id bigint NOT NULL,inner_order_id bigint NOT NULL,platform_name text,shop_id bigint,order_labels jsonb,shop_name text,alarm_type integer,alarm_stage integer,start_time timestamp with time zone,logistic_id text,logistic_company_id text,logistic_company_name text,timeout_time timestamp with time zone,rule_id integer,promotion_timeout_time timestamp with time zone,promotion_rule_id integer,custom_timeout_time timestamp with time zone,custom_rule_id integer,,PRIMARY KEY (co_id, inner_order_id, pt))PARTITION BYLIST (pt);CALL set_table_property('public.dwd_jst_erp_lgst_alarm_test', 'orientation', 'row,column');CALL set_table_property('public.dwd_jst_erp_lgst_alarm_test', 'storage_format', 'sst,orc');CALL set_table_property('public.dwd_jst_erp_lgst_alarm_test', 'binlog.level', 'replica');CALL set_table_property('public.dwd_jst_erp_lgst_alarm_test', 'binlog.ttl', '1800');CALL set_table_property('public.dwd_jst_erp_lgst_alarm_test', 'bitmap_columns', 'alarm_type,shop_id');CALL set_table_property('public.dwd_jst_erp_lgst_alarm_test', 'clustering_key', 'co_id:asc');CALL set_table_property('public.dwd_jst_erp_lgst_alarm_test', 'dictionary_encoding_columns', 'alarm_stage');CALL set_table_property('public.dwd_jst_erp_lgst_alarm_test', 'distribution_key', 'co_id,inner_order_id');CALL set_table_property('public.dwd_jst_erp_lgst_alarm_test', 'table_group', 'lgst_alarm_group');CALL set_table_property('public.dwd_jst_erp_lgst_alarm_test', 'time_to_live_in_seconds', '2592000'); Hologres如何实现10亿级，1W+qps，ms级在线分析一体化服务? 1.行列共存-满足高qps点查\olap查询\高频实时更新2.聚簇索引-文件内进行排序,快递定位block3.采用分区-实现商家级别物理分表4.位图索引-实现订单状态、的快速过滤5.字典编码-对基数小的列加速聚合查询6.分布键-实现数据合理的分布7.TableGroup选择-提升写入/查询并行度8.Fixed Plan（PK模型读写优化）9.表级binlog+Flink实时消费落地hologres满足告警日志分析 OLAP最佳实践物流预警架构迭代 现有链路不足 1.缺少订阅后长周期数据回放能力2.自建集群运维成本大3.订阅链路长，计算复杂4.实时链路数据复用度不高 迭代目标：Saas订阅能力升级，实现新增商家30天订单轨迹实时回放•2022-06，全商家实时计算，延迟问题频发、资源成本高（200CU）•2023-05，MaxComputeH+1调度+Flink实时订阅实现商家按需计算 OLAP最佳实践物流预警架构迭代 迭代架构•新增回放链路，支持长周期数据回放 •新增订阅逻辑，实现按需计算•从自建集群换成云组件(Lindorm)，降低运维成本，•实现轨迹相关实时公共层，便于后续业务展开 04未来展望 未来展望云原生OLAP 云原生 HSAP 1.更灵活的资源弹性，满足资源分钟级的弹性，自动感知业务流量的突增；2.更友好的多租户方案，满足多业务资源分时复用，业务负载互相不影响；3.更智能的运维能力，实现S级故障隔离、自动在线热升级，更专家级的自助服务 1.更灵活的表模型定义：再行列共存表的基础上，扩展明细、聚合等业务模型；2.更简单的实时处理链路：从binlog产生、订阅、ETL处理可以更透明；3.更强大的实时&离线一体化数仓能力：同Maxcmpute形成能力、资源的互补 —THANKS— 感谢您的观看
