前言

在过去几年中,我作为数据行业从业者开发过一系列应用,主要围绕

  • 数据接入
  • 数据治理
  • 数据处理
  • 数据存储
  • 数据展现

几个方面。

在这个领域工作的三年时间中,发现目前经历过的公司(以及从各种途径获取到的别的企业)对于数据架构这一大领域的处理思路其实都逐渐趋于相同。为了解决类似的问题,我也在这几年中做了很多重复的事情。

因此,本系列文章在结合我的工作经历和他人优秀内容的基础上试图描述过去几年我在数据架构这个领域的一些思考和总结。

构建数据应用的考虑

无论是从零开始构建一个数据应用,还是半途接手一个已经在生产环境运行了的数据应用,都需要从下面几个方面考虑:

了解这个数据应用要解决的是什么问题

这不是一个简单的要求,一个不完善(失败,难用)的数据应用很大程度上是由于没有完全理解这个应用是为了解决什么问题造成的。这种没有完全理解包括:

  • 没有掌握到所有的问题,遗漏了某些问题
  • 没有理解问题造成的影响,错误地估计了 SLA
  • 没有分清问题的优先级,先解决了不重要的问题

选择合适的技术栈

摒弃个人喜好和偏见,选择能解决问题的最佳技术栈。

这一点看似容易,但其实也比较难做到,在做技术选型时,很容易将自己的偏见带入到选择中,这往往是一个项目最终难以维护的根本原因。

正确的做法是集思广益,先筛选出可能的技术方案,然后根据要解决的实际问题做基准测试,最后结合其他考虑(可维护性,性能,团队接受度)做出抉择。

解决选择带来的风险

不管最后选择了哪种技术方案,都会带来新的风险,在上线新的方案之前,应该充分考虑到这些风险并且提前准备好对应的解决方案

搭建和管理团队

构建一个完善的数据应用需要一个团队的合作,单枪匹马很难向外交付一个成功的方案。团队成员的选择和成员的任务分配是这个考虑的重中之重。

持续评估方案完成度

方案设计完成后,就进入开发实现的阶段,在开发实现的过程中,应该持续评估方案的风险,主要包括:

  • 是否遇到技术问题;
  • 是否遇到数据问题;
  • 是否遇到沟通问题;
  • 是否遇到需求问题;
  • 项目是否会延期;
  • 我们都知道,一个数据应用最后呈现的形态和最初设计的形态往往是有差别的,作为方案的设计者,需要在实现方案的过程中持续评估这个方案暴露的风险,最终做到让所有相关人员知晓并一致同意解决这些风险的方案。

接下来

在接下来的系列文章中,我会从上述几个方面讲一讲我对构建数据应用的理解。