hbase 二级索引有哪些 字节跳动2-2需要几年的工作经验？
字节跳动2-2需要几年的工作经验？
百度投资2-2不需要5年的工作经验。字节跳动的发展越来越快，可能导致想再次进入腾讯的应届生越来越密集，竞争越来越大，所以字节跳动的面试也越来越难。这对普通本科世家出身的我，不得不说是一项挑战，而这项挑战是否可以成功的关键，就本质如何确定能坚持，有无做到了充足的准备。要知道，是对技术人员来说，技能水平比起比学历水平更重要。
如何设计每秒十万查询的高并发架构？
是需要回顾曾经下，整个架构右侧部分发展演进到的那个程度，其实早的很的确实不错了，而且百亿流量，最大速度十万级并发写入文件的场景，可以使用MQ人员限流削峰、分布式数据KV集群给抗住了。接着使用了算出与储存只是分离的架构，每个Slave可以计算节点会全权负责其他提取数据到内存中，基于条件自研的SQL内存算出引擎成功可以计算。同时采用了数据动静分离的架构，静态动态数据全部缓存，代码数据自动出现提纯，可以保证了尽很有可能把网络跪请开销降低到不超过。
另外，按照自研的分布式系统架构，以及数据分片和计算任务分布式执行、具有弹性资源调度、分布式高容错机制、主备智能切换机制，都能可以保证整套系统的横竖斜按需内存量，低功耗、高可用的的运行。
然后再，咱们得来研究去研究架构里左侧的部分了。
二、日渐兴盛膨胀起来的自动更新计算结果
其实大家会注意一点到，在左侧也有一个MySQL，那个MySQL就是利用唤起实时计算结果和自动更新计算出结果放在旁边里面汇总表格的。
终端的商家用户就是可以随手的查询MySQL里的数据分析结果，勉力支撑自己的决策，他也可以看当天的数据分析报告，也是可以看历史上任何一段时期内的数据分析报告。
但是那个MySQL在早期很有可能而且不少，只不过总之存放在这个MySQL里的数据量低些要小那些，况且是计算后的一些结果罢了吧。但是到了中后期，这个MySQL不过也风雨飘摇了。
给大家举一个例子，离线模式计算链路里，要是每天增量数据是1000万，那你每天换算完以后的结果至少唯有50万，早上50万新增数据放进去MySQL，其实我还是是可以进行的。
不过要是每天晚上增量数据是10亿，那么每天算出完以后的结果大致会是千万级，你是可以算他是计算结果有5000万条数据吧，每隔一天5000万增量数据中写入左侧的MySQL中，你觉着是啥感觉？
这个可以给大家说哈系统当时的情况，基本是是，单台MySQL服务器的磁盘存储空间迅速就要接近满掉，但是单表数据量都是几亿、甚至十亿的级别。
这种量级的单表数据量，你感觉用户网上查询数据分析报告的时候，亲身体验能好么？基本上当时一次可以查询大都几秒钟的级别。很慢。
殊不知，会出现过用户一次可以查询要十秒的级别，甚至于几十秒，上分钟的级别。很立刻崩溃，用户体验很差，仍旧达将近不收费产品的级别。
所以解决的办法了右侧的存储和计算出的问题之后，左侧的网上查询的问题也迫在眉睫。新一轮的重构，刻不容缓！
三、分库分表读写分离
首先应该是老把戏，分库分表读写分离，这个基本上是基于条件MySQL的架构中，必经之路了，不过率先实施下来难度不是什么最重要的的高，不过速度较快，效果比较比较作用效果。
整个的思路和之前第一篇文章（《大型系统架构演进之如何支撑百亿级数据的存储与计算》）讲的基本都一致。
说白了，那就是分库后，每台主库这个可以承载部分中写入压力，单库的写并发会降底；主要是单个主库的磁盘空间这个可以减低负载的数据量，不再说一下子就满了；
而分表之后，单个数据表的数据量可以降低到百万级别，这个是支撑海量数据包括能保证低功耗的最佳实践，基本是两三百万的单表数据量级应该合算的。
然后再读写分离之后，就可以将单库的读写负载压力分离到主库和从库多台机器上去，主库就容纳写电源输出，从库就支撑起读电源输出，那样的话尽量避免单库处机器的读写负载温度过高，会造成CPU负载、IO负载端、网络负载过高时，之后搞得数据库机器宕机。
简单这么说重构下数据库层面的架构之后，效果就好的多了。毕竟单表数据量减少了，这样的话用户去查询的性能我得到不大的提升，基本上也可以达到1秒以内的效果。
四、最大速度10万可以查询的高并发挑战
上面那套进一步的分库分表读写分离的架构倒是勉强支撑了一段时间，可是慢慢的的那套架构又被人发现不出来了弊端不出来了，因为商家用户也是开了数据分析页面之后，页面上有js脚本会每隔几秒钟就发送中一次只是请求到后端来读取最新的数据分析结果。
此时就有一个问题了，逐渐的查询MySQL的压力越来越大，大部分可预见的范围是朝着速度1010级别去走。
可是我们总结了再看看，其实99%的查询，全是页面JS脚本不自动能发出重新登陆当日数据的查询。只能1%的查询是针对昨天以前的历史数据，用户半自动指定你网上查询范围听说后来查询的。
但是现在的这个架构之下，我们是把当日实时数据计算出结果（代表了热数据）和历史不联网换算结果（贞洁戒了冷数据）都放在一起的，所以才大家也可以预料下，热数据和冷数据放在在一起，然后再对热数据的高并发去查询占到了99%，那这样的架构还合理吗？
当然不合理，我们不需要再一次全面重构软件架构。
五、数据的冷热分离的过程架构
是对本案所涉提到的问题，很明显再做的一个架构重构那是热和冷数据只是分离。也就是说，将今日实时计算出的热数据装在一个MySQL集群里，将自动更新计算不出来的冷数据放在另外一个MySQL集群里。
后再开发一个数据网站查询平台，整体封装底层的多个MySQL集群，根据去查询条件动态路由到热数据存储也可以是冷数据存储。
实际这个步骤的重构，我们就可以不有效的将热数据存储中单表的数据量会降低到更少更少，有的单表数据量很可能就几十万，毕竟将离线模式可以计算的大量数据结果从表里剥离回去了，扔到另外一个集群里去。此时大家可以想象得出，效果当然了是好了。
只不过热数据的单表数据量会减少了很多，当时的一个最明显的效果，应该是用户99%的查询大都是对热数据存储发动攻击的，性能从那个的1秒左右减低到了200毫秒以内，用户体验提升到，大家觉得更合适了。
六、自研ElasticsearchHBase纯内存的查询引擎
微服务化到这里，看起来好像好象还不错，但不过问题我还是很多。是因为到了这个阶段，系统碰上另一个特有相当严重的问题：冷数据存储，如果不是完全用MySQL来容纳是很不可靠的。冷数据的数据量是日增长不时提升，不过增速迅速，每隔一天都再新增几千万。
因此你的MySQL服务器将是面临不停的需要容量扩展的问题，但是如果不是是为勉强支撑这1%的冷数据查询只是请求，不停的扩容提高高配置的MySQL服务器，大家总觉得靠谱么？
肯定是不合适的！
要明白了，大量分库分表后，MySQL大量的库和表维护出声是蛮麻烦您的，修改个字段？加个索引？这都是场麻烦的话事儿。
当然了，是因为对冷数据的查询，一般全是因为大量数据的查询，比如说用户会你选择过去几个月，甚至还一年的数据通过分析查询，此时如果不是纯用MySQL肯定挺灾难性的。
是因为当时很明显突然发现，因为海量数据场景下，在一瞬间去查询分析几个月的或几年的数据，性能是极差的，那就容易搞成十几秒甚至连几十秒才出结果。
但针对这个冷数据的存储和可以查询的问题，我们终于你选择了自研一套基于组件NoSQL来存储，然后基于组件NoSQL内存的SQL计算引擎。
具体来说，我们会将冷数据所有采用ESHBase来并且存储，ES中比较多能保存要对冷数据进行再筛选的各种条件索引，比如日期在内各种维度的数据，接着HBase中会储存时全量的数据字段。
因为ES和HBase的原生SQL支持都不是太好，所以我们真接自研了另外一套SQL引擎，拿来支持什么这种特定的事件的场景，是基本上就没多表关联，是对单个数据集进行查询和分析，后再允许NoSQL存储内存计算。
这里有一个先决条件，那就是如果没有要可以做到对冷数据彻底是单表类的数据集查询，必须要在冷数据刚刚进入NoSQL存储文件的时候，完全实现ES和HBase的特性能做到多表验收入库关联，进数据存储就完全可以做成大宽表的状态，将数据关联全部上推到出库时能够完成，而不是在查询时参与。
对冷数据的查询，我们自研的SQL引擎是需要会依据什么各种where条件先走ES的分布式集高性能索引网上查询，ES是可以根据海量数据高性能的检索进去要的那部分数据，这个过程用ES做是最比较好的。
紧接着那是将检索出的数据不对应的完整的各个数据字段，从HBase里再提取出去，拼接成能够完成的数据。
然后再就是将这份数据集放在旁边内存里，通过急切的函数计算、分组聚合在内排序等你操作。
本案所涉操作，所有基于条件自研的针对这个场景的查询引擎能够完成，底层基于条件Elasticsearch、HBase、纯内存来实现程序。
七、实时地数据存储引入缓存集群
好了，到此为止，冷数据的海量数据存储、低功耗网站查询的问题，就能解决了。紧接着回过头来来去看看当日实时数据的查询，反正实时数据的每日算出结果不会太，但中写入并发不会最重要的特别的高，每秒上万也就也差不多了。
因此这个背景下，就是用MySQL分库分表来支撑数据的写入、存储和查询，都没有问题。
可是有一个小问题，是说每个商家的实时数据不过不是正常的变更的，在一段时间内，很可能压根就不知道没变化，因此不要高并发请求，每秒10万级别的全部落地之前到数据库层面吧？要都落地到数据库层面，那可能要给每个主库武器挂载很多从库来抵挡高并发读。
并且这里我们化入了一个缓存集群，实时数据你每次没更新后读取的时候，是写数据库集群同样的还写缓存集群的，是双写的。
然后把可以查询的时候是优先于从缓存集群来走，此时大部分90%以上的高并发网上查询都走缓存集群了，接着只有一10%的查询会落地之前到数据库集群。
八、阶段性总结
完了，到此结束吧，这个架构基本上左边也都重新架构后：
热数据设计和实现缓存集群数据库集群来承载高并发的每秒十万级别的查询冷数据实现ESHBase内存算出的自研去查询引擎来勉力支撑海量数据存储在内低功耗网站查询。经实践，整个效果非常的好。用户对热数据的查询基本多是几十毫秒的响应速度，对冷数据的查询都差不多大都200毫秒以内的响应速度。
九、下一阶段的展望
不过微服务化到这里巳经很不容易了，毕竟本是这样几张图，里面比较复杂到无数的细节和技术方案的落地，要一个团队需要时间至多1年的时间才能你做到这个程度。
不过接下来的事情，我们要对付的，就是高可用的问题，因为需要付费级的产品，我们可以要能保证高就的可用性，99.99%的可用性，甚至是99.999%的可用性。
但是越是奇怪的系统，越不容易又出现问题，对应的高可用架构就越是奇怪到极点
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
