Category Archives: Database

Uber 从 Postgres 切换到 MySQL

Uber工程师在官方博客上描述了他们为什么要从 Postgres 切换到 MySQL 数据库。Uber的早期架构是由 Python编写的后端应用构成，使用了 Postgres 数据库。但此后，Uber的架构发生了显著的改变，转变到了微服务模型和新的数据平台。以前他们使用 Postgres，现在则改用了基于 MySQL 的数据库分片层。Uber工程师称他们之所以切换到Schemaless和其它基于 MySQL 的后端服务，最主要的原因是Postgres 数据复制效率低下，Postgres更新已有行的效率低于 MySQL，Postgres需要重写每一个行索引，而MySQL只更新改变的索引。 相关链接 MySQL 的详细介绍：请点这里 MySQL 的下载地址：请点这里   from:http://www.oschina.net/news/75638/uber-mysql-migration

阿里巴巴分布式数据库同步系统 otter

otter 基于数据库增量日志解析，准实时同步到本机房或异地机房的mysql/oracle数据库. 一个分布式数据库同步系统。 工作原理： 原理描述： 1. 基于Canal开源产品，获取数据库增量日志数据。 什么是Canal, 请点击 2. 典型管理系统架构，manager(web管理)+node(工作节点) a. manager运行时推送同步配置到node节点 b. node节点将同步状态反馈到manager上 3. 基于zookeeper，解决分布式状态调度的，允许多node节点之间协同工作.   osc地址：http://www.oschina.net/p/otter

Incorrect string value: '\xF0\x90\x8D\x83…' for column… Emoji表情字符过滤的Java实现

Emoji表情字符现在在APP已经广泛支持了。但是Mysql的UTF8编码对Emoji字符的支持却不是那么好。所以我们经常会遇到这样的异常： Incorrect string value: '\xF0\x90\x8D\x83…' for column 原因是Mysql里UTF8编码最多只能支持3个字节，而Emoji表情字符使用的UTF8编码，很多都是4个字节，有些甚至是6个字节。 解决的方案有两种： 1.使用utf8mb4的mysql编码来容纳这些字符。 2.过滤掉这些特殊的表情字符。 关于第一种解决方法，请参考：http://segmentfault.com/a/1190000000616820 和 http://info.michael-simons.eu/2013/01/21/java-mysql-and-multi-byte-utf-8-support/ 有大量细节需要注意，例如：mysql版本，mysql的配置，mysql connector的版本等等。。 因为我们使用的云数据库，所以我选择了过滤这些特殊字符。其实过滤的方式很简单，直接使用正则表达式匹配编码范围，然后替换就行了。 下面是我的代码。 更多可以参考：http://stackoverflow.com/questions/27820971/why-a-surrogate-java-regexp-finds-hypen-minus import org.apache.commons.lang3.StringUtils; public class EmojiFilterUtils { /**      * 将emoji表情替换成*      *       * @param source      * @return 过滤后的字符串      */ public static String filterEmoji(String source) { if(StringUtils.isNotBlank(source)){ return source.replaceAll("[\\ud800\\udc00-\\udbff\\udfff\\ud800-\\udfff]", "*");         }else{ return source;         }     } public static void main(String[] arg ){ try{             String text = "This is a smiley \uD83C\uDFA6 face\uD860\uDD5D \uD860\uDE07 \uD860\uDEE2 \uD863\uDCCA \uD863\uDCCD \uD863\uDCD2 \uD867\uDD98 ";             System.out.println(text);             System.out.println(text.length());             System.out.println(text.replaceAll("[\\ud83c\\udc00-\\ud83c\\udfff]|[\\ud83d\\udc00-\\ud83d\\udfff]|[\\u2600-\\u27ff]", "*"));             System.out.println(filterEmoji(text));         }catch (Exception ex){             ex.printStackTrace();         }     } } from:http://blog.csdn.net/shootyou/article/details/44852639

一篇文章，掌握所有开源数据库的现状

