6.腾讯云EMR-需求及架构-技术选型原创

好，那接下来呢，我们就针对于刚才的四个问题逐一进行解答啊，首先第一个技术选型问题。哦。呃，那在我们。整个项目的过程当中，我们会涉及到采集、计算、存储、展示、调度、可视化等等各种各样的一些组件，对吧？那我们到底需要用到哪些，不需要用到哪些呢？我们用红色跟黑色分别进行表示，也就是说红色在本项目当中所涉及到的啊好，那我们来看一下。啊，我们主要考虑因素有数量大小对吧，业务需求，行业经验，技术的成熟度啊，开发维护成本，总成本预算，其实还有一个很重要点。公司当中开发人员的技术水平。比如说。我们公司团队对flink他不熟悉，就没有人能够站出来说我可以把这个搞定，但是有两个人两个同志对吧？他呢对Spark streaming非常熟性，那也会影响到我们的技术水性，他可能最后呢就会采用到我们的Spark streaming，所以呢还是技多不压身，都掌握一些，未来我们在抉择的时候也会更。

有更大的选择的空间，对不对？好，那接下来我们看第一个数据的采集，我们是要将MYSO中变化的数据实时的采集过来。对吧，那我们传统的采集框架有哪些呢？比如说弗CDC data叉。Losttech。对吧，那我们很明显要做到什么事，实时的采集由MYS中产生的这种变化数据，新增修改以及删除的数据，那面我们得需要用到一个CDC，可以动态的捕获，那弗CDC是最优的啊，那我们将数据采集呢，放到了。

卡夫卡啊，因为我们为什么选择卡夫卡呢？那我们思考一个问题，我们到了ods层以后，我们数据是不是还要进行一个输出。对不对，我们还要再进行一个把它拆分成明细，就算到了明细数据层，我们还要继续对数据进行一个加工。对吧，所以呢，我们用一个消息队列，在这个时候呢是最好，而卡夫卡呢，它作为阿巴奇的一个顶级框架，对吧，那是非常好用的一个消息队列，且它可以有集群，我们可以多病动提高我们的吞吐量啊。在我们数据。非常数据量非常大的时候，也可以正常的使用，保证我们任务正常的运行啊，这是第一个数据的采集好，那么第二块关于数据的存储。

那首先业务数据呢，我们选择的MYSQL啊呃，大数据这边呢，选择的HDFS以及。以及h base对吧？啊，那咱们其实也可以引入啊，后期呢我们再聊啊，那呃，用h base这块做什么事呢？我们思考一个问题，我们将数据呢存到了卡夫卡，那么对于我们的数据而言，我在这儿给大家浅聊一下，因为后面到了真正建模的时候，还会详细的去说这个事儿，因为现在呢说有同学呢，可能不太理解啊，能听懂的就听，听不懂的呢先。过稿时好吧，到后期我们聊的时候再回过头来想一想这个问题，呃，因为我们整个的数据呢，分为这个事实表，事实数据和这个维度数据。那比如说我们的商品。啊，用户像这样的数据呢，我们把它称为叫。

维度数据好，那我们一个用户下了一个订单，针对于某一件商品下了一个订单以后。我们要对这个订单进行一个分析，诶可能未来统计某一个商品。他的整个销售的排行榜。对吧，那这就涉及到我们需要去关联维表信息。好，那大家思考一个问题，那我比如说这个商品呢，是三年前上架的，我一直没有下架，那我今天还能不能够进行购买。答案是肯定的，当然可以购买好，那如果按照我们之前所聊，我们将数据呢，所有数据都放到卡夫卡。呃，那么你今天对这个商品下的订单，你在卡卡当中还能不能得到三年前的数据呢？

