共计 3160 个字符，预计需要花费 8 分钟才能阅读完成。
作者：零洞科技大数据部
零洞科技有限公司（以下简称“零洞”），是碧桂园团体的外围联盟企业，致力于成为国内当先的数智空间解决方案服务商，业务场景笼罩户内及户外，在智慧家居板块，打造一站式智慧家居解决方案，形成丰盛的生存场景，满足高端用户智能生存体验；在智慧园区畛域，为园区提供全链路智能化产品及服务，打造高效、节能、平安、智能的园区环境，具备千万级智慧园区我的项目理论落地案例。截至目前，零洞数字化交付我的项目超 2100 项，具备亿级设施和数据处理的平台建设及业务利用研发教训。
2022 年 6 月，零洞与碧桂园服务（HK6098）就物业企业微信数字化我的项目开展充沛单干。以后，碧桂园服务是全国规模最大的社区服务经营团体，经测算，共 7000+ 物业管家，上万服务人员，累积服务业主超 1400 万人，累积管辖屋宇达 486 万户。
一、引入背景
基于上述业务规模，经单干需要评估，该我的项目需搭建一个数据服务中台，以反对以下需要：
1、反对每年 超十亿数量级数据的存储和计算， 包含但不限于：物业企微会话存档聊天、关联认证、用户行为、管家工作治理、客户舆情剖析等各方面数据。
2、反对全国上千的高并发，秒级的拜访、查问、计算、报表导出等要求。
3、在此数据中台的根底上，在可视化平台实现报表、看板、大屏的开发展现等需要。
在技术框架选型上，碧桂园服务与零洞科技综合比照了国内外常见的 OLAP 零碎，StarRocks 凭借以下 6 大长处怀才不遇：
1、产品架构简洁，整个零碎的外围只有 FE（Frontend）、BE（Backend）两类过程。不依赖三方组件，运维简略；
2、数据查问实时性、高并发等方面的性能相较其余数据库产品有突出的劣势；
3、反对规范 SQL 语法，学习切换成本低；
4、反对主键模型，在实时写入和频繁更新的业务场景中性能优越；
5、流批数据导入：StarRocks 开发了 Flink-connector、Spark-connector 插件，反对将数据 sink 或批量写入到 StarRocks 中；
6、极速查问体验，亿级数据查问毫秒级响应；
StarRocks 合乎现代化的数据利用技术栈需要，最终作为外围存储计算组件来搭建本次碧桂园服务项目的数据中台。
二、基于 StarRocks 搭建的数据中台
对于传统企业的数据利用场景来说，数据中台的数据集成、研发、治理与服务链路很长，波及的组件比拟多，比方：须要应用 Hadoop 做为存储、Hive/Spark 做离线 ETL、Kudu 做实时批量更新、Flink 做流解决，各类组件之间又有很强的依赖关系，尤其是在机器资源无限且服务混合部署的状况下，容易呈现资源分配问题，比方 Impala 会经常性产生 OOM 问题。
StarRocks 完满解决了这个问题：对于传统企业来说，咱们能够将 Hadoop + Hive + Spark + Kudu + Flink 的性能全副交给 StarRocks，实现存储 / 流批处理一体化。
1、数据开发
针对数据开发，StarRocks 提供了多种导入形式，如 Stream Load 形式从本地文件系统导入数据、Broker Load 形式从 HDFS 或内部云存储系统导入数据、Routine Load 形式从 Kafka 导入数据、Spark Load 形式从 Spark 导入数据等等，基本上可满足咱们全场景的实时数据导入需要。
为了使架构简略，尽量少的应用到 Spark 或 Flink 等脚本语言进行开发，咱们在数据接入层应用 Kafka 做实时接入缓冲层，之后基于 StarRocks 的 Routine Load 性能开发自定义导入组件，实现了一键实现 Kafka 到 StarRocks 或者 API 到 StarRocks 的数据同步和监控性能。
思考到咱们的 ETL 工具须要与 StarRocks 做深度集成，咱们更偏差于抉择架构简略灵便的组件进行二次开发，因而在离线同步上咱们抉择了 DataX，数据管道 (调度平台) 抉择 Airflow，可视化工具抉择 Smarthart，并在此基础上进行了个性化的 Driver 及治理性能开发。
通过这一系列的革新，与咱们之前应用的传统大数据平台 (基于 CDH) 施行的我的项目相比，数据中台的施行老本大幅降落，具体体现为：
1、实时场景的实现更加轻松
之前的实时查问用到的组件较多，引入 StarRocks 后，只需通过 StarRocks 就能实现实时查问，链路变得简略，人力投入也更少，以前须要投入 Spark/Flink 开发人员，当初只用 SQL 开发就能实现。
2、服务器资源缩小：从 10 台以上缩减到了 4 台
3、施行部署周期缩短：从 2 周降落到 3 天
2、平台监控
在平台监控上，StarRocks 社区版本提供了兼容 Prometheus 的信息采集接口，能够通过间接连贯 BE 或 FE 的 HTTP 端口来获取集群的监控信息。
为了放弃与咱们可视化平台的对立和灵活性，咱们并没有应用 Grafana 做为可视化监控计划，而是基于 SmartChart 连贯 Prometheus 实现了可视化监控的大屏开发，将简单的数据和信息变得直观易懂，便于咱们日常运维，实时展现 BE 及 FE 的衰弱度及数据导入和查问的状态，不便咱们对理论状况进行实时监控与及时预警。
三、基于 StarRocks 的丰盛利用场景
1、 BI 场景的反对
在咱们的 BI 场景中，须要对千万级以上明细数据进行多表关联查问，更新频率需达到近实时，响应工夫需在秒级。同时，用户个性化需要又很强，比方须要同一个会话 ID 来查问上下文，并生成相干的词云统计。
在引入 StarRocks 之前，咱们的数据流转线路很长、开发治理的复杂度也十分高：比方为了均衡简单查问与极速查问的需要，咱们须要生成很多宽表或 cube 表；另外之前的计划对于须要频繁更新的业务场景也很不敌对：需先写入 Kudu 进行批量更新, 而后回写到 Hive 中，再从 Hive 抽取到 Kylin，BI 连贯 Kylin 进行查问。
有了 StarRocks 之后，基于 StarRocks 向量化执行引擎所带来的极速查问个性，咱们把自研 BI 的数据后盾间接切换到了 StarRocks，使得咱们数据建模更加简略，建模形式也逐步从宽表建模转化成星型建模，不仅缩小了数据开发的工夫，同时可能反对简单的业务逻辑实现，数据联动钻取的粒度反对得更细，数据响应工夫也从传统的秒级变为了毫秒级。
2、数据服务场景的反对
企业微信数字化我的项目须要基于会话的工单自动化生成，因而须要平台可能提供会话上下文查问 API，从而为算法平台提供实时的数据反对。
从咱们的实际来看，StarRocks 非常适合此类场景，完满的实现了大数据量的实时更新及同时反对高并发的极速查问需要。
3、数据 生命周期治理 :
一直积攒的大量会话明细数据，须要进行无效的数据周期治理，通过冷热辨别，来无效的管制存储老本。
在引入 StarRocks 之前，咱们须要应用脚本定时删除历史数据，有了 StarRocks 的动静分区及数据生命周期治理的性能，此局部内容就可由 StarRocks 主动实现，整体数据流变得十分整洁。
四、业务价值
数据已成为企业的重要资产，随着大数据的积攒，基于 StarRocks 搭建的数据中台曾经成为数据窗口的提供者，是物业根底管家服务强有力的反对。
通过数据中台更加高效、实时、全面的数据分析性能，咱们能够做更多的业主经营和员工治理，如：
- 利用上亿级的数据进行工单、舆情以及用户画像的剖析，让用户诉求解决得更加及时全面，晋升业主的满意度；
- 通过剖析业主的行为和偏好画像，带动社区多种经营业务，包含社区空间经营服务、社区生存服务、业主资产经营服务等等，倒退物业行业的第二曲线。
在我的项目施行过程中，咱们失去了 StarRocks 社区十分业余给力的反对，咱们也期待 StarRocks 也期待社区的蓬勃发展促成产品能力继续加强，期待基于 StarRocks 搭建的数据中台在将来让咱们数据施展更大的业务价值。
