相信很多同学在平时的工作中，一定遇到过一些让你感到“挑战性”的活，有的同学可能一听，没干过，直接放弃，而有的则硬着头皮，迎难而上，最后升职加薪。

最近一个星球球友就遇到了这个问题，他刚入职一家制造业的公司，结果老板就派给他一个“大活”，要他从0到1设计一个大数据系统的实现方案。

既然是方案，这里面就涉及到相关的大数据架构设计、技术选型，集群规模，业务处理等等问题。

大部分同学看到这些要求，再结合曾经的经验，估计瞬间就被唬住了，心想：卧艹，这么难的工作，我水平不行，肯定搞不定，连忙摆手拒绝。

但是你要知道，拒绝这个挑战，也就意味着放弃了一个从普通程序员晋升架构师的绝佳机会，你的这种求稳、保守的心态，很可能就只适合做一名普通开发。

在工作中，很多机遇就是在不经意间出现的，拼的就是一个手快和胆大，都等你准备好了，那机会也早就被人抢走了。

再说，这个事情就那么难吗？

那可真不一定。

想当初，我也还是个普通开发的时候，不也是赶鸭子上架，硬着头皮上嘛，当时我们正在跟一个物流公司谈一个大数据项目，老板对我们几个人说：如果谁能成功拿下这个项目，就分给谁10%的项目奖金。

本来没什么信心的我，一听到居然有钱可以拿，一下子就来了兴趣，于是举手对老板说：我来试试。

其实当时内心慌的一批，因为毕竟从来没有干过这种只有架构师才有资格干的事情，但是既然应承下来了，那咱就算含着泪也要搞定它。

今天这篇文章呢，就来跟你聊一下，从0到1设计一个大数据系统方案，都有哪些可以遵循的套路和技巧。

1. 确定文档结构

想做一名架构师，那写文档的能力咱必须得培养，而且是着重培养，因为这个是你直接面对老板和客户的脸面，只有脸面好看了，才会有接下来的故事。

那像这种项目方案设计的文档，第一步就是定好文档的框架结构，框架结构确定了，这个系统设计要包含的要素也就确定了。

确定文档的结构，就跟你陪女朋友出去旅游，提前做好攻略是一个道理，你们此行的目的是干啥，要去哪些地方，先去哪、后去哪、怎么去，去了之后有哪些安排等等。

那对应的这个文档结构就是：

1. 先来个概述，说说项目背景，当下遇到了什么困难和挑战，现在要做一件什么事情，实现什么目的；

2. 根据要实现的目的，如何将其转化为技术路径，也就是接下来的架构设计，这个呢，也不难，现在的大数据架构，网上大把可以参考的内容，找一个贴近你业务场景的，copy过来改改，就能用；

3. 技术选型，对于这一块，说实话，在绝大部分的公司和项目中，基本上都是写文档的人自己定的，用符合场景的，当下用的最多且你最熟悉的就行，什么POC测试，如果时间紧迫，可以不用考虑；

4. 架构说明部分，根据层级进行展开，之前说过很多次的，不管你多大的大数据系统，全部都可以划分为：数据接入层->数据落地层->数据计算处理层->处理结果存储层->数据服务层->报表展示层。然后对每一层做个阐述；

4. 数据处理部分，架构部分说完了，咱是不是得补充一个数据的处理流程图，根据刚才的那个层级顺序，从数据源开始，数据如何一步步从原始状态，被你一路捣鼓，最后把结果给展现出来的全过程。

5. 集群规模和服务器配置，这部分其实也简单，大概算一下当下接入的数据源流量为多少，估算每天的计算任务量，要存储多久等，集群的规模和服务器配置就能大概算出来。

6. 其他部分，如果你愿意，也可以加入一些其他跟项目有关的阐述，但我觉得，作为一个系统设计的初始版本，以上这些基本上就够了。

2. 细节润色

方案骨架确定了，接下来就是为其填充血肉，将其中的每一个部分用文字，并辅以图片加以说明。

概述部分

作为一般程序员，不喜欢也不太擅长说一些虚头巴脑的文字，那就言简意赅的把业务现状，和遇到的问题描述一下，然后说我们会用大数据手段来解决该问题巴拉巴拉，适当拔高一下，上点价值。

架构设计部分

之前没接触过这块的小伙伴会觉得，这也太难了吧，其实你仔细想想，这个难度在哪呢，大数据技术就那么些，各种所谓的架构图，其实都大差不差，不都是互相借鉴，互相抄袭吗。

