0%

概述

2018年华为在vldb 上发表了论文《FusionInsight LibrA: Huawei’s Enterprise Cloud Data Analytics Platform》。 这篇论文罗列了LibrA 的架构和很多powerful的功能, 整体看下来, 特别亮瞎眼睛的功能到没有,但在工程的角度,介绍很多很接地气的做法, 比起很多列一大堆数据公式, 一大堆机器学习的算法论文,可读性更强, 也更好理解数据库的实现和优化。

FusionInsight MPPDB, 又称Libr, 后来又改名为高斯200, 是针对olap 分析的一款mppdb 数据库。 高斯200 是高斯部门很成功的一款产品。从2012年开始研发, 2014年第一代原型研发出来, 现在已经在全球大量使用, 包括最大的金融企业工行。并且以用户为导向,实现了很多powerful的功能,如在线扩容, 自动tuning, sql on hdfs, 智能jit 编译执行(llvm code gen), 提供行列混存, 数据压缩特性, 智能workload管理, 为提高高可用增加重试失败request, 用sctp 协议替换tcp协议以提高scalability等等。

Read more »

snowflake 随谈

随想

今天,如果从事大数据或者OLAP 领域的朋友,都 应该仔细阅读一下snowflake 的论文。 snowflake 是前年看的, 但一直想写一篇介绍的读后感,一直没有下笔, 放在心中, 成为一个疙瘩, 终于在新年新气象的号召下, 终于把当初的阅读笔记找出, 梳理一遍, 列一下snowflake 中,很多有意思的东西。
论文原地址 :The Snowflake Elastic Data Warehouse

架构

snowflake 的架构呈现出来时, 还是很让人眼前一亮, 这一套架构, 吸收了传统数据库mpp 的架构的优点, 有吸收了云上DLA 架构(serverless)的优势, 整体是一套对云计算非常友好的olap 系统。 这一套系统比传统大数据(hadoop系列/emar) 要轻量高效, 比传统的mpp数据库(on-premise的云数据库)又要性价比高, 更便宜更灵活。 

整套系统是完全部署在云上, 所有的计算节点和service 都是购买虚拟机, 而存储是使用aws 的s3或微软的类s3的对象存储。 整套架构是share disk 的架构, 并且设计了一套都有cache机制,让整个计算层是无状态的, 所有有状态的东西存储到kvstore中, 而前端节点采用微服务, 保障系统的可靠性又让系统的成本最低化。  

Read more »

忽然之间, 发现已经到了2020年, 回首2019年立下的flag, 似乎一大半都还没有完成, 就来到了2020年。 2020 拥有2个20, 在中国传统习惯中, 好事成双,大家都喜欢偶数的东西, 同时20又是10的倍数,就更吉利。 看到2020年这么吉利的数字, 也祝愿自己新的一年, 顺顺利利, 开开心心。

今天,打开朋友圈, 发现一堆朋友,都跑步或健身, 似乎在这新的一年中, 大家都更积极面对生活,期待拥有一个更棒的身体。

最后立一个心愿清单吧: 1. 儿子身体棒棒, 个子长得高一点。 2. 每周带儿子和老婆, 做一次家庭运动。 3. 今年写完50篇博文 4. 看完12本书 (4本技术, 4本修心, 4本育儿) 5. 争取练出6块腹肌。 6. 每天12点前睡觉

最近花了几天的时间搭建和编译MySQL 环境

因为电脑之前安装过很多软件, 很多环境已经有一些混乱, 给编译和debug MySQL 带来很多坑。 踩过的坑,远超过网上的描述,还好在同事的帮助下和自己摸索,慢慢搞定。

Read more »

Abstract

