共计 3102 个字符，预计需要花费 8 分钟才能阅读完成。
邮政科学研究规划院有限公司（以下简称“邮科院”），作为中国邮政团体有限公司的科研智库单位，专一于战略规划、企业治理、工程设计、物流配备、智能终端、品质检测、标准化钻研等畛域，在助力中国邮政策略转型和经营倒退中施展着重要撑持作用。
邮科院数据组负责全院大数据体系架构的建设，撑持日常 BI 经营剖析、科研数据产品、物流数据、网点画像等业务场景。邮科院数据组通过应用 StarRocks，对立了实时和离线的剖析场景，替换了 ClickHouse、Presto、MySQL 等零碎，解决了原有多套零碎带来的运维和应用复杂性，简化了数据 ETL 流程，同时大幅晋升 OLAP、Adhoc 等场景的查问效率。本文次要介绍邮科院数据组基于新一代极速全场景 MPP 数据库 StarRocks，在数据服务体系和数据利用场景中的实际和摸索。
“作者：谢翔，
邮政科学研究规划院有限公司寄递研究所数据组负责人，专一于数仓建设、数据分析等畛域钻研。”
业务背景
随着科研数据积攒越来越大，数据规模和体量也急剧收缩。科研的原始数据通常来源于研报抽取、日志埋点文件、业务数据库、三方接口等。过来通常基于 CDH/Hadoop 等大数据分布式计算框架和数据集成工具，构建离线的数据仓库，并对数据进行适当的分层、建模、加工和治理，构建各类剖析主题。邮科院数据体系中积淀了诸多研报主题数据，例如：电商流量数据，物流企业财务数据，行业报告相干的数据等。
下层数据利用对查问的响应提早和时效性要求高，会将数据通过数据同步工具同步到 MySQL、ElasticSearch、Presto、HBase、ClickHouse 等数据库系统中，来撑持下层数据利用的查问要求。
邮科院的大数据总体架构如下图所示，从下到上能够分为数据接入层、数据计算层、数据服务层和数据应用层。
数据计算层应用科研工作各剖析场景下产生的模型 / 计划 / 业务的明细数据，进行离线数据计算，对 TB 级别的明细数据进行调度、聚合、计算，在数仓里积淀出大量明细表、聚合表和最终的数据报表。
数据计算层生成的各类数据表，会同步到数据服务层，由数据服务层提供接口给数据应用层应用，满足不同的数据业务需要。
业务痛点
数据服务层的愿景是凋谢数仓能力，建设对立的数据服务进口，针对不同的数据业务剖析场景（数据规模、QPS、UDF 反对、运维老本等），原有架构在底层应用了不同的查问引擎：
- 大数据量、低 QPS：应用 Hive、Presto、ClickHouse 等基于 Hadoop 生态的离线批工作计算框架和 MPP 数据库来解决。
- 小数据量、高 QPS：应用 MySQL、ElasticSearch、HBase、MongoDB 等关系型 / 非关系型数据库来解决。
应用多套查问引擎，咱们遇到如下问题和挑战：
- 离线 / 实时 ETL 工作过多，解决逻辑大部分为简略聚合 / 去重，聚合表数量宏大，导致经营和运维上的成本增加；
- 针对中等数据量、中等 QPS 的查问场景，如何能兼顾数据规模的同时，有较敌对的查问响应提早；
- 大数据量下插入、更新的实时数据场景无奈失去反对，例如：网点画像、实时数据导入、邮路门路、研报数据汇总等。
OLAP 引擎选型
针对如上的问题和挑战，咱们的指标是寻求尽可能少的 OLAP 引擎，利用在明细表上现场计算来解决 ETL 工作、数仓表过多问题，同时须要兼顾在数据规模、查问 QPS、响应耗时、查问场景方面的衡量。
目前市面上 OLAP 引擎百花齐放，诸如 Impala、Druid、ClickHouse、StarRocks。通过一番调研，咱们最终抉择了 StarRocks。StarRocks 是基于 MPP 架构的剖析型数据库，自带数据存储，整合了大数据框架的劣势，反对主键更新、反对现代化物化视图、反对高并发和高吞吐的即席查问等诸多长处，人造能解决咱们上述的问题。
StarRocks 利用实际
StarRocks 曾经投入生产环境，次要作为离线 / 实时数据的 OLAP 数据库应用。离线数据次要存储于 HDFS 中，通过 DataX 工作批量同步数据到 StarRocks；另一部分实时数据次要存储于 Kafka 中，应用 StarRocks 的 routine load 性能实时将数据从 kafka 写入到 StarRocks。
在没有引入 StarRocks 之前，咱们应用的底层引擎是 MySQL、Presto on HDFS 和 ClickHouse 等零碎，对明细表 / 聚合表进行查问。这几种形式都存在着不少问题：
- MySQL 解决上亿规模的数据，无论应用分库分表、分区表、集群化部署的 PolarDB 计划，都会存在慢查问、数据库扛不住、运维艰难的困境；
- Presto on HDFS 的计划更偏差于剖析型数据业务，尽管能存储海量的数据，计算能力不错，惟一致命的在于无奈满足在线业务的高吞吐 QPS，查问比拟难做到毫秒级。
- ClickHouse 对 Join 反对较弱，只能应用大宽表建模，不够灵便，另外运维也比较复杂。
在引入 StarRocks 替换 MySQL、Presto 和 ClickHouse 后，StarRocks 带来的业务成果如下：
- 撑持了在线报表查问 + 数据分析业务，服务于对内经营 + 对外行业剖析的数据产品，报表业务查问大部分耗时在毫秒级别，剖析型业务查问大部分耗时在秒级别；
- 反对 10 亿规模的明细表查问，月、季、年等维度统计数据现场算聚合统计、精准去重等，查问耗时都能管制在 500ms 以内；
- 千万级别的多表的 Join 和 union 查问，通过 Colocate Join 个性优化，查问响应在秒级。
另外，咱们还将 StarRocks 利用到实时数据分析场景，StarRocks 在实时数据分析次要有如下劣势：
- 实时写入性能 ：目前 StarRocks 反对 HTTP 形式的 Stream Load，能够自定义的分钟级别微批写入，以及 Routine Load 性能，能够将 Kafka 的数据实时同步到 StarRocks 中，满足以后实时数据分析业务；
- 对立离线和实时剖析 ：实时数据和离线数据更好的在 StarRocks 中进行交融，灵便撑持利用，数据存储策略通过 StarRocks 动静分区的性能进行主动治理；
- SQL Online Serving：高效的 SQL 即席查问能力，可能兼容业界规范的 SQL 标准，撑持业务灵便简单的拜访，进步取数开发的效率。
总结和布局
邮科院数据组引入 StarRocks 生产集群，解决了数据服务层单表亿级别规模、高 QPS 数据场景下引擎的空白，间接凋谢明细表准实时查问的能力，给各项目组下层数据业务和 BI 零碎提供了更多的抉择和自由度，同时将大大减少数仓中大量 ETL 工作、聚合表、报表，升高了数仓 ETL 的运维压力和保护老本，StarRocks 综合性价比拟原有的 MySQL、Presto、ClickHouse 等同类产品晋升数倍以上。
将来，邮科院在 StarRocks 的利用和实际上还有不少布局：
- 除了 unique 和 duplicate 数据模型，将来会将合乎的数据场景迁徙至 aggregation 模型，并应用物化视图，进一步升高数仓开发保护老本，升高查问提早；
- StarRocks on ES 的性能也值得咱们深挖和摸索，解决原生 ES 集群无奈反对跨索引 Join 的能力；
- 更多数据应用层的场景接入 StarRocks，例如网点画像服务、邮路路径分析等，将进一步拓展 StarRocks 在实时数据写入、批量数据更新场景中的利用；
- 与科研数据分析平台、数仓平台深度买通，欠缺数据整体架构，作为数据团队的基础设施去保障稳定性和服务；
- 思考应用多云架构，自主可控的数仓架构能够灵便的在多云间切换迁徙，升高繁多云厂商的依赖，管制老本进步可用性。
- ……
最初的最初，感激 StarRocks 技术团队给予的激情、靠谱的答疑解惑和技术支持！！！
