optional

一.比较两个函数 先来看看random.randint() import random for n in range(5 ): for i in range(10 ): print (random.randint(1,5),end= ' ' ) print () # 运行结果 1 5 5 3 3 1 3 1 5 2 4 4 4 4 4 4 3 1 5 2 3 2 3 1 1 5 5 1 4 3 3 4 4 2 5 5 3 4 4 4 3 5 4 5 4 5 4 5 2 4 Process finished with exit code 0 再来看看numpy.random.randint()方法： import numpy as np for n in range(5 ): for i in range(10 ): print (np.random.randint(1, 5), end= ' ' ) print () # 运行结果 2 4 1 1 1 1 2 2 2 4 3 4 3 2 3 4 3 2 2 4 2 2 1 2 1 1 3 3 3 4 4 1 4 2 4 1 3 4 3 2 2 3 3 2 3 4 4 3 4 4 Process finished with exit code 0 看出有什么不同了吗? random.randint()方法里面的取值区间是前闭后闭区间

1. 前言 内存（memory）在Linux系统中是一种牵涉面极广的资源，上至应用程序、下至kernel和driver，无不为之魂牵梦绕。加上它天然的稀缺性，导致内存管理（Memory Management，简称MM）是linux kernel中非常重要又非常复杂的一个子系统。 重要性就不多说了，Kernel自有分寸。关于复杂性（鉴于Linux kernel优秀的抽象能力），应该不会被普通人（Linux系统的使用者、应用工程师、驱动工程师、轻量级的内核工程师）感知到才对。事实确实如此，Kernel屏蔽掉了大多数的实现细节，尽量以简单、易用的方式向其它模块提供memory服务。 不过呢，这个世界上没有完美的存在，kernel的内存管理也是如此，由于两方面的原因：一、众口难调，内存管理有关的需求实在太复杂了；二、CPU、Device和Memory之间纠结的三角恋（参考下面图片），导致它也（不得不）提供了很多啰里啰唆的、不易理解的功能（困扰了很多从入门级到资深级的linux软件工程师）。 图片1 CPU, Device and Memory 基于上面的原因，本站 内存管理子系统 发布了很多分析文章，以帮助大家理解内存管理有关的概念。不过到目前为止，还缺少一篇索引类的文章，从整体出发，理解Kernel内存管理所需要面对的软硬件局面、所要解决的问题，以及各个内存管理子模块的功能和意义

概述 Kafka 的数据如何传输到HDFS？如果仔细思考，会发现这个问题并不简单。 不妨先想一下这两个问题? 1）为什么要将Kafka的数据传输到HDFS上？ 2）为什么不直接写HDFS而要通过Kafka? HDFS一直以来是为离线数据的存储和计算设计的，因此对实时事件数据的写入并不友好，而Kafka生来就是为实时数据设计的，但是数据在Kafka上无法使用离线计算框架来作批量离线分析。 那么，Kafka为什么就不能支持批量离线分析呢?想象我们将Kafka的数据按天拆分topic，并建足够多的分区，然后通过Spark-Streaming，Flink，又或者是KSql等来处理单个topic中的所有数据--这就相当于处理某一天的所有数据。这种计算的性能从原理上来说是不比Spark或者Hive离线计算差的。 而且更好的是，这样我们就不用将kafka中的数据翻来覆去的导到hdfs，而是直接在kafka上作计算。 后面我们将对此展开更多的讨论，这里先回归正题，在常见的大数据系统架构(lambda)中，通常会将kafka中的数据导入到HDFS来作离线的数据分析。在Kafka的官方wiki中提到了这样的一些方式来对接Hadoop生态。 https://cwiki.apache.org/confluence/display/KAFKA/Ecosystem 其中最常用的是Flume