论文是很早以前看的, 后来把笔记梳理一下。 F1 就是一套胶水系统, 将oltp和olap 系统粘在一起提供一个统一接口层和服务层, 类似数据库里面的HTAP系统, 但数据库htap系统往往是自身提供oltp和olap 服务, 而f1 是通过不同的系统来达到htap的效果。 F1 有一个背景就是现有很多数据库系统,如spanner, bigquery, dremel, 如果让应用无缝的在这么多系统中切换,一套接口,一套服务完成所有的事情。 今天的 TiDB 有一点点f1 的味道, 上层tidb server + tikv, tispark + tiflash,不过tidb 朝着tidb server + tikv/tiflash的方向演进, 融合程度更高一些, 不过f1 在oltp 上主要是依赖spanner 来完成。 曾经的hybriddb 更类似f1 这种架构。

坦白讲: 这种胶水系统没有什么前途, 对于oltp 业务, 对时延是非常敏感, 增加一层胶水系统, 不仅让时延增长很多,而且带来不确定性, 动不动抖动一下, 这些对oltp都是无法接受的, 因此粘合的场景是大数据的和olap的业务, 对于中小型企业, 大数据的系统太复杂, 一个olap 就够用,看看aws 上redshift 大行其道,就知道这个事实, 如果粘合多个olap,那就更不现实, 哪家公司没事干运行一大堆各式各样的olap系统, olap系统基本上就是赢者通吃, 没有那么多一个业务要跑好几个olap系统的, 所以这种胶水系统是没有什么前途的。 最后,google自己的员工透露到现在为止f1 已经事实上失败了。

架构图: f1_arc

Read more »

            <img src="{{ site.baseurl }}/img/keyilianxi.jpg" >

《刻意练习》

鲁肃推荐的一本书, 非常有意思,值得推荐。

成功都是靠大量不断提升的训练, 而刻意练习就是有针对性的训练。 在2000年, 英国科学家 对伦敦的出租车司机进行观察,出租车司机需要每天记住地图和所有标志性的建筑,用核磁共振观察16位出租车司机和普通50位男性相比,储存记忆的海马体要明显大很多。另外,对79名刚参加出租车考试的司机进行观察,在刚开始考试时, 大家的海马体在一个水平线上, 几年后, 79名中的41名仍然是出租车司机,另外38名中途放弃了, 结果这41名出租车司机的海马体要明显大于非出租车的38名非司机。

Read more »

            <img src="{{ site.baseurl }}/img/qiaobusi.png" >

乔布斯传,很早以前就看到人手一册, 但看到外界对乔布斯的点评就如同媒体点评马老师一样, 众彩纷纭, 最近因为机缘巧合, 被人要求阅读一下乔布斯传, 就把乔布斯传,拿过来读了一番, 读完之后,有很多不同的感悟,挑2个和大家探讨一下。 第一个印象就是 唯有偏执才能成功,做什么事情都有自己的想法和见地, 甚至对很多事情到了偏执的程度, 年少的乔布斯就放荡不羁,想到了什么就会坚信不疑, 对精神世界的探索, 对素食主义的偏好, 对极简主义的信奉,所幸这些偏执大部分都是善意的, 但在中国, 有句古语叫, 兼听则明, 偏听则暗, 个人观点, 天才往往是超凡脱俗, 天才往往总是坚持自己内心深处的追求, 总是引领世界, 将世界引向自己的方向, 如果非天才级的人物, 最终还是会走向“三个臭皮匠抵得上一个诸葛亮”,依赖群体智慧, 群体的智慧往往是最稳定,大部分时候都是正确的。 营销大师,这个世界上, 有2种事情是最难的, 第一就是从别人的口袋里把钱掏过来, 第二个,就是把自己的思想灌输到别人的大脑中。 乔布斯是一位世界级的营销大师。 乔布斯,最开始也不是总是灌输自己的idea到别人的脑中, 但从印度之行回来后, 就开始开挂的人生, 总是在不停的说服其他人按照自己想法,当还是一家小公司时,在做每次展览的时候,就深谙如何抓住眼球 而且他总是和很多营销大师进行交流, 因此他的营销技巧在不断的完善, 另外,他对营销的追求, 远远是高于其他人一个量级, 因此,当苹果的广告出来时,总是给人耳目一新。 营销已经不仅仅对苹果的产品产生深远影响, 同样带来了一个 “乔布斯磁场”, 当乔布斯出现时,大家最后总是在不知不觉中和乔布斯的观点一致。

