WBINGのBLOG

来美团也三个月了，也渐渐习惯这边的风格。再流程制度上，有让我觉得很不错的地方，也有一些需要改善的地方。自己的能力模型上，还有哪些需要提高的，接下来自己需要在这些地方进步。 好的地方 文档。在文档这方便做的挺好的，把工作中很多都能记录下来，比如会议纪要，产品PRD，技术方案，月度总结等，以及各个系统的详细文档等。而且也能搜到很多技术方案设计，能力模型等。这样比较详细的学习别人怎样去做的，怎样设计的。 各个基础平台和系统。在这边不用什么都从头开始，公司提供了各种基础平台，比如服务发布的CI/CD工具，微服务的RPC框架，服务治理，熔断降级等系统。以及各种存储，KV存储，es平台，大数据平台等，让自己能够专注于业务，而不需要放很多精力在以来的平台开发运维上面。 流程规范。大公司流程还是比较规范的，如开发上线流程，整套流程每一步都细化，大家按照这套流程开发。极大的规避掉一些因为个人理解偏差和信息对齐上面造成的上线问题，能够保质保量的进行新功能迭代上线。 制定绩效合同，后面绩效根据此打，更大化的做得客观。 因为我原来是做大数据平台的，更多的面向的是公司内部，而现在是面向用户。可以感受到 ...

很快，已经大半年没写博客了，这半年内，一直再准备面试，找工作，终于在7月去了自己还认为不错的公司。也发现自己已经工作四年了。如果要给自己前四年以一个词语做总结的话，我想我会选择“混沌”这个词。 过去在物理学上，混沌（chaos）是指确定性动力学系统因对初值敏感而表现出的不可预测的、类似随机性的运动。又称浑沌。英语词Chaos源于希腊语，原始 含义是宇宙初开之前的景象，基本含义主要指混乱、无序的状态。 而自己曾经的过往也是这样的随机飘荡。没有为自己制定一个人生目标，也不造为何而追求，是我之前很长一段时间的状态。主要体现在我认为的以下几点： 没有制定人生规划。因为没有大方向，所以很多时候更偏向于随遇而安。 工作单位随意性。和人生规划也有关，所以在面临单位的抉择方便没有去更加的努力。没有想好不同的单位能为我带来什么样的背景和能力。 情感的随意性。在情感方面，自己并没有什么优势，所以更需要自己勇于去争取。而为此，需要去提高自己的设计能力，沟通表达能力，自己却没有过多的在意。 到底想要什么。这个问题思考的不够深刻，因为道路上的一些阻碍，也造成前进方向的左右摇摆。 勇敢去争取的心。无论在工作上， ...

这些天，在标签调度上，可预见性的标签调度会越来越多，如果全由调度系统承载，调度系统压力增大，负责调度系统的同事担心会影响其他任务，遂在讨论下，决策开发一个简版的标签执行服务/脚本（相比现有调度系统，只保留任务执行控制，例如池化，并发控制等，任务编排，启动时间都由调度系统控制，整个执行服务就是调度系统的一个task）。而我对此持保持意见，我认为应该增强调度系统能力，2333。 既然决策已定，加上部门现在主要使用python，而调度系统也使用的是airflow，所以主要开发语言也定为python。对于此执行服务/脚本，希望能够并行的执行任务，并且能够控制每次在跑的任务数。调研了下python的并发模型，以及多线程的知识。很多说python多线程是鸡肋，而自己也不想引入第三方并发的库，又看到python支持协程，且相比线程轻量很多，代码易理解，遂最终选定使用协程来实现这个需求。 协程网上对协程的解释众说纷纭，有说协程是一种用户态的轻量级线程，协程的调度完全由用户控制。wikipedia的定义：协程是一个无优先级的子程序调度组件，允许子程序在特点的地方挂起恢复。但大家对协程 ...

不在以流水形式记录，而网易云音乐年报体搞笑却不能展示更多。在朋友圈看了别人的发的年终总结，遂借鉴其模板。 2018年让你印象深刻的5件事情是什么？ 定级答辩，完全暴露了自己的弱点，当大领导说自己的ppt很渣时，很懵逼。自己确实没太上心，做的少。虽然后来又重改了，但最终其实效果都不是很满意，包括答辩。表达能力以及技能包装能力都还需要多加练习。最后感谢领导的细心指导。 不应该老拿别人的弱点说事或者开玩笑。A之前说了个毫无依据的话被大家笑话，然后就竟然被大家拿出来说，以至于大家一旦把焦点给与他，他便有了种不舒服，即便知道大家也是寻乐。自己也会一直拿别人的弱点寻乐，虽然是玩笑，但别人的感受未必是玩笑。当然自己也会被拿着弱点一直攻击你，当然也是寻乐，但自己确实也有不爽，将心比心，也许有时候会意的鼓励会更好。以后自己应该多注意，少娱乐他人的弱点，多提升自己的弱点。 接近年底，回家办理贷款手续，正好外婆过生，一大家人和和睦睦，开开心心的氛围真好。希望明年能带外婆来北京玩，外婆那些年一路过来不容易，现在也该享享清福了。 你做的引以为傲的5件事？ 终于还是借着低价买的域名，开通的博客，开始记录技术，生 ...

之前讲解了Google的Dataflow模型。而spark streaming是以micro batch方式来近似streaming数据进行处理。Spark Streaming从实时数据流接入数据，再将其划分为一个个小批量供后续Spark engine处理，所以实际上，Spark Streaming是按一个个小批量来处理数据流的。 spark streaming离散数据流（DStream）是Spark Streaming最基本的抽象。它代表了一种连续的数据流，要么从某种数据源提取数据，要么从其他数据流映射转换而来。DStream内部是由一系列连续的RDD组成的，每个RDD都是不可变、分布式的数据集。每个RDD都包含了特定时间间隔内的一批数据，如下图所示： 任何作用于DStream的算子，其实都会被转化为对其内部RDD的操作。例如，在代码 1val words = lines.flatMap(_.split(" ")) 中，我们将lines这个DStream转成words DStream对象，其实作用于lines上的flatMap算子，会施加于lines中的每个RDD ...

