理论 streaming 101 streaming 102 spark 子雨大数据之Spark入门教程(Python版) RDD、DataFrame和DataSet的区别 Spark Streaming 不同Batch任务可以并行计算么？ Spark Streaming 管理 Kafka Offsets 的方式探讨 Spark Streaming容错性和零数据丢失 Structured Streaming Programming Guide结构化流编程指南 是时候放弃 Spark Streaming, 转向 Structured Streaming 了 选项 spark.io.compression.codec snappy (lz4依赖冲突) spark.streaming.concurrentjobs (spark streaming实时大数据分析4.4.4) spark.streaming.receiver.writeaheadlog.enable (spark streaming实时大数据分析5.6节) spark.sql.shuffle.partitions (default 200, 在单节点测试时,会造成极大的延迟). pyspark Improving PySpark performance: Spark Performance Beyond the JVM Python最佳实践指南 本地环境搭建 export JAVA_HOME=$(/usr/libexec/java_home -v 1.8) export SPARK_HOME="$HOME/opt/spark-2.3.2-bin-hadoop2.6" export PYTHONPATH=$SPARK_HOME/python:$SPARK_HOME/python/lib/py4j-0.10.7-src.zip:$PYTHONPATH export PATH=$SPARK_HOME/bin:$PATH python环境 virtualenv -p python3 spark-python3 source spark-python3/bin/activate pip install pyspark deactivate(仅从当前venv环境脱离时执行)

分布式系统 寻找一种易于理解的一致性算法（扩展版） (raft) Dapper，大规模分布式系统的跟踪系统 大数据 streaming 101 streaming 102(翻译)

Mac OS X 10.9 自带有 php-fpm，本文把预装的 php-fpm 配置起来。 直接运行，有报错找不到配置文件。 $ php-fpm [11-Jan-2014 16:03:03] ERROR: failed to open configuration file '/private/etc/php-fpm.conf': No such file or directory (2) [11-Jan-2014 16:03:03] ERROR: failed to load configuration file '/private/etc/php-fpm.conf' [11-Jan-2014 16:03:03] ERROR: FPM initialization failed 可以在 /private/etc/ 目录下生成配置文件，需要 root 权限(sudo) 或者在普通用户有权限的目录里放置配置文件，通过 --fpm-config 参数指定配置文件的位置，如下： $ cp /private/etc/php-fpm.conf.default /usr/local/etc/php-fpm.conf $ php-fpm --fpm-config /usr/local/etc/php-fpm.conf [11-Jan-2014 16:10:49] ERROR: failed to open error_log (/usr/var/log/php-fpm.log): No such file or directory (2) [11-Jan-2014 16:10:49] ERROR: failed to post process the configuration [11-Jan-2014 16:10:49] ERROR: FPM initialization failed 错误信息显示：不能正确的打开”日志“文件，原因是默认在 /usr/var 目录下工作，可以修改配置文件指定正确的日志文件路径。修改 /usr/local/etc/php-fpm.

