Apache 澳门美高梅手机网站Drill学习笔记一:环境搭建和不难试用

参考

付费消除 Windows、Linux、Shell、C、C++、AHK、Python、JavaScript、Lua
等领域相关题材,灵活定价,欢迎咨询,微信 ly50247。

尽心尽力使用开源成熟产品,jboss、redis、nginx、apache、mysql、rabbit
MQ都是很好的选拔。硬件负载均衡平日花费不低,可是意义显然,假诺实际没钱,域名解析接纳DNS轮询策略,也能达标近似效率,只可是可信性略差。

简介

Apache
Drill是3个低顺延的分布式海量数据(涵盖结构化、半结构化以及嵌套数据)交互式查询引擎,使用ANSI
SQL包容语法,帮助当地文件、HDFS、HBase、MongoDB等后端存储,资助Parquet、JSON、CSV、TSV、PSV等数码格式。受谷歌(Google)的Dremel启发,Drill满意上千节点的PB级别数据的交互式商业智能分析气象。

澳门美高梅手机网站 1

启动

在单机环境运维只必要运营bin/sqlline便可:

$ cd $WORK
$ . ./init.sh
$ ./drill/apache-drill/bin/sqlline -u jdbc:drill:zk=local
Drill log directory /var/log/drill does not exist or is not writable, defaulting to ...
Apr 06, 2015 12:47:30 AM org.glassfish.jersey.server.ApplicationHandler initialize
INFO: Initiating Jersey application, version Jersey: 2.8 2014-04-29 01:25:26...
sqlline version 1.1.6
0: jdbc:drill:zk=local> 

-u jdbc:drill:zk=local意味着使用本机的Drill,无需运行ZooKeeper,假如是集群环境则要求配备和起步ZooKeeper并填写地址。运维后便足以在0: jdbc:drill:zk=local>后敲入命令使用了。

一 、系统安全

试用

Drill的sample-data目录有Parquet格式的以身作则数据可供查询:

0: jdbc:drill:zk=local> select * from dfs.`/path/to/work/drill/apache-drill/sample-data/nation.parquet` limit 5;
+-------------+------------+-------------+------------+
| N_NATIONKEY |   N_NAME   | N_REGIONKEY | N_COMMENT  |
+-------------+------------+-------------+------------+
| 0           | ALGERIA    | 0           |  haggle. carefully f |
| 1           | ARGENTINA  | 1           | al foxes promise sly |
| 2           | BRAZIL     | 1           | y alongside of the p |
| 3           | CANADA     | 1           | eas hang ironic, sil |
| 4           | EGYPT      | 4           | y above the carefull |
+-------------+------------+-------------+------------+
5 rows selected (0.741 seconds)

此间用的库名格式为dfs.`本地文件(Parquet、JSON、CSV等文件)相对路径`。可以看来只要熟稔SQL语法大致一向不上学花费。但Parquet格式文件须要专用工具查看、编辑,不是很便利,后续再尤其介绍,下文先利用更通用的CSV和JSON文件举办出现说法。

$WORK/data中创制如下test.csv文件:

1101,SteveEurich,Steve,Eurich,16,StoreT
1102,MaryPierson,Mary,Pierson,16,StoreT
1103,LeoJones,Leo,Jones,16,StoreTem
1104,NancyBeatty,Nancy,Beatty,16,StoreT
1105,ClaraMcNight,Clara,McNight,16,Store

下一场查询:

0: jdbc:drill:zk=local> select * from dfs.`/path/to/work/drill/data/test.csv`;
+------------+
|  columns   |
+------------+
| ["1101","SteveEurich","Steve","Eurich","16","StoreT"] |
| ["1102","MaryPierson","Mary","Pierson","16","StoreT"] |
| ["1103","LeoJones","Leo","Jones","16","StoreTem"] |
| ["1104","NancyBeatty","Nancy","Beatty","16","StoreT"] |
| ["1105","ClaraMcNight","Clara","McNight","16","Store"] |
+------------+
5 rows selected (0.082 seconds)

可以见到结果和事先的稍有差异,因为CSV文件并未地方存放列列名,所以集合用columns取代,借使必要切实制定列则需求用columns[n],如:

0: jdbc:drill:zk=local> select columns[0], columns[3] from dfs.`/path/to/work/drill/data/test.csv`;
+------------+------------+
|   EXPR$0   |   EXPR$1   |
+------------+------------+
| 1101       | Eurich     |
| 1102       | Pierson    |
| 1103       | Jones      |
| 1104       | Beatty     |
| 1105       | McNight    |
+------------+------------+

CSV文件格式比较简单,发挥不出Drill的有力优势,上边更扑朔迷离的职能使用和Parquet更近乎的JSON文件进行出现说法。

$WORK/data中开创如下test.json文件:

{
  "ka1": 1,
  "kb1": 1.1,
  "kc1": "vc11",
  "kd1": [
    {
      "ka2": 10,
      "kb2": 10.1,
      "kc2": "vc1010"
    }
  ]
}
{
  "ka1": 2,
  "kb1": 2.2,
  "kc1": "vc22",
  "kd1": [
    {
      "ka2": 20,
      "kb2": 20.2,
      "kc2": "vc2020"
    }
  ]
}
{
  "ka1": 3,
  "kb1": 3.3,
  "kc1": "vc33",
  "kd1": [
    {
      "ka2": 30,
      "kb2": 30.3,
      "kc2": "vc3030"
    }
  ]
}

可以看看这几个JSON文件内容是有多层嵌套的,结构比在此之前尤其CSV文件要复杂不少,而查询嵌套数据正是Drill的优势所在。

