项目架构建议书

最新推荐文章于 2024-09-20 07:53:59 发布

AaronLwx

最新推荐文章于 2024-09-20 07:53:59 发布

阅读量543

点赞数

本文链接：https://blog.csdn.net/xiaoxiongaa0/article/details/89341826

版权

概要

背景

公司要出一款新游戏，技术部需要配合草帽研发开发出跟这款新游戏所对应的BI平台用作数据的统计分析和展示。

目标

围绕该BI平台，提出相应的多种技术架构及实施方案。

问题分析

对于接下来要开发的BI平台，通过研究并分析需求文档，对于一些相关的关键指标如新增账户，ACU，PCU等的实时展示，这些指标如果使用传统的RDBMS，即关系型数据库如MySQL，或者是NoSQL如MongoDB，ElasticSearch等，是可以，但不合适。举个简单的例子，公司LED显示屏实时展示公司的营收，注册用户等指标，就像天猫双十一大促的大屏那样，难道前端页面每隔一段时间去查数据库里面注册用户这张表然后计算出这张表的count？这种方式不是不可以，但不是最优的。对于这样的需求是需要使用到实时计算的相关技术，而这也是传统的RDBMS所不具备的。再补充一点，RDBMS在整个系统的作用更多的是作为计算好的结果存储在RDBMS中。后面再做详细解释。

以现在原厂提供给我们的BI后台为例，表面上来，除了页面的样式，布局稍微丑陋了一点之外，好像该有的

功能指标都能正常显示，但是如果你要查询日期靠后的历史数据，就会发现整个页面直接卡死了，或者需要等待很长的一段时间页面才显示结果。由于涉及到商业数据，就不贴图了。

可以看到，我只是查询订单页面的第10000条数据，大概10秒钟才出结果。根据上图显示，订单的数据可是有273097页，如果我再往后查询，所花费的时间只会比10秒要多。而且当我查询到10000页，订单所在的日期定格在2019-2-2，今天是2019-2-13，再结合订单的总页数，可以推测，273097页的订单数据是不全的，也就是说，系统每隔一段时间可能就会对距离今天时间比较长远的数据进行删除。而当我点击末页按钮想要查询系统数据库保存订单数据的时间跨度时，很遗憾，两分钟过去了，依然没有出来结果。

在这里，我大胆假设该BI系统已经做了数据库的集群，读写分离，分库分表等，这个假设的前提是公司现有的BI系统没有引进大数据的技术，仅仅使用传统的RDBMS作为数据的存储以及在其上进行数据的聚合分析，因为我不清楚它的技术架构是怎样的。如果现有的BI系统没做集群，读写分离，分库分表等，那刚才所提到的几点可以作为优化的点，而且经过优化之后，系统还可以正常稳定的运行一段时间。但是，随着数据量的不断增大，传统的关系型数据库无论怎么优化，处理PB级的数据应该可以到达瓶颈了。当然，你也可以继续把时间长远的历史数据删掉，这种拆东墙补西墙的做法治标不治本。但最重要的是，像订单这类的数据，即使是时间长远，也还是有它一定的价值。只是我们没有好好的利用，准确来说，我们还没有意识去利用好这些历史数据。

还存在一种可能，历史长远的数据并没有删除，而是同步到另外的服务器上去了，如果是这样，数据至少保存下来了，但这种方式对运维的要求很高。但据我了解，技术部SDK那边就是通过把时间长远的数据给直接干掉。如果你一直强调RDBMS没有问题，OK，顺着你的思路，存储是可以的，但是如果涉及到数据的聚合分析，挖掘等，要在这么大的数据量上做这些操作，其效率可想而知。

总结

传统的RDBMS满足不了实时计算，流处理等需求。
传统的RDBMS存储的数据量有限。
尊重数据，充分利用已有的数据，让数据为公司创造价值。

方案综述

目的

随着公司的日益壮大，游戏质量越来越高，吸引的玩家自然也越来越多，流量、PV、UV等不断上升，所有的这些都直接或间接的对公司现有系统对数据的处理能力提出了挑战，而现实情况是，通过上面的问题分析模块，我们知道公司整体对现有数据的处理能力可能已经到达瓶颈，或者说已经满足不了需求，简单来说现在公司发展的矛盾之一就是人民日益增长的物质文化需要同落后的社会生产之间的矛盾，可能说的有点夸张，但从另外一个角度来看，如果我们能够充分利用好数据所带给我们的价值，比如说根据我们提供的数据分析结果，运营部门可以进行活动策划的调整，市场部门可以调整各个渠道资金的投放比例，公司上层可以调整公司战略方针等等。说了那么多，现在这个时候正是引入大数据的各项技术非常好的timing。

TODO: 大数据介绍

TODO: Hadoop生态圈各个组件的介绍

关于Hadoop生态圈的相关介绍暂时不赘述了。后面这部分的内容我再补回来。下面直入主题。

方案

关于方案这一part，我会从以下几个点进行阐述，内容包括我之前的解决方案，强哥的解决方案，我的解决方案，结合阿里云的解决方案。

