网站的建设期,长沙人才网官网,wordpress固定连接,电商网站建设实训心得本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
本作品 (李兆龙 博文, 由 李兆龙 创作)#xff0c;由 李兆龙 确认#xff0c;转载请注明版权。 文章目录 引言内容总结 引言
春节假期回到家里断然是不会有看纸质书的时间的。造化弄人#…本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
本作品 (李兆龙 博文, 由 李兆龙 创作)由 李兆龙 确认转载请注明版权。 文章目录 引言内容总结 引言
春节假期回到家里断然是不会有看纸质书的时间的。造化弄人二月三号早上十一点的飞机延误到一点多原本三小时不到的阅读时间延长为五个小时也给了我看完这本书的机会。
第一次了解到这本书是Tison在朋友圈发了他写的书评[2]开头便是 值得一读尤其是对开始开发流计算任务或系统一到两年初步实现过一些功能或作业但是还没有对流式系统建立起系统认识的开发者。 Tison参与开源的起家项目就是Flink。而我对于流计算系统接触起源于时序数据库的流式计算降采样时序数据的以目前使用的场景来看绝大多数还是把分钟/秒级别数据基于SQL规则降维度/不降维度对应group by tag/*到小时/天级别这样的需求大多数决策者会在写入链路上加一个Flink/Spark将数据本身处理后写入时序数据库这也导致业务成本上相当一部分是在Flink/Spark上的。
我们可以看到TDengine的官网上将缓存、流计算数据订阅以及时序数据库的功能闭环在TDengine内部并将此作为卖点之一核心是为了降低系统设计复杂度和运行成本并标榜自己为时序大数据处理平台。 我对于流计算系统的浅薄了解便来自于这里。事实上TDengine包括我们的实现标榜为流计算系统并不完全正确准确的说应该窗口仅为时间无状态的且非DAG的简化批处理系统但是这样的场景对于目前绝大多数需求完全够用因为目的是为了加速查询而不是给业务赋能。
我参与了腾讯新一代时序数据库从立项到上云的全过程并实现了对于系统内部简化流计算能力的支持所以非常符合“开始开发流计算任务或系统一到两年初步实现过一些功能或作业”的人的这也是读这本书的主要原因。
在开始书评之前以TDengine这张图为背景我以我浅薄的知识评价下在决策者的角度我会怎样使用时序数据库。
首先我认为时序数据库的流式计算能力是可以解决时序场景中的绝大多数分析需求的所以我愿意尝试这里的能力。但是对于是否降本我持怀疑态度因为系统内部执行流计算系统需要大量的内存尤其是在流计算任务较多时每个measurement一个这个数字会极度膨胀这个时候扩容成了唯一的方法如果只按照读写的能力去申请资源加上流计算的资源消耗存在内存风险。但也并不是没有显而易见的好处即数据库自治绝大多数情况只有数据库自己知道该如何较优构建降采样和流计算。kafka的钱是省不了的这是系统的最后兜底假如我是一个CEO不可能把我身家性命放在“时序大数据处理平台”的而且业务数据还需要做更高级的分析需求降维度接入用户内部分析系统等时序数据库的流计算短期能很难看到超越专业流计算系统的可能所以接受到业务数据后架一个kafka是必要的。Cache功能完全可以集成到时序数据库内部这里有两个场景1. 系统需要快速将最新数据返回给应用程序 2. 相同sql数据缓存实际查询只查询两次sql的时间差值内的数据减少CPU/内存消耗时序数据库集成这些功能是完全可行的对于我们开发的多模数据库可以在用户的资源内起一个SSD Redis db存储大量数据在SSD中在增加了存储利用率的同时减少了用户查询时延。
内容 若河床上没有岩石溪流就不会有歌声 第一章阐述了应用程序后台服务批处理系统流处理系统之间的区别并讨论多阶段架构为后续引出DAG做铺垫。 先解决问题再编写代码 第二章引入收费站的例子指出基于Web服务构建存在流量增加时请求延迟引发了系统迟滞导致结果不准确的问题因而引出使用流系统并指出流系统的核心概念由事件作业源算子和流构成处理引擎由源执行器算子执行器和作业启动器构成。 九个人不可能再一个月造出一个孩子 第三章介绍了并行化和数据分组这可以解决分布式系统的一个根本挑战即如何扩展系统以增加吞吐量或者说如何在更短的时间处理更多的数据。并行化包含数据并行和任务并行前者含义为将一个任务的不同子集交给不同的执行单元后者含义为在不同的数据上运行相同的任务。章节的后续引入事件分发器并提出分组概念为了下游组件可以高效的并行处理上游事件这和kafka中的partition概念基本一致。 糟糕的程序员担心代码优秀的程序员担心数据结构和它们之间的关系 第四章引入欺诈检测的case与之前不同这时的流并不是一条直线在数据源之后需要执行多种检测这就引出了DAG并解释了算子的扇入扇出同时指出扇出时发出的事件可以只被推送到某些输出队列中此外不同的输出队列中可能拥有不同的数据。 人们从来没有足够的时间去做正确的事情但总有足够的时间去重做一遍 第五章介绍了送达语义即至多一次At-Most Once、至少一次At-Least Once和恰好一次Exactly Once并指出Exactly Once需要重试和幂等来保证。在我们的时序系统中实现了kafka ingest需要接受用户写入kafka的数据并高效的写入引擎这里开始我们使用autoCommit这就是经典的至多一次但是存在数据丢失风险后来我们使用手动管理offset保证在实际写入成功后再提交offset但这依旧只能保证至少一次真正的恰好一次是靠时序数据库本身的幂等保证的。 技术使人们能够控制除了技术以外的一切 第六章是对前五章的总结。 计算机能集中注意力的时间只和它的电源线一样长 第七章讨论了窗口计算和窗口水位前者讨论了固定窗口滑动窗口和会话窗口并指出可以使用外部系统来完善窗口算子其次提到乱序数据的到达需要设置窗口水位一般情况下维持多个窗口开销较大以目前的经验用户通常可以接受丢弃这部分数据。Tison提到The Dataflow Model 是 Google 流计算的经典论文Dataflow 模型的开山之作简单浏览了一下文章内容窗口水位部分对应文章中 When in processing time they are materialized ?How earlier results relate to later refinements ? 这里我还想讨论下目前公有云监控的实时性问题腾讯云上目前分钟监控在120s内秒监控在12s以内这个值是怎么得到的呢时序数据本质上也可以看作一个有界的数据流分钟级别监控可以认为是窗口为时间的数据在这种情况下首先存在一个攒数据的过程因为不确定数据实在一分钟的哪一秒到达这就60s了在加上上报存在失败在最后1s失败时允许重试最后就是时序数据库内写入的削峰这些加起来产品给出了120s的保证。 一个SQL查询来到酒吧走到两张桌子(table)前问道我能加入(join)你们吗 第八章讨论JOIN。书中把join当作一种特殊的扇入方式并提出流必须转化为表才可以执行join同时讨论了双流join中首先基于窗口物化流其次再join。这一节的内容在我们的流系统中无法使用但是在流式查询引擎中还是有理论指导意义的首先基于窗口截取其次再合并返回。 永远不要相信一台你无法扔出窗口的计算机 第九章讨论了流系统中广泛支持的故障处理机制即反压一种与数据流向相反的压力。因为流是源源不断的如果存在某个模块出现预期之外的情况问题很快会传播到其他组件导致系统崩溃反压就是最后一道防线 具体介绍了如何判断繁忙状态与如何执行反压前者我认为与系统相关后者的处理是通用的1. 停止数据源 2. 停止上游组件 并需要考虑如何解除反压状态让系统恢复。
且反压需要区分事件比如实例宕机或者消费能力不足这两者靠自身都是无法恢复的需要拉起实例和增加资源书中还提到一种特殊的case即持续触发反压这会造成整个系统的抖动。
这一章对我来说最大的意义在于从理论上确定了在流系统上思考极端情况是有理论基础的在我们的实现流计算过程中就遇到过类似的问题比如WAL拉取导致计算节点CPU暴增处理包变慢存储节点累计大包出现大范围OOM其次还有在均衡操作触发时存在消费老数据的情况造成CPU激增影响其他组件这些其实都是没有考虑反压的情况。
对于如何判断繁忙状态与如何执行反压前者可以通过统计CPU/内存来做后者可以选择停止输入和丢弃工程上不同的场景在监控上需要可以体现。 重启试试 第十章讨论了有状态计算这同时是Flink的最大价值即而在于实现了带状态的流计算。这一章主要阐述状态和检查点即何时持久化状态书中给出的方法是在数据流中加入检查点这可以理解为屏障barrier。其实以目前我们在时序数据库中实现的流系统来看最难的点其实在于调度因为调度的复杂性我们没有选择有状态的流计算在出现故障时选择重放几个窗口的事件并限制CPU/内存使用。 成功不在于是否曾经摔倒而在于能否重新站起来 第十一章终章是对七到十章节的总结和展望。
总结
现有的时序数据库只是实现了窗口仅为时间无状态的且非DAG的简化批处理系统想以此替代流系统的全部份额基本不太现实但是确实可以拿下其中部分收益领域垂直公司需要故事去活下去但是公有云需要关注业务上真正需要解决的问题可见的未来我们的精力不会投入到完善时序的流计算系统中去。
参考
大图书馆 #8 流式系统阅读指南大图书馆 #9 《流计算系统图解》书评支持消息队列和流式计算背后TDengine 3.0 存储引擎的优化与升级DolphinDB教程流数据时序引擎一文学会如何使用 TDengine 3.0 中的流式计算支持消息队列和流式计算背后TDengine 3.0 存储引擎的优化与升级NaiadA Timely Dataflow System论文阅读-NaiadA Timely Dataflow SystemThe Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing大数据理论篇 - 通俗易懂揭秘谷歌《The Dataflow Model》的核心思想(一)