Livy是一个基于Spark的开源REST服务，它能够通过REST的方式将代码片段或是序列化的二进制代码提交到Spark集群中去执行。它提供了以下这些基本功能： 提交Scala、Python或是R代码片段到远端的Spark集群上执行； 提交Java、Scala、Python所编写的Spark作业到远端的Spark集群上执行； 提交批处理应用在集群中运行。 livy安装livy安装很简单，从官网下载zip包。解压，设置spark和hadoop的环境。 12export SPARK_HOME=spark的路径export HADOOP_CONF_DIR=/etc/hadoop/conf （hadoop配置路径） 然后在livy的bin目录下执行：livy-server start livy配置在conf/livy.conf文件中有配置，常用的配置： 配置信息 含义 livy.server.host = 0.0.0.0 livy服务启动的host livy.server.port = 80 启动端口号 livy.spark.master ...

airflow 是一个编排、调度和监控workflow的平台，由Airbnb开源。airflow 将workflow编排为tasks组成的DAGs，调度器在一组workers上按照指定的依赖关系执行tasks。同时，airflow 提供了丰富的命令行工具和简单易用的用户界面以便用户查看和操作，并且airflow提供了监控和报警系统。 airflow 核心概念 DAGs：即有向无环图(Directed Acyclic Graph)，将所有需要运行的tasks按照依赖关系组织起来，描述的是所有tasks执行的顺序。 Operators：可以简单理解为一个class，描述了DAG中一个具体的task具体要做的事。其中，airflow内置了很多operators，如BashOperator 执行一个bash 命令，PythonOperator 调用任意的Python 函数，EmailOperator 用于发送邮件，HTTPOperator 用于发送HTTP请求， SqlOperator 用于执行SQL命令…同时，用户可以自定义Operator，这给用户提供了极大的便利性。 Tasks：Task ...

原始译文厦门大学林子雨老师翻译，见Google Spanner (中文版) 简介Spanner是谷歌公司研发的、可扩展的、多版本、全球分布式、同步复制数据库。它是第一个把数据分布在全球范围内的系统，并且支持外部一致性的分布式事务。本文描述了Spanner的架构、特性、不同设计决策的背后机理和一个新的时间API，这个API可以暴露时钟的不确定性。这个API及其实现，对于支持外部一致性和许多强大特性而言，是非常重要的，这些强大特性包括：非阻塞的读、不采用锁机制的只读事务、原子模式变更。 Spanner是个可扩展，多版本，全球分布式还支持同步复制的数据库。他是Google的第一个可以全球扩展并且支持外部一致的事务。Spanner能做到这些，离不开一个用GPS和原子钟实现的时间API。这个API能将数据中心之间的时间同步精确到10ms以内。因此有几个给力的功能：无锁读事务，原子schema修改，读历史数据无block。 功能从高层看Spanner是通过Paxos状态机将分区好的数据分布在全球的。数据复制全球化的，用户可以指定数据复制的份数和存储的地点。Spanner可以在集群或者数据发生变化的 ...

标签数据存储在Hbase中，为了加速标签探索功能，会每天导出一份全量数据表。有时候用户也会进行特定标签勾选导出需求。 导出遇到的问题导出后，出现部分用户，同一个用户多条数据（两条为主），见下图： 从图中可以看出，出现了重复用户uid。 问题原因首先想到会不会是源数据问题，即Hbase中存储的数据造成的。为何如此想，是因为为了用户scan并发度和热点问题，对rowkey进行了hash(uid)分区。会不会在之前hash方法有变化，造成了脏数据问题。这点个人想了下，貌似也没变过hash函数啊，不应该出现uid hash后出现不同值啊。 然后对重复的uid随机抽取了几个，查看了数据情况。发现重复的uid的标签数据，标签总是错开的，即第一条数据有标签A;B;C,第二条A;B;C数据为空，而其他标签数据存在。这是一个突破口，思考会不会在导出的过程中，同一个用户的标签并截成了两段，出现了两天数据。为什么如此，这个需要简单介绍下在使用spark程序导出Hbase存储的标签的code。 123456789val hbaseCols = hBaseContext.hbaseRDD(TableNam ...

snapshot（快照）基础原理snapshot是很多存储系统和数据库系统都支持的功能。一个snapshot是一个全部文件系统、或者某个目录在某一时刻的镜像。实现数据文件镜像最简单粗暴的方式是加锁拷贝（之所以需要加锁，是因为镜像得到的数据必须是某一时刻完全一致的数据），拷贝的这段时间不允许对原数据进行任何形式的更新删除，仅提供只读操作，拷贝完成之后再释放锁。这种方式涉及数据的实际拷贝，数据量大的情况下必然会花费大量时间，长时间的加锁拷贝必然导致客户端长时间不能更新删除，这是生产线上不能容忍的。 snapshot机制并不会拷贝数据，可以理解为它是原数据的一份指针。在HBase这种LSM类型系统结构下是比较容易理解的，我们知道HBase数据文件一旦落到磁盘之后就不再允许更新删除等原地修改操作，如果想更新删除的话可以追加写入新文件（HBase中根本没有更新接口，删除命令也是追加写入）。这种机制下实现某个表的snapshot只需要给当前表的所有文件分别新建一个引用（指针），其他新写入的数据重新创建一个新文件写入即可。 snapshot流程主要涉及3个步骤： 加一把全局锁，此时不允许任何的数 ...