如何搭建一套大数据系统？

由于工作关系，我从原来的数据库开发转变身份到 2c 的公司搭建大数据系统。经过一段时间的磨合，对如何搭建大数据系统有了更深入的理解。

在文章的一开头，太可研究所（techinstitute）不得不声明下，不同公司的 Data 部门都有自己的特殊性，同时受限于经验，也很难用一篇文章解决全部的场景……所以这不是一个技术选型的文章！属于结合自身经验写的一篇感悟，想看各个技术对比的朋友可以再等等。同时，数据方向的工种很多详见之前的文章 Data 领域分工及避坑指南，看这一篇就够了！

本文的侧重点是数据平台和数据引擎的建设，为 Data Engineer 和 Data Analyst 们提供更好用的工具。

Vol.1

首先，先做规划再干活。作为一个数据平台的建设者，一上来不是直接开干，而是要先分析公司内部的基建情况、团队构成、数据的复杂度、使用场景，这些因素对技术选型有着至关重要的影响。例如：如果数据量很小，选择简洁的架构即可；如果团队没几个人，选择云厂商的 SaaS 服务更有性价比；如果整体的基建使用的是云原生架构，那么 Hadoop 就不应该是第一选项。此外，数据平台不是一个一蹴而就静止不变的系统，会随着技术的迭代、数据量的变化、业务的演进以及公司组织架构的调整而演进，拥抱变化是常态。

在摸清楚了上述情况之后，就进入规划步骤，毕竟数据平台建设不是一朝一夕的事情，短则三个月，长则大半年才能见到一些效果。因此，在规划中就需要考虑分清楚建设的优先级，同时结合团队情况哪些东西需要自建、哪些外购也需要纳入考虑范围。举个例子，例如公司刚成立一两年，业务还在野蛮生长的阶段，同时业务增长迅猛可以预见的一两年内还有十倍以上的增长，并且数据分析的需求已经很旺盛了，这时候选择先使用云厂商的产品是一个能立竿见影的选择；同时，在选择云厂商的产品时尽量选开源标品而非独有的产品。

Vol.2

接下来就是基础架构来。大数据系统是一个很吃资源的东西，最重要的组件就是资源调度器，在 Hadoop 时代使用 Yarn 来管理节点、调度任务。而到了现在无论是社区还是大厂都在积极向 k8s 过渡，所以这几年的趋势是使用 k8s 调度大数据任务。但整个生态的迁移是需要时间的，哪怕是 Spark、Flink 这样的产品，在 k8s 的支持上推进也不快。目前处于一个勉强可以用的状态，如果要全栈大数据都使用 k8s 必然会碰到一些坑，需要做适度的源码改造。

Vol.3

到了开干阶段，第一步是想清楚数据从哪来。数据来源一般分为几种：

第一是最常见的业务数据，但每家公司的业务数据都有自身的特点，例如数据是存在哪类数据库，是否包含非结构化数据，是否有实时的需求等。

第二种有来自供应商的数据，第三方数据、爬虫数据等。

除此之外还有运行时产生的日志、监控、用户行为等采集类数据。每一类数据都有自己的特点，基本不能使用一种技术解决所有的问题，要做细致的分析后针对性的解决。

例如能使用表结构定义的数据，都可以先使用 parquet、avro 等列式存储存到分布式存储上，流式的数据可以先接到 kafka 里，非结构化数据按照一定的压缩格式存储到对象存储。

并且数据集成的过程还需要对数据进行归一化、清洗、去重等操作。比如来自不同源的数据在表示“北京"时，表现方式可能五花八门，有用中文的、拼音的、枚举值的、电话区号的，所以数据清洗这一步必不可少。

这里就需要搬出来数仓建模的理论，上述内容基本上就是数据入仓的步骤，而数据集成的工具有Apache NiFi、各种CDC工具、各种ETL工具、Apache Spark、实时的有Flink等。此外数据每时每刻都有增量产生，所以还需要有任务调度系统按照固定的周期去触发ETL任务，调度系统开源届的 Airflow 和 DolphinScheduler 已经相当成熟了，一般稍作修改就能拿来使用。

