partition

OpenStack Object Storage（Swift）是OpenStack开源云计算项目的子项目之一。Swift使用普通的服务器来构建冗余的、可扩展的分布式对象存储集群，存储容量可达PB级。Swift的是用Python开发。 Swift提供的服务与AWS S3基本相同： 作为IaaS的存储服务 与OpenStack Compute对接，为其存储镜像 文档存储 存储需要长期保存的数据，例如log 存储网站的图片，缩略图等 Swift使用RESTful API对外提供服务，目前 1.4.6版本所提供的功能: Account（存储账户）的GET、HEAD Container（存储容器，与S3的bucket相同）的GET、PUT、HEAD、DELETE Object（存储对象）的GET、PUT、HEAD、DELETE、DELETE Account、Container、Object的元数据支持 大文件（无上限，单个无文件最大5G，大于5G的文件在客户端切分上传，并上传manifest文件）、 访问控制、权限控制 临时对象存储（过期对象自动删除） 存储请求速率限制 临时链接（让任何用户访问对象，不需要使用Token） 表单提交（直接从HTML表单上传文件到Swift存储，依赖与临时链接） swift的构架一般如下：可扩展性和伸缩性是我们的主要目标 swift服务依赖于以下技术

性能测试及集群监控工具 Kafka提供了非常多有用的工具，如 Kafka设计解析（三）- Kafka High Availability （下） 中提到的运维类工具——Partition Reassign Tool，Preferred Replica Leader Election Tool，Replica Verification Tool，State Change Log Merge Tool。本章将介绍Kafka提供的性能测试工具，Metrics报告工具及Yahoo开源的Kafka Manager。 Kafka性能测试脚本 $KAFKA_HOME/bin/kafka-producer-perf-test.sh 该脚本被设计用于测试Kafka Producer的性能，主要输出4项指标，总共发送消息量（以MB为单位），每秒发送消息量（MB/second），发送消息总数，每秒发送消息数（records/second）。除了将测试结果输出到标准输出外，该脚本还提供CSV Reporter，即将结果以CSV文件的形式存储，便于在其它分析工具中使用该测试结果 $KAFKA_HOME/bin/kafka-consumer-perf-test.sh 该脚本用于测试Kafka Consumer的性能，测试指标与Producer性能测试脚本一样。 Kafka Metrics Kafka使用

kafka 架构Terminology(术语) broker（代理） 　　Kafka集群包含一个或多个服务器，这种服务器被称为broker Topic 　　每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic（可以理解为队列queue或者 目录 ）。物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处。　　 Partition 　　Parition是物理上的概念（可以理解为 文件夹 ），每个Topic包含一个或多个Partition。 Producer　　 　　生产者，负责发布消息到Kafka broker。 Consumer 　　消息消费者，向Kafka broker读取消息的客户端。 Consumer Group 　　每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。 Kafka拓扑结构 Topic & Partition 　topic可以看成不同消息的类别或者信息流，不同的消息根据就是通过不同的topic进行分类或者汇总，然后producer将不同分类的消息发往不同的topic。对于每一个topic，kafka集群维护一个分区的日志

