网站建设平台点击进入,做外贸网站效果图,wordpress自己写界面,哪里有做网站的平台导言
抱歉#xff0c;作为从 S2 开始的骨灰级玩家看到 EDGUZI 官宣首发上线#xff0c;兴奋之余忘了写文档 - -||#xff0c;还望各位看官老爷见谅#xff0c;这次错了#xff0c;下次还敢 ^_^
这是继上次的 30 问上篇的中篇#xff0c;也是 10 个问题#xff0c;有些…导言
抱歉作为从 S2 开始的骨灰级玩家看到 EDG·UZI 官宣首发上线兴奋之余忘了写文档 - -||还望各位看官老爷见谅这次错了下次还敢 ^_^
这是继上次的 30 问上篇的中篇也是 10 个问题有些还是比较难回答的欢迎大家在评论区或者私聊我来进行 battle~
QA
1. 时区 zone因现在国家在发展东数西算一些行业存在跨时区跨机房的情况即使在国内北京和云南也存在比较大的时差从业务角度如果要求时间偏差率控制在10秒级别如何解决是否会增加数据处理或者业务处理复杂度
时差和时延问题在跨地域应用场景中是一个难以避免的问题从软硬件一套系统的角度来看这个更多的应当是硬件方面要解决的问题比如光纤光缆的传输效率的提升以及多级级联的数据交换中心的配套和落地所以这个问题我觉得应该从两个角度看
1.从硬件角度而言网络传输的延迟是很难避免的这个想要有更高效的传输效率可能更多应该是从物理设备的介质角度、中继转发传输配套设施等角度来解决。
2.软件角度而言
1.要在 Doris 里统一的进行多时区时间戳的管理比如之前有一个用户是跨国企业部署的 Doris 集群在全球范围内有很多个每个集群要根据当地时间来统计业务指标而同时在中国的总部也必须同时去将所有地区的多时区进行并行转换比如一个表内以 shanghai_time 为主时区维度字段并同时有纽约、北爱尔兰、新加坡、曼谷等地区的时区维度字段然后在计算的时候进行不同时区的数据汇总剩下的需要贴合业务来进行进一步的设计。
2.其实从数据延迟这个角度而言有没有一种类比可能更贴合我们大多数的同学在日常处理中的认知——Flink 流式数据处理时数据的迟到问题在面试中经常被问到的零点漂移等问题其实就是类似这样的同质问题的实际例子那么零点漂移问题的答案其实发散性的去思考思考和当前这个光缆传输延迟的问题的答案无异都是很相似的要么等待等待要等待多久要么就是业务角度进行取舍能不能容忍数据计算时的延迟或者能不能容忍数据可见性的时延较高
3.在国内区域的业务的话其实这种延迟个人觉得可以视同为 Flink 无界流数据迟到来处理不需要考虑跨时区问题因为一般结算都是按照北京时间来结算的哪怕比如新疆时间和北京时间会差三个小时左右但是做结算一般都是按北京时间的。故而综合下来我觉得这个问题一方面要在数据落档的时候要进行多维度的存储同时要注意精度要求一方面要和业务方进行协商博得一个双方都可以接受的方案。
2. 时区 zone 其实存在2类问题1类问题是跨时区的集群节点2类问题是不跨时区的集群节点单存在跨时区的数据
这两种在上一个问题中都做了相应的解答如果是不跨时区的集群节点可以按照 Flink 无界流数据迟到的问题来处理如果是跨时区的集群节点做多时区时间维度同步和入库时间处理。
3. 对于目前业务开发普遍使用 spring boot/spring cloud数据库连接池数据事务控制的等方面的建议和应该避免和规避的使用 Doris 的方式有哪些建议
首先无论是用 SpringBoot 还是 SpringCloud只要使用 JDBC 来连接 Doris 做 CRUD那么就应当使用数据库连接池来管理和控制数据库的 session其原因和建议使用姿势如下
1. Doris 作为一个数据库本身的连接资源是比较珍惜的Doris 的连接是长连接不会随着会话的客户终端终止而立即释放所以如果拿着长连接当短连接来用那么就会很快把连接数用光具体的表现就是新的 Session 无法连上集群在 FE 的 WARNING 日志里报 Exception happened in one session 这样的日志。
2. Doris 在业务程序中使用的时候还是要遵循 Doris 是一个 AP 库的原则不能做频繁的毫秒级的频繁入库和事务性的修改等CRUD 中的 CUD但是可以做 RRead所以如果在用代码进行数据入库的时候我们建议使用 StreamLoad 的方式调用 Http API 来完成数据攒批写入这个攒批写入的批次值最好在 5000-20000 条一批次同时尽可能的保证数据入库的导入频次可以保证最小在 1s 以上建议5-10s。
3. 使用数据库连接池来管控连接无论是创建还是复用以及销毁对数据库本身的压力会减低很多对业务方的使用体感会提升很多。
4. Doris 默认一个账号的最大并发度是 100由 max_user_connectors参数来控制这不代表 Doris 只能抗这么多并发这只是为了防止一个用户用大量的链接把所有的资源都吃光当然也有可能用少量的大查询就已经把集群资源吃光了但这毕竟是少数情况一个 FE 的默认最大链接是 1024这两个数值都可以调整。
4. 并发查询量大的场景如何解决
并发查询应当要分场景来讨论在实际的业务场景里一般会有两类场景
1. 面向客户的查询场景这类场景常见于广告主的报表查询、运营商的用户查询明细、电商店铺查询后台情况、保险员查询自己管理的保单信息等整体的查询并发度会非常大要求的延迟要在毫秒级或者亚秒级但是一般不涉及关联查询都是基于一个表的过滤、聚合、排序、分组等查询方式这种场景在 Doris 2.0 里有了专项的解决特性——单表高并发查询能力底层实现是用行列混存的方式来加速点查效率我们测试的结果非常喜人在标准测试集群下16C64G * 3单 FE 的并发度可以达到上万 QPS。
2. 面向企业内部的查询场景这类查询通常以固定报表、AdHoc 这两类为主那么像这类查询并发度要根据企业的 QPS、查询数据量、查询复杂度等综合考虑包括需要的目标查询时延等需要具体情况具体分析了。
5. 对于 replace 关键字因官方文档所在同一批次无法保障有序性可以 udf 介入吗这个有什么好的建议吗
在 Unique Key 模型中其实有专门来保障这个同一批次有序性的特性Sequence 列。
这个 Sequence 列就是为了在同一导入批次中将数据根据 Sequence 列进行排序然后有序导入无需 UDF 接入一方面 UDF 介入只能在导入后进行重新排序另一方面 UDF 本身的性能是要比 Local Native 要低的所以还是建议使用专门来处理这个问题的 Sequence 列来解决这个问题。
6. FE 的 SQL 函数与 hive 和 presto 等的覆盖面和兼容性
当前 Doris 的函数已经在逐步丰富了如果你有更多需要可以在 github issue 区或者 Doris 论坛里发帖求助我们会不定期的进行补充同时也欢迎大家来贡献一起共建社区。那么剩下的我觉得从三个方面来解答
1. 常用的、主流的 Hive 函数我们都做了大量的兼容和适配。
2. 我们当前的 JAVA_UDF 框架是可以百分百兼容原 Hive UDF Jar 的也就是改造零成本。
3. 关于 Presto 的联邦查询能力这个在 Doris 1.2 开始已经做的很出色了以 Catalog 为基准的联邦查询层的改造让 Doris 有了很丰富的查询网关层统一的能力而且性能在大部分场景下是优于 Presto 的所以如果以平替 Presto 的角度来看这个覆盖面的话Doris 是可以胜任的。
而且现在 Doris 已经支持了 Hudi、Paimon、Iceberg 等数据湖新势力对 ES、MySQL、SQLServer、Hive、Oracle 等等甚至对 Hana 这类数据库都已经有了支持下一步会对更多的数据源进行兼容扩充比如国内的一些 TP 库等敬请期待。
7. flink- Doris -connnector 是否支持 source 和 sink是否支持 just-once
Flink-Doris-Connector 当前是支持上游数据源 Sink 到 Doris 来的但是从 Doris 通过 Binlog 这类机制做 Source 当前是无法支持的不过已经在支持的路上了。
至于 just-once 我认为这个的含义应该更多的是数据的一致性要求在 Doris 的导入阶段有两方面的保证一个是两阶段提交保证一致性二是由于单批次插入是事务性的那么不会出现一部分数据写入可查了另一部分数据没有写进来导致查询失败。
这里需要关注的点有两个
1. 一个是 Doris 的写入时候默认是关闭严格模式的而 Flink-Doris-Connector 底层用的是 StreamLoad如果出现数据导入失败但是没有找到报错信息可以先在 JOB 任务中打开严格模式然后再二次导入查看具体 ErrorURL 中的报错信息来针对性解决。
2. 一个是在使用 FlinkCDC 做传输的时候要注意设置 Checkpoint 值除非有硬性的数据可见性要求那最低建议设置到 1s否则建议设置到 5-10s避免背压以及 Doris Compaction 压力大等情况。
8. 系统监控项的要点慢查询、资源消耗性查询、水位监控达到什么情况下需要考虑扩容
首先慢查询的查询时延要业务方觉得OK那才算OK有些业务场景需要几十毫秒的延迟那么在 QPS 增高 99th 时延无法满足用户诉求的情况下就需要扩容了而在比如 ETL/ELT 场景中更多要看在并发调度执行的任务中集群的整体运行负载在什么程度了比如在整个集群资源峰值达 45% 的日常调度处理中如果不改变当前的任务数量和任务脚本的话那么其实还能再增个 150-200% 的数据来跑这个情况下集群会把资源吃满机器满负荷跑但基本不会出现宕机情况但是如果要保证整个集群的低故障率那么就得扩容了。
9. Doris 是否支持 Flink、Spark、MR 等计算引擎直接使用数据分片分布式计算
首先回答问题不支持。
不支持的原因在于两点
1. Doris 是一个完备的数据库有自己的计算引擎和存储引擎所以本身就不需要其他计算引擎来做分布式的计算而且只有 Doris 的计算引擎和存储引擎才更贴合 Doris 的数据存储格式和数据查询方式这样整个查询速度才会更快而且本身 Doris 就是 MPP 架构现在 1.2 开始还全面实现了向量化在查询性能上是不差于任何一个计算引擎的。
2. Doris 在 ETL 处理场景中等规模的集群资源下等规模的处理数据中Doris 的处理速度是 Hive On MR 的 8-10 倍是 Hive On Spark 的 2-3 倍所以更无必要使用外部计算引擎了~
10. Doris 最常用的可视化数据迁移工具是什么支持从 Doris 读入后 Sink 到几种数据源或从几种数据源读入后写入 Doris
先回答个偏离题意的答案不久的将来最常用的可视化数据迁移工具是 X2Doris。
为什么回答要加一个不久的将来呢因为这个工具我们内部还在进行打磨和开发研发进度很快同时已经有一大批协助我们测试和使用的用户反馈说这玩意真好用距离大家能来用相信应该是不远的时间。至于数据流向这个工具提供的是其他数据源流入 Doris是可视化的使用非常简单。
那么回到问题本身当前呢
当前如果是要做写入 Doris 的那么 Flink-Doris-Connector 和 Spark-Doris-Connector 都可以Datax 和 Airbyte 也都没问题甚至一些商业化的迁移工具都已支持了 Doris上游支持什么数据库得看 FlinkCDC 或 Spark 能支持哪些他们能支持的Doris 就可以。
如果是要做 Doris 写出那么现在最好的方案是使用 Spark-Doris-Connector这种方式适合批量的做数据迁移不适合增量的去做再或者就是使用 JDBC 进行查询然后做下游数据库的存储这种方式有比较大的不确定性所以不建议。
小结
这次的问题还是比较难的很多问题都要结合实际的业务场景定制化的来看那么如果你有想量身定制的场景问题可以加我微信来一起探讨不过我可能会比较忙如果有回答不及时的还望海涵~
老规矩我的微信fl_manyi
