查询网站建立时间,WordPress不会php,网站开发与维护工资,郑州百度网站优化300万字#xff01;全网最全大数据学习面试社区等你来#xff01; 最近Doris的发展大家是有目共睹的。例如冷热分离等新特性的持续增加。使得Doris在易用和成本上都有大幅提升。 基于Doris的一些存储实时数仓在越来越多的场景中开始有一些实践。大家也看到了这种方案频繁出现… 300万字全网最全大数据学习面试社区等你来 最近Doris的发展大家是有目共睹的。例如冷热分离等新特性的持续增加。使得Doris在易用和成本上都有大幅提升。 基于Doris的一些存储实时数仓在越来越多的场景中开始有一些实践。大家也看到了这种方案频繁出现在社区分享中。但是我们得客观看待这种方案基于存储的实时数仓有优势也有他的劣势生产环境中我们要谨慎评估个人的业务场景。这篇文章我结合个人的实践和思考简单说说这个问题。。 为什么有这样的方案 基于Doris等OLAP实现实时计算的业务很多情况下是基于以下考虑。 在更多的情况下基于Flink的实时数据开发难度要显著高于离线任务(二者根本不在一个数量级)基于Doris的存储实时数据开发可以显著降低开发门槛但是存在滥用的可能。 其次Flink在大窗口、大状态、灵活计算的场景下并不擅长(注意这里是不擅长不是不能)例如在多流Join、维表变更频繁、口径多变的场景下开发成本极高但是Doris可以显著降低这一点。 最后基于Flink的计算数据可观测性差例如状态数据是不可见的排查问题Debug都存在显著门槛修复历史数据也非常困难。 所以大家可以看到上述基于Flink为主的实时数据开发存在不小的门槛。所以我们有一个定性的结论在亿级(或者数千万)数据规模以下可以使用类似Doris这种的分析引擎仿照离线数据一样进行分层和定时调度处理大窗口数据(一般时间跨度超过30天)在保证性能的前提下降低实时数据的开发成本并且极大提高了数据的可观测性开发运维效率也有一定提升。 和基于Flink的一些方案对比 门槛低开发简单 所有人都可以开发这样的任务 运维简单 因为不像Flink一样考虑状态兼容不需要大量的资源长期占用。只在运行SQL时需要调度资源 开发效率提升 不需要对Flink有很深入的理解(当然这不是好事),几乎不存在参数条有测试简单无需启动调度容器(例如TaskManager和Task的调度) 数据调试方便中间结果落地可见 没有Flink的状态数据所有数据都在表中可查。 上面几点是一些优势但是基于Doris的这种方案也存在明显的短板需要大家特别注意 延迟明显 如果你采用了Doris那么我们大概率是配合定时调度进行的一般调度周期在30秒级以上意味着数据实时性大幅降低一些实时观测的指标例如实时GMV、在线人数等场景不适用 数据规模限制 如果你采用了Doris那么意味着你的TPS不能过高这不是Doris擅长的领域需要大家特别注意。另外单次扫描的数据不能过大正如我们前面所说亿级(或者数千万)数据规模以下才有比较好的性能保证。 最后如果你真的选择以Doris为主的实时数据开发那么意味着Doris会成为你的成本、运维中心。要有非常严格的配套工具例如报警、任务运行监控、任务规范性、调度和血缘能力。要特别注意资源和SQL性能问题一旦他们成为瓶颈会影响所有基于Doris的任务运行。 如果这个文章对你有帮助不要忘记 「在看」 「点赞」 「收藏」 三连啊喂 2022年全网首发|大数据专家级技能模型与学习指南(胜天半子篇) 互联网最坏的时代可能真的来了 我在B站读大学大数据专业 我们在学习Flink的时候到底在学习什么 193篇文章暴揍Flink这个合集你需要关注一下 Flink生产环境TOP难题与优化阿里巴巴藏经阁YYDS Flink CDC我吃定了耶稣也留不住他| Flink CDC线上问题小盘点 我们在学习Spark的时候到底在学习什么 在所有Spark模块中我愿称SparkSQL为最强 硬刚Hive | 4万字基础调优面试小总结 数据治理方法论和实践小百科全书 标签体系下的用户画像建设小指南 4万字长文 | ClickHouse基础实践调优全视角解析 【面试个人成长】2021年过半社招和校招的经验之谈 大数据方向另一个十年开启 |《硬刚系列》第一版完结 我写过的关于成长/面试/职场进阶的文章 当我们在学习Hive的时候在学习什么「硬刚Hive续集」
