records

前言 与生产者对应的是消费者，应用程序可以通过KafkaConsumer来订阅主题，并从订阅的主题中拉取消息。不过在使用KafkaConsumer消费消息之前需要先了解消费者和消费组的概念，否则无法理解如何使用KafkaConsumer。 <!--more--> Consumer 消费者（Consumer）负责订阅Kafka中的主题（Topic），并且从订阅的主题上拉取消息。与其他一些消息中间件不同的是：在Kafka的消费理念中还有一层消费组（Consumer Group）的概念，每个消费者都有一个对应的消费组。 当消息发布到主题后，只会被投递给订阅它的每个消费组中的一个消费者。如图所示，某个主题中共有4个分区（Partition）：P0、P1、P2、P3。有两个消费组A和B都订阅了这个主题，消费组A中有4个消费者（C0、C1、C2和C3），消费组B中有2个消费者（C4和C5）。按照Kafka默认的规则，最后的分配结果是消费组A中的每一个消费者分配到1个分区，消费组B中的每一个消费者分配到2个分区，两个消费组之间互不影响。每个消费者只能消费所分配到的分区中的消息。换言之，每一个分区只能被一个消费组中的一个消费者所消费。 分区分配的演变（Rebalance） 我们再来看一下消费组内的消费者个数变化时所对应的分区分配的演变。假设目前某消费组内只有一个消费者C0，订阅了一个主题

MySQL 分区表原理及数据备份转移实战 1、分区表含义 分区表定义指根据可以设置为任意大小的规则，跨文件系统分配单个表的多个部分。实际上，表的不同部分在不同的位置被存储为单独的表。用户所选择的、实现数据分割的规则被称为分区函数，这在MySQL中它可以是模数，或者是简单的匹配一个连续的数值区间或数值列表，或者是一个内部HASH函数，或一个线性HASH函数。 分表与分区的区别在于：分区从逻辑上来讲只有一张表，而分表则是将一张表分解成多张表。 2、分区表优点 1)分区表更容易维护。对于那些已经失去保存意义的数据，通常可以通过删除与那些数据有关的分区，很容易地删除那些数据。相反地，在某些情况下，添加新数据的过程又可以通过为那些新数据专门增加一个新的分区，来很方便地实现。 2)一些查询可以得到极大的优化，这主要是借助于满足一个给定WHERE语句的数据可以只保存在一个或多个分区内，这样在查找时就不用查找其他剩余的分区。因为分区可以在创建了分区表后进行修改，所以在第一次配置分区方案时还不曾这么做时，可以重新组织数据，来提高那些常用查询的效率。 3)优化查询。涉及到例如SUM()和COUNT(),可以在多个分区上并行处理，最终结果只需通过总计所有分区得到的结果。 4)通过跨多个磁盘来分散数据查询，来获得更大的查询吞吐量。 3、分区表限制 1)一个表最多只能有1024个分区； 2) MySQL5

移植自JavaScript版本的 「商品期货跨期对冲 - 百行代码实现」 ，本策略为简单的教学策略，意图展示Python语言的商品期货策略设计。主要用于学习策略编写、参考设计思路。 class Hedge : '对冲控制类' def __init__ ( self , q , e , initAccount , symbolA , symbolB , hedgeSpread , coverSpread ): self . q = q self . initAccount = initAccount self . status = 0 self . symbolA = symbolA self . symbolB = symbolB self . e = e self . isBusy = False self . hedgeSpread = hedgeSpread self . coverSpread = coverSpread self . opAmount = OpAmount def poll ( self ): if ( self . isBusy or not exchange . IO ( "status" )) or not ext . IsTrading ( self . symbolA ): Sleep ( 1000 ) return insDetailA =

