摘要
数据智能是一个领域，技术架构是实施方案，我们很难从好或者不好的维度去衡量一个架构，更多会基于当前的上下文下来审视架构是否具有合理性，以及遥想一下在可见的未来是否具有合理性的视角，来看待当前架构是不是一个最佳的选择。因此没有坏的架构，只有是否是当前上下文中最合理的架构，既然有审视维度，自然就会有合理层级，今天我们尝试通过不同的层级来描述一个架构当前所处的阶段，和其具备的合理性范围。
架构正确
正确指的是当前存在的功能是否能够解决具体的问题，架构正确则包含有两方面的含义：
- 当前架构是否能够实现所有需要的功能，功能除了业务性功能之外，还包括非功能性指标，简而言之，架构所实现的功能需要在符合客观条件的前提下输出正确的结果。
- 当前架构所涉及的具体的技术选型，是否是当前最合适的选择，例如对于一个纯Java背景的团队，选择一个C++的组件，并且还需要进行二次开发，则并非一个好的选择。
架构正确不是架构完美，对于架构正确来说，我们更多关注的是当前架构提供的功能本身，可操作的空间，是否能够完全覆盖已知的具体的业务。同时需要注意，架构不等于组件或者编程语言本身，也就是说选择正确合理的组件，不代表架构就合理正确，架构是一系列组件的基础上，构建出用来端到端解决某个业务领域问题的平台或者流水线，除了组件选择正确之外，还需要做更多的扩展和设计。
通常来说选对组件，选对技术语言，对于实现成本来说，已经可以大大提升效率，降低开发复杂度。所以这里的架构正确中的合适选择，更多指的是，具体的组件或者编程语言这种具体的选型实现。
那么对于数据智能这个领域来说，什么样的选择，能够算得上是架构正确呢？
我们得先分解一个数据智能领域到底要解决什么问题，我们把一系列的数据进行架构处理后，无论是支撑内部运营，还是给业务提供服务，至少完成这部分工作，我们“数据”了，同时我们希望利用数据潜在的信息，可以进行深层次的优化，无论是企业内部流程优化，例如做审计，做文本分析，还是外部用户体验优化，例如做推荐，做优惠券发放，做完这部分工作，我们“智能”了。
基于上面大的问题域，如果我们需要有一个东西来支撑上述需求，这个东西至少得具有这样的要求：
- 采集各方数据，进行汇总存储
- 基于存储进行各种维度的分析计算
- 将结果以某种形态呈现给某个部分
- 人工可干预中间的各个环节
那么在这样的前提下我们可以发现，当我们做出如下设计的时候，或许它不够完美，甚至无法演进，但是它是架构正确的：
- 虽然未来可能会有非结构化存储的需求，但是目前最为紧迫的是结构化数据的存储，于是我选择使用ClickHouse作为存储介质，承担存储和分析的职责。
- 虽然未来可能会有基于机器学习挖掘的诉求，但是目前更多的是规则类分析，于是我选择使用Yarn调度Flink进行流批一体的选择。
- 虽然未来公司会集体进行套装软件替换工作，但是目前大部分的数据来源和数据治理都是基于历史套装软件的，所以我选择使用informatica做元数据管理系统。
以上场景可以发现，虽然从整体来看，未来某一天整个架构都会被重新设计，甚至某些组件再也不会使用，基于以上场景的信息设计出的架构方案，算不上完美，甚至未来改造的成本会非常高，但是他们依旧是正确的，因为在当前可见的需求之内，可以很好，甚至很短平快地解决当下问题。
至于未来可能发生的问题和诉求，留给未来吧，对于这样的设计，我们依旧认为它是架构正确。
架构安全
安全应该无处不在，无论做什么事，仿佛都应该是安全先行，但实际上在架构设计上我们还是把架构安全放在了架构正确之上，某种意义上来说也算是业务先行的视角，但并不意味着架构正确的时候就放弃安全了，反而安全是一个持续的过程，架构正确关注功能实现的时候已经涵盖了安全的实现。
我向来认为安全是演进出来的，不是设计出来的，之所以存在设计，那是因为有某种经验仅仅作为参考而已。
当我们架构正确后，意味着当前最紧急的需求已经被缓解，需要的功能已经被实现，那么是时候在这个阶段关注架构安全了。
仔细想想，当我们谈论架构是否安全的时候，我们并不是广义上的谈论组件本身，或者协议的安全，更是贯穿了各个维度的考察，从数据内容到流程管控，所以当我们评判是否架构安全的时候，我们一般是从如下几个维度来查看：
- 系统安全：系统指的是企业自身的基础设施，包括基本的网络，存储等设备，从基本的网络隔离，存储异地容灾。
- 数据安全：数据安全更多强调的是数据内容的安全，而非本身的数据物理安全，数据内容安全涉及范围广，实施难度高。主要包括数据脱敏，数据计算访问权限控制，内容加密，以及角色对计算资源和内容的映射。
- 应用安全：脱离服务，数据则无法使用，服务并不是狭义的常见的HTTP Web此类服务，对于数据来说，BI工具，DB，或者消息队列，都算是数据服务提供者。对于此类服务来说，需要考量其应用安全，例如用户登陆认证安全，系统调用安全，数据缓存安全。
- 流程安全：流程安全更多聚焦在公司的组织结构和日常工作模式，例如数据使用审批流程，数据泄漏追责体系，数据接入导出责任人机制，是否具有足够的合理流程，既能避免冗长的形式主义，又能将过程透明和信息共享。对于数据上传下载，是否和有对应的生命周期管理机制，例如缓存时间，删除机制。
- 合规安全：合规的视角占据在运营和法务的角度，例如采购和使用的组件是否存在License问题，例如是Apache协议还是GPL协议，在当前国际形势下，某些企业会考虑当前采购的软件是否有涉A风险，源码归属等等系列问题都是合规需要考虑的。
安全是在架构正确的前提下，添加了一层保护，安全地做正确的事，所以设计一个安全的架构，会方方面面都考虑到，在当前的上下文下，如何确保架构中的每一个环节，都能安全地工作，如何确保架构本身不会存在明显的缺陷和漏洞，导致发生不可挽回的错误，从架构方案来说，不要求我们在上面的维度面面俱到，但是希望我们的整个方案有专门为安全设计的篇幅，有阐述当前安全方面考量的标准。
架构敏捷
敏捷软件研发是大家熟知的概念和知识，那么对于数据智能的架构方案来说，怎么做到架构敏捷呢？
敏捷是通过不断的反馈迭代，来响应快速变化的市场需求，通过合理的方法论和基础设施，保障软件可以快速被上线发布，得到反馈可以快速修正。
对于架构来说，变化的是啥呢？前面我们都是围绕功能讨论具体的实施方案，一直没有提到组织结构，任何软件设计都会受到“康威定律”的影响。因此对于架构来讲，变化的东西有组织结构，业务需求和协作模式。所以在架构敏捷的视角，通常我们会考虑如下维度：
- 持续智能基础设施：一个敏捷的数据智能架构，除了拥有常规的服务于数据智能的持续交付基础设施，其概念就是ThoughtWorks曾提到的持续智能，主要服务于整个数据智能流水线中的基础服务开发部署，数据ETL的部署发布，数据服务和模型的管理发布，其设计并不是单纯点搭建CI/CD或者说简单的一个组件改造，而是一套底层的自运行的基础设施，需要考虑任务运行周期时长，资源选择，调度编排等一系列问题。
- 重造轮子和扩展的局限：从敏捷来讲我们会逐步迭代，以适配业务诉求，但是对于数据这种重量级诉求来说，更多的时候是众多组件的合集，最多会有一个门户网站将其集成在一起，因此重量级的组件以及基于其开发的难度就局限了响应业务诉求的动作，更多的时候变成了软件包的妥协，在当前场景下如何设计定制化的程度，以及如何尽可能少的妥协，就是架构敏捷的程度。
- 组织结构：从组织结构来说，通常影响到技术架构部分的会是角色和消费权限之间的协作方式于权限分配，一旦组织结构发生变化，或者虚拟团队发生调整，职责发生更替，如何继续持有的在架构之上可以继续运行，就体现出了架构对于组织结构变动的响应力，通常像多租户管理，独立workspace，沙盒甚至data mesh，都是某种程度解决“康威定律”的逻辑下，如何快速拥抱变化的思路。
- 可落地的方法论：DDD和TDD是被熟知的知识，那么在数据智能架构下，如何合理的划分数据的服务，或者说已经设计出来的数据模型，数据服务等模块是否符合对应的上下文，边界拆分是否合理，实施开发层面是否有合理的方法论去支撑和诠释，也是架构敏捷评估的维度。
可以看到，架构敏捷更多的是我们在数据架构的视角，去看待周围可能发生的变化，以及在变化之后，我们如何快速在当前的基础上进行响应，同时我们移植部分方法论，尽可能多在设计之初就考虑到响应变化的诉求，避免太过于被动。
架构演进
在介绍架构演进的时候首先要区分一下和架构敏捷的区别，对于架构敏捷来说，更多的是从企业的软件开发文化，企业的组织结构分工，企业的软件开发基础设施建设程度来评估如果要对当前架构进行不断的迭代和修正，将会受到哪些非开发层面的约束，同时在当前企业的上下文下所带来的局限有多大。
而演进式架构更多的是一种实践的解决方案，并非一种具体的框架，也就是无论我们使用何种技术或者架构去落地，都能衍生出演进式架构的设计，当我们默认使用微服务的时候，就已经享受了演进式架构的诸多红利，但是并不是说微服务等于演进式架构，而是说微服务本身已经展现了很多演进式架构的特征，因此对于数据智能架构来说，架构演进除了外部驱动的优化外，还有内部驱动的优化，也就是变得更好和不要变得更坏。
微服务通常是外部驱动，站在服务也业务的视角，让整体变得更好，同时还有一个维度就是内部维度，比如类和类之间的依赖，是否有循环依赖，包和包之间的定义是否合理，等等都是内部驱动。因此内部优化通常是不要变得更坏，外部是可以优化的更好，两个视角的评估，是可演进的架构和敏捷架构的区别。
当我们判断是否是一个演进式架构的时候，通常可以从以下视角来看看待：
- 技术：企业的技术战略下，如何由内而外的设计数据架构的规范到架构整体。保障在实施过程中即可以快速进行演变，同时也能达到业务诉求的指标，符合企业战略方向。
- 数据：数据如何规范化地在架构之下进行加工处理和服务，如何在架构内进行快速响应的同时还能保持较高的数据治疗。
- 安全：整个数据架构运行和实施过程中，数据安全，流程安全，服务安全，并且可以根据需求进行快速变更。
- 运营：运营维度实际包含运维和运营两个维度，主要是从基础设施层面达到可以替换，增量升级，改造的效果。
架构演进不是进行好坏评价，例如单体架构，并不是坏架构，但是单体架构如果又是大泥球架构，那么则我们会认为该架构不具备演进的特性，针对架构演进举几个例子如下：
单体架构因为数据依赖，查询性能，改变频率等度量维度，可以发现该系统是否是当前最合理的架构，那么从演进视角来讲，我们可以在外部提供的服务都不发生变化的情况下，进行内部调整和修改，将其演进为分层架构。
同理，通过存储成本，数据类型，非结构化数据比例等指标来评价当前系统是否满足当前诉求，可以将其演变为Data Lake架构。
上面两个图提到的都是演进架构的路线，演进过程并不见得是架构的重新设计，很大可能是对当前架构进行简单的调整和修改，演进架构指的就是我们当前架构从编码到技术选型，是否支持快速调整修改演进到下一阶段，如果能够达到快速演进的效果，我们则认为该架构符合架构演进。
由此可见，对于架构演进来讲，关注的更多的是当前架构是否具有足够可演进的考量，而非采用了何种技术选型，演进式架构对于后续扩展投入的成本人力和开发周期有着非常大的影响，通常对于业务快速发展的支撑度也有着非常高的响应力。
架构前瞻
前瞻通常指的是我们要考虑非常多非常远的东西，同时软件研发最佳实践又告诉我们不要夸夸其谈未来性，也就是不要想太多，合适于当下就是最好的。想多想少本质上就是一个度的问题，既不要想太多，也不要啥也不想，一个架构是否具有前瞻性，通常我们会有多个维度来考量：
- 技术卓越：在当前领域下，所选择的组件或者技术是否是具有技术卓越的特点，该技术在未来发展方向上，技术卓越的特点是否能够完美契合当前业务，例如当前业务需要快速的全文检索和简单的聚合，那么ElasticSearch则是一个相对较好的组件，未来ES重点优化的落盘，索引等特性都会符合当前业务的诉求，能够使用上未来的技术红利，选择组件只是一个例子，从变成语言，到选择的第三方库，处处都有是否技术卓越的体现。
- 架构可演进而不是架构替换：在未来可见的岁月里，或者说投入开发此平台的成本在没有被均摊之前，我们希望新的业务发生变化的时候，架构是可演进的而不是需要重新涉及，业务侧对于此类要求通常会有更加白话文的要求：希望系统可以满足未来x年的业务发展诉求。
- 沉淀复用：平台除了解决流程和信任的问题，还有复用的价值，因此当设计架构的时候是否有考虑如何复用和沉淀企业核心能力，小到对一个通用的数据集进行权重设置，形成不同数据集的价值排序，大到一个个数据服务的共享，都是在沉淀资产方面的考虑。
架构前瞻，会让人看起来就眼前一亮，在未来的时间，似乎这样的架构可以安全可靠的使用，几乎找不到不契合的地方，架构前瞻除了对技术的广度和使用程度有要求之外，同时还对业务的发展有着自己的独立判断，结合多种因素，而输出的技术选型架构。
尾声
数据智能的架构多种多样，不同的权衡方式也多种多样，我们不需要追寻银弹，寻找最完美的解决方案，但是需要知道自己当前合适什么样的方案，以及未来的需要和约束下，应该往哪个方向发展，用最小的成本，实现最优的效果。