显然不能，那有同学说我将卡夫卡的数据呢，我把时间修改一下，修改成三年。那你觉得我们会对一个消息队列说，让他存三年的数据吗？对吧？好，再话说回来，假如真的存了三年，那我买的是18号商品，你在卡卡当中好定位18号商品，卡夫卡是不是直接可以消费最新的数据啊，但是他很难做到的一件事是什么呢？在里边精准定位到某一条数据。去消费，那个是我可以根据offet，但是18这个数据它不一定是offset是什么对吧，所以呢，对于微表数据，很明显我们需要一个永久存储的框架A，而且呢，方便我们。大数据这边去使用，那你才能想到，既然你是实时，那我很明显用可能更合适啊，对吧，那大家要思考一个问题，我们的用户表。

用户表的数据量呢是非常大的，如果我们直接采用ready作为我们维表的存储，那么势必会要很大的一个集群，而是一个内存数据库，它对于我们成本就要求比较高了，所以这个时候呢，我们可以选择HP结合Phoenix来使用，诶同样的来通过S的方式来进行一个查询，这样呢未来我们使用也很方便，效率呢也不至于特别的低，当然肯定比red效率要低一些的，对吧？这是我们关于数据存储的一个点啊，那么接下来数据计算啊，这个我们已经提到了，因为我们要做的是这个实时计算啊。呃，那这里边选择呢，就是Spark streaming，或者说Li，当然还有stop，当然现在在生场环境当中，Storm已经慢慢的去淘汰的地步了，使用到的公司呢，很少了啊，那现在呢，弗Li格是相对来说很火的一个实时计算框架，而本次项目当中呢，我们就用的是。

Flink来做的计算啊呃，那下面数据查询。就最终我们的DWS层，我们是一些大宽表聚合的大宽表对吧，那我们选用的是cleanhouse。选择它的原因呢，在于第一呢，是一个列存，他擅长于做一些。聚合逻辑的查询，第二，由于我们DWS层是一些宽表，也就未来呢，更多的时候做的是单表查询，从DWS，而我们的克雷house单表查询的效率非常高，所以在这个地方呢，基于种种情况我们选择了克house，那其实还有其他的框架，像psal kly inla、德鲁伊，还有Doris，那这些东西呢都可以啊，当然其中有一些是用的是这种离线的查询，可能会更方便一点啊，那这边呢，我们用的是科林号，更符合我们生产环境当中的一个实时出仓的应用场景，好，那这是我们最基本的模块，那其他我们拔高的一些有哪些呢？啊，首先数据的可视化。

那我们采用的是sugar，那除此之外啊，你像super set1你也可以自己去写，还有这个sugar，对吧，我们也可以用到这样的一个工具啊，帮助我们可以不用自己去做这个数据的开发啊呃，任务的调度，像这个dophin，海豚调度器，阿斯卡班oy alalo，那由于我们是实时数仓，其实我们不太能用到这个任务的调度，并不像离线输仓，离线输仓里边有的需求，我们可能每天或者每周或者每个月我们都需要去运行，对吧？那这个时候呢，可能我们需要一些任务调度的框架，让他每天去执行一下啊呃，最后呢，我们集群的监控有扎比斯，还有这个普罗米修斯，诶对我们任务呢，做了一个监控啊，相应的在我们上硅谷的官网上面，这些框架都是有的啊，最后呢，原数据的管理outlets对吧，那这个也是在离线当中用的，相对来说会更多一些。

点啊呃，那我们本次项目当中呢，只是用到了这里边儿标红的部分，那也就说其他的框架我也想学习怎么办呢？那呃，可以在B站搜索上硅谷大数据。啊，那所有的资料呢，都是免费提供给到大家的啊，当然了还有完整的这个整个项目。啊，也在我们的B站上面可以提供个给大家的，OK吧，好，这是我们关于技术的选型，当然这里边儿到时候我们还会具体的再具体一点给大家去分析，我们为什么要用到这些个框架，它对比于其他框架有什么优点，现在呢，由于大家可能都框架之间还有其他框架呢，不是那么熟悉，所以呢，我们现在只是听一听啊，而且框架涉及到特别特别的多啊，大家说已经晕了，那怎么会有这么多的框架对吧？啊，那这个在我们上硅谷的课程当中，体系当中都是有所涉及的啊。

好，最后还有一个权限管理啊，其实对于一个中小公司呢，一般是不做这个权限管理的啊。