最后,一千个读者就会有一千个哈姆雷特, 相信大家每次阅读乔布斯,都会有不同的感悟 。

认知革命

概述

花了半天,快速学习了认知革命的课程,不能保证能理解李善友所表达的所有观点, 只能说按照我现有的知识体系,对他的理论有一个消化和吸收。 他有几个核心观点, (1)第一性原理 (2)认知世界的方式 (3)科学革命 (4)非连续性。

第一性原理

第一性原理, 我个人非常赞同这个观点, 其实就是哲学中的现象和本质说, 只不过换了一个角度来演绎这个说法, 另外在李善友的观点中, 第一性原理是需要建立在认知世界方式中演绎归纳法的基础上, 认知世界的方式中演绎法,需要一个假设的前提, 这个前提是一个具备自证清白的共识,这个共识就是第一性原理。 我个人观点,这是哲学中现象和本质 这一理论的另外一个说法而已。

在我们今天人类的发展历史上, 所有的科学进步都是为了一个目标, 如何让人类变得更懒, 更舒适。 曾经paypal 的创始人Peter Thiel就说过关于创新的一段话(原话已经忘记,但意思应该差不多), 所有的创业第一原则,就是让人们更懒去完成一些事情, 另外,乔布斯信奉的 大道至简(简单就是美) 的产品理念, 其实,就是让用户不要去花时间去思考什么是好的。今天我们程序员开发, 为什么进行模块化,分层化, 就是将每个成果固化,方便别人快速使用。 我们开源一个技术, 就是让别人不要再花时间再去重复建设, 直接站在别人的肩膀上工作。另外,比如,像浏览器之争, 今天google chrome 浏览器做到浏览器的第一把座椅, 就是google chrome 是最快的浏览器(至少号称是最快的), 对于浏览器的众多需求中, 没有一个需求是能和性能相比, 人们永远都是追求更高,更快, 更远。

对比今天的产品设计, 如果我们面向用户, 那我们在思考用户的需求中, 哪些是最核心的需求, 哪些是第二原则, 哪些是末等公民。同样,如果我们中间件推出一些产品如果面向程序员, 帮助程序员开发程序, 那我们第一需求是什么, 第一需求就是如何帮助程序员更快的开发程序,帮助他们用更短的代价完成业务目标。 从技术语言的发展上, 从早期c 到c++, 再到java, 再到python, scala, go, 语言的层次愈来愈高, 一份需求需要的代码数量也变得越来越少。

认知世界的方式

在李善友的观点中, 认知世界, 有3种方式, 1. 归纳法, 2. 演绎法, 3. 带假设的归纳法; 归纳法就是通过大量的结果,来抽象出一个事务的内在联系,是一个证明在前,假设在后的逻辑思维, 由果去推因,这种思维会遭遇一个坑, 就是归纳出来的理论,只能证伪,不能存真, 只能用来验证一些东西,而不适合去做为普遍真理;而演绎法, 通过一些假设,再加上一些已知的规律, 由假设一步一步来推导结果, 是一个假设在前, 证明在后的观点, 由因去推果, 这种思维其实是更符合逻辑思维, 符合世界是由本质来推导出原因的过程, 不过这种思维会遭遇一个悖论, 演绎法需要一个证明的起点, 就是能够自证清白的原理,也就是第一性原理,当第一性原理不存在或无法自证清白时,就无法完成整个演绎; 因为2种理论都会有一些瑕疵, 因此李善友提出了一个补充,就是带假设的归纳法。

