共计 4019 个字符，预计需要花费 11 分钟才能阅读完成。
作者
张博晗
现实汽车大数据平台 - 高级大数据开发
负责公司级数据集成平台的设计和开发，以及 OLAP 平台的体系化建设
对于致力发明挪动的家、成为寰球当先的智能电动车企业的现实汽车，所要治理的数据规模十分宏大。智能电动车是一个非常复杂的 IoT + 互联网场景，除了会产生 各种业务零碎的数据、APP 埋点数据 外，还须要思考汽车应用过程中传感器产生的 海量时序信号数据。
除了宏大的数据量，智能电动车场景还依赖 弱小的 OLAP 剖析能力，去独特反对售后保护、OTA 降级、车辆的健康状况检测、晚期预警以及维修保养等各种需要。
目前，现实汽车应用 Hadoop 数据湖技术栈，依据业务需要实现各种简单的计算和剖析工作，次要依附 Spark SQL 和 Impala 独特反对 OLAP 多维分析、定制报表和 Ad-Hoc 数据分析等查问场景。
Hadoop 集群的扩容费时费力，有时甚至难以跟上业务的增长速度 。面对疾速倒退的业务，想要缓解业务对于敏捷性的高要求、维持业务运行的稳固，不够弹性的 Hadoop 让咱们越来越力不从心。另外，传统的 Hadoop 架构为了应答网络延时和带宽的瓶颈，采纳了计算和存储耦合部署的形式，减少计算意味着减少存储。 而存储和计算的匹配往往是错位的，不匹配的扩容也会带来很多冗余，造成不必要的节约。现如今，网络基础架构曾经从当年的 1Gbps 倒退到现在的 10Gbps、25Gbps 甚至是 100Gbps，网络在大数据架构中曾经不再成为瓶颈，存储和计算拆散的架构更加合乎咱们的需要。
业务的疾速倒退使得数据平台的转型火烧眉毛。通过外部多轮沟通和摸索，发现 StarRocks 能以一套零碎提供极速数据湖剖析、高并发查问、实时剖析等场景的解决方案，非常适合解决咱们目前遇到的痛点，能够帮忙现实汽车实现多场景极速对立剖析：
一、将 Hadoop 集群的存储和计算进行解耦。间接在 HDFS + Hive Metastore (HMS) 上构建数据湖，用于海量业务数据的存储。利用 StarRocks 的极速数据湖剖析能力，间接剖析 HDFS 上的数据，从而解决存储和计算错配的问题。同时利用 StarRocks 联邦查问的能力，使得 StarRocks 能够将 HDFS 上的数据源和其余数据源进行关联剖析，省去数据在不同数据源迁徙的老本。
二、构建弱小的实时剖析能力。低延时剖析要求的数据间接入库 StarRocks，利用 StarRocks 本身深度优化的数据存储构造、高效的剖析引擎以及通用 SQL 能力的反对，使得咱们可能以极低学习老本的形式进行实时数据分析。
01 场景一：高效对立的数据湖剖析引擎
在引入 StarRocks 之前，咱们用 Impala、TiDB 来提供离线报表的查问，用 TiDB 来提供实时数仓的查问能力，用 Spark SQL 来提供 AdHoc 查问能力。简单的架构（如下图所示）给咱们带来了很多困扰：
- 应用 Impala、TiDB 提供报表查问时，两种引擎中的数据没方法进行关联查问，常常须要互导数据，给数据处理带来很多额定老本。
- 应用 TiDB 提供实时数仓查问时，进行大表关联查问，常常无奈满足业务方的查问延时要求。
- 应用 Spark SQL 提供的 AdHoc 查问能力时，遇到的问题与状况 1 相似，同样无奈对 TiDB 中的数据进行关联查问。
咱们看到 StarRocks 能以内部表的模式，接入其余数据源。内部表指的是保留在其余数据源中的数据表。StarRocks 能够间接向内部表所在数据源发动查问，并且能够对多引擎中的数据进行关联，而且查问性能比拟强悍。这使得通过 StarRocks 造成对立的数据查问入口成为可能。
因而，咱们选型的重点落在了用 StarRocks 表面替换 Impala 的角度上。
以下是 StarRocks 和 Impala 基准测试详情：
测试环境
Hadoop / Hive MetaStore 和 Impala / StarRocks 别离运行在两个集群上，集群之间跨网络读取数据，地处雷同机房，这样将计算和存储进行拆散。Impala / StarRocks 集群别离有 3 个节点，每个节点的配置都是 16vCPU 和 64GB 内存。
咱们别离用 StarRocks 的 Hive 表面和 Impala，在 4 并发和 8 并发下，对 TPC-H 100Scale 规模数据集进行了比照测试，测试后果如下：
注：Impala 在运行 Q18 的时候呈现过 OOM，Q11 不反对 Having 子句，所以这两栏应用了自定义的数字代替。
Impala 负载状况（C=8）
CPU、内存和网络简直都压到了极限
StarRocks 负载状况(C=8)
CPU 简直压到极限，内存应用看起来比拟顺滑
综上，StarRocks 的 Hive 表面，在雷同硬件规格条件下，运行在 TPC-H 100Scale 规模数据集，查问性能是 Impala 的 2 倍以上。这些是两者都在存储计算拆散状况下，基于测试数据集失去的性能剖析。
在实在业务场景下，原来 Impala 计算和 Hive 存储耦合在一起，然而咱们把 StarRocks 计算和 Hive 存储进行了拆散，这样存储和计算能够独自弹性扩大，存储计算拆散后查问性能也实现了不错的晋升，性能是原有存储计算耦合时 Impala 的 1.6 倍。当然，对于现实汽车的业务场景来讲，StarRocks 能通过表面的形式笼罩全副 Impala 场景，并且可能和 TiDB 进行 Join 查问，就曾经动摇了咱们用 StarRocks 替换 Impala 的信心了。最终带来了不俗的性能晋升，更是意外之喜。
收益
采纳基于 StarRocks 的 OLAP 查问新计划后，咱们下线了 Impala 服务，加重了 Hadoop 集群运维压力。通过多引擎 Join 的表面查问性能，零碎用户能够在看板上对 Hive 和 TiDB 表间接进行关联查问，减短了数据加工的链路，成果十分现实。
02 场景二：实时画像标签零碎
咱们心愿通过这一零碎打造公司级画像数据服务，提供标签生产及标签元数据管理性能，促成各业务用户画像 ” 数据供应 ” 和 ” 数据生产 ” 高效匹配。面向经营、产品、分析师、用户钻研、设计、市场营销、数据研发、零碎研发等角色，画像平台零碎须要实现的性能有：
- 实时 + 离线标签的生产能力，收录各业务用户画像数据资产。
- 为用户标签查问服务与跟进标签圈选用户群服务提供反对，满足业务 ” 寻找目标群体、查问目标群体具体的属性 / 特色、判断画像形容对象是否合乎业务策略 ” 的诉求。
- 以数据服务的形式利用在用户经营、市场营销、数据分析、数据研发等业务场景中。
现实汽车旧版的标签零碎次要是用 ElasticSearch 来做，在开发迭代上不够灵便，不能写 SQL，根本都是定制开发。通过调研，StarRocks 能够基于 Roaring Bitmap 来做客群圈选，不便地把前端圈群的动作翻译为交加、并集、异或等关系计算，大大简化了 SQL 开发的复杂度，拓展了业务实现的设想空间。故此，咱们基于 StarRocks 对圈选业务进行了从新梳理和降级革新。
架构方面，通过 Spark 生成 T+1 数据标签，导入 StarRocks。通过 Flink 对实时数据进行加工，将近线数据进行补充。在离线层和减速层加持下，一直将新数据存入 StarRocks 中，同时保障既有数据的完整性。
下图是数据落地到 StarRocks 中的工作。离线数据和实时数据，写入了不同的表；加工好的离线标签数据，导入宽表模型；实时加工的数据，采纳高表的模型。实时进行写入、读取时，对两表进行 Join，这样能够更好地利用 StarRocks 进行查问减速。
收益
- 整体提供了更具时效性的人、车、桩的把控。借助 StarRocks 高效的多表关联能力和灵便的 Bitmap 汇合计算能力，咱们不仅能够在人、车、桩某一个因素体系内进行剖析查问，还能够跨域圈选，实现了人车关系、车桩关系和人桩关系的因素穿插剖析。
- 工程实现上，Bitmap 汇合 Bitwise 计算语义清晰，能够很好的把 UI 的圈选动作翻译过去，从而使得咱们轻松实现了全新的配置化页面的设计，可能提供简单外显指标在线计算。咱们下线了通过代码、简单 SQL 子查问嵌套、脚本等形式开发计算指标的历史通道，整体业务的复杂性大大降低，人效失去晋升。
- 利用上，新零碎提供了基于人、车、桩的实时特色多维查问剖析。针对碰撞告警、故障预警等场景，大数据平台团队与算法团队独特发展了一系列工程革新实际，整体响应速度较老零碎有显著晋升。
03 总结与瞻望
综上，通过 StarRocks 构建了一套湖仓一体的数据架构，这套架构让咱们可能低成本存储海量数据，也可能进行高效实时的数据分析，从而灵便应答各种业务剖析场景。
咱们始终在跟进 StarRocks 社区的倒退。晚期对 StarRocks 不相熟时，在应用中遇到了很多问题，感激社区小伙伴踊跃帮忙并疾速解决了问题。
应用过程中，咱们发现了以下几点须要改良的中央：
针对 Hive 表面的元数据刷新机制还不是很欠缺。针对一些分区较多的表，首次加载 Hive 元数据会比较慢，用户的间接感触就是 SQL 查问偶然较慢。StarRocks 社区反馈 2.2 版本当前会减少元数据增量更新的性能，届时将不再须要手动刷新元数据缓存。
心愿官网能尽快推出资源隔离、存算拆散等性能。
在咱们往年的工作布局中，一方面会在公司外部各业务部门进行推广并测试高并发的主键点查，尝试基于 StarRocks 打造 HSAP（Hybrid Serving/Analytical Processing）架构 。另一方面，咱们也开始 将 StarRocks 与公司的大数据平台进行更深度的集成，开发如数据管道、数据库管理工具等更丰盛的 StarRocks 周边工具，升高用户的应用门槛。
随着业务的倒退和应用的深刻，咱们也会投入更业余的人才来进行底层溯源和革新优化。置信咱们能够更好地和 StarRocks 社区单干，让 StarRocks 能够笼罩更多的场景，打造满足业务倒退的湖仓一体的数据库产品。
📣 现实汽车正在招募 OLAP 方向的大数据开发工程师，有趣味参加共建 StarRocks 并丰盛其能力的搭档们，欢送投递简历至 nielei@lixiang.com