数据库作为业务的核心，在整个基础软件栈中是非常重要的一环。近几年社区也是新的方案和思想层出不穷，接下来我将总结一下近几年一些主流的开源数据库方案，其背后的设计思想以及适用场景。本人才疏学浅如有遗漏或者错误请见谅。本次分享聚焦于数据库既结构化数据存储 OLTP 及 NoSQL 领域，不会涉及 OLAP、对象存储、分布式文件系统。 1 开源RDBMS与互联网的崛起 很长时间以来，关系型数据库一直是大公司的专利，市场被 Oracle / DB2 等企业数据库牢牢把持。但是随着互联网的崛起、开源社区的发展，上世纪九十年代 MySQL 1.0 的发布，标志着关系型数据库的领域社区终于有可选择的方案。 MySQL 第一个介绍的单机RDBMS就是MySQL。相信大多数朋友都已经对 MySQL 非常熟悉，基本上 MySQL 的成长史就是互联网的成长史。我接触的第一个 MySQL 版本是 MySQL 4.0，到后来的 MySQL 5.5 更是经典——基本所有的互联网公司都在使用。 MySQL 也普及了「可插拔」引擎这一概念，针对不同的业务场景选用不同的存储引擎是 MySQL tuning 的一个重要的方式。比如对于有事务需求的场景使用 InnoDB;对于并发读取的场景 MyISAM 可能比较合适;但是现在我推荐绝大多数情况还是使用 InnoDB，毕竟 5.6 后已经成为了官方的默认引擎。大多数朋友都基本知道什么场景适用 MySQL(几乎所有需要持久化结构化数据的场景)，我就不赘述了。 另外值得一提的是 MySQL 5.6中引入了多线程复制和 GTID，使得故障恢复和主从的运维变得比较方便。另外，5.7(目前处于 GA 版本) 是 MySQL 的一个重大更新，主要是读写性能和复制性能上有了长足的进步(在5.6版本中实现了SCHEMA级别的并行复制，不过意义不大，倒是MariaDB的多线程并行复制大放异彩，有不少人因为这个特性选择MariaDB。MySQL 5.7 MTS支持两种模式，一种是和5.6一样，另一种则是基于binlog group commit实现的多线程复制，也就是MASTER上同时提交的binlog在SLAVE端也可以同时被apply，实现并行复制)。 如果有单机数据库技术选型的朋友，基本上只需要考虑 5.7 或者 MariaDB 就好了，而且 5.6、5.7 由 Oracle 接手后，性能和稳定性上都有了明显的提升。 PostgreSQL PostgreSQL的历史也非常悠久，其前身是UCB的Ingres，主持这个项目的 Michael Stronebraker 于 2015 年获得图灵奖。后来项目更名为 Post-Ingres，项目基于 BSD license 下开源。 1995 年几个 UCB 的学生为 Post-Ingres 开发了 SQL 的接口，正式发布了 PostgreSQL95，随后一步步在开源社区中成长起来。 和 MySQL 一样，PostgreSQL 也是一个单机的关系型数据库，但是与 MySQL […]

大型网站应用中 MySQL 的架构演变史

