分享实录
一、导语
目前“中台”的概念很火，包括数据中台、AI 中台、业务中台、技术中台等。宜信技术学院沙龙上，井玉欣博士分享了宜信的 AI 中台实践：《宜信敏捷数据中台建设实践》。
本次分享分为三个部分 ：
二、宜信数据中台顶层设计
2.1 特点和需求
关于数据中台的建设，目前并没有一个标准的解决方案，也没有一个数据中台能适用于所有的公司，每个公司都应该结合自己的业务规模及数据需求现状来研发适合自己公司的数据中台。
在介绍宜信敏捷数据中台的顶层设计之前，我们先来了解其背景：
2.2 定位
关于数据中台的定位，每个公司都不太一样。有的公司业务比较专注，只有一条业务线，那它在建设数据中台的时候，可能需要一个垂直的平台，直达前线，更好地支持前线的运作。
前文提到宜信业务线很多，且在众多业务中没有一个主体业务，这就相当于所有业务线都是主体。基于这样的背景，我们需要一个平台化的数据中台，来支撑所有业务线的需求和运作。
图 1 定位
如上图所示，绿色的部分是宜信敏捷数据中台，我们称之为“ADX 数据中台平台”，“A”即“Agile（敏捷）”，之所以称为“平台”，是因为我们希望将其打造成一个服务于全业务线的平台系统，助力业务发展。
敏捷数据中台处于中间位置，最底下是各种数据集群，最上端是各个业务领域数据团队。数据中台通过整合处理数据集群的数据，为业务领域数据团队提供自助化、实时化、统一化、服务化、管理化、可溯化的数据服务。
右边三个蓝色的板块分别是数据管理委员会、数据运维团队和数据安全团队。前文提到宜信对数据安全的要求非常高，所以设置了专门的数据安全团队来规划公司数据安全的流程和策略；数据管理委员会负责数据的标准化、流程化，补齐技术型驱动的数据中台的推动效率，保证有效沉淀和呈现数据资产。
我们对 宜信敏捷数据中台的定位 是： 从数据技术和计算能力复用，到数据资产和数据服务复用，敏捷数据中台会以更大价值带宽，快、准、精让数据直接赋能业务 。
2.3 价值
宜信敏捷数据中台的价值集中表现为三个方面： 快、准、省 。
图 2 价值
2.4 模块架构维度
图 3 模块架构维度
如图所示，宜信敏捷数据中台的建设也是基于“小前台，大中台”的共识。整个中间部分都属于敏捷数据中台包含的内容，左边绿色部分是基于数据维度来看整个中台，右边蓝色部分则是基于平台维度来看中台。
值得一提的是，这些模块都不是从 0 开发的，而是基于我们已有的开源工具。首先，基于成熟的中间件工具来进行开发，可以节约开发的时间和成本；其次，开源工具成为引擎，可以共同合力支撑更大的一站式平台。
2.5 数据能力维度
图 4 数据能力维度
将上述架构模块重新按照能力维度划分，可以分成若干层，每一层都包含若干能力。如图所示，可以清晰地看到建设数据中台需要具备哪些数据能力，这些能力都对应哪些功能模块，分别能解决什么问题。此处不再展开赘述。
三、从中间件工具到平台
3.1 ABD 总览
图 5 ABD 总览
中间件工具指 DBus、Wormhole、Moonbox、Davinci 四大开源平台，它们从敏捷大数据（ABD，Agile BigData）理念中抽象而出，组成 ABD 平台栈，敏捷数据中台则被我们称为 ADX（Agile>
一开始，基于对业务需求共性的抽象和总结，我们孵化出若干个通用的中间件，去解决各种各样的问题。当出现更为复杂的需求，我们尝试将这些通用的中间件进行组合运用。实践中，我们发现经常会使用到某些特定的组合，同时，从用户角度来看，他们更希望能实现自助化，直接拿过来就能用，而不是每次都要自己去选择和组合。基于这两点，我们对这几个开源工具进行了封装。
3.1.1 ABD-DBus
DBus（数据总线平台），是一个 DBaaS（Data Bus as a Service）平台解决方案。
DBus 面向大数据项目开发和管理运维人员，致力于提供数据实时采集和分发解决方案。平台采用高可用流式计算框架，提供海量数据实时传输，可靠多路消息订阅分发，通过简单灵活的配置，无侵入接入源端数据，对各个 IT 系统在业务流程中产生的数据进行汇集，并统一处理转换成通过 JSON 描述的 UMS 格式，提供给不同下游客户订阅和消费。DBus 可充当数仓平台、大数据分析平台、实时报表和实时营销等业务的数据源。
开源地址：src="https://static001.infoq.cn/resource/image/3a/6e/3a58d2f235e3f869973fdbe10304826e.png"/>
图 6 DBus 功能及定位
如图所示，DBus 可以无侵入地对接各种数据库的数据源，实时抽取增量数据，做统一清洗和处理，并以 UMS 的格式存储到 Kafka 中。
DBus 的功能还包括批量抽取、监控、分发、多租户，以及配置清晰规则等，具体功能特性如图所示。
上图右下角展示的是 DBus 的一个截图，用户在 DBus 上可以通过一个可视化页面，拉取增量数据，配置日志和清洗方式，完成实时数据抽取等工作。
图 7 DBus 架构
从如上架构图可以看到 DBus 包括若干不同的处理模块，支持不同的功能。（GitHub 有具体介绍，此处不作展开。）
3.1.2 ABD-Wormhole
Wormhole（流式处理平台），是一个 SPaaS（Stream Processing as a Service）平台解决方案。
Wormhole 面向大数据项目开发和管理运维人员，致力于提供数据流式化处理解决方案。平台专注于简化和统一开发管理流程，提供可视化的操作界面，基于配置和 SQL 的业务开发方式，屏蔽底层技术实现细节，极大的降低了开发门槛，使得大数据流式处理项目的开发和管理变得更加轻量敏捷、可控可靠。
开源地址：src="https://static001.infoq.cn/resource/image/ad/30/add97d13d38aae03babbfec1d7b89730.png"/>
图 8 Wormhole 功能及定位
DBus 将实时数据以 UMS 的格式存储到 Kafka 中，我们要使用这些实时的流式数据，就要用到 Wormhole 这个工具。
Wormhole 支持配置流式化的处理逻辑，同时可以把处理完之后的数据写到不同的数据存储中。上图中展示了很多 Wormhole 的功能特性，我们还在开发更多新的功能。
上图右下角是 Wormhole 的一个工作截图，Wormhole 作为流式平台，自己不重新开发流式处理引擎，它主要依赖 Spark Streaming 和 Flink Streaming 这两种流式计算引擎。用户可以选择其中一个流式计算引擎，比如 Spark，配置流式处理逻辑，确定 Lookup 库的方式，并通过写 SQL 来表达这个逻辑。如果涉及 CEP，当然就是基于 Flink。
由此可以看出，使用 Wormhole 的门槛就是配置加上 SQL。这也符合我们一直秉承的理念，即用敏捷化的方式支持用户自助玩转大数据。
图 9 Wormhole 架构
上图展示的是 Wormhole 的架构图，包含很多功能模块。介绍其中的几个功能：
3.1.3 ABD-Moonbox
Moonbox（计算服务平台），是一个 DVtaaS（Data Virtualization as a Service）平台解决方案。
Moonbox 面向数据仓库工程师/数据分析师/数据科学家等， 基于数据虚拟化设计思想，致力于提供批量计算服务解决方案。Moonbox 负责屏蔽底层数据源的物理和使用细节，为用户带来虚拟数据库般使用体验，用户只需通过统一 SQL 语言，即可透明实现跨异构数据系统混算和写出。此外 Moonbox 还提供数据服务、数据管理、数据工具、数据开发等基础支持，可支撑更加敏捷和灵活的数据应用架构和逻辑数仓实践。
开源地址：src="https://static001.infoq.cn/resource/image/f5/cc/f5b2a1b5d79c9a036a0ce09abe24c6cc.png"/>
图 10 Moonbox 功能及定位
数据从 DBus 过来，经过 Wormhole 的流式处理，可能落到不同的数据存储中，我们需要对这些数据进行混算，Moonbox 支持多源异构系统无缝混算。上图展示了 Moonbox 的功能特性。
平时所说的即席查询并没有真正做到“即席”，因为需要用户先手工地把数据导到 Hive 再做计算，这是一个预置的工作。Moonbox 不需要事先把数据导到一个地方去，做到了真正的即席查询。数据可以散落到不同的存储中，当用户有需求时， 只需写一个 SQL，Moonbox 可以自动拆分这个 SQL，从而得知哪些表在哪里，然后规划 SQL 的执行计划，最终拿到结果。
Moonbox 对外提供标准的 REST、API、JDBC、ODBC 等，因此也可以将之看成一个虚拟数据库。
图 11 Moonbox 架构
上图展示的是 Moonbox 的架构图。可以看到 Moonbox 的计算引擎部分也是基于 Spark 引擎做的，并没有自研。Moonbox 对 Spark 进行扩展和优化，增加了很多企业级的数据库能力，比如用户、租户、权限、 类存储过程等。
从上图看，Moonbox 整个服务端是一个分布式的架构，所以它也是高可用的。
3.1.4 ABD-Davinci
Davinci（可视应用平台），是一个 DVaaS（Data Visualization as a Service）平台解决方案。
Davinci 面向业务人员/数据工程师/数据分析师/数据科学家，致力于提供一站式数据可视化解决方案。既可作为公有云/私有云独立部署使用，也可作为可视化插件集成到三方系统。用户只需在可视化 UI 上简单配置即可服务多种数据可视化应用，并支持高级交互/行业分析/模式探索/社交智能等可视化功能。
开源地址：src="https://static001.infoq.cn/resource/image/46/7d/46e415be23ef4d856e24b50a6e0ac77d.png"/>
图 12 Davinci 功能及定位
Davinci 是一个可视化工具，所具备的功能特性如图所示。
图 13 Davinci 架构
从设计层面来看，Davinci 有自己的完备和一致性的内在逻辑。包括 Source、View、Widget，支持各种数据可视化应用。
图 14 Davinci 富客户端应用
Davinci 是一个富客户端的应用，所以主要还是看它前端的使用体验、丰富性和易用性等。Davinci 支持图表驱动和透视驱动两种模式编辑 Widget。上图是一个透视驱动的效果样例，可以看到横纵坐标都是透视的，它们会将整个图切成不同的单元格，每个单元格里可以选择不同的图。
3.2 ABD 架构
图 15 ABD 架构
在 ABD 时代，我们通过 DIY 组合四个开源工具来支持各种各样的数据应用需求。如上图所示，将整个端到端的流程串起来，这个架构图展示了我们“有收有放把整个链路打通”的理念。
3.3 ADX 总览
发展到一定阶段时，我们需要一个一站式的平台，把基础组件封装起来，使得用户可以在这个平台上更简单地完成数据相关的工作，于是进入了 ADX 数据中台建设阶段。
图 16 ADX 总览
上图是 ADX 总览，相当于一个一级功能菜单。用户登录到平台，可以做以下事情：
3.3.1 ADX-DataHub 数据枢纽
图 17>
上图蓝色虚线框显示的是>
它是怎么做到的呢？通过将开源工具引擎化，然后进行整合 。举个例子：不同数据源，通过 DBus 实时抽取出来，经过 Wormhole 流式处理后落到 HDFS Log 数据湖中，我们把所有实时增量数据都存储在这里面，这就意味着我们可以从中拿到所有的历史变更数据，而且这些数据还是实时同步的。再通过 Moonbox 在上面定义一些逻辑，当用户提出想要某一历史时刻的快照或者增量数据，就可以即时计算并提供。如果想做实时报表，需要把数据实时快照维护到一个存储里，这里我们选择 Kudu。
流式处理有很多好处，同时也有短板，比如运维成本较高、稳定性较差等。考虑到这些问题，我们在>
假设用户自己有数据源，放在 Elasticsearch 或者 Mongo 里，也希望通过>
综上可以看出，DataHub 是在内部把几个开源平台常用的模式进行有机整合和封装，对外提供一致性、便捷的数据获取、发布等服务。 其使用方也可以是各种不同的角色 ：
图 18>
如图，将>
DataHub 与其他几个组件之间的关系也是非常紧密的。它输出的数据给 top="10527">3.3.2 ADX-DataLake 实时数据湖
广义的数据湖，就是把所有数据都放在一起，先以存储和归集为主，使用的时候再根据不同数据提供不同使用方式。
我们这里提到的是一个狭义的数据湖，只支持结构化数据源和自然语言文本这两种类型的数据归集，并且有统一的方式存储。
图 19>
也就是说我们的实时数据湖加了限制，公司所有结构化数据源和自然语言文本会统一实时汇总为 UbiLog，并由 ADX-DataHub 统一对外提供访问。UbiLog 的访问和使用只能通过 ADX 提供的能力输出，因此确保了多租户、安全、权限管控。
3.3.3 ADX-DataWorks 数据工坊
主要的数据加工都是在>
图 20>
如图来看>
所以>
上图左侧有一个数据建模师的角色，他在>
图 21>
如图，将 top="11676">3.3.4 ADX-DataStar 数据模型
图 22>
DataStar 跟数据指标模型或数据资产相关，每个公司都有自己内部的数据建模流程和工具。 DataStar 可以分为两个部分 ：
DataStar 是 DW 层的事实和维度表组成的星型模型，可以最后沉淀下来。但我们认为，从 DW 层到 DM 层或 APP 层，不需要写 SQL 开发了，只需要通过选维度和配置指标的方式，就可以自动可视化配置出来。
这样的话对使用人的要求就发生了改变，需要一个建模师或者业务人员来做这个事情，给他一个基础数据层，他根据自己的需求来配置想要的指标。整个过程，数据实施人员只需要关注 ODS 层到 DW 层就可以了。
3.3.5 ADXMgt/DataMgt 中台管理/数据管理
图 23 ADXMgt/DataMgt
中台管理模块主要关注租户管理、项目管理、资源管理、权限管理、审批管理等。数据管理模块主要关注数据管理层或数据治理层的话题。这两个模块从不同的维度对中间的三个主要组件提供支持和产生规则制约。
3.4 ADX 架构
图 24 ADX 架构
ADX 数据中台平台几个模块之间的关联如图所示。最底下是五个开源工具，每个模块都是对这五个开源工具的有机整合和封装。从图中可以看出各组件之间的关联非常紧密，其中黑色虚线代表的是依赖关系，绿色线条代表的是数据流转的关系。
四、典型案例分析
如上所述，我们基于几个开源工具进行有机整合和封装，打造了一个更加现代化、自助化、完备的一站式数据中台平台。那这个平台是如何发挥其作用，为业务提供服务的呢？本节将列举五个典型案例。
4.1 案例 1 — 自助实时报表
【场景】
业务领域组数据团队需要紧急制作一批报表，不希望排期，希望可以自助完成，并且部分报表需要 T+0 时效性。
【挑战】
【方案】
图 25 自助实时报表工作流程
用 ADX 数据中台解决自助实时报表的问题。
【总结】
【能力】
这个场景需要用到很多数据能力，包括：即席查询能力、批量处理能力、实时处理能力、报表看板能力、数据权限能力、数据安全能力、数据管理能力、租户管理能力、项目管理能力、作业管理能力、资源管理能力。
4.2 案例 2 — 协作模型指标
【场景】
业务线需要打造自己的基础数据集市，以共享给其他业务或者前线系统使用。
【挑战】
【方案】
图 26 协作模型指标工作流程
用 ADX 数据中台解决协作模型指标的问题。
【总结】
【能力】 本案例需要的能力包括：数据服务能力、即席查询能力、批量处理能力、数据权限能力、数据安全能力、数据管理能力、数据资产能力、租户管理能力、项目管理能力、作业管理能力、资源管理能力。
4.3 案例 3 — 敏捷分析挖掘
【场景】
业务领域组数据分析团队需要自助的进行快速数据分析挖掘。
【挑战】
【方案】
图 27 敏捷分析挖掘工作流程
用 ADX 数据中台解决敏捷分析挖掘的问题。
【总结】
图 28 敏捷分析挖掘示例
举个例子，一个用户打开 Jupyter，import 一个 mbpy 的库包，并以用户身份登录 Moonbox，就可以查看管理员授权给他的表。他可以运用拿到的数据和表进行分析、计算等，而不需要关注这些数据来自哪里，这对用户来说是一个无缝的体验。
如上图，有两张表，一张表是 5000 多万条数据，存储在 Kudu 里；另一张表是 600 万多条数据，存储在 Oracle 里。数据存储在异构的系统中，且 kudu 本身不支持 SQL。我们通过 Moonbox 制定逻辑，认为数据都在一个虚拟数据库中， 只用了 1 分 40 秒就计算出结果。
【能力】
本案例需要的能力包括：分析钻取能力、数据服务能力、算法模型能力、即席查询能力、多维分析能力、数据权限能力、数据安全能力、数据管理能力、租户管理能力、项目管理能力、资源管理能力。
4.4 案例 4 — 情景多屏联动
【场景】
为了支持全方位的场景化和数字化驱动，有时会需要大中小智多屏联动，大屏即为放映大屏，中屏即为电脑屏幕，小屏即为手机屏幕，智屏即为聊天客户端屏幕。
【挑战】
【方案】
图 29 Davinci 的 Display 编辑页面
上图展示的是 Davinci 的 Display 编辑页面，可以通过挑选不同的组件、调整透明度、任意摆放位置、调前景背景、颜色缩放比例等，自由地定义想要的展示样式。
图 30 Davinci 配置大屏
图 31 Davinci 配置小屏
图 32 智屏
上图展示的是智屏的示例。我们公司内部有一个基于 ConvoAI 的聊天机器人，可以通过一个聊天窗口，跟用户互动，针对用户需求返回结果，包括图表等。
4.5 案例 5 — 数据安全、管理
图 33 数据安全管理工作流程
这个案例比较简单，一个完备的数据中台，不仅有应用客户场景，还有管理客户场景，管理客户典型的比如数据安全团队和数据委员会。
五、总结
本次分享主要介绍了宜信敏捷数据中台的顶层设计和定位、内部的模块架构和功能、以及典型应用场景与案例。我们立足于宜信业务需求现状与数据平台发展背景，基于五大开源工具进行有机组合和封装，结合敏捷大数据的理念，打造适合宜信自己业务的一站式敏捷数据中台，并在业务及管理中得以应用与落地，希望能为大家带来启发和借鉴。
Q：企业能纯粹依靠开源社区的开源工具来搭建数据中台吗？
A：数据中台是要切合企业实际情况和目标去建设的，有些好的开源工具本身已经很成熟，不需要重复造轮子，同时也有一些企业根据自身环境和需求，需要定制化开发。所以一般数据中台都会既有开源工具选型，也会有结合自身情况的企业内通用组件的开发。
Q：数据中台建设中，需要避免哪些弯路、哪些坑？
A：数据中台比纯技术平台要求更多直接赋能业务的能力建设，如数据资产沉淀、数据服务建设、数据加工流程工艺抽象、企业数据标准化安全化管理等，这些可能都无法依靠纯技术驱动自下而上地推动，而是需要公司层面和业务层面达成一致认识和支持，并且由业务实际需求驱动数据中台迭代建设的。这样的自上而下和自下而上相结合的迭代方式，可以有效避免不必要的短视和过度设计。
Q：数据中台建设完毕，其成熟度和效果如何评估？
A：数据中台的价值由驱动的业务目标来衡量。定性来说，就是是否真正做到了快、准、省的效果；定量来说，可以通过平台组件复用度、数据资产复用度、数据服务复用度等指标来评估成熟度。
Q：平台的元数据是怎样管理的？
A：元数据是一个独立的大话题，从元数据类目划分，到如何采集维护各种元数据，再到如何基于元数据信息打造各种元数据应用等，是可以单独拿出一个完整的分享来探讨的。具体到宜信 ADX 的元数据管理，我们也是按照上述思路进行，先是整理出全景元数据类目划分，然后很重要的一点是“业务痛点驱动元数据体系建设“，我们会根据目前公司对元数据最迫切的需求圈定优先级，然后在技术层面可以通过 Moonbox 进行各种数据源的基础技术元数据采集，基于 Moonbox 的 SQL 解析能力来生成执行血缘关系等，最后根据业务的实际痛点，比如上游源数据表结构变更会如何影响下游数据应用（血缘影响度分析），下游数据问题如何追溯上游数据流转链路（数据质量诊断分析）等，迭代的开发一个个元数据应用模块。
Q：数据建模师建模的方法论是什么？和数仓的维度建模有什么区别？
A：我们的建模方法论也是基于著名的《数据仓库工具箱》来指导建设的，并且根据宜信实际情况，对 Kimball 的维度建模进行了一定的简化、标准化、通用化设计，同时也参考了阿里的 OneData 体系的经验，这块我们并无太多独创性。DataStar 更重要的目标，还是如何易用、有效的吸引和帮到数据建模师，从流程上能够让模型建设统一化、线上化、管理化，同时力求减少 ETL 开发人员负担，将 DW 到 DM/APP 层的个性化指标工作通过配置化下放给非数据开发人员自助完成。所以>
Q：Triangle 任务调度系统是开源的么？
A：Triangle 是另一个团队研发维护的，他们有开源计划，具体何时开源我们还太确定。
Q：Davinci 何时发版？
A：这是个永恒的问题，感谢大家对 Davinci 的持续关注和认可，我们有计划将 Davinci 推到 Apache 孵化，所以希望大家可以一如既往地支持 Davinci，让 Davinci 成为最好的开源可视化工具选择。
Q：数据服务是管控了所有的数据读取写入吗？最好的情况是所有业务方都可通过数据服务访问数据，这样的话数据管理、链路、地图就比较容易做。问题是很多情况下知道连接信息的话，业务方是可以直连的，怎么避免业务方自己使用 API 直连？
A：是的，DataHub 的目标就是统一收口数据归集、数据申请、数据发布、数据服务，这样像数据安全管理、链路管理、标准化管理等都更容易实现了。如何避免业务方绕过>
Q：DBus 支持 Postgres 数据源吗?
A：DBus 目前支持 MySQL、Oracle、DB2、日志、Mongo 数据源，其中 Mongo 由于本身日志的特点使得 DBus 只能接出非完整增量日志（只有更新的列会输出），这样对强顺序消费就提出了很高要求，内部来说没有太多 DBus 接 Mongo 的场景。社区有提出 DBus 对接 PostgreSQL 和 SQLServer 的需求，理论上都是可以扩展对接的，但目前团队都投入在数据中台建设上，更多数据源类型的对接，如果有需要的话，可以直接联系我们团队讨论。
Q：Moonbox 的底层是用 Spark SQL 实现的这种混合计算，需要消耗很多资源，是怎么优化的呢？
A：Moonbox 的混算引擎是基于 Spark 的，并对 Spark 做了一些优化工作，其中最大的一块优化就是支持了更多计算下推（Pushdown），Spark 本身也具备数据联邦混算能力，但 Spark 只支持部分算子下推，如 Projection 和 Predict，Moonbox 对 Spark 做了旁路扩展，支持更多如 Aggregation、Join、Union 等算子下推，并且在解析 SQL 时会根据数据源计算特点进行有策略的下推执行计划，尽量让数据源做更适合的计算工作，减少在 Spark 里混算的计算成本。
Moonbox 还支持如果 SQL 本身没有混算逻辑，且数据源适合整个 SQL 计算，Moonbox 可以绕过 Spark 直接将全 SQL 做整体下推到数据源。另外，Moonbox 支持 Batch 计算、分布式 Interactive 计算和 Local Interactive 计算模式，每种都做了不同的优化和策略。
Q：离线计算和实时计算是怎么配合的，离线计算可以做分层存储，实时计算怎么实现分层存储？
A：实时计算分层，有一种做法是通过 Kafka 来做，当然如果对实时分层数据的时效性要求不太高（如分钟级）的话，也可以选择一些实时 NoSQL 存储，如 Kudu。“离线计算和实时计算怎么配合“，有了 Moonbox，其实不管批量计算和流式计算的数据存储在哪里，都可以通过 Moonbox 做无缝混算的，可以说 Moonbox 简化并抹平了很多数据流转架构的复杂性。
Q：中台的定位是什么，会不会又是一个 buzzword？在宜信内部，数据中台跟传统后台的关系是怎样的？
A：宜信数据中台的定位在演讲开头已经谈到了，简单来说就是对下层做统一化管理化透明化，对中层做通用化标准化流程化，对上层做资产化服务化自助化。Buzzword 这个也是要一分为二的看，有些浪潮留下的更多是教训，有些浪潮带来的更多是进步。“数据中台跟传统后台的关系“，这里传统后台我理解是指业务后台吧，好的业务后台可以更好配合和支持数据中台，不好的业务后台会把更多数据层面的挑战留待数据中台去面对和解决。
Q：数据异构存储在如此多的存储组件中，如何保证个性化查询的效率？
A：这个问题应该是指 Moonbox 这种体系架构，如何保证即席查询效率。纯即席查询（源数据直接计算出结果），查询效率怎样都不会拼过内存型 MPP 查询引擎的。对于我们来讲，Moonbox 主要用于统一批量计算入口、统一即席查询入口、统一数据服务、统一元数据归集、统一数据权限、统一血缘关系生成、统一数据工具箱等。如果追求毫秒级/秒级查询效率，要么采用预计算引擎如 Kylin、Druid 等、要么 ES、Clickhouse 等，但这些都有个前提，就是基础数据都已经准备好。因此我们的数据中台链路，是支持 ETL 之后将 DW/DM 数据物理写入 ES、Clickhouse 并统一>
Q：如果有新的数据进入系统，整个数据采集到进入存储的过程是由开发人员控制，还是专门的数据管理人员通过界面组合各个组件 Pattern 来控制？
A：如果新数据源来自业务数据库备库，DBus 已经对接了此备库前提下，会有专门的数据中台管理员在数据中台管理界面上配置发布新的 ODS，以供下游使用方在>
所谓“数据采集到存储“，也是分为实时采集、批量采集、逻辑采集等的，这些常用数据源类型、数据对接方式、用户使用方式等都被>
原文链接 ：
