共计 7515 个字符，预计需要花费 19 分钟才能阅读完成。
作者：张栋，京东物流团体数据专家
京东团体 2007 年开始自建物流，2017 年 4 月正式成立京东物流团体，2021 年 5 月，京东物流于香港联交所主板上市。京东物流是中国当先的技术驱动的供应链解决方案及物流服务商，以“技术驱动，引领寰球高效流通和可继续倒退”为使命，致力于成为寰球最值得信赖的供应链基础设施服务商。
基于 5G、人工智能、大数据、云计算及物联网等底层技术，京东物流曾经构建了一套全面的智能物流零碎，实现服务自动化、经营数字化及决策智能化。截至 2021 年 12 月 31 日，京东物流在全国共经营 43 座“亚洲一号”大型智能仓库。到 2021 年，京东物流曾经领有及正在申请的技术专利和计算机软件版权超过 5500 项。
京东物流在经营数字化及决策智能化过程中，实时化经营剖析的业务需要越来越多，原有平台架构中的数据孤岛、查问性能低、运维难度大、开发效率低等问题日益凸显。在此背景下，京东物流基于 StarRocks 的联邦查问计划打造了 Udata 对立查问引擎，高效解决了数据服务与数据分析的泛滥痛点，大大降低了开发运维老本，解决了查问引擎不对立和数据孤岛，让剖析和服务不再宰割。
原有数据利用的痛点
数据服务与数据分析场景是数据利用的两个大方向，数据工作从业者有可能会遇到以下问题：
数据服务
烟囱式开发模式：每来一个需要开发一个数据服务，数据服务无奈复用，难以平台化，技术上无奈积攒。
- 服务保护难度大：当开发了大量数据服务后，前期保护是大问题。尤其是 618、双 11 大促期间，在没有对立的运维监控、限流降级、业务容灾计划的状况下，一个人保护上百个数据服务是很苦楚的，也造成了很大的安全隐患。
- 业务需求量大：数据开发的同学经常会被大量反复干燥的数据服务开发解放，大量工夫投入在业务数据服务开发中。
数据分析
- 找数据难：用户难以找到本人所想，即使找到名称相近的指标或数据，因为指标定义不明确、不对立，也无奈间接应用。
- 用数据难：因为目前数据分布在各个系统中，用户无奈用一个零碎满足所有的数据需要。特地是一线经营人员，要通过从各个系统导出大量 Excel 表格的形式做数据分析，费时费力，同时也造成数据安全隐患。
- 查问慢：用传统的 OLAP 引擎，用户跑 SQL 往往须要几分钟才出后果，大大降低了剖析人员的效率。
- 查问引擎不对立：零碎可能有多种查问引擎组成，每一种查问引擎都有本人的 DSL，增大了用户的学习老本，同时须要跨多数据源查问也是一件很不不便的事。异构查问引擎带来的另一个问题是造成了数据孤岛，各零碎间的数据之间无奈互相关联。
- 数据实时更新：传统离线 T + 1 形式数据更新曾经无奈满足当今的实时化经营的业务诉求，这就要求零碎须要达到秒级别的提早。
除了以上问题，数据服务和数据分析系统也无奈对立，剖析产生的数据后果往往是离线的，须要额定开发数据服务，无奈疾速转化为线上服务赋能内部零碎，使得剖析和服务之间难以疾速造成闭环。而且在以往数据加工过程中存储往往只思考了过后的需要，当后续需要场景扩大，最后的存储引擎可能不实用，导致一份数据针对不同的场景要存储到不同的存储引擎，带来数据一致性隐患和老本节约问题。
基于 StarRocks 的数据服务剖析一体化实际
基于以上业务痛点，京东物流经营数据产品团队研发了服务剖析一体化平台——Udata，Udata 零碎是以 StarRocks 引擎为技术根底实现的。Udata 把数据指标生成的过程形象进去，用配置的形式低代码化生成数据服务，大大降低了开发复杂性和难度，让非研发同学也能够依据本人的需要配置和公布数据服务。指标的开发工夫由之前的一两天缩短为 30 分钟，大大解放了研发力。
平台化的指标管理体系和数据地图的性能，让用户更加直观和不便地查找与保护指标，同时也让指标复用变成可能。在数据分析方面，咱们用基于 StarRocks 的联邦查问计划打造了 Udata 对立查问引擎，解决了查问引擎不对立和数据孤岛问题。
同时 StarRocks 提供了强悍的数据查问性能，无论是大宽表还是多表关联查问性能都非常杰出。StarRocks 提供数据实时摄入的能力和多种实时数据模型，能够很好反对数据实时更新场景。Udata 零碎把剖析和服务联合在一起，让剖析和服务不再是宰割的两个过程，用户剖析出有价值的数据后能够立刻生成对应的数据服务，让服务剖析疾速闭环。
革新前的数据流程架构：
- 实时数据由 JDQ (京东日志音讯队列，相似 Apache Kafka) 和 JMQ 导入 Apache Flink 做实时数据加工，加工后数据写入 ClickHouse 和 ElasticSearch，为数据服务和数据分析提供 OLAP 查问服务。
- 离线数据由 Apache Spark 做个数仓层级加工，APP 层数据会同步至 MySQL 或 ClickHouse 做 OLAP 查问。
此架构中，在数据服务和数据分析是两个分隔的局部，剖析工具因为要跨多数据源和不同的查询语言做数据分析比拟艰难的，数据服务也是烟囱式开发。
革新后的数据流程架构：
- 实时链路方面，咱们在原有的 ClickHouse 和 ElasticSearch 根底上引入 StarRocks，实现了极速的单表和多表查问能力。
前面咱们又以 StarRocks 为根底打造对立查问引擎。对立查问引擎依据京东的业务特点减少了数据源和聚合下推等性能，Udata 在对立查问引擎的根底上，对立了数据分析和数据服务性能。
打造一款数据服务剖析一体化系统对查问引擎有比拟高的要求，须要同时满足：极速的查问性能、反对联邦查问、实时与离线存储对立。基于这三点要求，接下来，咱们就 StarRocks 的极速查问性能、咱们对联邦查问的革新、实时场景的实际展开讨论。
StarRocks 的极速查问性能
极速查问的单表查问
StarRocks 在极速查问方面上做了很多，上面着重介绍四点：
1）向量化执行：StarRocks 实现了从存储层到查问层的全面向量化执行，这是 StarRocks 速度劣势的根底。向量化执行充分发挥了 CPU 的解决能力。全面向量化引擎依照列式的形式组织和解决数据。StarRocks 的数据存储、内存中数据的组织形式，以及 SQL 算子的计算形式，都是列式实现的。按列的数据组织也会更加充分利用 CPU 的 Cache，按列计算会有更少的虚函数调用以及更少的分支判断，从而取得更加充沛的 CPU 指令流水。另一方面，StarRocks 的全面向量化引擎通过向量化算法充分利用了 CPU 提供的 SIMD 指令。这样 StarRocks 能够用更少的指令数目，实现更多的数据操作。通过规范测试集的验证，StarRocks 的全面向量化引擎能够将执行算子的性能，整体晋升 3-10 倍。
2）物化视图减速查问：在理论剖析场景中，咱们常常遇到剖析百亿级大表的状况。只管 StarRocks 性能优异，但数据量过大对查问速度还是有影响，此时在用户常常聚合的维度加上物化视图，在不扭转查问语句的状况下查问速度能晋升 10 倍以上。StarRocks 智能化的物化视图能够让申请主动匹配视图，无需手动查问视图。
3）CBO：CBO 优化器 (Cost-based Optimizer) 采纳 Cascades 框架，应用多种统计信息来欠缺老本估算，同时补充逻辑转换（Transformation Rule）和物理实现（Implementation Rule）规定，可能在数万级别执行打算的搜寻空间中，抉择老本最低的最优执行打算。
4）自适应低基数优化：StarRocks 能够自适应地依据数据分布，对低基数的字符串类型的列构建一张全局字典，用 Int 类型做存储和查问，使得内存开销更小，有利于 SIMD 指令执行，放慢了查问速度。Clickhouse 也有低基数优化，只是在建表时候须要申明，应用起来会麻烦一些。
极速的多表关联
在实时数据分析场景中只满足单表极速查问是不够的。为了减速查问速度，业内习惯于把多张表打成一张大宽表，大宽表虽速度快，然而带来的问题是极其不灵便，实时数据加工层是用 Flink 将多表 Join 成一张表写入大宽表。当业务方想批改或减少剖析维度时，往往数据开发周期过长，数据加工实现后发现曾经错过了剖析最佳时机。因而就须要更灵便的数据模型，把大宽表模式退归回星型模型或者雪花模型是比拟现实的办法。
在此场景下，查问引擎对多表数据关联查问的性能成了要害，以往 ClickHouse 以大宽表为主，多表联查状况下无奈保障查问相应工夫，甚至有很大几率呈现 OOM。StarRocks 很好解决了这个问题，大表 Join 性能晋升 3-5 倍以上，成为星型模型剖析利器。CBO 是多表关联极致性能要害，同时 StarRocks 反对 Broadcost Join、Shuffle Join、Bucket shuffle Join、Colocated Join、Replicated Join 等多种 Join 形式，CBO 能够智能地抉择 Join 程序和 Join 形式。
京东物流团队对 StarRocks 联邦查问的革新
StarRocks 在联邦查问上反对了多种表面如 ElasticSearch、MySQL、HIVE、数据湖等，曾经有了很好的联邦查问根底。不过在理论的业务场景中，一些聚合类查问须要从内部数据源拉取数据再聚合，加上这些数据源本身的聚合性能也不错，反而减少了查问工夫。
咱们的思路是，让这部分善于聚合的引擎本人做聚合，把聚合操作下推到内部引擎。目前合乎这个优化条件的引擎有：MySQL、ElasticSearch、ClickHouse。同时为了兼容更多的数据源，咱们还减少了 JSF(京东外部 RPC 服务)/ HTTP 数据源，上面重点介绍下这两局部：
MySQL、ElasticSearch 的聚合下推性能
当初 StarRocks 对于聚合内部数据源的计划是，拉取谓词下推后的全量数据。尽管谓词下推后曾经过滤了一部分数据，然而把数据拉取到 StarRocks 再聚合是一个很重的操作，导致聚合工夫不现实。咱们抉择下推聚合操作，让内部表引擎本人做聚合，节俭数据拉取工夫，同时本地化聚合效率更高。首先看一个执行打算生成的过程：
- SQL Parse：将 SQL 文本转换成一个 AST（形象语法树）
- SQL Analyze：基于 AST 进行语法和语义剖析
- SQL Logical Plan：将 AST 转换成逻辑打算
- SQL Optimize：基于关系代数、统计信息、Cost 模型，对逻辑打算进行重写、转换，抉择出 Cost“最低”的物理执行打算
- 生成 Plan Fragment：将 Optimizer 抉择的物理执行打算转换为 BE 能够间接执行的 Plan Fragment 咱们在步骤 4 中对生成的物理执行打算再次优化，当遇到 ElasticSearch 或者 MySQL 的聚合操作时，会把 ScanNode+AGGNode 的执行打算优化为 QueryNode。QueryNode 为一种非凡的 ScanNode，与一般 ScanNode 的区别在于，QueryNode 会把聚合查问申请间接发送到对应内部引擎，而不是 Scan 数据后在本地执行聚合。其中，用到 ElasticSearch QueryNode 时，咱们会在 FE 端就生成 ElasticSearch 查问的 DSL 语句，间接下推到 BE 端查问。同时在 BE 端，咱们实现了 ElasticSearch QueryNode 和 MySQL QueryNode 这两种 QueryNode。咱们也为这个 feature 设置了 agg_push_down 的开关，默认是敞开的。
参考下图查问语句，下方是来自 ElasticSearch 和 MySQL 的两个数据源聚合后 Join 查问的 SQL。原先的执行打算须要从数据源 Scan 大量数据后本地聚合，优化后去掉了这部分 Scan 和聚合的过程，间接拿到聚合后的数据。
上述 SQL 在优化后生成的执行打算变动如下：
减少 JSF(京东外部 RPC 服务)/ HTTP 数据源
数据服务中可能会波及到整合内部数据服务和复用原先已开发指标的场景。咱们的思路是，把 JSF(京东外部 RPC 服务)/ HTTP 也形象成 StarRocks 的内部表，用户能够通过 SQL 像查询数据库一样拜访数据服务。这样不仅能够复用老的指标，还能够联合其余数据源的数据，生成新的复合指标。咱们在 FE 和 BE 端同时减少 JSF 和 HTTP 两种 ScanNode。
实时场景的实际
京东物流实时数据绝大多数属于更新场景，运单类数据会依据业务状态的扭转而扭转，上面介绍咱们在生产中的三种实时更新计划：
基于 ElasticSearch 的实时更新计划
原理：
1）外部先获取 document
2）内存中更新老的 document
3）将老的 document 标记为 deleted
4）创立新的 document
长处：
1）反对数据实时更新，能够做到 Partial update
毛病：
1）ElasticSearch 聚合性能较差，当呈现多个聚合维度时查问工夫会很长
2）ElasticSearch 的 DSL 语法减少了开发工作，尽管 ElasticSearch 能够反对简略 SQL，然而无奈满足简单的业务场景
3）旧数据清理难，当触发 Compaction 物理删除标记位文档时，会触发大量的 IO 操作，如果此时写入量又很大，重大影响读写性能
基于 ClickHouse 实现准实时的计划
原理：
1）应用 ReplacingMergeTree 的形式实现
2）将 Primary key 雷同的数据散发到同一个数据节点的同一个数据分区
3）查问时做 Merge on read，合并多版本数据读取
长处：
1）ClickHouse 写入根本是 Append 写入，所以写入性能强
毛病：
1）因为读取时做版本合并，查问和并发性能较差
2）ClickHouse 的 Join 性能不佳，会造成数据孤岛问题
基于 StarRocks 主键模型的实时更新计划
原理：
StarRocks 收到对某行的更新操作时，会通过主键索引找到该条记录的地位，并对其标记为删除，再插入一条新的记录。这相当于把 Update 改写为 Delete+Insert。StarRocks 收到对某行的删除操作时，会通过主键索引找到该条记录的地位，对其标记为删除。这样在查问时不影响谓词下推和索引的应用，保障了查问的高效执行。查问速度比 Merge on read 形式快 5-10 倍。
长处：
1）只有惟一版本数据，查问性能强，实时更新
2）尽管 Delete+Insert 在写入性能有轻微损失，但总体上还是非常强悍
3）MySQL 协定，应用简略
毛病：
1）目前版本在数据删除上有一些限度，无奈应用 Delete 语句进行删除，新版本中会减少此性能
实时更新场景总的来说有以下几种计划：
1）Merge on read：StarRocks 的聚合、Unique 模型和 ClickHouse 的 ReplacingMergeTree、AggregatingMergeTree 都是用的此计划。此计划特点是 Append 形式写入性能好，然而查问时须要合并多版本数据，导致查问性能不佳。适宜数据查问性能要求不高的实时剖析场景。
2）Copy on write：目前一些数据湖零碎如 Apache Hudi、Apache Iceberg 都有 Copy on write 的计划。此计划原理是，当有更新数据后，会合并新老数据并重写一份新的文件替换掉老文件，查问时无需做 Merge 操作，所以查问性能很好。带来的问题是，写入和合并数据的操作很重，所以此计划不适宜实时性强的写入场景。
3）Delete and insert：此计划是 Upsert 计划，通过内存中的主键索引定位要更新的行，标记删除而后插入。在就义了局部写入性能的状况下，带来数倍于 Merge on read 的查问性能晋升，同时也晋升了并发性能。
实时更新在 OLAP 畛域始终是一个技术难点，以往的解决方案很难同时具备写入性能好、读取性能好、应用简略这几个个性。StarRocks 的 Delete and insert 形式目前更靠近于现实的计划，在读写方面都有很优良的性能，在反对 MySQL 协定方面非常简单敌对。同时 Udata 的离线剖析也是用 StarRocks 实现，让京东物流实现了实时离线剖析一体化的指标。
后续方向
数据湖摸索
批流一体曾经成为今后倒退的大趋势，数据湖作为批流一体的存储载体曾经成为规范，咱们当前大方向也必然是批流一体。目前批流一体中一个大痛点问题是没有一种查问引擎能够在数据湖上做极速查问，前期咱们会借助 SR 打造在湖上的极速剖析能力，让批流一体不只停留在计算阶段。架构图如下：
实时数据存储对立
目前零碎中有多套实时存储计划，运维老本还是相当高，咱们会逐渐把 ElasticSearch、ClickHouse 替换为 StarRocks，在实时层做到存储对立。咱们也很期待 StarRocks 前期对于主键模型反对 Detele 语句形式删除数据的性能，从而能够解决目前的数据革除问题。
反对更多的数据源
今后咱们还会反对更多的数据源，如 Redis、Apache HBase 等 KV 类型的 NoSQL 数据库，加强 StarRocks 的点查能力。
StarRocks 集群间的联邦查问
在理论生产中很难做到只用一个大集群，特地是当有大量实时写入的状况，比拟平安的做法是拆分不同的小集群，当一个集群出问题时不会影响其余业务。然而带来的问题是，集群间可能又会变为数据孤岛，即使把 StarRocks 伪装成 MySQL 创立表面，但也须要工具去同步各个集群的表构造等信息，治理起来费时费力，后续咱们也会和社区探讨如何实现集群间的联邦性能，如果有对此感兴趣的社区小伙伴也能够一起来参加共建。
资源隔离
StarRocks 在 2.2 版本开始推出资源组的性能，能够无效隔离大小查问负荷，后续还会在大查问熔断、导入和查问负荷资源隔离方面推出更多功能。因而，一些体量较小的业务混合在同一集群上通过资源隔离的模式运行，将成为可能。
StarRocks 是一款非常优良的 OLAP 数据库产品，在社区小伙伴的帮忙下，咱们解决了很多技术难题。在这里感激 StarRocks 社区，咱们后续也会鼎力参加社区建设，并心愿能有更多的小伙伴参加到 StarRocks 社区共建中来！
对于 StarRocks
StarRocks 创建两年多来，始终专一打造世界顶级的新一代极速全场景 MPP 数据库，帮忙企业建设“极速对立”的数据分析新范式，助力企业全面数字化经营。
以后曾经帮忙腾讯、携程、顺丰、Airbnb、滴滴、京东、众安保险等超过 110 家大型用户构建了全新的数据分析能力，生产环境中稳固运行的 StarRocks 服务器数目达数千台。
2021 年 9 月，StarRocks 源代码凋谢，在 Github 上的星数已超过 2900 个。StarRocks 的寰球社区飞速成长，至今已有超百位贡献者，社群用户冲破 5000 人，吸引几十家国内外行业头部企业参加共建。