多 web 部署时，面临的核心问题是 web 服务器间的数据共享和同步。就数据存储的方式而言，Discuz 数据包含两部分：一部分存储在 MySQL 数据库中（用户、帖子等文本类、结构化的数据），一部分存储在文件系统（附件、缓存文件等）。其中存储在 MySQL 中的数据可以方便地在多服务器间共享，扩展和冗余也已经有比较成熟的方案。这里我们主要讨论 Discuz 文件类型的数据，部分涉及到多台服务器的内容。 数据梳理 Discuz 文件类型的数据都存储于 DISCUZ_ROOT/data 目录，各目录主要功能如下： 目录 数据说明 data/attachment 附件类 data/log 运行日志 data/cache 配置参数类缓存文件（默认是sql，配置参数通过pre_common_syscache表缓存）、CSS缓存、部分JS缓存 data/template 模板缓存 data/threadcache 论坛页面缓存（针对游客的优化） DISCUZ_ROOT/data目录下有几个重要的文件（文件锁） data/install.lock，安装程序锁定。如果该文件存在，DISCUZ_ROOT/install/ 中的安装程序不能执行。 data/sendmail.lock， 发送邮件锁。Discuz 默认通过类似 home.php?mod=misc&ac=sendmail&rand=1379315574 这个隐藏页面调用，由用户的浏览行为触发邮件发送流程（浏览器侧用一个300秒的 cookie 控制频率，服务器侧通过 sendmail.lock 文件的 mtime 控制频率5秒）。如果可以控制服务器，应该优化掉这个机制。 data/updatetime.lock， 某管理后台使用的锁。 data/update.lock， 系统升级锁。执行版本升级程序（如x2升级到x3）时，会生成这个文件锁。 下面这些功能会涉及到多 web 服务器间的数据共享和同步，默认 Discuz 通过 MySQL 实现。 用户session， 表 pre_common_session 管理面板session， 表 pre_common_admincp_session 系统配置项缓存， 表 pre_common_syscache NFS 我们假设部署两台 web 服务器的场景（且 web 服务器也是 php 应用服务器）。我们需要解决 data 目录共享的问题，引入 NFS 服务可以简单解决这个问题。服务器复用，此处不表。这里会有一个选择，哪些目录放置在 NFS 上，从上面的分析来看，将 data 目录放置在NFS上即可，即各 web 服务器均独立部署程序文件，将NFS挂载到 data 目录节点，缺点是需要将程序文件部署到每一台 web 服务器上，要解决程序文件更新部署的问题，优点是可以节省 web 服务器通过网络取 NFS 上的程序文件的开销。如果图方便，也可以把程序文件也放到 NFS 上，则所有文件都只有一个副本了，程序更新也很方便，缺点是会增加 web 服务器通过网络取程序文件的开销。这两者需要权衡，建议第一种。

顶置贴的存储 表 pre_forum_thread 字段 displayorder 4 多版块顶置。Disczu!7.2引入的一个特性，操作入口在“论坛”－“版块/群组顶置” 3 3级置顶、全局顶置 2 2级置顶、分区顶置 1 1级置顶、版块顶置 0 正常 -1 回收站 -2 审核中 -3 审核忽略 -4 草稿 顶置2、3类的tid会被保存在pre_common_syscache的cname=“globalstick"记录中 顶置2 $_G['cache']['globalstick']['categories'][分区ID] 顶置3 $_G[‘cache’][‘globalstick’][‘global’][’tids’] 多版块顶置数据（4）被保存在pre_common_syscache的cname=“forumstick"记录中 $_G[‘cache’][‘forumstick’][版块ID] 帖子列表页对顶置贴的显示逻辑。 Discuz!通过下面的SQL查询检索上面3种置顶帖子数据。 第一页 SELECT * FROM pre_forum_thread WHERE `tid` IN('3','13','12','5') AND `displayorder` IN('2','3','4') ORDER BY displayorder DESC, lastpost DESC LIMIT 20 Using where; Using filesort 第二页 SELECT * FROM pre_forum_thread WHERE `tid` IN('3','13','12','5') AND `displayorder` IN('2','3','4') ORDER BY displayorder DESC, lastpost DESC LIMIT 20, 20 Using where; Using filesort 可以看到，即使第二页没有需要显示的顶置贴，但仍然会执行查询，这里可以做个小小的优化，计算一下IN（）表达式中的tid的数量。 然后是排序部分，如果条件允许的话，建议通过PHP脚本来排序。是否使用这一项优化，主要受版块中顶置贴的数量影响。如果顶置贴数量较多，必须要通过分页来显示，就需要在数据库中排序后，才能确定在指定页面要显示的顶置贴是哪些。不过按通常的情况来看，版块中顶置贴的数量都还是比较少，很少会出现顶置贴翻页的情况。

