蚂蚁目的系统的设计与通常
本次分享人为蚂蚁个人的王高航教员，分享标题为蚂蚁目的系统的设计与通常，王高航教员自 2016 年参与蚂蚁个人以来，不时在数据中台畛域深耕。在此时期，介入了蚂蚁新老两代数据平台的研发并主导了多个外围子产品。目前，王高航教员担任蚂蚁数据中台的数据架构与控制、数据建模、资产控制、安保合规等产品的研发。
一、目的系统的疑问定义
首先须要明白什么是目的。从统计学角度看，目的是综合表现总体数量特色的概念和数值。在数据仓库体系中，目的是其外围产物，它是信息层面的一种载体。从 DIKW 模型的角度剖析，目的必定满足一些基本要求，包括准确性、完整性、及时性和分歧性。
另一方面，系统是由若干相互作用、相互依赖的组成部分构成的，具有特定性能的无机全体。这里的外围概念是“无机”，由于目的并不是一个孤立的技术，而是与人有着十分严密的互动，构成了一个无机的全体。
目的系统包括三个档次：
咱们面临的关键是二义性的疑问。详细来说，是同名不同义、同义不同名、或许目的间值抵触的状况。为了处置这些疑问，须要对各个畛域的概念达成共识。
须要关注的是如何确保目的的继续保鲜和有效迭代。虽然在短期内研发一批目的相对容易，但常年坚持这些目的的生机和有效性却十分有应战性。为了处置这一疑问，咱们须要从机制和流程的角度登程，树立相应的保证措施，以确保目的的继续优化和更新。
关键处置的是效率疑问。这包括目的定义、研发运维以及进一步下钻剖析的效率。为了优化效率，咱们须要对相关结构启动优化，并借助人工智能技术启动辅佐，提高目的工具敌对台的经常使用成果，降低不用要的老本和时期消耗。
综上，咱们须要在概念、流程机制和产品三个层面上区分处置二义性、继续保鲜和效率疑问。经过共识畛域概念、设计流程机制、外围结构优化及人工智能辅佐等手腕，更好地应答这些应战，优化目的系统的有效性和运行价值。
接上去引见如何构建目的系统。首先从第一层开局，即概念共识。概念共识是整个目的系统的基石，没有概念共识整个目的系统只是一个地面楼阁，只能在短期、部分颁布有限的价值。上方咱们开展引见一下如何启动概念共识。
一是经过 BI 驱动的方式。由于 BI 是衔接业务和数据工程师的桥梁，能够在实践沟通交流中启动一些形象和翻译，从而构成完整的目的体系。
另一种方式是由数据架构师驱动。由于他们作为数据工程师的代表，对整个畛域有更深化的意识，能够启动全局的形象和概念定义。
关于无法成功全成员共识的状况，就只能在角色外部共识，而后在交互的时刻启动言语的翻译，翻译的上班可以由数据工程师或 BI 来成功。
不能等候一切成员都能达成共识，特意是在一个比拟大的组织内。因此，共识的范围须要依据详细状况启动划分。可以经过组织架构视角、业务畛域视角或消费场景视角来成功。例如，按公司级、部门级或团队级启动划分，或许基于业务畛域形象启动范围划分。或许，也可以依据详细的消费场景来选择共识的范围。
在选用共识形式和范围时，没有相对的规范，须要思索各种要素。如全成员共识的优势是共识水平高，但难度也较大，关于外围角色的才干要求很高；角色外部共识的难度较低，但成果相对较差；按组织架构视角共识的难度较低，但稳固性较差；按业务畛域共识的稳固性较好，但难度较高；按消费场景共识的灵敏性高，但共识水平较低。
经过探求与通常，在蚂蚁外部，外围目的关键依照业务畛域启动范围划分，并在畛域内成功全成员的共识的方式。这样既可以保证共识水平，也能保证其稳固性。
目的是业务语义的外围载体，在架构层面语义层有三种不同的方式。
（1）第一种是将语义层与数据层融合
即间接在数仓中定义语义层。这种方式的好处是前期实施老本较低，只要要将已有的表、视图等启动相应的调整即可。此外，由于数据通常由独立的数据团队集中控制，因此具有组织保证。但是，这种方式的缺陷也很显著，关键表如今矫捷性无余。由于是集中式团队作业，只能由数据同窗启动定义，或许会缺乏业务输入和全局视角，造成了解老本相对较高。此外，由于语义层与物理层适度耦合，访问性能和灵敏性会遭到必定限度。
（2）第二种方式是将数据独立于数据仓库层
把语义层独自抽进去成为独立的一个产品。这种方式的好处在于逻辑层与物理层的解耦，可以一致数据的访问模型，允许各种湖仓的场景，并经过智能优化提高性能。由于是独立进去的，因此业务了解和保养老本相对较低，BI 等人员也有独特介入构建的或许性。此外，集中式控制使得控制水平较好，可以缩小一些二义性的疑问。但是，这种方式的缺陷在于前期老本较高，须要独立抽取这一层，同时复杂性也相对较高。
（3）第三种方式是集成在数据的消费工具中
这种方式的好处在于高度的灵敏性和矫捷性。但是，由于各自扩散，很难成功分歧性，且跨平台工具难以复制和复用。由于这一层会有很多贴近消费的不凡优化，关于其余工具来说很难复用。
这三种方式没有相对的好坏之分，应依据公司的详细状况而定。依据形式定义和偏差性，假设只是角色外部控制，可以选用第一种和第三种方式；假设是全成员共识，第二种方式或许愈加适宜；假设按组织架构共识，第一种方式较为适宜；假设是业务畛域共识，独立于一层的方式更好；假设是按消费场景共识，则应选用第三种方式。
为了构建这个概念共识，须要借助一些工具或方法论作为撑持。
从实质上讲，概念共识是一致言语的环节，而阿里之前提出的 OneData 方法论，是一个目的言语规范化的工具。这套工具关于从事目的上班的各位来说并不生疏。但是，随着时期的推移，咱们发现仅依赖这一套工具并无余够。关键要素是，它在通常层面更多的是从微观的视角登程，缺乏微观视角。
为了补偿这一无余，咱们引入了畛域驱动设计这一思维。畛域驱动设计并非咱们的翻新，而是在工程畛域被宽泛采用的一种思维。引入它的目的在于增强微观视角，更具前瞻性以顺应不时变化的业务需求。此外，随着数据业务化的趋向，咱们须要成功更大范围、更深档次的言语共识。畛域驱动设计的一些方法论在此环节中施展了关键作用。
畛域驱动设计的外围在于畛域模型与一致言语。畛域模型是对业求实质的形象，基于业求实质启动建模。在实践操作中，须要关注两个联合点。
首先，在微观层面上，基于业求实质对数据域启动划分，这有助于畛域常识的交流与共享。假设划分仅按组织启动，那么畛域常识也只能按组织划分，这无疑参与了交流的难度。
其次，咱们须要启动更大范围的业务术语讨论。这象征着在线运行架构师与数据架构师之间须要有必定的交流，能够一同讨论相似的疑问，确保彼此的言语是相通的。
三、目的系统设计——机制流程设计
机制流程的设计是为了确保目的的继续树立及保鲜。咱们在通常环节中发现，目的系统的树立相对容易，但继续的保养和运转却十分艰巨。从因果图上看，良好的树立和保养能够促成消费者的经常使用；用的人多了，也就能促成树立和保养。但理想中这个增强回路很难运转起来，关键从树立角度看，往往是可建可不建的形态，有部分同窗更偏差于保养在离线的 excel 中，一旦保养无余目的不保鲜，消费者就丢失信念转而线下问人；关于消费者，目的的经常使用场景有限，只是偶然去看一下的话增量价值没有那么大，不必定会继续去推进消费者启动目的保养。
为了处置这个疑问，有两个思绪，一是经过产品化及 AI 才干，优化目的控制、目的研发的效率，让在线的目的保养控制效率高于线下表格；二是经过与消费平台的深度集成，优化找数、取数、剖析的效率。当然在前期，咱们还须要依托一些控制机制来确保系统的冷启动。
在控制机制中，有几个关键角色须要详细论述。
首先，业务担任人是担任提出需求和树立目的模型的人。他们通常是 BI 或数据架构师，具有深沉的业务背景和专业常识。业务担任人对目的原子或业务限定有最终解释权，须要在担任畛域内制订无歧义的规范，确保目的建模的准确性和规范化。
接上去，技术担任人担任成功目的模型。他们须要选用成功方式，确保准确成功并及时产出。技术担任人须要与业务担任人坚持亲密沟通，确保对目的口径的了解坚持分歧，防止歧义。
最后，消费者是目的的最终经常使用者。他们享有知情权，对目的口径的变卦需及时了解。消费者有责任准确了解目的口径，正当经常使用数据，防止滥用。
在控制机制中，各角色需明白职责，相互协作，确保目的建模、成功和消费的顺利启动。
基于权责划分，咱们设计了一套变卦的流程。在流程中，业务担任人领有最终解释权，并承当着明白成功口径的责任，具有审批权。消费者则领有被通知的权益，业务担任人和技术担任人应确保消费者及时得知相关信息。
四、目的系统设计——产品化
产品化的载体就是目的平台，其目的是处置效率疑问。平台服务于数据控制者、目的建模者、目的研发者和消费者。
数据控制者的关键诉求是确保目的数据的准确性，防止出现任何歧义，同时关注数据品质和投入老本。目的建模者关键关注的是建模效率和建模门槛。目的研发者关心研发效率。而消费者，则更关心数据品质和消费效率。
基于这些外围诉求，目的平台须要具有四个外围才干：
在业界，目的平台曾经失掉了宽泛的运行。阿里个人和蚂蚁个人外部也有多个目的平台，有些是作为业务控制平台中的目的模块，而有些则是独立的目的平台。
从结构上看，目的平台通常包括一致词库控制、原子目的控制以及业务限定控制。基于这些基础，经过派生目的，可以构成一个宏大的目的库。在这个库中，可以启动繁难的目的运维、衍生以及提供看数、取数或目的 API 等服务。最终，物理目的会在研发平台中成功，并异步挂载到 ADM 或 DWS 表中。
但是，从咱们对目的平台才干的要求上看，现有的目的平台也存在一些疑问。
首先是规范化目的口径定义和控制的才干。这个结构只规范化了逻辑口径，没有规范化物理口径，它的物理口径通常暗藏在复杂的 SQL 中。因此，它只能处置单目的的二义性，无法处置多目的间的二义性，只能经过组织流程保证和一致两边层资产树立来缓解。
第二是目的下钻剖析才干。由于基于 ADM 或 DWS 有很多复杂 SQL，要做到下钻明细是比拟艰巨的，无法做到智能的下钻剖析，只能人为地检查 SQL 去了解口径。
第三是须要具有高效的研发才干。基于基础目的启动繁难衍生可以快捷消费，处置一部分效率疑问。
第三个疑问是通用方便的消费才干。这个结构在，挂载的目的只能以一个目的 code 这样一维的方式存在，但数据畛域大部分消费还是以“表”这样的二维方式，因此，这个结构下的目的要消费只能是目的取数 api 的方式，或许须要与下游数据服务启动深度买通，不够通用。
综上所述，现有的目的平台结构虽然处置了很多疑问，但仍不能齐全满足才干的要求。
蚂蚁目的平台在近期启动了一次性更新，关键触及以下几个关键方面。
首先，在原子词库的框架下，咱们为每个词设定了详细的物理口径。这种物理口径是基于数据模型启动确定的，以确保其二义性失掉保证。
基于这些绑定的物理口径，构建了一个一致词库。这个一致词库依托规范化模板，可以智能计算目的并产出，省去了手动计算这一步骤。此外，咱们还为这些目的赋予了一个载体，使其能够智能汇总到一张汇总逻辑表中。
这一结构具有几个优势。首先，它处置了口径不分歧的疑问。由于每个词库都绑定了物理口径，成功了逻辑口径与物理口径的规范化，因此可以更彻底地处置二义性疑问。
第二点是它增强了研发效率及目的下钻剖析的才干。目的成功了定义即研发，不须要在研发模块手动写义务再上挂到目的中，极大地提效。另外由于最终的目的是基于绑定口径的词库计算而来的，它有一个强血统，因此很容易基于目的就回溯到相应的明细表，开展详细口径，进后退一步的剖析。
最后针对智能研发的目的，咱们将同粒度的目的智能汇总到一张“逻辑表”中，这样下游用户可以基于该表的模型启动数据消费，成功更通用的消费。
为了处置目的建模中的难点，咱们引入了目的辅佐建模。在通常中，咱们发现从目的抽取出四要素（如原子目的、业务限定）或许会遇到一些艰巨。艰巨关键在于缺乏一致的规范。例如，当须要检查昨日支付宝在国外线下成交金额数时，目的建模者或BI、架构师须要拆分原子目的、业务限定和统计周期。虽然统计周期相对容易处置，但原子目的和业务限定有多种拆分方式。由于没有明白的对错之分，这或许造成凌乱。
为了处置这一疑问，咱们引入了一些目的的智能建模介绍。基本逻辑原理包括两条路途：一是基于基本目的启动分词，分词词库基于业务词条和目的词库。分词后，启动分类和同义词批改。例如，确定是“成交金额”还是“买卖金额”，并确保每个目的的惟一性。另一条路途是应用大模型对业务词条和已有词库启动构建，并基于大模型间接给出介绍结果。经过这些方法，可以提高目的建模的准确性和效率。
关于目的 SQL 的研发提效疑问，其基本原理是基于模板，每个模板对应一个基本元素，经过逻辑生成来处置疑问。基础才干比拟繁难，关键在于如何提高场景的笼罩率。
后来，咱们经过繁难的单表模板或性能来处置疑问，只能笼罩约 30% 的状况。接上去，咱们引入维度或雪花模型的目的性能，将一切维度扩展成一张虚构大宽表，启动目的性能，处置了约 60% 的疑问。
为了处置 80% 的疑问，咱们进一步丰盛关联相关和模型才干。例如，引入桥接表、层级维度以及复杂的关联相关。更进一步，处置 90% 的疑问则须要处置二次汇总和自关联才干，比如一些二次汇总或许自关联的标签类目的。
关于更复杂的状况，咱们仍在探求或许的处置打算。但是，任何处置打算都存在极限，无法到达 100% 的笼罩率。在未来，咱们须要愈加关注产品交互才干，或许经常使用更适宜的 DAX 言语来处置复杂的剖析目的。
最后，关于通用消费才干，可以经过汇总逻辑表将一切目的按维度汇总成一张虚构宽表。用户可见的维度和目的可以作为表的字段启动开展。关于物理层，启动一些外部智能物化处置以提高效率。
应用逻辑表的查问翻译引擎，将用户一切的 SQL 转化为逻辑表，并进一步将逻辑表转换为物理表的 SQL。这个引擎是整个系统中的外围组件。
在此基础上，树立接入层。在这一层，咱们成功了多种协定，包括 HTTP、RPC 以及 JDBC 等，以满足不同用户的需求。此外咱们还对蚂蚁外部的 Max Computer 引擎启动查问协定的代理，用户只要切换一个 endpoint，就可以繁难地查问逻辑表。
为了提高查问效率，咱们还引入了逻辑表减速技术，以满足一些须要极速照应的目的服务的需求。
基于业务模型的特性，经过专家阅历的积攒，可以有效优化数仓的口头效率。为了成功这一目的，关键采取了以下几个战略：
这些战略关于专家来说是经常出现的优化手腕，但关于刚上手的同窗来说或许并不容易把握。因此，咱们经过内置优化方法，有效优化数仓的平均口头效率，为业务提供更好的允许。
在逻辑表物化层面，咱们依据下游的消费频率和时期要求，对目的所在的汇总表启动智能的物化拆分和冗余处置。拆分和冗余的决策关键基于 3 个要素：
一是消费者对每个目的的时效要求，假设一切的表都被整合在一张物化表中，它受限于产出时期最慢的目的，使全体产出时效很长，所以在物化的时刻须要依据时效启动分组，例如要求在九点产出数据，那么七点和七点二十的数据可以兼并到同一张物化表中。雷同地，依据十点的要求，九点和九点二十的数据也可以兼并在一同。
二是在逻辑表内基于消费的频率启动计算与存储的取舍，假设下游经常须要将某些字段频繁地衔接在一同，咱们会在物化表外部启动冗余处置。
三是跨表的冗余。在实践经常使用时，许多维度属性会被一同经常使用。为了提高性能，咱们会针对一些维度属性启动冗余处置。例如，用户的一些信息，如姓名和性别会被冗余存储在另一张物化表中，由系统来保证分歧性。
五、业务虚践及未来展望
在蚂蚁个人，已有近三万个派生目的，其中 70% 是智能化研发的。基于 codeless 定义和智能物化的战略，数据二义性疑问显著有所改良，尤其是基于智能化的效率成功了数量级的优化。在目的计算性能方面，由于各种物化的智能化战略的运行，研发提效 10 倍以上，目的计算老本降低 20%。
在网商银行这一典型场景中，关键面临的疑问是口径的一致，由于各子模块间存在口径性的抵触，造成子业务报表合在一同时数据无法对齐。此外，矫捷性和灵敏性也是目的交付中须要关注的疑问。一旦目的交付出现意外动摇或疑问，启动二次剖析的难度较大。
在目的系统的通常中，咱们采取了一致的数据模型为基础，构建了目的模型。在此基础上，树立了一致的目的库，并与业务制度剖析平台启动了深度联合，这种联合使得咱们能够启动线上剖析。目前已构建了数千个派生目的，其中智能化率高达 90% 以上，保证了口径的分歧性，并优化了效率。
在蚂蚁安保畛域，关键面临的疑问包括口径疑问、重复研发造成的计算和存储糜费、老本增速超越估算以及依赖凌乱的计算老本压力。为了处置这些疑问，数据工程师聚焦于数据建模和目的建模，而业务同窗则担任派生目的的构建。经过这种方式，咱们成功了上万个派生目的，智能化率到达了 85%，交付周期从两天缩短到一小时，计算老本平均降低了百分之三十左右。同时，目的安保性疑问也失掉了较好的处置。
未来将愈加关注大模型的运用。大模型为语义层带来了一个贵重的时机。
一方面大模型能够辅佐建模，降低语义层构建的老本。但短期内，大模型不会齐全替代，由于业务的形象以及一些子畛域基础数据仍比拟稀缺。
另一方面语义层是大模型无法替代的畛域常识中心，经过将语义层与大模型联合，将极大优化消费效率，包括人造言语找数、人造言语取数和人造言语剖析等。
Q1：物理口径是如何做到绑定的？
A1：在物理口径的绑定方面，咱们须要在定义原子目的时，间接为其指定相应的口径。详细的绑定环节可以分为两个关键步骤。首先，选用主表，并为其参与相应的原子目的计算口径。其次，业务限定通常与维表相关，这或许触及到主表或其关联的表。在绑定环节中，咱们通常不须要对时期周期启动绑定，只要要在主表指定时期字段和格局就可以了。
Q2：目的是独自存储的吗？假设是独自存储的，是不是依照列式存储比拟好？假设维度不太固定或许多变的状况，有什么好的打算吗？
A2：首先，目的存储分为两个层级。第一层是最基础的层级，通常不会启动独自的存储。在物化视图方面，假设原始数据是采用列式存储，那么物化后依然会坚持列式存储。
关于减速后的目的服务存储，存在多种选用。一种方式是咱们可以内置一些减速存储的性能。另一种方式则是做减速，并存储到目的消费平台中。不过，数据并不会独自存储在目的消费平台中。
此外，关于维度不太固定或许或许会变化的状况，咱们须要思索一些好的处置打算。目前汇总逻辑表是依照同维度启动聚合的。当维度出现变化时，比如参与或缩小维度，这通常不是建表的疑问。
假设引入新的维度，咱们须要思索如何迭代表结构。关于新表，咱们会创立另一张汇总逻辑表，而不是在同一张表上启动操作。由于不同维度很难聚合在一同。假设硬要聚合，或许会造成数据表变得宏大而难以控制。
为了防止这种状况，咱们可以思索经常使用分区表来控制不同维度的数据。经过正当设置分区键和分区战略，可以有效地将不同维度的数据扩散到不同的分区中，从而成功高效的数据存储和控制。同时，咱们还可以应用数据库的分区性能启动查问优化，提高查问效率。
Q3：目的平台应该是从明细理想表开局计算，还是从业务部门的两边表去计算？
A3：关于目的的定义，我以为应该基于语义，即数据模型这一层面。两边表和明细表是不同的概念，关于明细表，也须要详细剖析。有些明细表在规范上相对收敛，而有些则较为发散。为了确保分歧性，咱们应从概念模型开局，这一层面具有必定的形象性。经过这种方式，明细内层不会过于扩散，明细与概念能够更好地联合，从而更易于到达分歧性。
Q4：目的的查问关于 BI 看板来说，性能要求会比拟高，性能应该从哪几方面保证呢？
A4：关于性能这一方面，咱们在蚂蚁金服并没有启动过多的钻研和涉猎。关键要素在于，咱们将这一畛域的上班关键交给了底层引擎来处置，例如逻辑表减速等，这些都是由引擎来担任的。在咱们的上班中，咱们更专一于构建语义层这一块，而不是过火关注技术层面的优化。
关于性能优化，咱们采取了两种战略。首先是把相关上班交给引擎处置，这样可以应用它们的专业性能优化技术。其次，关于逻辑表的减速，咱们并不须要处置一切的数据存储疑问，而是选用性地减速到业务的数据剖析平台，例如 Power BI 等。这些平台领有专业的性能处置打算，能够提供愈加完备的性能优化服务。
Q5：派生目的是蕴含维度和原始目的吗？是由业务同窗来编写吗？
A5：关于派生目的的定义，存在不同的观念和了解。
在通常操作中，咱们的派生目的蕴含统计粒度和维度两个方面。
至于派生目的确实定，我以为业务团队的介入是十分关键的。但是，这种介入是有前提条件的。首先，业务团队须要对树立的模型和相关概念有一致的意识。假设业务团队和数据团队经常使用不同的言语，那么派生目的确实定将十分艰巨。此外，关于数据建模形象才干的要求也比拟高。数据工程师须要表演数据架构师或数据建模师的角色，构建出能够顺应各种业务需求的优质模型。这样的一种形式是比拟理想的选用，能够确保派生目的的有效性和适用性。
Q6：有出现下钻的时刻，就是出现算子不相反的疑问吗？比如说一开局下钻的某一层级须要去重。
A6：详细来说，咱们须要将这一层向下转换，以提醒其外围口径，也就是恢复到明细模型这一层级。一旦恢复到明细模型层，系统会自动展现原子目的的算式。但是，要启动更初级的剖析，你或许须要经常使用其余算式或参与额外条件。这就须要与咱们的剖析平台相联合，轻松地交流这些算式、限定、周期或维度。
这样的调整不只扩展了讨论的空间，还突出了基于明细模型的灵敏性。另外，我想补充一点，咱们的目的通常基于数据模型来定义聚合算子，这或许触及多层聚合。这时，咱们可以借助 BI 工具，启动二次或三次上卷剖析。我了解一些特意复杂的剖析或许会更须要借助这些工具和言语来处置。
Q7：一切的目的都是耐久化之后的吗？有没有一些目的是灵活的？比如咱们实时查问三月份到如今的成交额。
A7：依据您提供的原始内容，以下是经过改写的谨严、稳重、理性、官网格调的言语：
在数据仓库中，目的通常都是耐久化的。关于一些衍生目的，例如 a 加 b 或 a 除以 b，咱们不会一律而论地启生物化，而会依据实践需求和状况来选择能否将其物化。
Q8：目的的计算口径都是经过图形化界面性能的吗？还是可以基于 SQL 语句性能？
A8：关键是看结构，以原子目的与基本算子级别的口径绑定为例，触及到图形与 SQL 的联合的，有些是选用定义 SQL。在定义好这些基础要素后，系统将生成相应的目的，这个环节可以经过图形化界面启动展现。
Q9：词根的二义性怎样处置？
A9：关于词根的二义性疑问，其实咱们之前曾经有所触及。要成功业务词条的一致言语，关键有三种形式选用：基于畛域、基于组织或基于消费场景。在确定形式后，后续上班就会变得相对繁难。
假设是基于畛域，就须要畛域专家独特协作，采用畛域驱动的方法，依据业务用例启动形象，达成词根的一致。基于组织的形式或许相对繁难一些，而基于消费场景的方式或许无法处置基本的安保性疑问，因此倡导采用基于畛域的方式。
另外，关于机制流程的变化，须要十分审慎地启动。关于畛域设计的开展，须要强调的是，这些词并不是一次性性录入系统就完结了。要让畛域词在各种日常交流、文档和需求提案中失掉宽泛运行，以规范经常使用规范的词汇。只要不时加深对词根的印象，才干真正达成共识，处置二义性疑问。
Q10：目的关键是离线计算吗？是存算分别的吗？
A10：咱们在此启动计算时，关键集中在最基础的一层，采用离线计算方式，由于离线计算在效率上更具优势。在线计算则关键用于减速和口头一些繁难的衍生操作，如组合或聚合。至于存算分别，我以为它更多地取决于底层技术架构中引擎的存算分别特性。假设底层引擎允许存算分别，咱们也会采用这种架构。
Q11：派生进去的目的普通是单个类型的目的落表。但是 BI 看板经常会须要拿各种类型的派生目的，这个怎样处置？
A11：关于处置多个派生目的的疑问，确实须要审慎处置。
首先，思索到咱们现有的目的曾经聚合在汇总逻辑表中，假设在 BI 工具中引入这个表，或许会出现数据量过大的状况。特意是当咱们面对的是领有数千个目的的大型逻辑表时，按需引入是必要的。
其次，为了提高效率和准确性，咱们也可以思索与下游的平台启动整合。这样，下游平台可以间接援用目的列表。之后，咱们可以智能将相关的数据集或底层逻辑表、物理表传输到下游平台，从而协助它们构建自己的数据模型。这种方式可以成功更为流利和高效的数据传输和处置。
总结来说，处置多个派生目的的疑问须要咱们综合思索数据量、效率和准确性等多个方面。经过按需引入数据、与下游平台深度整合等战略，咱们可以更好地满足业务需求并优化数据处置的全体成果。
