个人头像照片 封神

个人介绍

09年加入阿里巴巴,阿里云高级技术专家、架构师;专注在大数据领域,多年分布式经验;先后研发上万台Hadoop、ODPS集群;先后负责阿里分布式调度平台YARN;自主研发分布式内存计算引擎,负责Spark; 目前为广大公共云用户提供专业的大数据结构化存储服务(云HBase)

  • 最新动态
  • 文章
  • 问答

2019年06月

  • 06.21 16:57:05
    发表了文章 2019-06-21 16:57:05

    欢迎加盟云智能数据库BigData NoSQL团队

    数据库事业部承载着阿里巴巴及阿里云的数据库服务,为超过数万家中国企业提供专业的数据库服务。我们提供在线事务处理、缓存文档服务、BigData NoSQL服务 、在线分析处理的全栈数据库产品。本团队提供基于Apache HBasePhoenixSparkCassandraSolrES等,结合自研技术,打造存储、检索、计算的一站式的BigData NoSQL自主可控的服务,满足客户的数据驱动业务的诉求。
正在加载, 请稍后...
滑动查看更多
正在加载, 请稍后...
暂无更多信息
  • 回答了问题 2019-07-17

    Cassandra优势在哪里?

    参考:https://www.iteblog.com/archives/2530.html

    分布式和去中心化(Distributed and Decentralized)
    Cassandra 是分布式的,这意味着它可以运行在多台机器上,并呈现给用户一个一致的整体。事实上,在一个节点上运行 Cassandra 是没啥用的,虽然我们可以这么做,并且这可以帮助我们了解它的工作机制,但是你很快就会意识到,需要多个节点才能真正了解 Cassandra 的强大之处。它的很多设计和实现让系统不仅可以在多个节点上运行,更为多机架部署进行了优化,甚至一个 Cassandra 集群可以运行在分散于世界各地的数据中心上。你可以放心地将数据写到集群的任意一台机器上,Cassandra 都会收到数据。

    对于很多存储系统(比如 MySQL, Bigtable),一旦你开始扩展它,就需要把某些节点设为主节点,其他则作为从节点。但 Cassandra 是无中心的,也就是说每个节点都是一样的。与主从结构相反,Cassandra 的协议是 P2P 的,并使用 gossip 来维护存活或死亡节点的列表。关于 gossip 可以参见《分布式原理:一文了解 Gossip 协议》。

    去中心化这一事实意味着 Cassandra 不会存在单点失效。Cassandra 集群中的所有节点的功能都完全一样, 所以不存在一个特殊的主机作为主节点来承担协调任务。有时这被叫做服务器对称(server symmetry)。

    综上所述,Cassandra 是分布式、无中心的,它不会有单点失效,所以支持高可用性。

    弹性可扩展(Elastic Scalability)
    可扩展性是指系统架构可以让系统提供更多的服务而不降低使用性能的特性。仅仅通过给现有的机器增加硬件的容量、内存进行垂直扩展,是最简单的达到可扩展性的手段。而水平扩展则需要增加更多机器,每台机器提供全部或部分数据,这样所有主机都不必负担全部业务请求。但软件自己需要有内部机制来保证集群中节点间的数据同步。

    弹性可扩展是指水平扩展的特性,意即你的集群可以不间断的情况下,方便扩展或缩减服务的规模。这样,你就不需要重新启动进程,不必修改应用的查询,也无需自己手工重新均衡数据分布。在 Cassandra 里,你只要加入新的计算机,Cassandra 就会自动地发现它并让它开始工作。

    高可用和容错(High Availability and Fault Tolerance)
    从一般架构的角度来看,系统的可用性是由满足请求的能力来量度的。但计算机可能会有各种各样的故障,从硬件器件故障到网络中断都有可能。如何计算机都可能发生这些情况,所以它们一般都有硬件冗余,并在发生故障事件的情况下会自动响应并进行热切换。对一个需要高可用的系统,它必须由多台联网的计算机构成,并且运行于其上的软件也必须能够在集群条件下工作,有设备能够识别节点故障,并将发生故障的中端的功能在剩余系统上进行恢复。

    Cassandra 就是高可用的。你可以在不中断系统的情况下替换故障节点,还可以把数据分布到多个数据中心里,从而提供更好的本地访问性能,并且在某一数据中心发生火灾、洪水等不可抗灾难的时候防止系统彻底瘫痪。

    可调节的一致性(Tuneable Consistency)
    2000年,加州大学伯克利分校的 Eric Brewer 在 ACM 分布式计算原理会议提出了著名的 CAP 定律。CAP 定律表明,对于任意给定的系统,只能在一致性(Consistency)、可用性(Availability)以及分区容错性(Partition Tolerance)之间选择两个。关于 CAP 定律的详细介绍可参见《分布式系统一致性问题、CAP定律以及 BASE 理论》以及《一篇文章搞清楚什么是分布式系统 CAP 定理》。所以 Cassandra 在设计的时候也不得不考虑这些问题,因为分区容错性这个是每个分布式系统必须考虑的,所以只能在一致性和可用性之间做选择,而 Cassandra 的应用场景更多的是为了满足可用性,所以我们只能牺牲一致性了。但是根据 BASE 理论,我们其实可以通过牺牲强一致性获得可用性。

    Cassandra 提供了可调节的一致性,允许我们选定需要的一致性水平与可用性水平,在二者间找到平衡点。因为客户端可以控制在更新到达多少个副本之前,必须阻塞系统。这是通过设置副本因子(replication factor)来调节与之相对的一致性级别。

    通过副本因子(replication factor),你可以决定准备牺牲多少性能来换取一致性。 副本因子是你要求更新在集群中传播到的节点数(注意,更新包括所有增加、删除和更新操作)。

    客户端每次操作还必须设置一个一致性级别(consistency level)参数,这个参数决定了多少个副本写入成功才可以认定写操作是成功的,或者读取过程中读到多少个副本正确就可以认定是读成功的。这里 Cassandra 把决定一致性程度的权利留给了客户自己。

    所以,如果需要的话,你可以设定一致性级别和副本因子相等,从而达到一个较高的一致性水平,不过这样就必须付出同步阻塞操作的代价,只有所有节点都被更新完成才能成功返回一次更新。而实际上,Cassandra 一般都不会这么来用,原因显而易见(这样就丧失了可用性目标,影响性能,而且这不是你选择 Cassandra 的初衷)。而如果一个客户端设置一致性级别低于副本因子的话,即使有节点宕机了,仍然可以写成功。

    总体来说,Cassandra 更倾向于 CP,虽然它也可以通过调节一致性水平达到 AP;但是不推荐你这么设置。

    面向行(Row-Oriented)
    Cassandra 经常被看做是一种面向列(Column-Oriented)的数据库,这也并不算错。它的数据结构不是关系型的,而是一个多维稀疏哈希表。稀疏(Sparse)意味着任何一行都可能会有一列或者几列,但每行都不一定(像关系模型那样)和其他行有一样的列。每行都有一个唯一的键值,用于进行数据访问。所以,更确切地说,应该把 Cassandra 看做是一个有索引的、面向行的存储系统。

    Cassandra 的数据存储结构基本可以看做是一个多维哈希表。这意味着你不必事先精确地决定你的具体数据结构或是你的记录应该包含哪些具体字段。这特别适合处于草创阶段,还在不断增加或修改服务特性的应用。而且也特别适合应用在敏捷开发项目中,不必进行长达数月的预先分析。对于使用 Cassandra 的应用,如果业务发生变化了,只需要在运行中增加或删除某些字段就行了,不会造成服务中断。

    当然, 这不是说你不需要考虑数据。相反,Cassandra 需要你换个角度看数据。在 RDBMS 里, 你得首先设计一个完整的数据模型, 然后考虑查询方式, 而在 Cassandra 里,你可以首先思考如何查询数据,然后提供这些数据就可以了。

    灵活的模式(Flexible Schema)
    Cassandra 的早期版本支持无模式(schema-free)数据模型,可以动态定义新的列。 无模式数据库(如 Bigtable 和 MongoDB)在访问大量数据时具有高度可扩展性和高性能的优势。 无模式数据库的主要缺点是难以确定数据的含义和格式,这限制了执行复杂查询的能力。

    为了解决这些问题,Cassandra 引入了 Cassandra Query Language(CQL),它提供了一种通过类似于结构化查询语言(SQL)的语法来定义模式。 最初,CQL 是作为 Cassandra 的另一个接口,并且基于 Apache Thrift 项目提供无模式的接口。 在这个过渡阶段,术语“模式可选”(Schema-optional)用于描述数据模型,我们可以使用 CQL 的模式来定义。并且可以通过 Thrift API 实现动态扩展以此添加新的列。 在此期间,基础数据存储模型是基于 Bigtable 的。

    从 3.0 版本开始,不推荐使用基于 Thrift API 的动态列创建的 API,并且 Cassandra 底层存储已经重新实现了,以更紧密地与 CQL 保持一致。 Cassandra 并没有完全限制动态扩展架构的能力,但它的工作方式却截然不同。 CQL 集合(比如 list、set、尤其是 map)提供了在无结构化的格式里面添加内容的能力,从而能扩展现有的模式。CQL 还提供了改变列的类型的能力,以支持 JSON 格式的文本的存储。

    因此,描述 Cassandra 当前状态的最佳方式可能是它支持灵活的模式。

    高性能(High Performance)
    Cassandra 在设计之初就特别考虑了要充分利用多处理器和多核计算机的性能,并考虑在分布于多个数据中心的大量这类服务器上运行。它可以一致而且无缝地扩展到数百台机器,存储数 TB 的数据。Cassandra 已经显示出了高负载下的良好表现,在一个非常普通的工作站上,Cassandra 也可以提供非常高的写吞吐量。而如果你增加更多的服务器,你还可以继续保持 Cassandra 所有的特性而无需牺牲性能。

    踩0 评论0
  • 提交了问题 2019-04-03

    Cassandra优势在哪里?

  • 回答了问题 2019-07-17

    cassandra的cql的基本命令

    踩0 评论0
  • 提交了问题 2019-04-03

    cassandra的cql的基本命令

  • 回答了问题 2019-07-17

    请问阿里云hbase的小版本升级,是直接升级到最新的小版本吗?

    是直接到最新的版本的,小版本升级保障兼容,全自动一键升级解决bug及提升性能。 可以参考文档:https://help.aliyun.com/document_detail/87670.html?spm=a2c4g.11186623.6.562.2d3778f00lmUFM

    踩0 评论0
  • 回答了问题 2019-07-17

    hbase写入很慢,但是集群负载也不高

    建议 端到端看下原因,一般可能是线程数不足引起。包括region的个数,客户端的写入线程数等。

    踩0 评论0
  • 回答了问题 2019-07-17

    ODPS到数据到hbase乱码问题

    此应该是 使用cdp的编码格式不对,建议都使用统一的编码格式。如果是使用 阿里云hbase,建议联系 云hbase答疑 咨询

    踩0 评论0
  • 回答了问题 2019-07-17

    请问phoenix乱码的问题怎么解决呢?

    阿里云hbase包含的Phoenix原则没有问题,你的问题没有场景及版本及代码片段,我们解决不了此问题。

    踩0 评论0
  • 回答了问题 2019-07-17

    export/inport阿里云HBase数据到oss乱码问题

    阿里云的hbase,支持 自动的备份恢复的

    踩0 评论0
  • 回答了问题 2019-07-17

    阿里云hbase的phoenix能支持Apache Kafka对接写入数据到phoenix里面吗?

    是支持的,需要咨询 请联系 钉钉号 云hbase答疑

    踩0 评论0
  • 回答了问题 2019-07-17

    请问下阿里云hbase的小版本升级需要多久?

    欢迎阿里云hbase产品:https://cn.aliyun.com/product/hbase?spm=5176.8097504.1280361.128.2ec76fb52JS1N6

    小版本升级的文档:https://help.aliyun.com/document_detail/87670.html?spm=a2c4g.11186623.6.562.52bb78f0WgwnRp

    一般 在10-20分钟之内,随着集群的大小,时间会线性增加。 小版本升级会重启hbase集群,重启过程之中,会滚动重启,对业务几乎没有影响。

    踩0 评论0
  • 回答了问题 2019-07-17

    phoenix应用场景

    Phoenix主要是给hbase提供sql的能力,大部分表单查询或者物联网或者不想使用kv接口 都可以使用Phoenix

    另外,阿里云的hbase直接支持x-pack Phoenix服务

    踩0 评论0
  • 回答了问题 2019-07-17

    时序数据如何设计rowkey?

    时序可以参考opentsdn的表设计,也可以直接用opentsdb的

    踩0 评论0
  • 回答了问题 2019-07-17

    跨集群备份效率怎么样,以后会开源吗

    开源hbase目前整个都没有健全的备份恢复的方案,目前阿里云介绍的是 备份恢复的方案,完全自研的。
    目前没有开源,后面看情况是否开源。

    踩0 评论0
  • 回答了问题 2019-07-17

    关于hbase宽表设计

    hbase的列基本没有限制,且是动态的。3000列没有问题。
    不过超过1w,查询效率肯定有一定的下降。如果是稀疏的,每次查询一部分问题不大。

    踩0 评论0
  • 回答了问题 2019-07-17

    HBase一般情况下怎么预分区

    可以参考 : https://help.aliyun.com/document_detail/71787.html?spm=a2c4g.11186623.6.572.1c413375kzX7Hc

    初次接触HBase的客户,在创建HBase表的时候,不指分区的数目,另外就是rowkey设计不合理,导致热点。

    最为常见的建表语句为:

    create ‘t3’,’f1’, { NUMREGIONS => 50, SPLITALGO => ‘HexStringSplit’ , COMPRESSION => ‘snappy’}

    其中 NUMREGIONS 为 region的个数,一般取10-500左右,集群规模大,可以取大一些,
    SPLITALGO 为 rowkey分割的算法:Hbase自带了两种pre-split的算法,分别是 HexStringSplit 和 UniformSplit,HexStringSplit 如果我们的row key是十六进制的字符串作为前缀的,就比较适合用HexStringSplit,关于rowkey的设计可以参考:RowKey设计
    COMPRESSION压缩算法,参考:数据压缩与编码

    踩0 评论0
  • 回答了问题 2019-07-17

    在安装过社区版 HBase 的服务器的里面安装 CDH 可以吗?

    这个 你试下就可以了,不行就不行,行就行。 可能会出现一些问题~ 这个问题等于没有回答

    踩0 评论0
  • 回答了问题 2019-07-17

    现在的各种大数据平台产品都说SQL化开发,是怎么做到的呢?

    流表 这里面一般是讲这个表可以支持 更新、删除、写入,且是实时的。 一般我们建议 采取hbase为流表。再 sparkStreaming或者Spark关联 写入 或者读取查询~ 可以参考:https://help.aliyun.com/document_detail/93899.html?spm=a2c4g.11186623.6.596.38b478f045VXtE 及一些案例

    踩0 评论0
  • 回答了问题 2019-07-17

    数据量达到多少适合换成 HBase+Spark来处理数据?

    对于数据量,hbase+spark是任意数据量都合适的。越大的数据量越有优势,因为其他引擎搞不定~

    踩0 评论0
  • 回答了问题 2019-07-17

    通过 Hive 创建 Phoenix外部表,稳不稳?

    建议通过spark访问Phoenix,hive访问Phoenix原则支持,阿里云团队不提供源码支持

    阿里云 hbase团队的文档 创建:https://help.aliyun.com/document_detail/95046.html?spm=a2c4g.11186623.6.601.ec9b33e0UqTftw

    踩0 评论0
正在加载, 请稍后...
滑动查看更多