Vol.4

下一步是存储。曾几何时，说到大数据的存储基本就是 HDFS，在大厂里就是自研的类 HDFS 系统。但现在分布式存储这块迎来了很大的变数。

看过作者其他文章的朋友应该知道，我是一个云原生的鼓吹者 + Hadoop的唱衰者，所以在实践分布式存储这块很不推荐HDFS，最主要的原因就是运维复杂，存储计算耦合严重，不利于扩展。

当然，现在还没有出现能够平替 HDFS 的产品，只有 Alluxio/JuiceFS + 对象存储的组合方案能达到勉强替换的效果。由于 HDFS 在前十年有着统治性的地位，很多产品都是围绕着 HDFS 建设，并且存储类产品迁移替换成本太高，所以依旧有很大的存量市场在使用 HDFS 。

如果单独使用对象存储替换 HDFS，会碰到各种各样的性能倒退问题，例如对象存储的限流、rename、网络带宽、元数据拉取等问题，所以增加 Alluxio/JuiceFS 这类缓存层非常有必要，具体 Alluxio 和J uiceFS 的差异可以单独开一篇文章介绍。如果使用传统的分布式文件系统例如 Ceph、GlusterFS替换 HDFS 呢？目前还没见到成功的案例，估计还是卡在生态集成上。

所以在分布式存储这一层，目前最符合潮流的选择是对象存储+缓存层，一方面对象存储各个云厂商都提供而且 API 也相对标准，另一方面大数据的生态都在积极适配对象存储，同时对象存储被广为诟病的性能问题，通过缓存层也能有效改啥。所以在没有 Hadoop 历史负担的环境里，就大胆地和 Hadoop 说再见吧。

Vol.5

数据能有效地存储之后，事情就已经完成了关键的一步，此时有能力的用户已经可以直接使用数据了。比如会用 PySpark 的同学，可以直接写脚本把自己想要的数据导出来，Data Engineer 也可以写脚本完成数仓的建设，把 ODS 层的数据一层层的建设起来，算法同学可以自助的从数据沼泽里面找到自己感兴趣的跑一跑。

如果想把数据开放给更多的用户使用，就要支持SQL，也就是 OLAP 的建设。现在 OLAP 的选项有很多，但多少都有自己的局限性，实力强的团队可以 fork 开源的产品自研，ClickHouse、Doris、Trino 都可以。实力弱一些的团队适合做路由层，底下部署好几套 OLAP 数据库，开发一套 proxy 层把用户发过来的 SQL 解析转发到合适的 OLAP 上。实力再弱一些的只能部署一套 OLAP 数据库，严格约束用户的 SQL 语法和使用场景，团队实在没人就采购 OLAP 供应商的产品，做甲方爸爸指挥供应商适配自己的业务。

OLAP 建设到一定阶段之后，可以试着做指标层。严格来讲这一层数仓团队和数据平台两方谁做都可以，只能说谁对业务理解深刻谁做。指标层对于用来讲是对数据做了进一步的抽象，最终的用户只能看到一个个的指标，而不是某张表中的某个字段，使用方式也从使用 SQL 变成了可视化、交互式的指标，使用方也从分析师扩展到了一线业务用户，可以试产品经理、销售、售前、运营等一线角色。

Vol.6

下一步是治理。如果这套大数据系统能落地，并且运行几年下来，百分之百会变成一团糟。例如说不清楚数据是谁产生的、从哪来的、是谁在用……随着组织架构调整人员变动权限问题也说不清楚。这时候再来个降本增效的最高指令，要清理无效的存储，回收多余的机器，在线离线混部等要求。

数据治理是个综合学问，不是一个单纯的技术问题，我也还没经历到那个阶段，就不发表太多的观点了。

最后，一套系统搭建起来很容易，但是要一直适应业务的需求、技术的潮流很难。持续学习、保持对技术的热情，才能在数据行业保持竞争力。

欢迎关注太可研究所（techinstitute），了解更多。