各位嘉宾、好友们，下午好。当天上午，咱们公司的 CEO 曾经在主会场的第一场分享了关于咱们公司的状况。或许大家对 Aloudata 还不太相熟，咱们是一家成立不久的初创公司。之前咱们的团队成员在阿里蚂蚁上班了一二十年，深知数据畛域尤其是供应侧在服务业务时存在许多痛点。因此，咱们宿愿经过一些新技术来协助大家处置日常上班中的疑问。
我当天的分享关键分为三部分。第一部分，咱们将讨论在业务对接环节中存在的疑问，以及能否有新的方法可以协助咱们处置这些疑问。第二部分，我将引见咱们守业后开发的产品化处置方案——第三代目的平台。我会说明这个产品具有哪些才干，以及它能为企业带来哪些价值。第三部分，我将分享这个产品在不同行业客户中的一些实在落地案例。
一、ETL 的原罪与 NoETL 全新思绪
首先，咱们知道，近年来每个企业和行业都在启动数字化转型。在这个环节中，数据人员收到的业务部门数据需求越来越多，对数据的时效性要求也越来越高。咱们发现，传统的数据从业人员通常经过开发少量面向业务场景的宽表和汇总表来极速照应业务需求。这造成整个数据管道和数据链路变得越来越长。许少数据同窗会埋怨，他们的数据加工链路有上百层，一旦出现疑问，他们很难极速排查并定位疑问。
需求的清楚增长让数据控制的难度越来越大。咱们以为，这面前的疑问关键是由于传统 ETL 作业启动了少量的反范式宽表和汇总表的加工。这种加工形式使得在整个数据处置环节中，很难在效率、品质和老本之间到达平衡。例如，假设一个业务需求须要极速照应，咱们或许就没有时期去启动充沛的数据校验和优化。
此外，假设须要防止重复开发，须要不同业务线的 ETL 工程师彼此沟通，是不是咱们数仓外面曾经积淀了这么一张表，是不是曾经开发好了这个字段。这种协同沟通的老本会很高，时期或许会很长。所以，在这种状况下，为了保证效率，或许就会存在数据的少量重复开发，会存在口径的差异。或许不同的业务提的需求是同一个目的，但拿到的结果是不同的。
假设我要处置这个品质疑问，防止重复开发，那前期就要投入少量的协同沟通老本，要把这个模型设计得很好。这个时刻，业务或许又等不迭，由于业务会感觉我只是提了一个便捷的需求，为什么要等这么长时期。所以就造成咱们如今堕入了这种老本、效率、品质的无法能三角。
那究竟有没有或许破解这个无法能的三角呢？其实从整个 MECE 准则来拆分，咱们刚刚讲到造成无法能三角的原罪是由于做了少量的反范式 ETL 开发宽表和汇总表的作业。那咱们是不是可以不去加工宽表汇总表，这样就把这个疑问的源头处置掉了？
大家也知道，当天企业的数据量越来越大，那当天咱们的查问引擎技术还没有开展到足够撑持这么大的数据量的直查，所以看起来这条路是无法行的。
那咱们换个思绪，假设要经过人工保证它的品质，保证不要做重复开发，须要很大的协同沟通老本，那是不是能够把人工的上班变成由系统来做，由于系统会知道究竟开发了哪些表，做了哪些目的的加工。这里咱们先给出一个论断就是可以从原来的人工加工变成 NoETL 智能化，并基于该理念开发了一款智能化的目的平台——Aloudata CAN。
Aloudata CAN 如何成功 NoETL 智能化呢？其**机制关键依托于两项关键技术才干。首先是语义化，其次是智能化。
每个企业都有其共同的行业特色和目的建模需求，这些都是各企业之间差异化的表现。如何让系统准确了解该如何处置数据和开发目的，这就须要第一项才干——弱小的目的定义才干。这象征着系统必定能够识别出每一个目的应当驳回的开发逻辑，在传统形式下，这些逻辑的开发通常由数据仓库的 ETL 工程师编写 SQL 来成功。如今，咱们宿愿经过低门槛的性能形式成功语义定义，让业务人员可以经过业务语义的性能表白向系统明白各名目的的业务计算逻辑。一旦系统把握了这些逻辑，咱们便能够确保数据仓库和 ETL 工程师专一于数据资产的积淀。
只需通知系统目的的业务计算逻辑和业务含意是什么，它就可以让系统去口头。这是第一点——语义化。第二点，或许大家会有不懂，由于前面提到如今数据量很大，假设只是通知了系统计算逻辑，它是一个虚构化的逻辑化的，怎样能处置大数据量下的查问性能疑问呢？能否对存储计算资源要求很高？
这就触及到咱们讲的第二个才干：智能化。当咱们面对大数据时，并不是真正地“干掉”了宽表和汇总表，而是把这部分从人工上班变成了系统智能化去做。系统会依据定义的业务计算逻辑智能翻译成 SQL，智能地启动链路编排，生成面向业务场景的宽表和汇总表。
接上去再开展讲一下这两方面详细技术的成功逻辑。在语义化方面，Aloudata CAN 蕴含了六个**才干。
第一个**才干是让系统知道目的的计算逻辑是什么，这面前须要咱们提供一个规范的目的定义才干。
咱们在做目的定义时经常须要跨表定义目的。假设说数仓不做宽表的加工了，那咱们怎样能够成功跨表的目的定义？咱们的解法是构建一个语义模型，再在这样的一个语义模型基础之上，把目的拆解成一些最原子的要素，比如说原子目的、时期限定、业务限定、衍生形式等。有了这个拆解之后，实践上咱们给到业务的体验是一些语义化、性能化的模板，不须要去写 SQL 了。
假设不须要去写 SQL，但系统查的是一个 SQL，怎样能够成功这种复杂的表白呢？这面前实践上是依赖于第二点**才干——一个弱小的目的函数体系。
这个函数体系也是咱们自研的，外面蕴含了惯例日期文本、聚合函数，也蕴含了复杂的窗口函数和剖析函数。咱们会把这样的一个函数形象成一些模板化，关于用户来讲，他只需去点点选选就可以在界面上性能进去一个复杂的目的，比如说咱们要去性能一个门店的开售金额，例如在华东地域的排名。原来须要在数仓写 SQL，写开窗函数去成功，但在 Aloudata CAN 外面，只须要经过性能化的形式，不会写 SQL 也能定义进去。
第三点**才干是智能构建多档次、多聚合的义务 DAG（有向无环图）。例如，在构建目的的第一阶段，系统会先计算每个门店的开售量；第二阶段，依据开售量启动排名；第三阶段，得出排名结果。基于这种形式，无论目的多复杂，都可以经过多档次、多聚合的形式构建 DAG。
接着，系统会依据用户性能的多档次、多聚合要求，智能将这些性能转化为 SQL 语句，这是第四大才干。
此外，在 SQL 翻译环节中，也触及性能优化疑问。这就触落第五点**才干——查问 SQL 优化。一是基于目的计算自身的优化，如关联下推、多层 AGG 兼并和裁剪；二是基于规定优化器（RBO）启动的优化，如 Limit 下推、子查问裁剪和列裁剪等。
第六点**才干是自建内存计算引擎优化查问效率。这个计算引擎是专门针对目的场景开发的，包括目的剖析器、RBO 和 CBO 的拆分、DAG 构建、义务控制、算子级别口头器、缓存等。
基于这六大才干支持的语义化才干，咱们经过定义大批的原子目的，就可以轻松成功少量派生目的的运行场景。在很多企业中，实践须要的原子目的数量并不多，一条业务线或许只须要大概一百个原子目的。过去，企业或许会基于这些原子目的定义上千个派生目的，造成了渺小的目的控制变卦老本。Aloudata CAN 的方案则可以降落这一老本，优化企业数据剖析的效率与效果。
首先，咱们宿愿经过定义大批的原子目的来笼罩更多派生目的的场景。其次，从目的控制的角度来看，咱们知道企业中存在目的口径不分歧的疑问。虽然企业或许经过一些目的控制工具或目的口径注销工具来启动控制，但这并不能齐全处置疑问。咱们发现，要真正处置这一疑问的**在于，须要将目的的定义逻辑从数据仓库转移到目的平台，这样才干成功智能化的同名同义校验，确保目的计算逻辑积淀在目的平台上，从而成功口径的一致控制和分歧性。
此外，咱们还支持一些复杂的原子目的和派生目的的定义，这些都是经过模板化的性能来成功的。以上可以标明，Aloduata CAN 具有了将目的计算逻辑告知系统的语义才干，系统知道如何计算这些目的。
在处置大数据量时，咱们或许会遇到性能疑问，因此须要第二个才干——智能化才干。这种智能化才干实践上是经过系统的形式来平衡性能老本和时效性。
在智能化方面，Aloudata CAN 是经过系统的形式来平衡性能老本和时效性。其**步骤有四个。
首先是基于前面讲述的目的语义，Aloudata CAN 能够智能构建启生物化视图，将查问恳求转变成 DAG 的构建，而后再将其拆分红多层不同的物化视图，以此来保证整个查问的性能和灵敏性。同时也支持人工指定构建物化视图，例如在控制驾驶舱中，指导或许须要依据特定目的和维度启动极速照应，因此可以手动选用这些目的和维度，系统将智能创立物化视图启动估量算，相似于以前在数据仓库中人工创立的汇总表。
在物化视图的多层构建战略中，越贴近明细数据的物化视图灵敏性越高，越凑近结果的物化视图性能越高。前者实用于灵敏剖析场景，后者实用于控制驾驶舱和一些固定报表的场景。在两者之间，咱们还可以针对复杂目的（如先计算均值再计算排名）的全体构建物化视图，以及构建行间偏移类目的（如最近 30 天的日均买卖客户数等）的物化视图。
在整个物化视图的构建环节中，咱们可以依据须要调整减速的粒度，以成功性能和老本的最优平衡。此外，Aloudata CAN 支持视图依赖视图的构建形式，例如基于日常的聚合视图来构建行间偏移的物化视图。系统智能生成视图依赖相关有助于防止重复构建。假设系统检测到已存在相应的物化视图，就不会启动重复的构建上班。
Aloduata CAN 的物化减速战略遵照了数据仓库中的最佳工程通常。
第一个战略是冗余维度打宽。即针对罕用的维度，将其与明细理想表启动预打宽，这样下层在经常使用时就可以基于该明细宽表启动计算，可以缩小屡次关联带来的计算消耗。
第二个战略是同理想同实体兼并计算。如针对订单表的多个不同的目的，可以放在一同启动计算，缩小对理想表的屡次扫描。
第三个战略是长周期依赖短周期。如已有物化视图是基于“天”粒度构建的，那么，派生目的中的近 7 天、本月、近 30 天等等，都可以基于该天粒度的物化视图启动构建。
第四个战略是细粒度上卷聚算计算。如已有物化视图的维度是 A、B、C、D，当用户新构建的物化减速方案是基于 A、B 两个维度时，则可以来 A、B、C、D 四个维度的物化视图启动上卷，防止了从原始数据启动计算。
以上四种例子较为经常出现，Aloudata CAN 还设置了许多其他减速数据处置的战略。
第二步是物化视图的调度更新机制。假设抢先数据出现变化，咱们须要知道何时刷新物化视图的数据。这可以经过两种形式成功：一是与抢先义务对接，经过调度通知触发实时更新；二是设置定时更新机制，系统会智能处置物化视图的变卦和刷新。这种机制能够识别哪些目的遭到影响，并针对这些目的启动更新。
Aloudata CAN 基于目的的血统相关，构成一个网络算子图谱。例如，假设一个维度表或理想表出现变卦，咱们不会对一切目的启动回刷，而是只针对受影响的目的启动部分回刷，以尽量缩小回刷范围。
第三步是物化视图的命中改写才干。用户在经常使用时通常不须要知道面前经常使用的是哪种表，查问时，系统可以依据用户的查问行为将查问路由到最婚配的物化视图上。
Aloudata CAN 经过逻辑树的形式判别用户的查问应该路由到哪一个物化视图，或是间接下推启动实时计算。这种判别或许基于 BI 工具动员的查问，也或许是来自咱们的 APP 或业务系统的查问。在动员查问时，Aloudata CAN 会遍历物化视图。
首先审核能否能命中顶层的物化视图，即能否能间接获取查问结果。假设顶层的物化视图没有命中，咱们会继续向下遍历，审核能否有合乎行间偏移的物化视图。假设这一层也未命中，咱们将继续查找能否有合乎特定粒度（如按天）的个别物化视图。假设这些都未命中，最后咱们会尝试兜底的星型模型物化视图。假设连兜底的物化视图都未命中，那么咱们将间接查问底层的明细数据，并启动实时计算。
查问假设命中多个物化视图，Aloudata CAN 会选用一个最优的。这个最优选用基于几个准则：数据量能否最小，目的能否与业务需求最婚配，以及时期范围能否最凑近。
最后一步是关于物化视图生命周期的控制。在传统的数据仓库环境中，颁布新表容易，但下线旧表难，由于 ETL 工程师不容易判别下游能否还在经常使用这张表。如今，系统能够智能识别物化视图能否被下游消费，从而成功有效物化视图的智能回收，缩小了保养老本微危险。
总结一下：传统人工启动的宽表和汇总表加工可以经过 NoETL 智能化成功。这得益于两个**技术才干。首先是语义化才干，它准许任何目的的计算逻辑被定义并一致控制，这是智能化的前提。其次，一旦一切复杂的目的都能被表白，咱们就能成功这些目的的极速计算，从而保证在大数据量下也能有良好的性能和业务照应效率，同时确保数据的分歧性。
二、第三代目的平台的才干与价值
咱们将 Aloudata CAN 定义为第三代目的平台，即 NoETL 智能化的目的平台。在讨论第三代目的平台之前，咱们先便捷回忆一下第一代和第二代目的平台的特点。第一代目的平台关键是将原本线下经过 Excel 保养的目的字典转移到线上，成功了目的口径的注销和控制。但在这一代中，目的的定义和开发是分别的，无法成功智能化消费和一致控制。
第二代目的平台遭到近年来国外 Headless BI 概念的启示，将目的平台作为一个独立层，位于数据仓库和 BI 工具之间。这一代目的平台尝试处置了一些智能化和语义化的疑问，但依然存在局限性。由于缺乏弱小的语义化和智能化才干，许多复杂的目的仍需回到数据仓库中由 ETL 工程师处置，因此第二代平台依然依赖于 IT 部门来开发复杂的宽表。
第三代目的平台的**在于成功目的的定义、开发和运行的一体化，即所谓的“管研用一体化”。这种一体化的面前，是四大**才干的支持。首先是目的的规范定义才干，这不只仅是对目的启动定义，还包括了目的的控制。与以往在数据曾经开发成功后才启动控制不同，第三代平台宿愿经过当时的规范定义来防止疑问的出现。由于目的的语义已在平台上获取了很好的积淀，咱们可以应用这些语义启动同名同义的智能校验，从而提高控制效率和准确性。
总的来说，第三代目的平台经过强化语义化和智能化，以及成功目的控制的高度集成，为企业带来了更高效和一致的目的控制处置方案。就是比如说雷同的一个目的，或许每团体首先看到的是称号相反，我只准许它存在一个。其次，它的语义表白，即业务的口径是一样的，但原来或许有不同的称号。例如在批发或电商畛域，有的目的叫 GMV，有的叫买卖金额。实践上它们面前的逻辑是一样的，咱们的系统能够智能识别这一点，由于咱们经常使用的是智能翻译的 SQL，咱们知道它们的逻辑是相反的。因此，咱们也会以为它是一个同义不同名的目的，并且只准许定义一次性。
其次，目的定义成功后，就可以立刻便用。假设没有性能疑问，实践上由于咱们存储的是逻辑数据，不须要像传统数仓那样启动测试、颁布或运维调度义务等。经过界面化性能成功后，就可以间接经常使用。假设在环节中遇到性能疑问，就可以经常使用咱们之前提到的智能化目的消费，经过这种形式可以成功一级消费性能。
第三点是，目的定义成功后，咱们的系统会智能生成一个以目的为目录的企业一致目的体系。传统上或许依托工程师或剖析师在自己的文档中保养企业目的体系，但关于企业来说，咱们在与客户交换时会征询企业有多少目的，每个业务有多少目的，这些目的是如何构成的。很少有企业能够清楚地回答进去，由于他们或许从未清点过或许清点的难度十分大。但有了这样的一个目的平台，它会智能生成一个目的目录，咱们能清楚地看到企业里总共有多少目的，每个目的的业务逻辑是什么，每个目的的血统加工逻辑是什么，是基于咱们数仓的哪张表，经过哪个字段加工进去的。
此外，咱们经常会发现，或许在业务开展环节中，会存在目的的口径版本变卦。原来的版本变卦或许在数仓中启动了版本保养，也或许没有。比如我之前在阿里做剖析师时，咱们会发现给业务看的数据上方都会有一个补充说明，比如什么时刻我对这个口径启动了调整，因此调整前后数据或许会有变化。在咱们的目的目录中，咱们提供了目的的多版本控制性能，这使咱们能够清楚地了解一个目的在历史上教训了多少次口径的变卦，并且可以明白每一个版本口径的差异。假设须要回溯到之前的版本，咱们也可以经过一键操作便捷地回到历史版本，这是目的目录中的一项关键性能。
此外，目的目录的另一个关键特点是能够将企业的业务知识经过产品化的形式积淀上去。在高员工流动的环境中，很多企业面临的一个疑问是，员工离任后，之前在数据仓库中加工的逻辑信息交接不到位，新接手的员工往往须要投入少量上班量来了解和继续之前的上班。经过 Aloudata CAN，原有的加工逻辑可以被完整地承接上去，即使出现人员变化，也能极速对接上这些目的的逻辑。
在目的消费方面，咱们经过规范的 JDBC 和 API 接口，可以成功与企业现有的 BI 工具、业务系统以及控制驾驶舱的无缝对接。
经过这四大才干，咱们宿愿为企业带来以下效果：首先，业务人员能够愈加明晰地理解目的的口径和计算形式，由于目的平台使得加工链路可视化、变卦历史可查问。其次，关于数据人员和控制人员而言，由于一切逻辑都是在名目初期经过严厉的校验确定的，并且经过语义化的定义，咱们可以成功一个目的定义一次性，少量派生目的无需重复定义，从而成功高效控制。最后，关于业务人员来说，他们可以更灵敏地经常使用目的，从各个维度消费和剖析数据，甚至可以下钻到面前的明细数据，并基于恣意维度启动挑选。这大大提高了业务人员的上班效率和满意度。基于咱们的语义模型才干，它也能成功跨多个理想表的多个目的和来自多个维度表的多个维度的综合剖析，而无需经过技术同窗将多个理想表启动汇总开发。
咱们将 Aloudata CAN 的价值从供应侧（IT）和消费侧（业务）启动了总结。对 IT 的价值体如今能够成功运行层 NoETL，大大缩小了开发和运维的上班量。这是由于，传统数仓通常有四层结构：从贴源层到公共层，再到 DWS 层，最后是集市层或运行层。如今，咱们让 IT 人员专一于公共层的资产开发，业务场景端的集市层可以经过咱们的目的语义层来代替，经过目的的定义来取代集市层的开发。这样不只缩小了少量的开发和运维上班量，也缩小了与业务沟通和协作的老本。
对业务侧的价值表现，首先，咱们提供了一种以目的为中心的业务自主剖析体验。传统上，许多 BI 工具还是基于数据集、表和字段这种技术逻辑的形式。如今，咱们提供了一种用户只需知道他们想要剖析的目的，这些目的实践上更贴近他们的业务言语，因此他们可以间接拖拽目的和维度启动剖析，只需有权限即可。正如我之前提到的，他们可以选用来自不同理想表的目的和来自不同维度表的维度，将它们放在一同启动图形化剖析。
此外，咱们还支持一种状况目的标签化的灵敏需求。例如，在电商或金融行业，咱们或许会经常举行一些活动，在活动时期，咱们经常会收到少量的暂时取数需求。这些暂时取数的需求关键是宿愿经过特定目的将某些客户个体标签化或维度化，以便在活动时期圈选出特定的人群。详细来说，可以经过选用满足特定条件的用户 ID，例如最近一个月买卖次数超越三次的用户，来检查他们在活动时期能否访问了活动页面、支付了活动券或购置了商品。Aloudata CAN 使业务部门能够自主成功这些操作。
其次，关于目的的智能归因，虽然许多 BI 工具提供了归因才干，但关键在于归因算法所经常使用的数据是明细数据还是汇总数据。传统形式下，归因算法少数经常使用的是曾经聚合过的数据。而在咱们的目的平台上，倡导的最佳通常是基于公共层的明细数据来定义目的，这样可以启动更深化的维度拆解，成功从广度到深度的归因剖析。
最后，关于大模型的运行。OpenAI 等机构曾经提出，间接经常使用人造言语处置（NL to SQL）或许难以保证百分之百的精准度。许多企业的 AI 团队也发现，虽然启动了屡次调优，运行场景依然有限，笼罩的场景不够宽泛，或精准度无余。因此，面前须要一个弱小的语义模型来撑持大模型，确保数据品质和业务知识的有效积淀，这关于提矮小模型的运行效果至关关键。
咱们发现，目的与数据模型的联合，在许多企业内被以为是打造交互式对话剖析体验的最佳路径。咱们也正与不同行业的客户共同发明这样的体验。当然，目前咱们尚未推出 ChatBI 的产品，咱们正在与一些顶尖的金融客户协作，他们领有自己的数据模型，咱们的义务是将这些底层才干与他们的模型才干相联合。咱们也在思考，下半年将朝这个方向进一步开展。
做个总结：第三代目的平台给咱们 IT 部门带来的体验扭转，表如今大幅缩小目的重复开发的上班量和运维变卦的上班量。对业务部门来说，它提供了真正处置“最后一公里”自主剖析疑问的体验，让业务人员能够自助成功剖析上班，而不须要为参与字段或维度而频繁咨询 IT 部门。
三、第三代目的平台做轻数仓通常
以上内容是关于技术与产品的一些引见。接上去，咱们分享在一些企业中实在落地的通常状况。由于咱们团队来自阿里巴巴和蚂蚁团体，对电商和金融畛域有深化了解，因此，我将举例引见金融行业的两个案例，涵盖证券和银行业务。
首先是来自证券行业的一个客户案例。先来了解一下这家公司的 IT 团队。他们没有复杂的专职剖析岗位，仅有一个技术部，而担任数据的技术人员人数也十分有限。
在与咱们协作前，他们面临三个关键的痛点。首先，为了满足业务需求，这些 IT 人员须要开发和保养少量的数据表，ETL 的运维上班量渺小，尤其在他们人手十分有限的状况下。
另外一个痛点是，证券行业的专业知识要求高，了解业务逻辑面前的细节极端艰巨。这经常造成 IT 人员与业务部门之间沟通不畅。即使 IT 部门开发了数据表，业务部门在验证时仍或许提出与 IT 了解不分歧的需求，这样就须要重复调整目的口径，极大参与了上班量和沟通老本。这家公司宿愿能将目的定义的上班交由业务人员自行成功，以此缩小重复沟通的时期和精神损耗。这是他们的第二个痛点。
第三个痛点就是数据照应效率的疑问。如今一切企业都越来越依赖数据启动业务决策，而这家客户的数据团队人手十分有限，极速照应业务需求的应战十分大。
在咱们提供的处置方案中，企业只需处置公共层面上的明细资产积淀，并围绕行业十大模型启动资产积淀。
于是，它实践上从新定义了目的开发的形式：从过去须要开发少量运行层的表，到如今简化为在公共层应用目的平台就可以轻松地成功。举例来说，在该企业的资管业务线上，咱们将目的分为原子目的、派生目的和复合目的三种。资管业务作为证券行业的**业务之一，业务人员便能够应用原子目的和维度自主组合出所需的派生目的。
这个企业，虽然人力资源有限，却成功地提供了一种以目的为中心的自主剖析体验。业务人员可以经常使用便捷直观的形式，灵敏地启动剖析。他们的 IT 团队仅开发了约 80 个基础和复合目的，但有超越 300 个可供业务人员自在组合的维度。
这样的做法，使得在目的开发上节俭了大概 70% 的上班量。客户评价称，一个工程师原本一天只能开发约 3.12 个目的，但驳回咱们的产品后，他们半天就能处置超越 20 个基础目的，大幅提高了开发效率。此外，产品的性能化界面，还降落了操作复杂 SQL 的门槛，让应届生和实习生也能轻松定义目的。
第二个案例是银行业的，这个协作中，客户面临三个关键疑问：首先是 BI 工具的性能疑问，查问 3s 关上率不到 70%，这是由于数据仓库的性能与灵敏性之间须要平衡；其次，业务剖析环节中，业务部门在检查数据后常有新的需求，须要 IT 部门预备数据，造成数据剖析难以买通“最后一公里”的疑问；第三，总行和分行选用了不同的 BI 工具，造成无法共享和复用数据。
这家银行领有数百到上千人的 IT 团队，他们选用自建交互层面，仅在目的语义层经常使用了咱们的服务。经过咱们提供的 API 接口，客户能够自助地从数据预备到剖析，成功一体化操作，清楚优化了交付效率。此外，从只能启动客群级别的剖析优化到了客户级别的剖析，并且成功了总行和分行经常使用不同 BI 工具间的目的复用。
去年一期的协作成绩包括：原本一切数据集都须要科技部 IT 团队处置，如今 65% 的上班可以由业务部门自主成功；原本在多个 BI 工具中积淀的目的下沉到咱们的目的平台成功了共享和复用；经过咱们的智能化才干，成功了 95% 的查问在三秒内成功。这是一期的成绩，往年咱们也在继续启动第二期的上班。
在这个环节中，咱们发现它扭转了企业外部业务的协作形式，特意是 IT 人员和业务人员之间的协作。他们自己总结出了一种叫做“136”的协作形式。“136”指的是的科技人员担任语义模型关联相关的建设，以及整个企业的通用基础目的和原子目的的加工与定义，这部分目的占比 10%。其他的部分，许多业务部门都有自己的业务剖析师，这些剖析师围绕业务条件定义通用的派生目的，这部分占比 30%。最后，60% 的灵敏需求则交给业务人员自己，让他们像搭积木一样选用目的和维度，以满足自己的需求。这就是“136”协作形式的**内容。
Q1：关于目的中心，实践上有很多运行场景，比如用户须要提取一些清复数据。这种数据提取可以成功吗？
A1：是的，这外面关键分为两部分。第一部分是提取暂时数据，这种数据通常是基于公共层的明细数据定义的，比如提取用户买卖的明细数据，这种是罕用的目的，如买卖金额，咱们的平台可以成功。第二部分是翻新业务的目的，这种目的或许没有固定上去。关于这类目的，咱们不倡导在目的平台上处置，由于咱们以为一个目的应该具有必定的通用性、实用性和继续性才适宜进入目的平台。然而，咱们发现很多企业的暂时数据或目的实践上是可以经过在平台上叠加各种挑选条件来处置的。
Q2：您好，我想征询一下，大少数企业或许曾经领有数据仓库，并且曾经建设了很多宽表，甚至曾经部署了自己的目的系统，并领有很多目的。当它们切换到您的系统时，假设在您的系统中定义了原子目的，它们还须要定义一些限定词，并配合定义复合目的。这些内容如何与我原有的宽表和目的系统绑定，以构成物理表上的相关？
A2：对，这确实是咱们在与许多企业交换时经常遇到的疑问。首先，咱们曾经落地的一些客户，他们原本领有自己的目的平台，但那个平台仅用于目的口径的注销，不能成功目的的实践开发。在这种状况下，咱们可以经过 API 接口，让他们在原有平台上录入目的的业务逻辑，而实践的计算口径则在咱们的平台上启动开发。
其次，确实许多企业曾经有了少量的宽表和汇总表。咱们不要求客户丢弃经常使用这些现有的表。您可以将宽表和汇总表接入到咱们的目的平台，但这样做无法成功目的的灵敏运行。
因此，咱们通常倡导企业在实施环节中采取逐渐战略。例如，您可以从那些经常提出需求、痛点较为突出的业务线开局，先不动原有的宽表和汇总表，而是逐渐启动优化。比如咱们最近与一家大型股份制银行协作，他们的第二期名目名为“虚构集市层”，他们方案逐渐优化原有数据仓库中的内容。咱们倡导从业务条件通顺、需求较多的部分开局，缓缓过渡到这种形式，由于这是一个渐进的环节。