安徽建设监理协会网站,网站设计中新闻版块怎么做,WordPress仿站助手,建设银行手机银行网站用户名是什么原因福建纵腾网络有限公司#xff08;简称“纵腾集团”#xff09;成立于 2009 年#xff0c; 以“全球跨境电商基础设施服务商”为企业定位#xff0c;聚焦跨境仓储与物流#xff0c; 为全球跨境电商商户、出口贸易企业、出海品牌商提供海外仓储、商业专线物流、定制化物流等…福建纵腾网络有限公司简称“纵腾集团”成立于 2009 年 以“全球跨境电商基础设施服务商”为企业定位聚焦跨境仓储与物流 为全球跨境电商商户、出口贸易企业、出海品牌商提供海外仓储、商业专线物流、定制化物流等一体化物流解决方案 旗下拥有谷仓海外仓 、云途物流 、WORLDTECH 等知名品牌 。 作者纵腾集团数据技术架构师 张彬华
随着纵腾集团业务的快速发展各产品线提出的数据需求越发严格而早期基于多套 CDH 大数据架构的技术栈和组件繁杂开发和运维难度高、效率低数据质量和时效难以保障已无法满足当下数据分析需求严重影响相关工作的开展。因此纵腾集团在 2022 年正式引入 Apache Doris基于 Apache Doris 构建了新的流批一体数据架构同时建立了以 Apache Doris 为核心的数据中台。构建过程中对读写时效性、服务的稳定性及高并发读写等多方面进行了优化在这一过程中我们也积累了诸多实践经验在此总结分享给大家。 早期架构
早期数仓架构主要分为两套基于 CDH 的大数据集群这两套架构用于不同产品线的数仓需求、数据大屏和 BI 报表等应用。 这两套架构为独立的数据管道具有耦合度低集群间相互独立等特点便于精细化管理。但随着业务需求的不断变化这样的特点也引发出许多新的问题。 遇到的问题 元数据和数据质量缺乏管控数据质量无法得到保证 不同业务数据独立存储维护导致数据孤岛不利于数据整合 每个集群的机房分布不一维护成本非常高 集群间的技术栈和组件较多且存在差异性对统一开发运维和数据整合都极具挑战性 架构选型
为了解决早期架构的痛点、更好满足日益严苛的数据需求我们希望能有一款产品帮助我们快速构建流批一体的数仓架构、构建数据中台服务。 我们对传统数仓、 实时数仓和数据湖进行了对比。从上图可知传统数仓可以支撑超 PB 级的海量数据但是交互查询性能相对差一些偏离线场景不满足我们对数据实时性的要求数据湖可以支撑超海量的数据支持数据更新查询性能适中但是数据湖近两年才开始应用成熟度较低使用风险较大实时数仓适用 PB 级数据存储支持数据更新且查询性能非常好。结合我们的要求实时数仓与我们的使用和需求场景都比较贴合因此我们最终决定选择实时数仓作为数据底座。
接着我们对市面上较为流行的三款实时数仓ClickHouse、Apache Druid、Apache Doris 进行了选型对比对比图如下 对比可知Apache Doris 优势明显、性价比更高具有独立主从架构简单、运维更灵活便捷、丰富的数据模型、优秀的查询性能和周全的生态规划等诸多优势对比这三个产品Apache Doris 最符合我们的选型要求。 新数据架构 新数据架构基于 Apache Doris 简化了数据采集、存储和计算的流程 结合 DataHub 实现自研元数据采集和周期管理 通过 Seatunnel 集成 Flink Doris Connector 稍加改造实现全量加增量数据的一体化采集 简化存储媒介对 ClickHouse、Kudu、HBase 等技术栈进行收敛由 Apache Doris 进行流批数据的统一存储 以 Apache Doris 为核心数据底座结合 Apache Kyuubi 的 JDBC 引擎直连查询自研和 Spark 引擎中的 Spark Doris Connector 进行 ETL 开发原生统一计算引擎管理、权限管控和对外服务。
基于上述几点进行了数据应用开发及对外提供数据服务构建了数据中台。 数据中台
我们以 Apache Doris 为核心底座创建了数据平台核心功能包括指标中心、元数据中心、基础配置中心、即席分析和数据接口服务中心其中指标中心和即席分析的数据主要来源于 Aapche Doris 当前已上线几百个指标。 数仓建模
我们结合 Apache Doris 的特性重新对数仓进行了建模数仓分层与传统数仓类似其中 ODS 数据为存量加增量一体的导入模式同时为防止出现[随机查询结果问题]ODS 层最终选用 Unique 数据模型相比于 Aggregate 模型可以实现写时合并Merge-on-Write有效提高数据实时性且 Aggregate 模型查询性能更接近于 Duplicate 模型对于 ODS 层是非常好的选择。
DIM/DED/DWS/ADS 层主要选用 Aggregate 数据模型Aggregate 数据模型提供的四种聚合方式可以在大部分场景下达到事半功倍的效果帮助我们快速应对不同的需求场景。 SUM能够高效实现 PV 类指标计算但对于 UV 类的指标需要考虑预去重。 MAX/MIN常用于最大最小运单时间节点类指标或包裹体积/重量最大最小值的指标计算。 REPLACE_IF_NOT_NULL可以自动地过滤空值非常便捷地实现仅记录最后一条数据适用于大部分 DW 场景。 数据导入
ODS 层的数据导入目前主要以 Stream Load 为主在 HDFS 上的历史存量数据也会通过 Broker Load 或Spark Load 导入。DW 层数据主要以 insert into 方式导入同时为减轻 Doris 内存压力我们将部分 ETL 任务放到 Kyuubi On Spark 引擎上去计算目前在 DolphinScheduler 每天平稳调度 Doris DW 任务有上万个其中大部分为 T1 任务小部分为小时级任务。 实践经验 对于以 Apache Doris 为核心的新数据架构我们规划了6个阶段进行运行测试直至可以上线运行。重点关注压测阶段和运行阶段有一些调试优化经验分享给大家
1、准备阶段
引入 Apache Doris 时是 2022 年 2月因此选择当时最新版本 Apache Doris 0.15 Release 版本进行应用主要考虑维度如下 支持事务性插入语句功能 支持 Unique Key 模型下的 Upsert 支持 SQL 阻塞 List 功能可以通过正则、哈希值匹配等方式防止某些 SQL 的执行 官方不支持跨两位版本号进行升级而 0.15 为当时最新的 Release 版本选用该版本利于后期版本升级 可通过资源标签的方式将一个Apache Doris 集群中的 BE 节点划分为多个资源组实现多租户和资源隔离 该版本提供了官方认可的 Flink-Doris-Connector/Spark-Doris-Connector/DataX Doriswriter 等插件利于ETL流程建设
2、验证阶段
该阶段主要是为了二次验证官方文档中介绍的功能是否满足我们的实际运用场景比如生态扩展中的 Connector、外表联邦查询、各种 Load 方式、多租户隔离及物化视图等。
3、压测阶段 压测阶段首先进行数据生成数据集选用的是 TPC-DS 数据接着根据 Doris 的特性对 DDL 和 SQL 等规则进行对应调整最后通过脚本将数据导入到 Apache Doris 存储中再通过自动化脚本进行查询及导入压测最终将压测结果输出到 MySQL 表中量化为图表进行展示。下方为本阶段的基本配置及压测过程介绍
- 硬件环境 内存256G CPU96C 硬盘SSD 1.92T * 8
- 软件环境 Apache Doris 版本0.15-release/1.0-release该阶段进行时1.0-release 版本刚好发布 Apache Doris 集群3 FE 9 BE 系统CentOS Linux release 7.9.2009
- 数据集信息
我们生成了 1T、5T、10T 的 TPC-DS 数据集1T 的数据集约有 30 亿数据量。 查询压测 压测过程中最初使用 0.15-release 版本进行测试正巧 1.0-release 版本发布后决定更换为 1.0-release 版本进行后续的压测。下图是基于 1T 的 TPC-DS 数据在同等硬件配置环境下和某商业 MPP 数据库的对比结果 如图所示Apache Doris 的查询压测性能优异有着明显的性能优势作为开源产品能够达到这样的效果是非常优秀也是十分不易的。
导入压测 导入方式通过 DataX Doriswriter 以 StreamLoad 方式进行写入压测 数据来源为避免因 Source 端原因影响写入时效选择 100 张相同大表即 100 个并发从内网 Hive 中导入例如 tpcds-ds 的 store_sales_1t 表 数据模型选用 Unique 模型模拟ODS层同时为充分考虑 Compaction 性能及小文件场景每张表设置 70 个 Tablet
经调整优化后最大写入时效为 269 MB/S680K ops/s平均写入时效 70 MB/S180K ops/s写入时效大幅提升。 4、上线阶段
该阶段主要是确认 Apache Doris 上线需要的检查清单、预调参数、BE 资源组规划及用户权限的划分。 检查清单包括但不限于 FE BE 端口、网络检查及 Apache Doris 的一些功能性验证例如读写是否正常等。 预调参数确认优化后的 FEBE 参数是否配置是否开启global enable_profile、动态分区以及数据盘保存位置是否有误等。 BE 资源组由于我们需要通过 Apache Doris 的多租户特性对不同的用户进行资源隔离所以需要提前规划好每个 BE 节点对应的资源组。 用户权限对于不同的用户群体提前规划好权限范围比如分析师开发只需要SELECT_PRIV权限而 ETL 工程师需要SELECT_PRIV、LOAD_PRIV和CREATE_PRIV权限。
5、宣导阶段
该阶段主要是输出前面各阶段的 TimeLine、总结以及上线后使用 Apache Doris 的注意事项说明比如我们用到多租户隔离那么 DDL 建表时则需要在 Properties 中显示指定各副本对应的资源组 create table zt_table
......
properties(replication_allocationtag.location.group_a:1, tag.location.group_b:1, tag.location.group_c:1
)
6、运行阶段
Tablet 规范问题
问题描述上线运行一段时间后随着越来越多的数据增长集群每次重启后一周左右读写就会开始变得越来越慢直到无法正常进行读写。
问题处理 经过对生产和 UAT 环境的对比测试以及对数仓表的 Schema 的分析我们发现有些表数据并不大但是 Bucket 却设置的非常大。 结合show data from database 命令我们将整个集群所有表的 Bucket 信息罗列出来明确了大部分表的 Bucket 设置的不合理而当前集群共 20T 左右数据平均 1T 数据近 10W 个 Tablet这就会导致小文件过多造成 FE 元数据负载过高从而影响导入和查询性能。 定位原因后与社区小伙伴二次确认并根据官方建议将 Bucket 设置不合理的表全部调整调整后集群逐步恢复读写正常。即将发布的 Apache Dorie 1.2.2 版本将推出 Auto Bucket 动态分桶推算功能可以根据历史数据和机器数目自动推算新建 Partition 的分桶个数保证分桶数始终保持在合理范围内可有效解决上述问题
问题小结 Tablet数 分区数 * 桶数 * 副本数 1TB 数据的 Tablet 数量控制在 8000 个左右三副本控制到 2.4W 左右 建议大表的单个 Tablet 存储数据大小在 1G-10G 区间可防止过多的小文件产生 建议百兆左右的维表 Tablet 数量控制在 3-5 个保证一定的并发数也不会产生过多的小文件
集群读写优化
问题描述1.1.3 release 版本中高并发的同时进行 Stream Load、Broker Load、insert into 和查询时读写会变得非常慢如下图 11/01 19:00 并发上来后的 Txn Load 所示 问题处理
1. 我们进行了十几轮对比测验结论如下 写入速度与并发的增长成反比但不会骤变而是缓慢变化 单表 BucketTablet设置过大会导致集群写入速度骤减例如 A 库的 TA 表设置 80 个 Bucket 时启动相关 Flink Sink Job 就会导致集群整体写入速度迅速变慢降低 Bucket9~10个时写入恢复正常。 insert into select 的 ETL 任务与 Stream Load 写入任务会进行资源抢占同时并发运行会使整个集群读写变慢。 2. 通过be.INFO发现80 个 Bucket 表写入某个 Tablet 的memsize/rows/flushsize/duration数值比 10 个 Bucket 写入时的数值呈数倍之差即 80 个 Bucket 表的数据写入时效无论 Memsize 还是 Flushsize 都非常小、但花费时间却很长。 3. 同时收集 Pstack 日志经过分析可以确定Tcmalloc 在频繁地寻找 pageheap_lock导致高频竞争锁从而降低了读写性能。 4. 于是进行如下参数调整 减少doris_be进程内存返回给linux系统的频率从而减少tcmalloc频繁竞争锁的情况
tc_use_memory_min 207374182400
tc_enable_aggressive_memory_decommit false
tc_max_total_thread_cache_bytes20737418240
5. 调参并滚动重启 BE 后集群状况如下图所示
18:50 前将 Broker Load、insert into 和查询任务同时开启18:50 后将 Stream Load 任务也开启包括 80 bucket的表集群整体的读写性能不仅没有下降反而 Stream Load 时效突破了压测阶段的最大值 269 MB/S680K /ops/s并且持续稳定。 问题小结
使用 Apache 1.1.3 及以上版本非常推荐调整 Tcmalloc 相关参数减少doris_be进程与系统之间的内存申请回收过程可明显减少锁竞争的现象大大提升读写性能和集群稳定性。从 Apache Doris 1.1.5 版本开始增加了Tcmalloc 简化配置可将众多 Tcmalloc 参数归约到参数memory_mode中compact 为节约内存模式performance 为性能模式用户可根据实际需求进行调整 总结收益
当前 Apache Doris 的生产集群为 3 FE 9 BE 组合 已导入集团存量和增量数据的 60%以及部分 DW 数据生成3 副本共占 44.4TB 的存储。 依赖 Apache Doris 自身优异特性及其生态圈帮助我们快速构建了一套新的流批一体数据架构平均每天实时入库的数据量达到上亿规模同时支持上万个调度任务平稳运行相比早期架构单表查询效率提升近 5 倍数据导入效率提升近 2 倍内存资源使用率显著减少。除此之外Apache Doris 以下优势也是我们快速构建数据架构的重要推动力 扩展表联邦查询的设计便于集成其它存储 数据表设计丰富的数据模型可快速应对不同的数据需求。 数据查询不同的 Join 算子结合自身完善的优化器让查询快而稳。 架构设计架构清晰明了且运维简单大大地降低了我们的运维成本。 数据导入各种 Load 方式及 Connector 的扩展基本涵盖大部分的数据同步场景应用。 活跃度社区高度活跃SelectDB 为 Apache Doris 社区组建了一支专职技术支持团队疑难杂症基本能在 12H 内快速响应并有社区小伙伴跟进和协助解决。 未来规划
结合当下业务场景的考虑未来我们将引入数据湖进行非结构化和结构化数据一体存储进一步完善流批一体架构。同时也会将 Apache Doris 回归它最本质的定位专注于 OLAP 分析场景并通过 Apache Doris 统一湖仓查询引擎层发挥其最大的功效。 最后非常感谢 Apache Doris 社区和 SelectDB 团队的张家锋、曲率和杨勇强等小伙伴对我们无私的技术支持未来我们也将持续参与 Apache Doris 社区建设中贡献绵薄之力。祝 Apache Doris 社区和 SelectDB 越来越好日臻完善
# 相关链接
SelectDB 官网
https://selectdb.com
Apache Doris 官网
http://doris.apache.org
Apache Doris Github
https://github.com/apache/doris