《shell脚本学习指南》6.1.3节描述了 shell 的算术展开，其支持的运算与C语言差不多，语法 $((...)) $ echo $(( 3 * 4 )) 12 在某些场景特别方便，可以免去写程序的烦琐，如验证某些运算。 下面是验证《深入理解计算系统》练习题2.12的场景 表达式 ~0 将生成一个全1的掩码，不管机器的字大小是多少，可移植。 $ printf "%x\n" $(( ~0 )) ffffffffffffffff $ printf "%#x\n" $(( ~0 )) 0xffffffffffffffff 上面的测试显示，shell中，0按位取反后的值是64位的。 shell 的 printf 命令前导字符打印：《shell脚本学习指南》表7－4：printf 的标志中描述了格式参数中"#“号的意义，”#“可以用以输出前导"0x”(16进制)、“0”(8进制) x & 0xFF 生成一个由x的最低有效字节组成的值 $ printf "%#x\n" $(( 0x89ABCDEF & 0xFF )) 0xef $ printf "%#.8x\n" $(( 0x89ABCDEF & 0xFF )) 0x000000ef 以下x = 0x87654321 A.x的最低有效字节，其他位均置为0 $ printf "%#.8x\n" $(( 0x87654321 & 0xFF )) 0x00000021 $ printf "%#.

cacti用于监控系统的各项运行指标，提供了交互界面和图表，是一个整合工具集，它完成两个核心任务： 1)指标数据的采集，2) 将数据通过数图进行展示。其中图表的绘制、图表数据的存储是通过rrdtool工具实现的，《RRDtool简体中文教程》对rrdtool工具进行了介绍，是很好的资料。本文分析指标数据采集的实现。 如何获取目标数据 我们需要按照目标数据的暴露方式去采集相应的数据. 基于主机(host)的数据，如：系统负载，网卡流量，磁盘IO，TCP连接等已通过SNMP标准化，需要使用SNMP方式获取。应用级的数据要按照应用暴露数据的方式去获取,如: 如果要监控nginx（stub_status）数据,该项数据是通过http方式暴露，需使用http获取数据;如果要监控mysql-server（show status）数据，需要可以连接到mysql服务器，并有权限打印数据。 cacti由cron驱动 cacti不是一个daemon进程，它由cron驱动。通常我们需要配置如下的cron: 下面的典型配置为每5分钟运行一次cacti的轮换数据进程。 */5 * * * * /PATH/TO/php /PATH/TO/cacti/poller.php > /dev/null 2>&1 cron任务的运行频率，影响cacti采集数据周期，但cron的运行频率，并不是cacti最终的采集频率。举例来说，如果cron的运行频率为每5分钟触发一次，但我们希望每分钟采集一次数据，cacti是可以做到的，这要求我们将cron的运行频率正确的配置到cacti，这样cacti会在一次cron进程生命周期内，尽可能的按照预期的频率，进行多次数据采集。 实现 涉及 $cron_interval，$poller_interval 两项参数，比如cron的周期是5分钟，poller周期是1分钟，则cron触发的poller.php进程，要负责安排5次数据轮询，以满足poller粒度。 $poller_runs = intval($cron_interval / $poller_interval); define("MAX_POLLER_RUNTIME", $poller_runs * $poller_interval - 2); // poller.php进程的最大运行时间（比计划任务周期少2秒） poller进程(poller.php) poller进程由cron启动，在其生命周期内，负责编排所有的数据采集任务. 任务初始化 poller进程启动后，在进行一系列cacti的初始化后，从系统中检索出数据采集任务集，然后将它们持久化到数据库(poller_output表)中,每一项数据指标一条记录。 并发控制 cacti提供了两种并发模型来提升数据采集的效率，cmd.php和spine。其中cmd.php是多进程模型，用php语言实现; spine是多线程模型，具体实现不详。这里我们只讨论cmd.php方式的并发。下面的引文来自cacti的配置界面说明，大意是说，当使用cmd.php抓取数据时，可以通过增加进程数来提高性能（多进程模型）；当使用spine时，应该通过增加“Maximum Threads per Process”的值，提升性能（多线程模型）。 “The number of concurrent processes to execute. Using a higher number when using cmd.php will improve performance. Performance improvements in spine are best resolved with the threads parameter”