Hadoop

本文根据黄东旭在 PingCAP D 轮融资线上发布会的演讲实录进行整理。 TiDB 的现在和未来 大家好，我是黄东旭，是 PingCAP 的联合创始人和 CTO，这是 PingCAP 成立以来的第一次发布会，我想跟大家简单聊聊 TiDB 在产品和技术上的更新。考虑到线上的很多观众不一定是有很强的技术背景，我将尽我所能将技术的部分说得让大家都能够理解。 在讲正题之前有一个小故事，我们做基础软件的产品经理去跟客户聊需求的时候，客户经常都会说：对于数据库，我的要求特别简单、特别基础、非常朴素，我不要求很多功能，安全稳定是必须的，最好能高可用，性能一定要好，如果数据量大了，能实现弹性伸缩就更好了；另外，最好别让我学太多新东西，用起来跟过去使用的产品差不多，这就是一款完美的数据库产品。 就像大家在家里用自来水一样，我们对自来水的需求就是拧开水龙头水就能出来，但是背后自来水厂是怎么处理的大家不用知道，我们只需要根据实际情况使用冷水或者热水就好。但是从技术的角度来说，刚才类似冷热水这个非常朴素的基础需求，类比一下放到数据库的世界这就是一个图灵奖级别的基础需求，稍微解释一下图灵奖是计算机行业学术界最顶级的，相当于计算机界的诺贝尔奖。 这里有两位行业泰斗级的人物，左边 Leslie Lamport 在 2013 年研究相关问题拿了图灵奖，右边这位跟我们挺有缘的，发型跟（我们的 CEO）刘奇同学挺像

导读：Flink 从 1.9.0 开始提供与 Hive 集成的功能，随着几个版本的迭代，在最新的 Flink 1.11 中，与 Hive 集成的功能进一步深化，并且开始尝试将流计算场景与Hive 进行整合。 本文主要分享在 Flink 1.11 中对接 Hive 的新特性，以及如何利用 Flink 对 Hive 数仓进行实时化改造，从而实现批流一体的目标。主要内容包括： · Flink 与 Hive 集成的背景介绍 · Flink 1.11中的新特性 · 打造 Hive 批流一体数仓 一、 Flink 与 Hive 集成背景 为什么要做 Flink 和 Hive 集成的功能呢？最早的初衷是我们希望挖掘 Flink 在批处理方面的能力。众所周知，Flink 在流计算方面已经是成功的引擎了，使用的用户也非常多。在 Flink 的设计理念当中，批计算是流处理中的一个特例。也就意味着，如果 Flink 在流计算方面做好，其实它的架构也能很好的支持批计算的场景。在批计算的场景中，SQL 是一个很重要的切入点。因为做数据分析的同学，他们更习惯使用SQL 进行开发，而不是去写 DataStream 或者 DataSet 这样的程序。 Hadoop 生态圈的 SQL 引擎，Hive 是一个事实上的标准。大部分的用户环境中都会使用到了 Hive 的一些功能，来搭建数仓。一些比较新的 SQL 的引擎

Caused by: java.lang.RuntimeException: Error while running command to get file permissions : java.io.IOException: (null) entry in command string: null ls -F D:\tmp\hive Caused by: java.lang.RuntimeException: Error while running command to get file permissions : java.io.IOException: (null) entry in command string: null ls -F D:\tmp\hive at org.apache.hadoop.util.Shell$ShellCommandExecutor.execute(Shell.java:762) at org.apache.hadoop.util.Shell.execCommand(Shell.java:859) at org.apache.hadoop.util.Shell.execCommand(Shell.java:842) at org.apache.hadoop.fs.FileUtil.execCommand(FileUtil.java:1097)