首先看一下我之前的方案，这张图是从项目编号为123-4567的建议书截取过来的，那时主要为了推ELK这个技术。现在关于日志收集这一块，我们可以直接使用阿里云日志服务来替换掉。当时关于实时流处理这一部分，xx提出了使用Kafka Streams来进行处理，现在可以使用Spark Streaming替换掉。
再来看结合大数据的一个方案，引进Spark生态圈。我们先来看一下数据离线处理的流程
1. 数据采集，可以采用ELK，Flume，Fluentd等，或者阿里云的日志服务，自带日志收集功能
2. 数据清洗可以使用Spark，Hive， MapReduce或者其他的分布式计算框架进行数据的清洗，清洗完之后的数据可以存放在HDFS，HBase等，使用Hive或Spark SQL进行查询
3. 数据处理可以使用Spark，Hive， MapReduce或者其他分布式计算框架
4. 处理结果入库结果可以存放到RDBMS NoSQL里面，通过前端界面可视化展示

从以上数据处理的5个流程来看，数据清洗和数据处理这两个步骤均可以使用Spark来进行处理。这里的Spark指的是Spark生态圈里的各个组件，其中Spark SQL可以负责数据的清洗和数据处理，查询等工作。对于有实时性要求比较高的需求我们可以使用Spark Streaming来解决。这里需要说明一点，Hadoop是一个分布式存储系统+分布式计算系统，Spark只是一个分布式计算框架。两者其实是相辅相成，不是说使用了Hadoop生态圈就没有Spark什么事。Spark可以替换Hadoop的MapReduce分布式计算框架来提升整个系统的计算性能以及运行效率。

从上面这幅从Spark的官网截取的图来看，Spark替换掉Hadoop的MapReduce计算框架之后，运算速度提上了了100倍以上。所以，我们可以使用Hadoop + Spark的组合，使用Spark替换MapReduce。对于实时性要求不高的需求，可以离线批处理，对于实时性要求较高的需求可以使用Spark Streaming。可以说我们可以使用Spark生态圈的各个组件来处理大数据领域的大多数事情，而以往的解决方案是Hadoop生态圈专门针对实时性不高的离线批处理，对于实时性计算要求高的需求还需要额外引进像Storm，Flink这样的实时流处理框架。Spark，一个大一统的技术栈，既可以做离线批处理，又可以做实时流处理。当然Spark还可以做机器学习和图形计算，由于暂时用不着，这里就不说了。而且Spark还提供了基于Python，Java，Scala和SQL的简单易用的API以及内建丰富的程序库。下面来看看使用Spark的架构图。

再来看一下强哥的方案。年会那天我跟强哥聊了一下，他们那边是使用Kafka收集MySQL中binlog日志。通过网上查资料，我猜测强哥应该是这样实现的，阿里云的Kafka上面有一个叫Connect的服务，在这个服务上运行一个Connector，这个Connector是实现从数据源读写数据的。而Debezium提供了一个MySQL Connector插件。这里有很多英文，不理解不用管，我们只要知道，只要安装了这个插件，MySQL的binlog日志就可以流到Kafka那里了。假设我们已经做好了这些前置工作，当我们在MySQL中创建了一张表，Kafka就会自动的创建一个跟这张表对应的topic，当我们对表中的数据进行CRUD，这个topic就会产生相应的数据。接着可以通过编写相应的Java代码去消费这些数据。强哥的这个方案用来做实时流处理是没有问题的，只要数据库有增删改查操作，Kafka马上就能收集到binlog日志，下游的Java客户端就可以准实时的去消费，计算。强哥的方案解决了数据的实时性处理问题。但数据量的问题通过这种方式还是不能解决，这种方案依然是围绕MySQL做数据的存储，如果数据增长到MySQL所能承受的最大量，MySQL里面的历史长远数据还是得要删才能继续正常对外服务。当然，现在Kafka里面已经有了binlog的日志，如果想恢复删除掉的数据，可以通过binlog来恢复，这种方式是可行的，但是操作起来应该不简单，具体实施细节我没有过多研究，就不发表言论了。当然，那个时候跟强哥聊的时候大家没有提到他这个方案数据的存储方式，也许强哥也有考虑到了这个问题。因为实时的流处理是一个方面，其实BI后台有不少的需求不需要实时性那么高的，这些数据是可以离线批处理的，简单来说就是在晚上某个时刻去计算这些指标，哪怕是这些指标的计算需要花几个小时也没关系，只要在上班之前给我都计算好了就行。当然，上面所说的有不少是我的猜测，具体的还是需要问问强哥。
再来看一下数数科技他们是怎么做的。下面两张图是从数数科技给到的产品文档里面截取的。他们的产品ThinkingGame是类似于TalkingData的产品。从他们的架构图我们可以看到在数据缓冲层中，他们使用Kafka作为收集过来的日志的缓冲区，在数据持久层他们使用了Kudu和HDFS。Kudu是一个既支持随机读写、又支持 OLAP 分析的大数据存储引擎。我们知道HDFS分布式存储系统数据无法进行随机的读写，但是适用于大数据的离线批处理场景。以 HBase、Cassandra 作为存储引擎，适用于大数据随机读写场景。这类存储的局限性是批量读取吞吐量远不如 HDFS，但不适用于批量数据分析的场景。而Kudu就是两个存储引擎的折中，既支持数据的随机读写，有支持大数据的离线批处理等OLAP分析的场景。但我猜测数数科技使用Kudu主要是为了支持数据的随机读写，因为Kudu后面还把数据同步到HDFS中，大部分的离线批处理应该还是在HDFS上去做。Presto就是类似于HIve和Spark SQL这么一个东西。所以数数科技的技术架构中的Presto集群其实是完全可以使用Spark SQL来替换，然后再增加Spark Streaming做实时流处理，就是方案二了。

