摘要

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

架构正确

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

  • 当前架构是否能够实现所有需要的功能，功能除了业务性功能之外，还包括非功能性指标。
  • 当前架构所涉及的具体的技术选型是否是当前最合适的选择，例如对于一个纯Java背景的团队，若非再毫无第二种选择的情况下，选择一个C++的组件，并且还需要进行二次开发，则并非一个好的选择。

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

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

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

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

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

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

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

  • 虽然未来可能会有非结构化存储的需求，但是目前最为紧迫的是结构化数据的存储，于是我选择使用ClickHouse作为存储介质，承担存储和分析的职责。
  • 虽然未来可能会有基于机器学习挖掘的诉求，但是目前更多的是规则类分析，于是我选择使用Yarn调度Flink进行流批一体的选择。
  • 虽然未来公司会集体进行套装软件替换工作，但是目前大部分的数据来源和数据治理都是基于历史套装软件的，所以我选择使用informatica做元数据管理系统。

以上场景可以发现，虽然从整体来看，未来某一天整个架构都会被重新设计，甚至某些组件再也不会使用，基于以上场景的信息设计出的架构方案，算不上完美，甚至未来改造的成本会非常高，但是他们依旧是正确的，因为在当前可见的需求之内，可以很好，甚至很短平快的解决当下问题。

至于未来可能发生的问题和诉求，留给未来吧，对于这样的设计，我们依旧认为他是架构正确。

架构安全

安全应该无处不在，无论做什么事，仿佛都应该是安全先行，但实际上在架构设计上我们还是把架构安全放在了架构正确之上，某种意义上来说也算是业务先行的视角，因为安全是一个持续的过程，我向来认为安全是演进出来的，不是设计出来的，之所以存在设计，那是因为有某种经验仅仅作为参考而已。

当我们架构正确后，意味着当前最紧急的需求以及被缓解，需要的功能已经被实现，那么是时候在这个阶段关注架构安全了。

仔细想想，当我们谈论架构是否安全的时候，我们并不是广义上的谈论组件本身，或者协议的安全，更是贯穿了各个维度的考察，从数据内容到流程管控，所以当我们评判是否架构安全的时候，我们一般是从如下几个维度来查看：

  • 系统安全：系统指的是企业自身的基础设施，包括基本的网络，存储等设备，从基本的网络隔离，存储异地容灾。
  • 数据安全：数据安全更多强调的是数据内容的安全，而非本身的数据物理安全，数据内容安全涉及范围广，实施难度高。主要包括数据脱敏，数据计算访问权限控制，内容加密，以及角色对计算资源和内容的映射。
  • 应用安全：脱离服务，数据则无法使用，服务并不是狭义的常见的HTTP Web此类服务，对于数据来说，BI工具，DB，或者消息队列，都算是数据服务提供者。对于此类服务来说，需要考量其应用安全，例如用户登陆认证安全，系统调用安全，数据缓存安全。
  • 流程安全：流程安全更多聚焦在公司的组织结构和日常工作模式，例如数据使用审批流程，数据泄漏追责体系，数据接入导出责任人机制，是否具有足够的合理流程，既能避免冗长的形式主义，又能将过程透明和信息共享。对于数据上传下载，是否和有对应的生命周期管理机制，例如缓存时间，删除机制。
  • 合规安全：合规的视角占据在运营和法务的角度，例如采购和使用的组件是否存在License问题，例如是Apache协议还是GPL协议，在当前国际形势下，某些企业会考虑当前采购的软件是否有涉A风险，源码归属等等系列问题都是合规需要考虑的。

安全是在架构正确的前提下，添加了一层保护，保护安全的做正确的事，所以设计一个安全的架构，会方方面面都考虑到，在当前的上下文下，如何确保架构中的每一个环节，都能安全的工作，如何确保架构本身不会存在明显的缺陷和漏洞导致发生不可挽回的错误，从架构方案来说，不要求我们在上面的维度面面俱到，但是希望我们的整个方案有专门为安全设计的篇幅，有阐述当前安全方面考量的标准。

架构敏捷

敏捷软件研发是大家熟知的概念和知识，那么对于数据智能的架构方案来说，怎么做到架构敏捷呢？

敏捷是通过不断的反馈迭代，来响应快速变化的市场需求，通过合理的方法论和基础设施，保障软件可以快速被上线发布，得到反馈可以快速修正。

对于架构来说，变化的是啥呢？前面我们都是围绕功能讨论具体的实施方案，一直没有提到组织结构，任何软件设计都会受到“康威定律”的影响。因此对于架构来讲，变化的东西有组织结构，业务需求和协作模式。所以在架构敏捷的视角，通常我们会考虑如下维度：

  • 持续智能基础设施：一个敏捷的数据智能架构，除了拥有常规的服务于数据智能的持续交付基础设施，其概念就是ThoughtWorks曾提到的持续智能，主要用于服务于整个数据智能流水线中的基础服务开发部署，数据ETL的部署发布，数据服务和模型的管理发布，其设计并不是单纯点搭建CI/CD或者说简单的一个组件改造，而是一套底层的自运行的基础设施，需要考虑任务运行周期时长，资源选择，调度编排等一系列问题。
  • 重造轮子和扩展的局限：从敏捷来讲我们会逐步迭代，以适配业务诉求，但是对于数据这种重量级诉求来说，更多的时候是众多组件的合集，最多会有一个门户网站将其集成在一起，因此重量级的组件以及基于其开发的难度就局限了响应业务诉求的动作，更多的时候变成了软件包的妥协，在当前场景下如何设计定制化的程度，以及如何尽可能少的妥协，就是架构敏捷的程度。
  • 组织结构：从组织结构来说，通常影响到技术架构部分的会是角色和消费权限之间的协作方式于权限分配，一旦组织结构发生变化，或者虚拟团队发生调整，职责发生更替，如何继续持有的在架构之上可以继续运行，就体现出了架构对于组织结构变动的响应力，通常像多租户管理，独立workspace，沙盒甚至data mesh，都是某种程度解决“康威定律”的逻辑下，如何快速拥抱变化的思路。
  • 可落地的方法论：DDD和TDD是被熟知的知识，那么在数据智能架构下，如何合理的划分数据的服务，或者说已经设计出来的数据模型，数据服务等模块是否符合对应的上下文，边界拆分是否合理，实施开发层面是否有合理的方法论去支撑和诠释，也是架构敏捷评估的维度。