没有什么东西是一成不变的，包含我们的理想和生活！MySQL作为一个免费的开源的关系型数据库，深受大家喜爱，从最初的无人问津到当下的去IOE，都体现出了MySQL举足轻重的作用。今天我们就从淘宝的发展来阐述MySQL在大型网站下的架构演变史！ MySQL的可扩展性 架构的可扩展性往往和并发是息息相关，没有并发的增长，也就没有必要做高可扩展性的架构，这里对可扩展性进行简单介绍一下，常用的扩展手段有以下两种 Scale-up : 纵向扩展，通过替换为更好的机器和资源来实现伸缩，提升服务能力 Scale-out : 横向扩展,  通过加节点（机器）来实现伸缩，提升服务能力 对于互联网的高并发应用来说，无疑Scale out才是出路，通过纵向的买更高端的机器一直是我们所避讳的问题，也不是长久之计，在scale out的理论下，可扩展性的理想状态是什么？ 可扩展性的理想状态 一个服务，当面临更高的并发的时候，能够通过简单增加机器来提升服务支撑的并发度，且增加机器过程中对线上服务无影响(no down time)，这就是可扩展性的理想状态！ MySQL架构的演变 MySQL简单网站架构(V1.0) 一个简单的小型网站或者应用背后的架构可以非常简单,  数据存储只需要一个mysql instance就能满足数据读取和写入需求（这里忽略掉了数据备份的实例），处于这个时间段的网站，一般会把所有的信息存到一个database instance里面。 在这样的架构下，我们来看看数据存储的瓶颈是什么？ 1.数据量的总大小  一个机器放不下时 2.数据的索引（B+ Tree）一个机器的内存放不下时 3.访问量(读写混合)一个实例不能承受 只有当以上3件事情任何一件或多件满足时，我们才需要考虑往下一级演变。 从此我们可以看出，事实上对于很多小公司小应用，这种架构已经足够满足他们的需求了，初期数据量的准确评估是杜绝过度设计很重要的一环，毕竟没有人愿意为不可能发生的事情而浪费自己的经历。 这里简单举个我的例子，对于用户信息这类表 （3个索引），16G内存能放下大概2000W行数据的索引，简单的读和写混合访问量3000/s左右没有问题，你的应用场景是否 MySQL的垂直架构(V2.0) 一般当V1.0 遇到瓶颈时，首先最简便的拆分方法就是垂直拆分，何谓垂直？就是从业务角度来看，将关联性不强的数据拆分到不同的instance上，从而达到消除瓶颈的目标。以图中的为例，将用户信息数据，和业务数据拆分到不同的三个实例上。对于重复读类型比较多的场景，我们还可以加一层cache，来减少对DB的压力。 在这样的架构下，我们来看看数据存储的瓶颈是什么？ 单实例单业务，依然存在V1.0所述瓶颈，遇到瓶颈时可以考虑往本文更高V版本升级, 若是读请求导致达到性能瓶颈可以考虑往V3.0升级， 其他瓶颈考虑往V4.0升级 MySQL的主从架构(V3.0) 此类架构主要解决V2.0架构下的读问题，通过给Instance挂数据实时备份的思路来迁移读取的压力，在Mysql的场景下就是通过主从结构，主库抗写压力，通过从库来分担读压力，对于写少读多的应用，V3.0主从架构完全能够胜任 在这样的架构下，我们来看看数据存储的瓶颈是什么？ 写入量主库不能承受 MySQL的路由多集群架构(V4.0) 对于V2.0 V3.0方案遇到瓶颈时，都可以通过水平拆分来解决，水平拆分和垂直拆分有较大区别，垂直拆分拆完的结果，在一个实例上是拥有全量数据的，而水平拆分之后，任何实例都只有全量的1/n的数据，以下图Userinfo的拆分为例，将userinfo拆分为3个cluster，每个cluster持有总量的1/3数据，3个cluster数据的总和等于一份完整数据（注：这里不再叫单个实例 而是叫一个cluster 代表包含主从的一个小mysql集群） 数据如何路由？ 1.Range拆分 sharding key按连续区间段路由，一般用在有严格自增ID需求的场景上，如Userid, Userid Range的小例子：以userid 3000W 为Range进行拆分 1号cluster userid 1-3000W 2号cluster userid 3001W-6000W 2.List拆分 List拆分与Range拆分思路一样，都是通过给不同的sharding key来路由到不同的cluster,但是具体方法有些不同,List主要用来做sharding key不是连续区间的序列落到一个cluster的情况，如以下场景： 假定有20个音像店，分布在4个有经销权的地区，如下表所示： 业务希望能够把一个地区的所有数据组织到一起来搜索，这种场景List拆分可以轻松搞定 3.Hash拆分 通过对sharding key 进行哈希的方式来进行拆分，常用的哈希方法有除余,字符串哈希等等，除余如按userid%n 的值来决定数据读写哪个cluster，其他哈希类算法这里就不细展开讲了。 数据拆分后引入的问题： 数据水平拆分引入的问题主要是只能通过sharding key来读写操作，例如以userid为sharding key的切分例子，读userid的详细信息时，一定需要先知道userid,这样才能推算出再哪个cluster进而进行查询，假设我需要按username进行检索用户信息，需要引入额外的反向索引机制（类似HBASE二级索引），如在redis上存储username->userid的映射，以username查询的例子变成了先通过查询username->userid，再通过userid查询相应的信息。 实际上这个做法很简单，但是我们不要忽略了一个额外的隐患，那就是数据不一致的隐患。存储在redis里的username->userid和存储在mysql里的userid->username必须需要是一致的，这个保证起来很多时候是一件比较困难的事情，举个例子来说，对于修改用户名这个场景，你需要同时修改redis和mysql,这两个东西是很难做到事务保证的,如mysql操作成功 但是redis却操作失败了（分布式事务引入成本较高）,对于互联网应用来说，可用性是最重要的，一致性是其次，所以能够容忍小量的不一致出现. 毕竟从占比来说，这类的不一致的比例可以微乎其微到忽略不计（一般写更新也会采用mq来保证直到成功为止才停止重试操作） 在这样的架构下，我们来看看数据存储的瓶颈是什么？ 在这个拆分理念上搭建起来的架构，理论上不存在瓶颈（sharding key能确保各cluster流量相对均衡的前提下),不过确有一件恶心的事情，那就是cluster扩容的时候重做数据的成本，如我原来有3个cluster，但是现在我的数据增长比较快，我需要6个cluster，那么我们需要将每个cluster 一拆为二，一般的做法是 1.摘下一个slave,停同步, 2.对写记录增量log（实现上可以业务方对写操作 多一次写持久化mq  或者mysql主创建trigger记录写 等等方式） […]

