1、刘成彬 资深大数据开发|StarRocks在游族的多维分析场景01历史背景历史背景02StarRocks优势优势03应用场景应用场景04未来规划未来规划目录目录 CONTENT|历史背景01|历史背景|痛点1.维护多套组件，运维成本高2.各组件SQL语法存在差异，开发维护任务成本高3.同指标数据下，需要保证不同组件计算的结果与口径都一致的成本比较高4.结果数据比较大时，MySQL性能比较差诉求|为了解决我们的痛点，并且能够适应公司未来的实时查询需求，我们需要统一OLAP引擎，选择引擎至少需要满足以下要求：数据秒级写入，低延迟毫秒级响应复杂场景多表关联查询性能好运维简单，方便扩展支持高并发易用性
2、强，开发简单方便StarRocks优势02|StarRocks优势|极致的查询性能分布式执行框架(MPP)列式存储引擎全面向量化引擎CBO优化器StarRocks优势|丰富的导入方式Broker LoadSpark LoadStream LoadRoutine LoadInsert IntoStarRocks优势|运维简单不依赖外部组件，方便缩扩容丰富的数据模型支持明细/聚合/更新/主键 四种数据模型，同时支持物化视图简单易用兼容MySQL协议，支持标准的SQL语法支持多种外部表MySQL,Elasticsearch,Hive,StarRocks,Apache Iceberg,.应用场景03|
3、实时计算场景/家长监控中心|家长监控中心截图 数据流转图离线覆盖实时写入DataAPI实时更新模型选择|主键模型与更新模型对比更新模型：使用merge on read的方式，在执行时实时合并多个版本的数据主键模型：使用delete and insert 的方式更新数据，主键存储于内存中主键模型不能使用delete方式删除数据|主键模型无法使用delete的方式删除数据，只能通过Stream Load、Broker Load、Routine Load这三种导入方式进行数据的删除软删除|增加数据有效标志位，通过insert into select 的方式来更变需要删除数据的标志位，达到软删除的目的
4、有删除操作的情况下，主键模型与更新模型应该怎样抉择？数据更新频率很频繁更新模型的删除也有一些限制，删除条件复杂的情况下也无法删除软删除后冗余比较少报表实时指标计算/架构介绍|引入StarRocks后Flink只做简单的ETL工作统一使用StarRocks做实时指标计算,在StarRocks内部做数据的逻辑分层报表系统直接读取StarRocks结果数据对外提供的数据以DataAPI的形式提供数据关系模型转变|会更多的考虑星型模型/雪花模型，以应对更加灵活的多维分析场景精确一次性保证|Flink-Clickhouse 与 Flink-StarRocks 精确一次性对比可以保证精确一次性写入无法保证
5、精确一次性写入指标存储转变|引入StarRocks之前，报表结果数据存MySQL，需要借助外部工具导入SqoopMySQL库引擎或程序写入Hive外表MySQL外表引入StarRocks后，以StarRocks为核心，算存一体，查询分析统一常用数据导入方式|实时数据 使用Flink-connector-StarRocks，其内部实现是通过缓存并批量由 stream load 导入离线数据 创建Hive外表，用insert into select 的方式直接写入结果表Hive外表Flink-connector-StarRocksInsert into分区分桶选择|StarRocks使用先分区后分
6、桶的方式，如果不分区，则把整张表作为一个分区分区选择：从数据的管理角度来选择分区键，大多数情况下会选择使用时间分区分桶选择：通常选择高基数的列来作为分桶键，这样可以保证数据在各个桶中尽可能均衡分桶个数：计算数据存储量，将每个tablet设置成 500M 左右慢查询分析|Profile 与 Plan 查看可以在fe/log/fe.audit.log中看到所有查询和慢查询信息Profile是BE执行后的结果，包含了每一步的耗时和数据处理量等数据，可以通过StarRocksManager的图形界面查看详细内容未来规划04|未来规划|将剩余的实时场景全部迁入StarRocks建立以StarRocks为核心统一的查询分析平台DataAPI服务集成StarRocks完善StarRocks监控非常感谢您的观看|
sgpjbg002
工作日 8:30 - 17:30
报告分类