下面来看看使用阿里云的方案。首先看一下阿里云官网上的两张张图。第一张图是墨迹天气大数据分析的架构图。其实我们可能所使用到的也就是日志服务，DataWorks(MaxCompute)，DataHub，E-MapReduce，RDS等，有可能后面会使用到DataV这个可视化组件。而使用阿里云的产品，可用的产品组合也不少。首先日志服务是毋庸置疑的。收集到的日志全部导进日志服务里头。日志服务里面有个功能，可用把收集到的日志投递到MaxCompute里面，MaxCompute你可以简单理解为Hadoop生态圈，用阿里云官方的话来说，MaxCompute服务于批量结构化数据的存储和计算，提供海量数据仓库的解决方案及分析建模服务，其实就是Hadoop里面的分布式存储+分布式计算。所以日志服务+MaxCompute就解决了数据的离线批处理。对于实时流处理，阿里云其实提供了两种解决方案，第一种就是通过使用E-MapReduce，第二种就是使用阿里云的实时计算。我稍微解释一下这两者的区别，E-MapReduce包括Hadoop、Spark、Kafka、Flink、Storm等组件，而阿里云的实时计算其实就是Flink。两者都可以从日志服务那里消费数据。第二张图是阿里云实时计算的一个企业方案的架构图。

从中我们可以发现，上面的架构去掉了实时计算，应该就是强哥的架构了。总结一下这两种方案：

日志服务 + DataWorks(MaxCompute) + E-MapReduce
日志服务 + DataWorks(MaxCompute) + 阿里云实时计算

如果在阿里云的基础上结合方案二，那就是采用日志服务 + DataWorks(MaxCompute) + E-MapReduce这种方式。

总结

上面说了好几种方案，其实最终采取哪种方案已经不重要，最重要的是现在正是公司引入大数据的比较合适的一个timing。当然，这个过程非常艰辛，而且还有很多不确定的因素。下面我简单说一下。

首先，据我所观察，公司比较缺大数据方面的人才，更不要说我们运维部了。运维部应该除了博哥之外，了解大数据的小伙伴应该没有。技术部那边，上次在跟强哥聊天的过程中，强哥也说之所以没选大数据相关的框架，而选择使用Kafka做流处理，也是因为部门里面缺少有大数据相关经验的人。上次跟博哥的交谈中，博哥也提到过招人的成本。
大数据所涵盖的东西实在太多。一个Hadoop生态圈，一个Spark生态圈，还有其他像Storm，Flink等等这些流式处理框架，每一个框架都在整个大数据领域扮演重要的角色。而我这篇建议书由于时间关系，有很多大数据的组件没有做过多的介绍，甚至没提到，是因为上面所说的那些组件已经可以比较好的解决我们BI平台的各种需求和问题，也够折腾一段时间了。
站在运维部本部门的角度，熟悉Java开发的小伙伴应该比较少。大数据这个领域是Java的天下，要想使用好Spark，Flink这些框架，还需要额外掌握Scala，因为Spark，Flink还有Kafka就是使用Scala来写的。虽然Spark对Python的支持也是比较好的，但是有一些数据集如DataSet，Python也是不支持的，当然可以使用DataFrame来替代，一般也是推荐使用DataFrame。但无论怎样，Java和Scala是绕过的，虽然Java不是我们的强项，如果要深入大数据肯定会比技术部要走更长的路，但语言不是阻碍，不熟悉就额外花时间学。

上面所说到的三点，每一点都是需要解决的。但其中很多都是可以曲线救国。比如说使用阿里云的大数据服务。阿里云的大数据服务为我们解决了很多的问题，不仅仅为我们提供了大数据开发的环境（上面所提到的开源软件，阿里云基本都有提供，并做了很好的集成），而且大大降低了运维成本，让我们更加专注于业务逻辑的实现。当然，阿里云的这些服务也是需要money的。但从长远来看，物超所值。关于大数据人才方面，如果觉得现在还不是引进大数据的合适时机，那我们现在可以着手准备，待时机成熟，就可以马上投入大数据的研发当中去。由于时间关系，关于大数据的一些基础知识，我并没有在这篇文章中涉及到，只是在相应的地方打了个TODO。还有，虽然我使用过阿里云的这些大数据服务，像日志服务、DataWorks(MaxCompute)、E-MapReduce，并按照官方提供的例子做了测试并成功运行得到相应结果，但是还没有结合项目的需求计算需求里面的几个指标，刚才所提到的两点我都会在后面补充完整，最后，感谢阅读！