Mysql支持的数据类型(总结)

一.数值类型 Mysql支持所有标准SQL中的数值类型，其中包括严格数据类型(INTEGER,SMALLINT,DECIMAL,NUMBERIC)，以及近似数值数据类型(FLOAT,REAL,DOUBLE PRESISION),并在此基础上进行扩展。 扩展后增加了TINYINT,MEDIUMINT,BIGINT这3种长度不同的整形，并增加了BIT类型，用来存放位数据。 整数类型        字节       范围（有符号）      范围（无符号）          用途  TINYINT        1字节        (-128，127)          (0，255)            小整数值 SMALLINT       2字节     (-32 768，32 767)       (0，65 535)         大整数值 MEDIUMINT      3字节    (-8 388 608，8 388 607) (0，16 777 215)      大整数值 INT或INTEGER   4字节   (-2 147 483 648，2 147 483 647) […]

VS2015 +EF6 连接MYSQL数据库生成实体

使用EF设计器 此时此刻，发现二逼了，咋没有MySQL Database呢？ 好吧，下面重点： 需要下载安装： 1：mysql-for-visualstudio-1.2.6.msi http://dev.mysql.com/downloads/file/?id=460645 2：mysql-connector-net-6.9.8.msi http://dev.mysql.com/downloads/connector/net/ 3：使用Nuget安装EF   我这边是已经安装完了（版本选择6.1以上的），所以显示“更新”和“卸载”，如果你安装了，继续看下面的   下图是随便找了一个没安装的，就会有“安装”按钮，   4：使用Nuget安装Mysql.Data.Entity 与安装EF相同 点击安装后，一会会出现如下图：     执行完上述步骤，看web.config文件，会自动增加如下代码 OK,现在我们所有的步骤就执行完了。最好重启下VS（不知道是不是必须，反正我重启了），之后重新编译。 再之后，就可以按开始的步骤生成MYSQL对应的实体了。 注：如果刚开始那两个MSI文件安装有问题，则生成实体的时候，到了这一步之后（如下图），会出现闪退问题，无法生成实体   （本人就遇到过这个问题） 到了这一步，已经没有任何悬念了。   来自为知笔记(Wiz) from:http://www.cnblogs.com/RushPasser/p/5438334.html

实战：上亿数据如何秒查？

最近在忙着优化集团公司的一个报表。优化完成后，报表查询速度有从半小时以上(甚至查不出)到秒查的质变。从修改SQL查询语句逻辑到决定创建存储过程实现，花了我3天多的时间，在此总结一下，希望对朋友们有帮助。   数据背景 首先，项目是西门子中国在我司实施部署的MES项目，由于项目是在产线上运作(3 years+)，数据累积很大。在项目的数据库中，大概上亿条数据的表有5个以上，千万级数据的表10个以上，百万级数据的表，很多… (历史问题，当初实施无人监管，无人监控数据库这块的性能问题。ps:我刚入职不久…) 不多说，直接贴西门子中国的开发人员在我司开发的SSRS报表中的SQL语句：