问题： I have a basic dict as follows: 我有一个基本的命令，如下所示： sample = {} sample['title'] = "String" sample['somedate'] = somedatetimehere When I try to do jsonify(sample) I get: 当我尝试执行 jsonify(sample) 我得到： TypeError: datetime.datetime(2012, 8, 8, 21, 46, 24, 862000) is not JSON serializable What can I do such that my dictionary sample can overcome the error above? 我该怎么做才能使我的词典示例可以克服上述错误？ Note: Though it may not be relevant, the dictionaries are generated from the retrieval of records out of mongodb where when I print out str(sample['somedate']) , the output is 2012-08-08 21:46:24.862000 . 注意：尽管可能不相关

前言 涵盖各大公司会问到的面试点，同时随着版本的升级，可能也会有一些面试题更新，也会同步保持更新，因为篇幅原因（其实是我懒，哈哈）所以列了一部分答案，所有的答案见下文，总共485页合计20个技术点，文末自取pdf. 1、如何获取 topic 主题的列表 bin/kafka-topics.sh --list --zookeeper localhost: 2181 2、生产者和消费者的命令行是什么？ 生产者在主题上发布消息： bin/kafka-console-producer.sh --broker-list 192.168 . 43.49 : 9092 -- topic Hello -Kafka 注意这里的 IP 是 server.properties 中的 listeners 的配置。接下来每个新行就是输入一条新消息。 消费者接受消息： bin/kafka-console-consumer.sh --zookeeper localhost: 2181 -- topic Hello -Kafka -- from -beginning 3、consumer 是推还是拉？ Kafka 最初考虑的问题是，customer 应该从 brokes 拉取消息还是 brokers 将消息推送到 consumer，也就是 pull 还 push。在这方面，Kafka

（图1） （图2） 使用说明 （1）自行导出目标QQ群聊天记录 （2）将聊天记录.txt保存在软件根目录文件夹：QQgroup_records（可选） （3）打开软件，选择需要分析的聊天记录.txt （4）聊天记录分析结果默认保存在软件根目录文件夹：QQgroup_results （5）技术支持：Python Bokeh 数据可视化库 链 接: https:// pan.baidu.com/s/14Dbg2S GWkJpzPbLwe5S5DA 提取码: 69bb 【注】适于win7以上64位台式电脑或笔记本；XP、Linux等就不用下载了~ 使用场景 1.适合QQ群主数据化管理群：直观查看QQ群活跃程度；激励活跃的用户；升级QQ群副管理员等。如（图1），某注册岩土专业考试QQ群聊天记录了分析结果：考试结束后+成绩出来后，QQ群变得很欢快；过年期间，QQ群变得很安静。 2.横向对比同业不同QQ群的活跃程度，用数据进行宣传。如（图2），可以每个月活跃前N名，可以成为群管理员，管理员可以上传一些别人没权限上传的资料或者其他权限；可以给前N名，送书、送视频、送... 3.自行复制表格数据，进一步分析。如（图2），QQ邮箱应该还是有用的，10%~15%的打开率，想知道怎么用不？ 【强烈推荐】文字、表格、公式图片识别神器V0.3 yeayee：Python数据分析及可视化实例目录 ​

MySQL事务控制语句（学习笔记） MySQL事务控制语句 在mysql命令行的默认下，事务都是自动提交的，sql语句提交后马上会执行commit操作。因此开启一个事务必须使用begin，start transaction，或者执行 set autocommit=0; 可以使用的事务控制语句 start transction | begin : 显示的开启一个事务 commit （commit work） commit work与completion_type的关系，commit work是用来控制事务结束后的行为，是chain还是release的，可以通过参数completion_type来控制，默认为0（或者NO_CHAIN），表示没有任何操作 与commit效果一样。当completion_type=1的时候 [sql] view plain copy mysql> set names utf8; Query OK, 0 rows affected (0.00 sec) mysql> create table t(a int, primary key (a))engine=innodb; Query OK, 0 rows affected (0.29 sec) mysql> select @@autocommit; + --------------+ | @