什么时候需要 shuffle writer 假如我们有个 spark job 依赖关系如下 我们抽象出来其中的rdd和依赖关系: E <-------n------, C <--n---D---n-----F--s---, A <-------s------ B <--n----`-- G 对应的划分后的RDD结构为： 最终我们得到了整个执行过程： 中间就涉及到shuffle 过程，前一个stage 的 ShuffleMapTask 进行 shuffle write， 把数据存储在 blockManager 上面， 并且把数据位置元信息上报到 driver 的 mapOutTrack 组件中， 下一个 stage 根据数据位置元信息， 进行 shuffle read， 拉取上个stage 的输出数据。 这篇文章讲述的就是其中的 shuffle write 过程。 spark shuffle 演进的历史 Spark 0.8及以前 Hash Based Shuffle Spark 0.8.1 为Hash Based Shuffle引入File Consolidation机制 Spark 0.9 引入ExternalAppendOnlyMap Spark 1.1 引入Sort Based Shuffle，但默认仍为Hash Based Shuffle Spark 1.2

1 redis的事务(pipeline)测试 　　Redis本身对数据进行操作，单条命令是原子性的，但事务不保证原子性，且没有回滚。事务中任何命令执行失败，其余的命令仍会被执行，将Redis的多个操作放到一起执行，要成功多成功，如果失败了，可以把整个操作放弃，可以实现类似事物的功能。redis事务包含三个阶段：开始事务，命令入队，执行事务。redis的分片副本集集群不支持pipeline，redis只支持单机版的事务（pipeline），Redis的主从复制也支持pipeline（目前一些公司就是这样干的）。若是想用集群，可以使用MongoDB， MongoDB集群支持事物，是一个NoSQL文档数据库，支持存储海量数据、安全、可扩容。 RedisPipelineTest package com._51doit.spark14 import com._51doit.utils.JedisConnectionPool import redis.clients.jedis.{Jedis, Pipeline} object RedisPipeLineTest { def main(args: Array[String]): Unit = { val jedis: Jedis = JedisConnectionPool.getConnection jedis.select(1) //

现在的arm soc嵌入式系统,如android设备,启动过程虽然各个soc均有差异,但大体一致.即有一段程序内置在soc的rom中,可根据外接管脚的选择不同的启动设备,如内部nand,sd卡,u盘等,这段代码可以认为bootloader0,大多数情况下,这段代码很精简,不会识别分区格式(树莓派除外),这段精简代码在soc内部的sram执行,从启动设备的某个固定地址读取一定大小的数据,这段数据可以认为时bootloader1,这段代码一般负责初始化基本时钟和dram控制器,然后读取bootloader2,bootload2一般具有基本的设备驱动程序,如uart/屏幕/存储设备,通过这些基本的驱动,识别分区,打印log,加载内核. 当内核加载后,内核具有编译进内核本身的基本驱动如存储设备和文件系统,串口,从而可以打印log到屏幕或串口.之后初始化各种外设后挂载rootfs.之后可以加载动态内核模块,执行init进程,最终进入系统. One of the main issues when dealing when embedded systems -specially as an amateur developer- is understanding what happens since our board/tablet/phone/etc (we will refer to is

博文大纲： 一、Kafka概述 1）消息队列 2）为什么要使用消息队列？ 3）什么是Kafka？ 4）Kafka的特性 5）Kafka架构 6）Topic和Partition的区别 7）kafka流程图 8）Kafka的文件存储机制 9）数据的可靠性和持久性保证 10）leader选举 二、部署单机Kafka 1）部署Kafka 2）测试Kafka 三、部署Kafka群集 1）环境准备 2）部署zookeeper群集 3）部署Kafka群集 一、Kafka概述 1）消息队列 1）点对点模式 （一对一，消费者主动拉取数据，消息收到后消息清除） 点对点模型通常是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信息，而不是将消息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个接收者接收处理，即使有多个消息监听者也是如此； 2）发布/订阅模式 （一对多，数据生产后，推送给所有订阅者） 发布订阅模型则是一个基于推送的消息传送模型。发布订阅模型可以有多种不同的订阅者，临时订阅者只在主动监听主题时才接收消息，而持久订阅者则监听主题的所有消息，即使当前订阅者不可用，处于离线状态。 2）为什么要使用消息队列？ 1）解耦 允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 2）冗余 消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险

一，库操作 　　 1.1 语句结构 　　 1.2 创建库 二，表操作 　　 2.1 语法结构 　　 2.2 基本建表语句 　　 2.3 删除表 　　 2.4 内部表和外部表 　　 2.5 分区表 　　 2.6 CTAS建表语法 三，数据导入和导出 　　 3.1 将文件导入hive的表 　　 3.2 将hive表中的数据导出到指定的路径文件 　　 3.3 hive的文件格式 四，修改表定义 正文 一，库操作 　　 1.1 语句结构 CREATE (DATABASE|SCHEMA) [IF NOT EXISTS] database_name 　　[COMMENT database_comment]　　　　　　//关于数据块的描述 　　[LOCATION hdfs_path]　　　　　　　　　　//指定数据库在HDFS上的存储位置 　　[WITH DBPROPERTIES (property_name=property_value, ...)];　　　　//指定数据块属性 　　默认地址：/user/hive/warehouse/db_name.db/table_name/partition_name/… 　　 1.2 创建数据库 create database db_order; 库建好后，在hdfs中会生成一个库目录： hdfs://hdp20-01:9000/user/hive

High Level Consumer 很多时候，客户程序只是希望从Kafka读取数据，不太关心消息offset的处理。同时也希望提供一些语义，例如同一条消息只被某一个Consumer消费（单播）或被所有Consumer消费（广播）。因此，Kafka High Level Consumer提供了一个从Kafka消费数据的高层抽象，从而屏蔽掉其中的细节并提供丰富的语义。 Consumer Group High Level Consumer将从某个Partition读取的最后一条消息的offset存于ZooKeeper中（ Kafka从0.8.2版本 开始同时支持将offset存于Zookeeper中与 将offset存于专用的Kafka Topic中 ）。这个offset基于客户程序提供给Kafka的名字来保存，这个名字被称为Consumer Group。Consumer Group是整个Kafka集群全局的，而非某个Topic的。每一个High Level Consumer实例都属于一个Consumer Group，若不指定则属于默认的Group。ZooKeeper中Consumer相关节点如下图所示： 很多传统的Message Queue都会在消息被消费完后将消息删除，一方面避免重复消费，另一方面可以保证Queue的长度比较短，提高效率。而如上文所述

RabbitMQ 的高可用性 RabbitMQ 是比较有代表性的，因为是 基于主从 （非分布式）做高可用性的。 RabbitMQ 有三种模式：单机模式、普通集群模式、镜像集群模式。 单机模式： Demo 级别、本地启动，生产不使用该模式 普通集群模式（无高可用性）： 在多台机器上启动多个 RabbitMQ 实例，每个机器启动一个实例。 创建的 queue，只会放在其中一个 RabbitMQ 实例上 ，但是每个实例都同步 queue 的元数据（元数据可以认为是 queue 的一些配置信息，通过元数据，可以找到 queue 所在实例）。消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从 queue 所在实例上拉取数据过来。 缺点：普通集群提高吞吐量，没有分布式，不存在高可用性 镜像集群模式（高可用性）： 创建的 queue，无论元数据还是 queue 里的消息都会 存在于多个实例上 。每个 RabbitMQ 节点都有 queue 的一个 完整镜像 ，包含 queue 的全部数据。然后每次写消息到 queue 的时候，都会自动把 消息同步 到多个实例的 queue 上。 如何开启镜像集群模式？ 在 RabbitMQ后台新增 镜像集群模式的策略， 指定的时候是可以要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次创建 queue 的时候，应用这个策略