大数据技术周报第 006 期

这里记录过去一周，大数据相关值得分享的东西，每周发布。

今天尝试写第 6 期，记录过去一周一点所见所闻。

技术一瞥

1、hdfs getconf 命令使用

hdfs getconf is utility for getting configuration information from the config file.

hadoop getconf
 [-namenodes]   gets list of namenodes in the cluster.
 [-secondaryNameNodes]   gets list of secondary namenodes in the cluster.
 [-backupNodes]   gets list of backup nodes in the cluster.
 [-includeFile]   gets the include file path that defines the datanodes that can join the cluster.
 [-excludeFile]   gets the exclude file path that defines the datanodes that need to decommissioned.
 [-nnRpcAddresses]   gets the namenode rpc addresses
 [-confKey [key]]   gets a specific key from the configuration

栗子：hdfs getconf -confKey fs.defaultFS 查看 hdfs 的 uri 地址。

2、gzip 在 hadoop 中不会分割

http://www.it1352.com/541051.html

图片

对比 Storm，我为什么选择 Flink 引擎？

在使用 Storm 开发时处理逻辑与实现需要固化在 Bolt 的代码。Flink 则可以通过 SQL 进行开发，代码可读性更高，逻辑的实现由开源框架来保证可靠高效，对特定场景的优化只要修改 Flink SQL 优化器功能实现即可，而不影响逻辑代码。使我们可以把更多的精力放到到数据开发中，而不是逻辑的实现。当需要离线数据和实时数据口径统一的场景时，我们只需对离线口径的 SQL 脚本稍加改造即可，极大地提高了开发效率。同时对比图中 Flink 和 Storm 使用的数据模型，Storm 需要通过一个 Java 的 Class 去定义数据结构，Flink Table 则可以通过元数据来定义。可以很好的和数据开发中的元数据，数据治理等系统结合，提高开发效率。

文章

1、Flink Kafka Connector 与 Exactly Once 剖析

Flink Kafka Connector 是 Flink 内置的 Kafka 连接器，它包含了从 Kafka Topic 读入数据的 Flink Kafka Consumer 以及向 Kafka Topic 写出数据的 Flink Kafka Producer，除此之外 Flink Kafa Connector 基于 Flink Checkpoint 机制提供了完善的容错能力。本文从 Flink Kafka Connector 的基本使用到 Kafka 在 Flink 中端到端的容错原理展开讨论。

2、唯一ID生成算法剖析

在业务开发中，大量场景需要唯一ID来进行标识：用户需要唯一身份标识；商品需要唯一标识；消息需要唯一标识；事件需要唯一标识…等等，都需要全局唯一ID，尤其是分布式场景下。唯一ID有哪些特性或者说要求呢？按照我的分析有以下特性：

• 唯一性：生成的ID全局唯一，在特定范围内冲突概率极小
• 有序性：生成的ID按某种规则有序，便于数据库插入及排序
• 可用性：可保证高并发下的可用性
• 自主性：分布式环境下不依赖中心认证即可自行生成ID
• 安全性：不暴露系统和业务的信息

3、真实案例 | Flink实时计算处理脏数据问题

Flink在处理实时数据时，假如其中一条数据是脏数据，例如格式错误，字段缺少等会报错，这时候该怎么处理呢？该篇文章结合实际生产实例，总结了实际经验。

4、阿里巴巴高级技术专家章剑锋：大数据发展的 8 个要点

笔者从 2008 年开始工作到现在也有 11 个年头了，一路走来都在和数据打交道，做过大数据底层框架内核的开发（Hadoop，Pig，Tez，Spark，Livy），也做过上层大数据应用开发（写 MapReduce Job 做 ETL ，用 Hive 做 Ad hocquery，用 Tableau 做数据可视化，用 R 做数据分析）。我一直不太喜欢张口闭口讲“大数据”，我更喜欢说“数据”。因为大数据的本质在于“数据”，而不是“大”。由于媒体一直重点宣扬大数据的“大”，所以有时候我们往往会忽然大数据的本质在“数据”，而不是“大”，“大”只是你看到的表相，本质还是数据自身。

5、Linux系统——架构浅析掐指一算自己从研究生开始投入到Linux的海洋也有几年的时间，即便如此依然对其各种功能模块一知半解。无数次看了Linux内核的技术文章后一头雾水，为了更系统地更有方法的学Linux，特此记录。

资源

1、分享几个我的必备软件工具

2、深入理解浏览器原理本文从市面主流的浏览器及相应的内核引擎开始，介绍了Chromium为代表的浏览器架构及Blink内核的功能架构。Chromium为多进程架构，用户从启动运行浏览器后，先后经过页面导航、渲染、资源加载、样式计算、布局、绘制、合成到栅格化，最后完成GPU展示。而页面渲染完成后，浏览器如何响应页面操作事件也进行了深入的介绍。良心推荐！

3、redis实践及思考

当面临存储选型时是选择关系型还是非关系型数据库？如果选择了非关系型的redis，redis常用数据类型占用内存大小如何估算的？redis的性能瓶颈又在哪里？