平时我们在设计数据库表的时候总会设计 unique 或者 给表加上 primary key 的限制条件. 此时 插入数据的时候 ，经常会有这样的情况： 我们想向数据库插入一条记录： 若数据表中存在以相同主键的记录，我们就更新该条记录。 否则就插入一条新的记录。 逻辑上我们需要怎么写： $result = mysql_query('select * from xxx where id = 1'); $row = mysql_fetch_assoc($result); if($row){ mysql_query('update ...'); }else{ mysql_query('insert ...'); } 但是这样写有两个问题 1、效率太差，每次执行都要执行2个sql 2、高并发的情况下数据会出问题，不能保证原子性 还好MySQL 为我们解决了这个问题：我们可以通过 ON DUPLICATE KEY UPDATE 达到以上目的, 且能保证操作的原子性和数据的完整性。 ON DUPLICATE KEY UPDATE 可以达到以下目的: 向数据库中插入一条记录： 若该数据的主键值/ UNIQUE KEY 已经在表中存在,则执行更新操作, 即UPDATE 后面的操作。 否则插入一条新的记录。 示例： Step1 . 创建表，插入测试数据 SET FOREIGN_KEY_CHECKS=0

网上查阅一些资料，收集整理如下： 1、 通用性 spark更加通用，spark提供了transformation和action这两大类的多个功能api，另外还有流式处理sparkstreaming模块、图计算GraphX等等；mapreduce只提供了map和reduce两种操作，流计算以及其他模块的支持比较缺乏。 2、 内存利用和磁盘开销 MapReduce的设计：中间结果需要写磁盘，Reduce写HDFS，多个MR之间通过HDFS交换数据，，可以提高可靠性，减少内存占用，但是牺牲了性能。 Spark默认把结果写到内存， Spark的DAGScheduler相当于一个改进版的MapReduce，如果计算不涉及与其他节点进行数据交换，Spark可以在内存中一次性完成这些操作，也就是中间结果无须落盘，减少了磁盘IO的操作。（但是，如果计算过程中涉及数据交换，Spark也是会把shuffle的数据写磁盘的！！！），还有一方面就是对shuffle操作的优化，spark提供Cache机制来支持需要反复迭代计算或者多次数据共享，减少中间文件的生成，减少数据读取的IO开销。另外DAG相比MapReduce在大多数情况下可以减少shuffle次数。 3、 任务调度 mapreduce任务调度和启动开销大; spark线程池模型减少task启动开销 4、 排序 Spark 避免不必要的排序操作

简介 Aerospike 是一个分布式、可扩展的数据库，其架构有三个关键目标: 为 web 规模的应用程序创建一个灵活的、可扩展的平台 提供传统数据库所期望的健壮性和可靠性(如 ACID) 以最少的人工参与提供操作效率 T级别大数据高并发的结构化数据存储解决方案，读写操作达微妙级，99%的响应可在1毫秒内实现，99.9%的响应可在5毫秒内实现。 采用混合架构，索引存储在 RAM 中，而数据存储在闪存/固态硬盘(SSD) 上，自动感知集群，可以随意增加节点线性扩容，无需分片，无需人工干预（性能与节点成正比上升），支持多语言集成；与redis相比不太会遇到性能瓶颈 大部分的源代码是用 c 语言编写的，符合 ANSI C99标准。 为什么要用AS K-V类型的数据库必须要提的就是redis，redis数据完全存储在内存虽然保证了查询性能，但是成本太高。AS最大的卖点就是可以存储在SSD上，并且保证和redis相同的查询性能。 AS内部在访问SSD屏蔽了文件系统层级，直接访问地址，保证了数据的读取速度。 AS同时支持二级索引与聚合，支持简单的sql操作，相比于其他nosql数据库，有一定优势。 Namespaces(库) AS数据存储的最高层级，类比于传统的数据库的库层级，一个namespace包含记录（records），索引（indexes ）及策略（policies）。