big data decode club

一个Applciation运行在YARN上的流程为，从YARN Client向ResourceManager提交任务，将Applciation所需资源提交到HDFS中，然后ResourceManager启动APPMaster，APPMaster通知各个NodeManager启动container执行具体到计算任务。在启动container之前需要从HDFS上下载该container执行所依赖的资源，这些资源包括jar、依赖的jar或者其它文件，这个过程就称为资源本地化(Resource Localization)。 本篇主要介绍下资源本地化相关的内容。 相关概念本地化(Localization)本地化是指将HDFS上的资源下载到本地的过程。将资源本地化，使container不用总是访问HDFS上的数据，而是直接访问本地数据，提高效率。 本地资源(LocalResource)本地资源是指container运行时所需要的资源，可以是某个文件或者依赖的library，这些资源存在HDFS中。NodeManager在container启动之前负责将这些资源进行本地化。对于Applicati ...

本篇是一篇译文，主要介绍下FSImage改进为protobuf的设计原理，原文地址。 背景为了能从故障中快速恢复，HDFS会周期性的将内存中的namespace在磁盘上的文件系统中进行持久化。FSImage的性能和扩展性在保证数据的耐用性和可用性上至关重要。随着越来越多的高级功能被引入HDFS中，FSImage已经从一个简单的blob演变为了一个需要存储在磁盘的复杂的数据结构。FSImage有3个方面需要改进： 效率在生成环境中，我们观察到持久化到磁盘的FSImage大小能达到二三十GB。因为加载和停机时保存FSImage是NameNode的关键环节，其效率对确保NameNode操作的可用性非常重要。 兼容性FSImage将随着HDFS的各种功能的不断发展和演变。FSImage的实现将能够被各种不同的版本所使用，这在某些功能下非常重要，比如滚动升级。 互通性FSImage能被第三方工具访问的需求越来越强烈了。例如某个工具可以通过扫描FSImage收集一些统计信息。因此FSImage应该提供一个使第三方工具能与其进行交互的清晰规范。 当前FSImage模块有大约2500行代码，但 ...

分布式系统中有个著名的原则CAP原则，C为Consistency(一致性)、A为Availability(可用性)、P为Partition tolerance(分区容错性)。这里主要介绍下分布式环境下如果达到一致性。 说到一致性不得不说下经典的拜占庭问题。 拜占庭问题话说一组拜占庭将军分别各率领一支军队共同围困一座城市。为了简化问题，将各支军队的行动策略限定为进攻或撤离两种。因为部分军队进攻部分军队撤离可能会造成灾难性后果，因此各位将军必须通过投票来达成一致策略，即所有军队一起进攻或所有军队一起撤离。因为各位将军分处城市不同方向，他们只能通过信使互相联系。在投票过程中每位将军都将自己投票给进攻还是撤退的信息通过信使分别通知其他所有将军，这样一来每位将军根据自己的投票和其他所有将军送来的信息就可以知道共同的投票结果而决定行动策略。 系统的问题在于，将军中可能出现叛徒，他们不仅可能向较为糟糕的策略投票，还可能选择性地发送投票信息。假设有9位将军投票，其中1名叛徒。8名忠诚的将军中出现了4人投进攻，4人投撤离的情况。这时候叛徒可能故意给4名投进攻的将领送信表示投票进攻，而给4名投撤离的 ...