对世界的认知方式上, 从逻辑思维角度出发, 演绎论会更全面更严谨; 归纳法会直接,更快速。 对于我们it 工程师来说, 结合第一性原理和科学革命原来来思考, 很多的事情都是要抓住事物的本质, 少受一些干扰项干扰, 当现有的做法是从大量的结果中抽象出一套规律时, 我们需要研究是不是需要从客户的最本质需求上去思考,如何一步一步完成客户最大的痛点。

科学革命

科学革命,在李善友的名词中, 有一个叫范式转换, 就是 只有管道更替, 创新是新的范式出现, 对过去很多东西,是一个颠覆性思考, 或者是完全换道考虑。 就像intel 从存储器转到cpu领域, 苹果推出iphone, 所谓 “重新定义手机”, 对过去的功能机一种完全全新的革命。

我对这种观点认为, 科学革命是一种颠覆性的创新, 这种创新其实很难, 也是非常少见的。 但有几点,需要注意 1. 自我革命的勇气, 当意识到一种新的创新出现时, 必须有勇气自我革命, 就是腾讯 就说过, 微信就是要革qq的命, 如果害怕革命, 当别人完成自我蜕变时, 自己就沦为鱼肉, 比如柯达, 当数码出现时,没有及时抛弃传统胶片,最终被市场抛弃。 2. 这个事情大的创新都是非常非常难的, 只能从几个角度去努力尝试创新, 从认知世界的方式出发, 从用户最本质的需求上, 从另外一个赛道上全新去演绎一件事情, 会有更多的思路。 另外个人观点是, 博采众家之长, 把一个领域的成功经验移植到另外一个领域, 从而对这个领域进行全新的改变。 就像《三体》里面说的降维攻击。

非连续性

李善友的观点是 “世界是由非连续性节点组成,而人类的认知是由连续性的节点来贯穿, 在一些非连续的节点之间穿插连续的桥梁, 而这些桥梁就是人类解决问题的各种手段”。 我觉得这个观点可能正确, 但没有什么大的价值。 对于一个程序员来说, 这个世界无论是连续还是非连续性的, 在计算机的世界里面都是非连续性的, 需要一些手段将他们连贯起来。 任何一个曲线都是由一串的节点贯穿起来。

插曲

screamscope 论文读了好几个月了,把之前分享,今天发出来。


总结:

论文主要是提出一种设计理念 rVertex/rStream, 这个设计理念其实还非常先进。尤其是在低延迟和容错性上思考很多

这个设计理念换了一种角度来思考常见的分布式计算框架(常见思路,主要是考虑DAG 和节点), 将计算拆解为计算单元(rVertex)和管道(rStream)2种抽象, 尤其是管道(rStream)将上下游的关系进行解藕, 对failure 问题上还是解的很漂亮。

核心一些观点:

  • 这套系统起源于批处理系统SCOPE, 是对SCOPE 系统一个扩展,并且将原来一些批处理的任务已经迁移到StreamScope 上。已经部署到2万台机器上,每天处理百亿/数十TB 的数据。另外因为它起源于SCOPE, 它应该用sql 解决应用问题上, 会比其他流式框架要更成熟(这个是个人猜测);
  • 用户接口上面, 为用户提供申明式语言(类似sql)和udf,
  • 用户提交一段类sql,将它编译成logic plan(含一些udf和各种算子),然后用优化器,选择一个最优路径,然后,转化为physical plan,部署到每台机器上, 最后用job manager 来跟踪所有的状态。 很多组件都是用scope的组件完成或稍加改造。 (现代系统大致思路都是这个逻辑)
  • 接口抽象上,接口还是适配性非常强; 节点rVertex 提供3个核心接口Load/Execute/GetSnapshot, 这个模型可以适配到绝大部分计算场景。rStream 接口 Write(seq, e)/Register(seq)/GarbageCollect(seq)
  • 在容错性上, 首先通过rStream 来将上下游节点进行解藕, 下游的失败不一定需要影响到上游, 然后提供3种策略来,让用户选择。(读者可以看后面的详细介绍)
  • 在exactly-once 要求上, 依赖3大部分: 1. 容错机制; 2. sequence number(每条消息配置单调递增的) 3. 确定性, 明确每个节点在状态相同时,接受相同输入时(无论是多实例同时计算或者同一个实例重启后计算),必须产生相同结果
  • 性能上, 1. 通过sequence number来减少ack 数据流;2. rStream 的3层设计 (volatile/Reliable/GC)在保障稳定性同时,可以获得一些好的性能。3. 一次读取,可以获取一个小collection