这个查询语句，实际上通过我的检测和调查，在B/S系统前端已无法查出结果，半小时，一小时 … 。因为我直接在SQL查询分析器查，半小时都没有结果。 (原因是里面对一张上亿级数据表和3张千万级数据表做全表扫描查询) 不由感慨，西门子中国的素质(或者说责任感)就这样？ 下面说说我的分析和走的弯路(思维误区)，希望对你也有警醒。   探索和误区 首先相关表的索引，没有建全的，把索引给建上。 索引这步完成后，发现情况还是一样，查询速度几乎没有改善。后来想起相关千万级数据以上的表，都还没有建立表分区。于是考虑建立表分区以及数据复制的方案。 这里有必要说明下：我司报表用的是一个专门的数据库服务器，数据从产线订阅而来。就是常说的“读写分离”。 如果直接在原表上建立表分区，你会发现执行表分区的事物会直接死锁。原因是：表分区操作本身会锁表，产线还在推数据过来，这样很容易“阻塞”，“死锁”。 我想好的方案是：建立一个新表(空表)，在新表上建好表分区，然后复制数据过来。 正打算这么干。等等！我好像进入了一个严重的误区！ 分析： 原SQL语句和业务需求，是对产线的数据做产品以及序列号的追溯，关键是查询条件里没有有规律的"条件"(如日期、编号)，贸然做了表分区，在这里几乎没有意义！反而会降低查询性能！ 好险！还是一步一步来，先做SQL语句分析。   一、对原SQL语句的分析 1、查询语句的where条件，有大量@var in … or (@var =") 的片段 2、where条件有like '%’+@var+’%' 3、where条件有 case … end 函数 4、多次连接同一表查询，另外使用本身已嵌套的视图表，是不是必须，是否可替代？ 5、SQL语句有*号，视图中也有*号出现   二、优化设计 首先是用存储过程改写，好处是设计灵活。 核心思想是：用一个或多个查询条件(查询条件要求至少输入一个)得到临时表，每个查询条件如果查到集合，就更新这张临时表，最后汇总的时候，只需判断这个临时表是否有值。以此类推，可以建立多个临时表，将查询条件汇总。   这样做目前来看至少两点好处： 1、省去了对变量进行 =@var or (@var=")的判断； 2、抛弃sql拼接，提高代码可读性。   再有就是在书写存储过程，这个过程中要注意： 1、尽量想办法使用临时表扫描替代全表扫描； 2、抛弃in和not in语句，使用exists和not exists替代； 3、和客户确认，模糊查询是否有必要，如没有必要，去掉like语句； 4、注意建立适当的，符合场景的索引； 5、踩死 "*" 号； 6、避免在where条件中对字段进行函数操作； 7、对实时性要求不高的报表，允许脏读(with(nolock))。   三、存储过程 如果想参考优化设计片段的详细内容，请参阅SQL代码：

虽然牺牲了代码的可读性，但创造了性能价值。本人水平有限，还请各位不吝赐教！ 最后，将SSRS报表替换成此存储过程后，SQL查询分析器是秒查的。B/S前端用时1~2秒！   四、总结 平常的你是否偶尔会因急于完成任务而书写一堆性能极低的SQL语句呢？写出可靠性能的SQL语句不难，难的是习惯。 本文的优化思想很简单，关键点是避免全表扫描 & 注重SQL语句写法 & 索引，另外，如果你查询的表有可能会在查询时段更新，而实际业务需求允许脏读，可加with(nolock)预防查询被更新事物阻塞。 作者：hangwei 出处：http://www.cnblogs.com/hangwei/ 关于作者：专注于微软平台项目的架构设计与开发、数据库调优等工作。如有问题或建议，请多多赐教！   from:http://www.oschina.net/news/74787/how-the-data-on-the-second-search

六个藉藉无名但迅速崛起的Apache大数据项目