cryptozombies源码解析一中对以太坊开发中的事件与合约交互进行了介绍，看过这篇文章的同学我相信对Dapp开发也有了一个初步的了解，下面我们继续学习一些智能合约开发中特性。 如何减少gasgas是EVM中代码执行所消耗资源的计量单位，gas是需要用以太币购买的，现在你是不是已经get到了为什么要减少gas了，嘿嘿。。。 使用合适的数据结构这里以uint为例，在Solidity中除了有基本版的uint外，还有其他变种uint：uint8，uint16，uint32等。通常情况下我们不会考虑使用uint变种，因为无论如何定义 uint的大小，Solidity为它保留256位的存储空间。例如，使用uint8而不使用uint(uint256)，并不会为你节省任何gas，因为Solidity始终保留了256的空间。 那么为什么还要有其他uint的变种呢？是因为在struct里，可以通过声明具体的uint变种来节省存储空间。在struct里，相同类型的uint要紧邻，例如uint8的变量要放在一起，uint16的要放在一起，这样可以将这些uint打包在一起，从而占用较少的存储空间。 1 ...

学习区块链的朋友应该都了解去年又一款迷恋猫的爆款游戏，他是一款基于以太网的Dapp游戏。此游戏将区块链应用推向了高潮，网上各种解读接踵而来。但对于学习区块链的技术人员肯定想从代码层次学习下，想借此掌握一些Dapp开发的技巧，我也是这么想的，但是不巧的是我的水平有限(虽然代码真的很简单，代码量也不多)，读了一遍源码发现脑子里没有留下什么。 于是就在网上各种找资料，无意中发现了Loom Network的一个游戏教程cryptozombies，就尝试了下，发现停不下来，就把Solidity 教程: 智能合约基础教程给学完了。在学习的过程中发现很多知识也在迷恋猫的代码中出现了，瞬间感觉开朗了很多。 此篇博客算是学完课程之后的回顾和总结吧。 僵尸工厂这是个僵尸游戏，所以游戏的开始肯定得有个创造僵尸的地方，这里就是从僵尸工厂开始的。先贴下代码，相信有点代码基础的同学都可以看懂。 12345678910111213141516171819202122232425262728293031323334353637383940// zombiefactory.solpragma solidity ^0 ...

前面提到Ozone的原创团队对大规模Hadoop集群运维和优化有着丰富的经验，所以Ozone的设计中也体现了很多HDFS的优点，并屏蔽了一些HDFS的性能瓶颈。 HDFS目前的瓶颈主要在NN上，NN内存中维护着两个大对象，一个是NameSpace，另一个是BlocksMap，这两个是常驻内存而且随着集群存储的文件数和规模成线性增长，这就造成NN的内存占比越来越大，成为HDFS扩展的瓶颈。 那么Ozone是如何解决这些瓶颈呢？ NameSpace扩展性 Ozone使用Ozone Manager的服务来管理namespace，其并不会把整个namespace存储在一个节点的内存中，而是只将一些正在使用的集合存储在内存中。(因为namespace具有本地引用性，所以可以这么搞) Block Map扩展性 这部分解决起来比较难，因为其不像namespace一样具有本地引用性，因为block map是dn周期性的把每个块的信息汇报给nn而来的。Ozone将此问题委托给名为Hadoop Distributed DataStore(HDDS)的共享通用存储层来解决 接下来主要谈下Ozo ...

之前一篇文章介绍了在小文件合并方面的一些心得，*本篇介绍下Hadoop解决小文件的最新利器Ozone(本篇基于0.3.0-alpha版本)*。 Ozone诞生的背景众所周知，HDFS是大数据存储系统，并在业界得到了广泛的使用。但是无论大集群还是小集群其扩展性都受NN的限制，虽然HDFS可以通过Federation进行扩展，但是依然深受小文件和4亿个文件的困扰。 于是分布式key-value存储系统Ozone诞生了，Ozone能够轻松管理小文件和大文件。(HDFS提供了类似POSIX的语义，Ozone的外观和行为更像一个Object存储系统。) OzoneOzone是专门为Hadoop设计的可扩展的分布式对象存储系统。Hadoop生态中的其它组件如Spark、Hive和Yarn不需要任何修改就可以直接运行在Ozone之上。Ozone的使用方式也较为丰富，可以通过命令行直接使用也有java客户端接口，而且接口支持RPC和REST。 Ozone由volumes、buckets和Keys组成，其中Volumes只有管理员能够创建和删除，类似账号的概念，管理员一般都是给某个团队或者组织创建一 ...