Read more »

插曲

《The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing》 2015年,这篇文章就发布了, 每次快速扫描, 理解上总是有些遗漏, 最近,决定将他翻译一下, 仔细阅读一下. 补充一下,2.4及之后的章节自己看了,但是没有翻译, copy一下同事默岭的翻译(版权归默岭所有哦)。

为什么重新设计dataflow 编程模型

  1. 一份代码运行在不同的引擎, 现有很多google的业务方, 使用lambda架构, 实时部分使用millwheel做一些计算,不能保证完全正确, 然后通过离线flumejava作业不停的矫正数据。 (吐槽一句, millwheel 论文里面说自己的强一致多么牛x, 最后在dataflow 论文里面被打脸, 不过,millwheel里面提到的强一致设计是可以保证强一致,但成本非常高)。 业务方只需要实现一次代码,就可以在不同的引擎上切换,按照自己的业务需求。
  2. 会话窗口需求, 需要支持session window
  3. trigger, accumulate和retraction 需求, 一些业务方使用watermark来标记数据已经完成,但经常有数据延迟到达,因此,需要处理迟到的数据。 整个设计需要考虑: 1. 支持增量处理, accumulate和retraction; 2, trigger机制, 一份相同的数据,根据不同的准确性和扩展性要求,选择不同的模式,从而达到不同的结果。
  4. 水位线百分位触发器, 比如, 部分节点处理特别缓慢, 成为job的长尾, 拖慢了整个项目的进度。 另一个需求是, 很多时候,只需要达到一个很高的准确行就好了,而不是100%准备。 这样,只需要通过percentile watermark trigger, 就可以确定是否要提前终止长尾任务或提前计算。
  5. 时间trigger, 在google 推荐系统中, 使用大量google 基础设施建立用户行为画像, 这些用户行为画像会被用来根据兴趣来做推荐。注意的是, 这些系统使用处理时间进行数据驱动, 因为,这些系统需要经常更新,并且查看局部view 数据比等待直到当watermark 来了计算完整view 更重要。也就是说,对于一些时效要求高的系统, 必须具备根据处理时间来进行驱动的。
  6. 数据驱动 & 组合trigger, 在MillWheel的论文中,我们描述了一种用来检测谷歌网站搜索查询趋势的异常探测系统。当我们为模型设计触发器的时候,这种微分异常探测系统启发我们设计了数据驱动触发器。这种微分探测器检测网站检索流,通过统计学估计来计算搜索查询请求量是否存在一个毛刺。如果系统认为一个毛刺即将产生,系统将发出一个启动型号。当他们认为毛刺已经消除,那么他们会发出一个停止信号。尽管我们可以采用别的方式来触发计算,比如说Trill的Punctuations,但是对于异常探测你可能希望一旦系统确认有异常即将发生,系统应该立即输出这个判断。Punctuations的使用事实上把流处理系统转换成了微批次处理系统,引入了额外的延迟。在调查过一些用户场景后,我们认为Punctuations不完全适合我们。因此我们在模型中引入了可定制化数据驱动触发器。同时这个场景也驱使我们支持触发器组合,因为在现实场景中,一个系统可能在处理多种微分计算,需要根据定义的一组逻辑来支持多种多样的输出。图9中的AtCount触发器是数据驱动触发器的例子,而图10-14使用了组合触发器。
Read more »