分布式与集群的区别
发布时间：2022-10-26 10:41:50 所属栏目：云计算 来源：
导读： CSDN: 请您简要介绍一下本次HBTC2012大会上的议题的内容。
代志远：06年Google发表论文Bigtable，社区随之出现HBase，后Google 08年发表第二代数据库产品MegaStore至今未有社区同类产品出现，现今Google
代志远：06年Google发表论文Bigtable，社区随之出现HBase，后Google 08年发表第二代数据库产品MegaStore至今未有社区同类产品出现，现今Google
|
CSDN: 请您简要介绍一下本次HBTC2012大会上的议题的内容。 代志远：06年Google发表论文Bigtable，社区随之出现HBase，后Google 08年发表第二代数据库产品MegaStore至今未有社区同类产品出现，现今Google又出现新一代数据库理论Spanner和F1。 而最近几年随之Bigtable和NoSQL的兴起，社区产品HBase逐步走向NoSQL系统的主流产品，优势明显然而缺点也明显，大数据平台下的业务由SQL向NoSQL的迁移比较复杂而应用人员学习成本颇高，并且无法支持事务和多维索引，使得许多业务无法享用来自NoSQL系统中线性拓展能力。 Google内部MegaStore就作为Bigtable的一个补充而出现，在Bigtable的上层支持了SQL，事务、索引、跨机房灾备，并成为大名鼎鼎的Gmail、Google App Engine、Android Market的底层存储。因此我们决定以MegaStore为理论模型进行探索如何在HBase系统上不牺牲线性拓展能力，同时又能提供跨行事务、索引、SQL的功能。 HBase系统故障恢复的优化实践 其实在第四届中国云计算大会上，当时还在支付宝数据平台的架构师代志远就为大家带来了题为“HBase系统故障恢复的优化实践分享”的精彩演讲，他分析了支付宝海量数据在线处理的现状，以HBase解决方案取代传统MySQL解决方案的技术历程，并详尽分享了Region Server的宕机恢复流程（阅读全文）。 在Hadoop的体系当中，支持实时的一条线，HBase，支持海量数据库初衷的时候，设计为了设计万一级实时数据库，HBase这个东西经过这几年的发展，已经逐渐成为目前业界当中主要的实时数据库，分布式数据库，像支付宝直接上HBase系统，就是考虑到HBase的先进架构，能够帮助支付宝完成现在很多的海量数据的存储以及在线随机读写高性能的访问和存储。 不过在HBase的系统当中，体现它的可用性有几个风险。第一个是HBase本身在底层依赖的HDFS，加载了唯一一块数据，单台机器保证一致性，HDFS保持了冗余。第二点，恢复过程当中，Failover过程非常复杂，这个时间消耗越长，作为在线系统，这种时间越长可能会影响到在线访问用户体验。第三点它依赖的HDFS，HBase作为在线数据库依赖HDFS有故障的，经过几小时恢复提供生产业务，对业务方没有直接感受，作为在线系统如果挂掉，如果需要经过近小时恢复时间，恐怕就会直接收到自于支付宝外部的用户投诉了。HBase目前它自己的监控体系尚不完善，目前的监控力度非常得粗，只能监控到单台的Region Server的情况，看不到当前用户表有多少读写比例，看不到当前服务结点写作量多少，读出量多少。 Region Server在恢复过程当中有几个流程，这个流程很复杂，流程非常非常多，以当前的系统规模，它凸显出来的问题，这几个流程是影响到它的恢复速度的关键流程。等待时间周期非常长，周期之所以比较长，是因为现在的机器发展速度非常得快，每台机器从两个G到8个G，96G，140G的大层次的机器，Java语言实现了系统当中大内存管理本身存在问题，除非革新这门语言，否则别无他法。如果说在设计的参数不合理，就可能会导致一个问题，有可能这台服务器就会停止运行，发生这么一次情况就非常可怕，几十G的内存这个过程需要几十秒甚至上分钟，通常情况下，我们会设置到3分钟，这就意味着，为了避免出现这种问题，就会同时引入新的问题，宕机之后恢复等待时间需要三分钟。第二个关键流程当中，当它感知到已经挂掉了，在线数据库协助WL数据重新做到存储当中去，以保证实时更新是同步，否则这个数据库肯定要丢出去，重做数据过程当中，会有一个过程，Split Hlog，跟当前数据量有关系，Edit Log数据又比较多，大家在业余时间可以进行测试，数据不以支付宝的为准，以当前数据系统大小为准。 第三个关键流程云计算分布式，重做完数据之后，这部分重新上线，上线之前进行数据进行二次扫描，告诉系统，Region怎么加入到Region Server当中去，扫描也存在问题，问题可能引发到两分钟到6分钟，这也跟当前系统数据有关。第四部分，这个过程称之为再次上线的过程，这个再次上线，上线时间跟当前这台机器的Region上线有关系。支付宝面对消费记录查询，用户查不出来数据，15分钟之后才能查到，在面临在线问题上这是非常可怕的事情。 针对Region Server这一关键流程，做了一些优化。这个优化正是提到关键流程第一点，在判断宕机超市的情况下，不强依赖于Zookeeper，支付宝又启动了监控进程Mirror Process，每一台，Region Server当中都会起到PID存不存在，这种检查并非完全可靠，当检查PID不存在，就有理由认为已经挂掉了，要进行可靠检查，通常DBA在线判断数据库是否可用，通常会用PIng连续服务端口，这就弥补了系动中的调用命令不可靠的事情。最后当发现服务端口不可用时，有理由认为当前进程已经死掉了，死掉了之后，那么就按照现有逻辑删除结点，这三分钟的时间就完全省略掉了。 （编辑：草根网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐
浙公网安备 33038102330471号