在很多的流处理框架的介绍中，都会说kafka是一个可靠的数据源，并且推荐使用Kafka当作数据源来进行使用。这是因为与其他消息引擎系统相比，kafka提供了可靠的数据保存及备份机制。并且通过消费者位移这一概念，可以让消费者在因某些原因宕机而重启后，可以轻易得回到宕机前的位置。 但其实kafka的可靠性也只能说是相对的，在整条数据链条中，总有可以让数据出现丢失的情况，今天就来讨论如何避免kafka数据丢失，以及实现精确一致处理的语义。 kafka无消息丢失处理 在讨论如何实现kafka无消息丢失的时候，首先要先清楚大部分情况下消息丢失是在什么情况下发生的。为什么是大部分，因为总有一些非常特殊的情况会被人忽略，而我们只需要关注普遍的情况就足够了。接下来我们来讨论如何较为普遍的数据丢失情况。 1.1 生产者丢失 前面介绍Kafka分区和副本的时候，有提到过一个producer客户端有一个acks的配置，这个配置为0的时候，producer是发送之后不管的，这个时候就很有可能因为网络等原因造成数据丢失，所以应该尽量避免。但是将ack设置为1就没问题了吗，那也不一定，因为有可能在leader副本接收到数据，但还没同步给其他副本的时候就挂掉了，这时候数据也是丢失了。并且这种时候是客户端以为消息发送成功，但kafka丢失了数据。 要达到最严格的无消息丢失配置，应该是要将acks的参数设置为-1

）当 sink 到 hdfs 时： ) 需修改 flume-env.sh 配置，增添 hdfs 依赖库： 　　FLUME_CLASSPATH="/root/TDH-Client/hadoop/hadoop/*:/root/TDHClient/hadoop/hadoop-hdfs/*:/root/TDH-Client/hadoop/hadoop/lib/*" 实例： a1.sources=r1 a1.sinks=k2 a1.channels=c2 a1.sources.r1.type=avro a1.sources.r1.channels=c1 c2 a1.sources.r1.bind=172.20.237.105 a1.sources.r1.port=8888 #r1的数据通过c2发送给k2输出到HDFS中存储 a1.sinks.k2.channel = c2 a1.sinks.k2.type=hdfs a1.sinks.k2.hdfs.kerberosKeytab=/etc/hdfs1/conf/hdfs.keytab a1.sinks.k2.hdfs.kerberosPrincipal=hdfs/gz237-105@TDH #存储到hdfs上的位置 a1.sinks.k2.hdfs.path= hdfs://nameservice1/yang/flume/portal

本来打算直接用原生yum源安装，但是跨国访问网络太慢，只好采用离线安装的方式，原理就是把所需的rpm下载下来再上传服务器安装。 1、rpm文件下载地址： 目录： http://repo.mysql.com/yum/mysql-5.7-community/el/7/x86_64/ 具体文件： http://repo.mysql.com/yum/mysql-5.7-community/el/7/x86_64/mysql-community-common-5.7.28-1.el7.x86_64.rpm http://repo.mysql.com/yum/mysql-5.7-community/el/7/x86_64/mysql-community-devel-5.7.28-1.el7.x86_64.rpm http://repo.mysql.com/yum/mysql-5.7-community/el/7/x86_64/mysql-community-libs-compat-5.7.28-1.el7.x86_64.rpm http://repo.mysql.com/yum/mysql-5.7-community/el/7/x86_64/mysql-community-libs-5.7.28-1.el7.x86_64.rpm http://repo.mysql.com/yum/mysql

1 背景 对于数据开发人员来说，手写sql是比较熟悉的了，就有这样一道题，面试时需要手写sql，这就是非常经典的连续登录问题，大厂小厂都爱问，这种题说简单也不简单，说难也不难，关键是要有思路。 2 真题 hql统计连续登陆的三天及以上的用户 这个问题可以扩展到很多相似的问题：连续几个月充值会员、连续天数有商品卖出、连续打车、连续逾期。 数据提供 用户ID、登入日期 user01,2018-02-28 user01,2018-03-01 user01,2018-03-02 user01,2018-03-04 user01,2018-03-05 user01,2018-03-06 user01,2018-03-07 user02,2018-03-01 user02,2018-03-02 user02,2018-03-03 user02,2018-03-06 输出字段 +---------+--------+-------------+-------------+--+ | uid | times | start_date | end_date | +---------+--------+-------------+-------------+--+ 3 群内讨论 这道题在群里发出后，大家就展开了激烈的讨论： 4 解决方案 可以看出来，有很多种不同的解决方案。