0: jdbc:drill:zk=local> select * from dfs.`/path/to/work/drill/data/test.json`;
+------------+------------+------------+------------+
|    ka1     |    kb1     |    kc1     |    kd1     |
+------------+------------+------------+------------+
| 1          | 1.1        | vc11       | [{"ka2":10,"kb2":10.1,"kc2":"vc1010"}] |
| 2          | 2.2        | vc22       | [{"ka2":20,"kb2":20.2,"kc2":"vc2020"}] |
| 3          | 3.3        | vc33       | [{"ka2":30,"kb2":30.3,"kc2":"vc3030"}] |
+------------+------------+------------+------------+
3 rows selected (0.098 seconds)

select *只查获第①层的多寡,更深层的数据只以本来的JSON数据显现出来,大家鲜明不应有只关心第②层的数目,具体怎么查完全自由:

0: jdbc:drill:zk=local> select sum(ka1), avg(kd1[0].kb2) from dfs.`/path/to/work/drill/data/test.json`;
+------------+------------+
|   EXPR$0   |   EXPR$1   |
+------------+------------+
| 6          | 20.2       |
+------------+------------+
1 row selected (0.136 seconds)

可以经过kd1[0]来做客嵌套到第2层的那几个表。

0: jdbc:drill:zk=local> select kc1, kd1[0].kc2 from dfs.`/path/to/work/drill/data/test.json` where kd1[0].kb2 = 10.1 and ka1 = 1;
+------------+------------+
|    kc1     |   EXPR$1   |
+------------+------------+
| vc11       | vc1010     |
+------------+------------+
1 row selected (0.181 seconds)

创建view:

0: jdbc:drill:zk=local> create view dfs.tmp.tmpview as select kd1[0].kb2 from dfs.`/path/to/work/drill/data/test.json`;
+------------+------------+
|     ok     |  summary   |
+------------+------------+
| true       | View 'tmpview' created successfully in 'dfs.tmp' schema |
+------------+------------+
1 row selected (0.055 seconds)

0: jdbc:drill:zk=local> select * from dfs.tmp.tmpview;
+------------+
|   EXPR$0   |
+------------+
| 10.1       |
| 20.2       |
| 30.3       |
+------------+
3 rows selected (0.193 seconds)

可以把嵌套的第1层表打平(整合kd1[0]..kd1[n]):

0: jdbc:drill:zk=local> select kddb.kdtable.kc2 from (select flatten(kd1) kdtable from dfs.`/path/to/work/drill/data/test.json`) kddb;
+------------+
|   EXPR$0   |
+------------+
| vc1010     |
| vc2020     |
| vc3030     |
+------------+
3 rows selected (0.083 seconds)

应用细节上和mysql如故截然差距的,其余涉及到多层表的复杂性逻辑,要想用得百发百中还需求仔细阅读官方文档并多多陶冶。这一次先不经消化明白就接受了,之后会深深摸底语法层面的风味。

3、成本

安装

Drill可以安装在单机可能集群环境上,支持Linux、Windows、Mac OS
X系统。简单起见,大家在Linux单机环境(CentOS 6.3)搭建以供试用。

准备安装包:

在$WOQashqaiK(/path/to/work)目录中设置,将jdk和drill分别解压到java和drill目录中,并打软连以便升级:

.
├── drill
│   ├── apache-drill -> apache-drill-0.8.0
│   └── apache-drill-0.8.0
├── init.sh
└── java
    ├── jdk -> jdk1.7.0_75
    └── jdk1.7.0_75

并添加一init.sh脚本起初化java相关环境变量:

export WORK="/path/to/work"
export JAVA="$WORK/java/jdk/bin/java"
export JAVA_HOME="$WORK/java/jdk"

上图中,除了“硬件负载均衡”节点外,其它节点都得以安插成集群(DB有点特殊,古板奥迪Q5DBMS要达成分布式/集群依然相比较不方便的,要看具体应用的数据库产品,并非全部数据库都能方便的做Sharding),Jboss本人可以经过Domain方式+mod_cluster已毕集群、Redis通过Master/Slave以Sentinel格局得以兑现HA、IBM
MQ本身就援救集群、FTP
Server协作底层储存阵列也可以成功HA、Nginx静态能源服务器自不必说

② 、尽量消除单点故障

那是任重(英文名:rèn zhòng)而道远考虑的,以那张图为例,互连网划分为二个区:

夜晚把公司选用的架构重组此前讨论的东西梳理了下,整理了一张架构规划图,贴在此处备份

一旦系统数据量级达到单机OdysseyDBMS的上限,尽早考虑Sharding方案,近期mysql在这地点可比早熟,其它数据库就不好说了。

web server、app
server那么些相似都得以经过集群落成横向扩充,满意质量一般增加的急需。最大的障碍照旧DB,借使局面真达到了DB的上限,依然考虑换分布式DB可能迁移到“云”上吧。

b) App Core区能与DMZ区、DB
Core区互通,不过力不从心直接从公网访问 (平日这里放置
应用服务器、中间件服务器之类)

a) DMZ区可以直接公网访问,也得以 与App Core区互通,但不能够一贯与DB
Core区互通 (常常那里放置 反向代理Web服务器)

4、Database问题

上边是私房知道的做架构的多少个要点:

5、性能

c) DB Core区仅与App Core区互通 (常常这里放置 主旨数据库)

例行公司应用中,古板关系型数据如故是主流,然而no-sql经过这几年发展,技术也渐渐成熟了,一些非关键数据能够适合选择no-sql数据库,比如:系统日志、报文历史记录那类相对相比较独立,而且提升很快的数据,可以考虑存储到no-sql
db甚至HDFS、TFS等分布式开源文件系统中。

发表评论

电子邮件地址不会被公开。 必填项已用*标注