可以看到，架构敏捷更多的是我们在数据架构的视角，去看待周围可能发生的变化，以及在变化之后，我们如何快速的可以在当前的基础上进行响应，同时我们移植部分方法论，尽可能多在设计之初就考虑到响应变化的诉求，避免太过于被动。

架构演进

演进式架构更多的是一种思路，并非一种实施方案，也就是无论我们使用何种技术或者架构去落地，都能衍生出演进式架构的设计，当我们默认使用微服务的时候，就已经享受了演进式架构的诸多红利，并不是说微服务等于演进式架构，而是说微服务本身已经展现了很多演进式架构的特征，因此对于数据智能架构来说，当我们判断是否是一个演进式架构的时候，通常可以如此看待：

  • 可进化性：微服务所承载的期望便是让我们能尽可能快的适应变化，随之而来的好处就是可维护性，而演进式架构中所倡导的进化性与此不谋而合，因此可进化性是一种随时准备响应变化的状态，而不管你是否提前就设想好了这些变化。对于数据架构来讲，是否有合理的服务来包装底层独立的组件，以达到可以快速响应不同诉求的效果，而不是直接暴露组件本身，受限于组件能力。
  • 符合康威定律：架构需要关注怎么组织团队结构，以及不同的团队结构可能影响到最终的系统形态。只有考虑团队结构，企业运作模式，数据智能需求程度，设计出来的模块才是真的松耦合。
  • 适当耦合：架构是否充分考虑和平衡耦合与性能、复杂度等其他因素之间的关系，这样的考虑会合理点权衡模块之间的耦合，例如数据和模型，是否需要共用缓存，是否需要共用算力。
  • 协议：不同模块之际需要有统一的规范，规范并不只是通信协议本身，还包括数据协议，也就是常说的元数据或者主数据规范，对于数据智能架构来说，统一而又规范的数据协议，能够拉通整个平台的质量标准，对于后续无论是模块升级还是替换，都可以解耦。

由此可见，对于架构演进来讲，关注的更多的是当前架构是否具有足够的可演进的考量，而非采用了何种技术选型，演进式架构对于后续扩展投入的成本人力和开发周期有着非常大的影响，通常对于业务快速发展的支撑度也有着非常高的响应力。

架构前瞻

前瞻通常指的是我们要考虑非常多非常远的东西，同时软件研发最佳实践又告诉我们不要夸夸其谈未来性，也就是不要想太多，合适于当下就是最好的。想多想少本质上就是一个度的问题，既不要想太多，也不要啥也不想，一个架构是否具有前瞻性，通常我们会有多个维度来考量：

  • 技术卓越：在当前领域下，所选择的组件或者技术是否是具有技术卓越的特点，该技术在未来发展方向上，技术卓越的特点是否能够完美的契合当前业务，例如当前业务需要快速的全文检索和简单的聚合，那么ElasticSearch则是一个相对较好的组件，未来ES重点优化的落盘，索引等特性都会符合当前业务的诉求，能够使用上未来的技术红利，选择组件只是一个例子，从变成语言，到选择的第三方库，处处都有是否技术卓越的体现。
  • 架构可演进而不是架构替换：再未来可见的岁月里，或者说投入开发此平台的成本在没有被均摊出来之前，我们希望新的业务发生变化的时候，架构是可演进的而不是需要重新涉及，业务侧对于此类要求通常会有更加白话文的要求：希望系统可以满足未来x年的业务发展诉求。
  • 沉淀复用：平台除了解决流程和信任的问题，还有复用的价值，因此当设计架构的时候是否有考虑如何复用和沉淀企业核心能力，小到对一个通用的数据集进行权重设置，形成不同数据集的价值排序，大到一个个数据服务的共享，都是在沉淀资产方面的考虑。

架构前瞻，会让人看起来就眼前一亮，在未来的时间，似乎这样的架构可以安全可靠的使用，几乎找不到不契合的地方，架构前瞻除了对技术的广度和使用程度有要求之外，同时还对业务的发展有着自己的独立判断，结合多种因素，而输出的技术选型架构。

尾声

数据智能的架构多种多样，同时不同的权衡方式也多种多样，我们不需要追寻银弹，寻找最完美的解决方案，但是需要知道自己当前合适什么样的方案，以及未来的需要和约束下，应该往哪个方向发展，用最小的成本，实现最优的效果。

扫码手机观看或分享：