如今全球各地的无数企业组织在处理数据集，这些数据集是如此地庞大而复杂，以至于传统的数据处理应用软件再也无法支持经过优化的数据分析和洞察力获取。这是新一批大数据应用软件旨在解决的问题，而Apache软件基金会（ASF）最近将一批值得关注的开源大数据项目升级为Apache顶级项目。这意味着，这些项目将获得积极的开发和强有力的社区支持。 （图片来源：Creative Commons Zero） 大多数人已听说过Apache Spark，这种大数据处理框架拥有内置模块，可用于数据流、SQL、机器学习和图形处理。IBM及其他公司正在往Spark项目投入数十亿美元的开发资金，美国宇航局和SETI研究所在开展合作，利用Spark的机器学习能力，分析数TB的复杂的外太空无线信号，搜寻可能表明存在智能外星生命的模式。 然而，另外几个最近被提升为顶级项目的Apache大数据项目同样值得关注。实际上，其中一些打造的生态系统在活动和开发上可与Spark的生态系统相媲美。本文介绍了你应该知道的几个Apache大数据项目。 下面是六个迅速崛起的项目： Kylin Apache最近宣布，Kylin项目这个脱胎于eBay的开源大数据项目已被提升为顶级项目。Kylin是一个开源分布式分析引擎，旨在提供一种基于Apache Hadoop的SQL接口和多维分析（OLAP），支持极其庞大的数据集。它仍广泛用于eBay和另外几家组织。 Apache Kylin副总裁Luke Han说：“Apache Kylin的孵化之旅已证明了开源治理在Apache软件基金会（ASF）具有的价值，并证明了围绕该项目打造一个开源社区和生态系统的力量。我们的社区在与世界上最庞大的本地开发者社区积极互动，完全依照Apache之道。” 作为一种基于Hadoop的OLAP解决方案，Apache Kylin旨在填补大数据探索与人类使用之间的空白，“让分析员、最终用户、开发人员和数据爱好者能够对庞大数据集执行交互式分析，延迟低于1秒，”据开发人员声称。他们补充道：“Apache Kylin将商业智能（BI）带回給Apache Hadoop，发掘大数据的价值。” Lens Apache最近还宣布，Apache Lens这个开源大数据和分析工具由Apache孵化器提升为顶级项目（TLP）。据宣布声称：“Apache Lens是一种统一分析平台。它为统一视图的分析查询提供了一种最佳执行环境。Apache Lens旨在通过针对多个分层数据存储系统，提供单一的数据视图，从而消除数据分析孤岛。” “通过在数据基础上提供一种联机分析处理（OLAP）模型，Lens将Apach Hadoop和传统数据仓库无缝集成起来，好比是一个整体。它还为在系统中运行的查询提供了查询历史记录和分析统计功能，另外提供了查询生命周期管理。” Apache Lens的副总裁Amareshwari Sriramadasu 说：“在ASF孵化Apache Lens是个神奇的经历。Apache Lens着眼于最终用户，解决了大数据分析领域的一个非常关键的问题。它让业务用户、分析员、数据科学家、开发人员及其他用户能够轻松处理复杂的分析，不需要了解底层的数据布局。” Ignite Apache软件基金会还宣布Apache Ingite成为了一个顶级项目。这个开源项目旨在构建一种内存中数据架构（in-memory data fabric）。 据Apache社区的成员声称：“Apache Ignite是一种高性能、集成、分布式的内存中数据架构，针对大规模数据集可实现实时计算和处理，速度比基于磁盘或闪存的传统技术要快几个数量级。它旨在可以轻松支持成本合理、基于行业标准的硬件上的分布式大规模并行架构中的新旧应用程序。” Brooklyn Apache软件基金会宣布，Apache Brooklyn现在是个顶级项目（TLP），“这标志着该项目的社区和产品已在该基金会的精英管理流程和原则下得到了妥善治理。”Brooklyn是一种应用程序蓝图和管理平台，用于跨多个数据中心集成服务，并集成云端的众多软件。 据Brooklyn宣布声称：“由于现代应用程序由许多组件构成，微服务架构日前受到关注，部署应用程序和已部署应用程序的日常改进成了一个越来越难的问题。Apache Brooklyn的蓝图提供了一种清晰简洁的方式，可以在部署到公共云或私有基础设施之前，明确应用程序、组件、配置以及组件之间的关系。基于策略的管理建立在自主计算理论这个基础上，不断评估运行中的应用程序，并对它进行改动，让应用程序保持顺畅运行，并且针对成本和响应能力等度量指标进行优化。” Brooklyn现用于一些知名企业组织。云服务提供商Canopy和Virtustream已开发了基于Brooklyn的产品。IBM也广泛使用Apache Brooklyn，以便将大量的工作负载从AWS迁移到IBM Softlayer。 Apex 今年4月份，Apache软件基金会将Apex项目提升为顶级项目。它号称是“面向Apache Hadoop生态系统的一种大规模、高吞吐量、低延时、容错、统一的大数据数据流和批量处理平台。”Apex可与Apache Hadoop YARN协同运行，后者是一种适用于Hadoop集群的资源管理平台。 Tajo 最后，Apache Tajo是需要了解的另一个新的大数据项目，这是Apache Hadoop中一个先进的开源数据仓库系统。Apache声称，Tajo为Hadoop部署系统、第三方数据库和商用商业智能工具提供了快速获取更多信息的功能。 很显然，虽然Apache Spark吸引了大量眼球，但它不是Apache提供的唯一引人注目的大数据工具。今年，Apache可能会将更引人注目的大数据项目提升为顶级项目，这些项目将得益于经过优化的开发资源及更多优势。 原文标题：On the Rise: Six Unsung Apache Big Data Projects   from:http://developer.51cto.com/art/201606/513276.htm