数据智能架构的度量标准

摘要

数据智能是一个领域，技术架构是实施方案，我们很难从好或者不好的维度去衡量一个架构，更多会基于当前的上下文下来审视架构是否具有合理性，以及遥想一下在可见的未来是否具有合理性的视角，来看待当前架构是不是一个最佳的选择。因此没有坏的架构，只有是否是当前上下文中最合理的架构，既然有审视维度，自然就会有合理层级，今天我们尝试通过不同的层级来描述一个架构当前所处的阶段，和其具备的合理性范围。

架构正确

正确指的是当前存在的功能是否能够解决具体的问题，架构正确则包含有两方面的含义：

• 当前架构是否能够实现所有需要的功能，功能除了业务性功能之外，还包括非功能性指标，简而言之，架构所实现的功能需要在符合客观条件的前提下输出正确的结果。
• 当前架构所涉及的具体的技术选型，是否是当前最合适的选择，例如对于一个纯Java背景的团队，选择一个C++的组件，并且还需要进行二次开发，则并非一个好的选择。

架构正确不是架构完美，对于架构正确来说，我们更多关注的是当前架构提供的功能本身，可操作的空间，是否能够完全覆盖已知的具体的业务。同时需要注意，架构不等于组件或者编程语言本身，也就是说选择正确合理的组件，不代表架构就合理正确，架构是一系列组件的基础上，构建出用来端到端解决某个业务领域问题的平台或者流水线，除了组件选择正确之外，还需要做更多的扩展和设计。

通常来说选对组件，选对技术语言，对于实现成本来说，已经可以大大提升效率，降低开发复杂度。所以这里的架构正确中的合适选择，更多指的是，具体的组件或者编程语言这种具体的选型实现。

那么对于数据智能这个领域来说，什么样的选择，能够算得上是架构正确呢？

我们得先分解一个数据智能领域到底要解决什么问题，我们把一系列的数据进行架构处理后，无论是支撑内部运营，还是给业务提供服务，至少完成这部分工作，我们“数据”了，同时我们希望利用数据潜在的信息，可以进行深层次的优化，无论是企业内部流程优化，例如做审计，做文本分析，还是外部用户体验优化，例如做推荐，做优惠券发放，做完这部分工作，我们“智能”了。

基于上面大的问题域，如果我们需要有一个东西来支撑上述需求，这个东西至少得具有这样的要求：

• 采集各方数据，进行汇总存储
• 基于存储进行各种维度的分析计算
• 将结果以某种形态呈现给某个部分
• 人工可干预中间的各个环节

那么在这样的前提下我们可以发现，当我们做出如下设计的时候，或许它不够完美，甚至无法演进，但是它是架构正确的：

• 虽然未来可能会有非结构化存储的需求，但是目前最为紧迫的是结构化数据的存储，于是我选择使用ClickHouse作为存储介质，承担存储和分析的职责。