HDFS是一个大数据存储系统，主要面向的场景是一次写入多次读取，大文件。但是在实际使用过程中由于各种原因集群中总是充斥着各种小文件，而且数据惊人。无论社区还是公司都在积极解决这个问题。(为什么要解决小文件，这个问题我想看到这篇文章的人应该都知道啊!) 无论你怎么优化集群，指定各种规范，让业务方优化程序，小文件总是无法避免的。 都说解决一个问题，不能只从表面去解决，需要从根上彻底解决，需要根据产生问题的n个原因去解决，但是这种方式对目前小文件这个问题上确实不好办。即使你知道小文件产生过多的原因很大一部分归结于用户的应用程度在执行的时候没有很好的预估写出数据量的规模，导致写出过多的小文件。你依然无法从根上解决这个问题，因为你要想从根上解决这个问题需要用户对自己程序的逻辑和数据有较高的了解，而且用户的水平也参差不齐，最最重要的是用户认为这是尼玛平台该优化的事，干毛浪费我的时间给你搞。所以种种原因造成收益较少。 不能从根上解决这个问题，那就只能从面上解决这个问题了。怎么解决？那就是定期对小文件进行合并(是不是比较low，嘿嘿)。 合并方案 Hadoop Archives很早提出的一种解决方 ...

区块链一个重要的亮点就是防篡改，那么它是怎么做到防篡改的呢？其中一个重要的知识点就是Merkle Patricia Tree(MPT)，本篇就来解析下何为MPT。 MPT是一种加密认证的数据结构，它融合了Merkle树和Patricia Trie树(基数树/压缩前缀树)两种数据类型的优点。 则在介绍MPT树之前先介绍下Merkle树(默克尔树)、Trie树(前缀树)和Patricia Trie(基数树/压缩前缀树)，介绍Trie树是因为Patricia Trie是基于Trie树衍化来的。 Trie树Trie树又称前缀树或字典树，是一种检索树，使用一个有序的树结构存储一个动态数据集或者关联数组，其中的键通常是字符串。与二叉查找树不同，键不是直接保存在节点中，而是由节点在树中的位置决定。一个节点的所有子孙相对于当前节点都有相同的前缀，而根节点为空字符串。一般情况下，不是所有的节点都有对应的值，只有叶子节点和部分内部节点所对应的键才有相关的值。 Trie树中，key是从树根到对应value得真实的路径。即从根节点开始，key中的每个字符会标识走那个子节点从而到达相应value。Value ...

随着容器和编排技术持续发展，各个公司都已陆续在容器云领域有了相关实践，转转也不例外，也在进行一些积极探索与实践。本文以日志采集为切入点，介绍下转转容器云平台中的业务日志是如何自动化采集的。 背景在微服务和docker大火的当下，各个公司都在积极主推容器化，最大化的利用资源并减少运维成本，希望各个业务方能尽早接入云平台。 而做为数据团队的我们却遇到了一个问题，我们的数据源绝大多数都来自于业务程序的埋点日志，如果业务方迁移到云平台，埋点日志将无法采集，所以我们急需一套云平台日志采集方案。 先看下容器日志采集与传统日志采集的区别 容器日志采集与传统日志采集区别容器云平台的最大的特点就是能够最大化的利用资源，并且利用编排工具可以做到弹性伸缩，所以容器云与传统日志采集的最大区别有如下两点： 采集日志的实例较多，且数据量较大。 采集日志分布不固定，无法像传统日志采集方案那样配置固定的采集目录。 调研 最简单粗暴的方法就是让业务方将埋点日志直接打入kafka或者redis等中间件，这种方式对业务侵入性较大，无法做到对业务无感知，要保证日志传输的可靠性也比较困难。 使用容器推荐的方法将日志写到 ...