你把网上那些花里胡哨的架构图，随便找一幅，拿过来改吧改吧，就能用，你觉得你的老板或者客户能给你挑出什么毛病出来吗。

更多时候，他们也就是看看热闹，看这个图炫不炫酷，用的技术新不新潮，高不高大上，你要能给他们解释清楚，自圆其说，这个就不是什么问题。

再者，谁说实际实现就必须得根据架构设计上画的，丝毫不差的，要知道，理论跟现实永远都有一定距离。

所以，大胆去设计，没你想的那么可怕。

架构说明部分

架构图搞定了，接下来就是对其中的每一个环节进行丰富了。

1. 数据接入：描述清楚数据的接入方式，推还是拉，实时还是离线，接入工具怎么选择，考虑生态兼容性，还是团队熟悉程度等；

2. 数据落地：把数据接入之后，就要想着怎么把数据给“暂存”，或者“备份”起来，那落到哪呢？常见的选择有消息队列，文件系统，离线数仓，或者数据湖方案等；

3. 数据计算：对于当下的开源大数据计算方案来说，主流的计算引擎就那么几种：MR、Tez、Spark、Flink，不同的引擎适用的场景不同，数据处理的特点也不一样，需要你根据实际业务需求，去设计和规划；

4. 结果存储：这里主要涉及到数据库的选择问题，同样的，数据库如何选，取决于你对数据如何使用，对存储规模，查询效率高低、是否支持跨表join、数据修改和删除是否方便、事务特性强不强等方面进行考虑，不同的需求场景，符合要求的数据库就会不一样；

5. 数据服务：这部分现在最流行的，当属spring boot那一套微服务体系了，初期的设计，一个单实例的springboot基本也就可以搞定，大概描述下技术原理，也就差不多了；

6. 报表展示：这部分看你是准备用现成的报表工具呢，还是打算自己来开发，如果用报表工具，那么上面的数据服务可能就不需要了，报表工具直接怼到数据库取数据就可以，如果是自己开发，选择用什么前端技术vue、nodejs还是其他的。

数据处理流程部分

把上面部分捋清楚了，再画一个像模像样的数据处理流程图，再辅以文字说明，讲清楚每一个处理步骤要做什么事情，看着像那么回事就可以了。

集群规模评估部分

根据当下系统的数据源流量，估算出每天存储到系统的原始数据量，再加上经过中间层转换的存储量，最后加上计算结果的存储量，三者合在一起，就是你系统每天需要的存储空间。

然后大致估算每天并发的最大计算任务数量，推算出集群需要的算力，这个过程有些虚，大概判断一下就好了，一般不可能很准的，主要是老板或者客户问起，知道你是有判断依据的，而不是随口胡诌。

最后再看你的集群要存储多久的历史数据，来判断集群的总存储空间，根据总存储空间和估算的算力，最终确定集群的规模。

至于说单台服务器的配置，这个不好定死，需要根据项目的采购商或者云厂商能提供的服务器规格来选择，可以事先打听一下。

其他部分

系统的重点部分写完了，如果你还觉得不过瘾，还可以再加入一些其他跟系统有关的内容，比如数据治理、集群监控、任务调度、DevOps之类的，来丰富你的文档内容。

3. 最后

这个所谓的系统设计，在我看来，最难的不是你不知道怎么写，而是你敢不敢去写。

只要你敢接下这个烫手山芋，那么接下来，你将思考的不再是你会不会的问题，而是想着，我到底怎么样才能完成这个任务。

而一旦你的思维从自己会不会，转变成了要怎么去搞定，这个事情你就成功了一半，因为接下来，你总能找到完成这件事情的办法。

可能有小伙伴会觉得，明明水平不行，却还要硬着头皮往前冲，这么做真的行吗？这不是在欺骗公司，欺骗老板吗？

只能说你想多了，方案设计这种东西，站在老板的层面，就是要你大胆去设计，充分发挥你的想象力。

在真正落地的时候，方案只是参考依据，不一定就要跟现实严丝合缝，毕竟很多业务需求都还没有确定，技术细节也一定会存在诸多值得商榷的地方，后期实施时也一定会有很多的改动。

但这个方案设计，却是你给老板或者客户吃的一颗定心丸，如果你能搞定，那你在老板心中的地位，至少比现在要拔高一个层次。

（PS：如果你有任何相关问题，欢迎加入我的知识星球探讨）