Kyligence + 亚马逊云科技丨实现云上的精细化运营和数字化指挥

近日，Kyligence 联合创始人兼 CTO 李扬出席“亚马逊云科技 INNOVATE｜ 数据驱动创新大会”，并发表 《 Kyligence + 亚马逊云科技｜实现云上的精细化运营和数字化指挥》主题演讲，他结合实际应用案例深入浅出地给出了 Kyligence 对于企业数字化转型过程中所面临的困境的解答。

以下为李扬在大会演讲文字实录

企业数字化管理的困境

Gartner 在采访完众多企业后总结出了当今数字化转型中很多 CIO 的主要焦虑所在：

• 无法找到最有价值的数据；

• 将大量时间花在寻找数据中而非分析数据中；

• 在跨部门的全局数据分析中，缺乏统一的数据语义。

造成这些焦虑的主要原因，是因为企业在现实的业务建设中采用了垂直的烟囱式建设，缺少水平的对齐。这就导致了企业的业务数据缺乏治理，会因为数据口径混乱而造成数据过于复杂、找不到数据等诸多问题。

那么如何解决这些焦虑呢？

数字化指挥从“业务数字建模”开始

在数据源到数据应用的过程中加入一个数字建模平台是解决这些焦虑的最好方式。以业务数字模型为中心，每一个业务人员都可以用数据来优化自己的日常工作，而非直接和技术数据打交道。

其中的逻辑关系与“农场经营类游戏”类似，在游戏中，农场主作为一个农场的数字化指挥官，能够在控制面板中以上帝视角掌控整个农场的日常运作，这便是业务数字建模的逻辑。

而将现实的农场抽象到数字世界中，需要完成业务对象、业务流程、业务规则三者的数字化建模的过程。一旦完成了这一现实到电子世界的转换，就能够在电子世界当中指挥和运筹，优化现实中的工作效率。通过优化后的现实又会给到我们最新的反馈、业务对象的状态以及流程的状态，安排进行下一轮的指挥，这样就形成了一个正向的飞轮效应。

不过，这在现实环境中有些困难。从技术的层面来看，这些企业确实已经具备了如数据仓库、数据湖等的统一的数据平台，但当这些数据对接到业务之时，呈现一种垂直型的“烟囱式建设”。在这种建设模式中，业务模型通常位于烟囱的最顶端，是由业务分析师在脑中产出这个业务模型后，再由数据工程师们完成由数据到业务模型的转化，即为一个分析师+一群工程师的一种劳动密集型的数据分析方式。

运用这种分析方式，业务模型将无法得到沉淀。这意味着当企业需要建设一条新的业务线时，之前的业务经验难以被复用，也就没有横向的对齐，无法产生全局视角，更不用谈全局指挥。

Kyligence 智能数据云底座

1.数据治理必须从技术层面上升到业务层面

要改变这一现状，数据的治理必须从技术层面上升到业务层面。在技术的数字平台之上需要有一层业务的数字平台，可以将其称为业务数字模型层，也可以叫它业务语义层。作为一个平台层，它的作用是逐步地整理、沉淀、复用企业的业务数字模型。在一条业务线进行垂直建设的同时，能够把业务数字模型留在这个层次中。这样当我们做下一条垂直建设的时候，它就可以做到横向的对齐和打通，有效减少重复建设。它的价值还在于能够形成一个全局统一口径的数字化指挥棒，不论是在高层、中层还是基层、跨部门，企业都能够运用这个统一的标准（比如：KPI 标准）。在企业日常运营的过程当中，就能够呈现出高度对齐、力出一孔的状态。

有关业务数字模型（即业务语义层）的想法在经典数仓理论与《华为数据之道》中均有所提及，经典理论也推荐我们要将其进行沉淀，而当下很多企业在数字化建设的过程中只关注到了技术层面，往往忽视了业务数字建模的层面。

2.基于业务模型提供服务，让人人都是分析师

一旦做到了业务数字建模，它将会产生一系列立竿见影的优势。其中，最直观的一点就是：基于业务模型提供数据服务，可以让数据民主化得到实现，人人都能成为分析师。因为对于分析师来说，如若能够直接与数据服务层进行交互，就可以不再依赖工程师为其收集数据，而是直接进行数据分析，从而实现独立工作。

Kyligence 的核心是一个多维数据库，它区别于传统的关系型数据库，是一个能够体现业务模型的地方。所谓业务模型，就是以“指标”、“标签”、“维度”、“度量”等这类传统业务人员都可以理解的概念提供数据服务，普通人无需数据库基础就能使用。相比于从前的关系型数据资产而言，给予了普通业务人员自我理解和自己操作的可能性。

在使用数据方面，Kyligence 支持探索、微创新甚至协作分享数据。比如某银行的某个站点产生了一些数据的探索和创新，银行希望这些成果能够沉淀到业务模型中，甚至分享给平行的其他分行的大堂经理，这个目标可以在多维数据库的模型层面得以实现。

再举一个具体的例子，某银行意图在 2019 年增加 5000 个分析师，这 5000 个分析师如果是通过教会他们使用传统的关系型数据库来进行培训，产生理想效果的可能性很低。而如若使用多维数据模型提供的业务型的数据服务来赋能，他们不需要太多额外的学习就能直接使用数据。当他们用 Excel 的 PivotTable 功能连接上 Kyligence 的多维数据模型服务，就能够直接自助式地使用数据。这样就能极大地释放数据的生产效率，让 5000 个普通的业务员直接使用数据来优化他们的日常工作。

3.AI 增强的数据服务和管理平台能力

Kyligence 提供的另一层能力是 AI 增强的数据服务和管理平台能力，能够通过 AI 自动化做到降本增效。一旦业务模型建立了之后，就可以根据业务模型中高频维度、度量组合来自动优化数据索引。可以在业务模型这一层通过统计很快发现最有价值的数据以及低频数据。我们也可以通过逆向工程，从一些传统的 SQL 里面来帮助大家倒推出业务模型。此外，还有自动的数据准备，从业务的定义开始就能够自动地把技术层面的数据上升到业务层面。

Kyligence 具有开放的技术标准，整套系统可以无缝对接各个主流的 BI 平台。这就意味着不管用的是哪种 BI 工具，都能够对接到统一标准的数据语义层，即标准的业务模型上。平台提供的数据接口也是标准且开放的，包括 SQL、MDX、Rest API。最底层有着开源的技术引擎，包括 Kylin、 ClickHouse 和 Spark 。

以下是 Kyligence 在亚马逊云科技环境上为客户提供自动化的数据服务与管理的案例介绍：

实践 1:全球大型车企实战 on 亚马逊云科技

某生产智能汽车为主的车企希望在进入中国市场的起步阶段就完成业务模型中层的建立。完成这一建设需要应对很多挑战，比如：平台建设初期需要面对复杂的机房审批流程、较高的技术学习门槛、搭建成本高而利用率却低下的问题，并且作为一个大型车企，每天会产生大量的批量数据和实时数据的处理，对并发度的分析要求很高。

Kyligence 仅用了三个月，便在亚马逊云科技上成功帮助这家车企交付了他们第一个数据湖的平台。

我们意图解决的业务场景有很多，举其中几个例子：

1.基于预测性故障识别，使主动改善质量成为可能

传统的数据分析模式只能分析即时的数据状态，也就是说 CallCenter 上遇到预警也只是根据目前的状态，出了问题才能发现。有了数据分析能力就能够提前来做预警和识别。因为汽车内部安装有很多感应器，能产生足够多的数据积累，因此完全可以做到提前七天、一个月，甚至更早地发现问题，随着技术的不断先进，发现问题的时间也可以被不断提早。

2.数据湖带来更多场景：车联网数据分析

车就像一个移动的小房间，客户在车里不仅需要移动的能力，也需要旅途中的服务，如：餐饮、宾馆等。这些额外的增值服务，其实就是一个典型的互联网服务客户的体验优化或者是留存的场景，这是典型的可以通过精准数据分析来优化的场景。

3.数据湖带来更多场景：智能充电服务分析

续航一直都是电动汽车的大问题，数据分析可以大大优化电动汽车的续航。如：分析客户群体最常去的地方，就能在附近设立最有效率的充电设备；帮助用户提前规划他的行驶线路，就能使他在一路上都有续航能力。

诸如此类的应用场景的范围非常广，因为在一个统一的数据湖的中台上，Kyligence 的核心使命就是从上游的全渠道数据中把各种入口的数据都收集起来，并以这个统一的平台为起点，再来服务下游所有的场景，而且这些场景可以随着平台数字化运营指挥能力的不断提升进行拓展。

基于亚马逊数据湖的架构实现图比较复杂，其主要意义在于：不管是流式的数据流入或是批式的数据流入，到了监控、安全、存储、计算还有元数据这几大模块中，亚马逊的技术都能够很好地给到支撑。

这是一个更简化的架构图，就是最常见的数据湖建设的图。它体现的价值点和上一张图相似，但它去掉了下面的基础设施部分。在此类架构图中，我们很容易就聚焦到技术层面上，而忽视了业务数据模型，就是开篇所讲的，在如今企业数字化转型中被忽视的核心。

Kyligence 直接对接着上层的数据应用，可能是一个报表，也可能是一个自助式的数据使用。Kyligence 希望在这个大型车企的数据湖场景中给到用户快速数据创新闭环的能力，也就是当企业需要自助式地来分析和收集数据，从当中创新出一些想法的时候，直接可以在 Kyligence 给到的这一层业务模型层上给出答案，而不需要业务人员再去找一大堆数据工程师来帮助他们解决问题。所以这个新的结构架构给到的是自助式的数据创新能力，业务人员自己就能使用数据，就能够发挥数据的价值。除了这个最核心的数据创新快速闭环的能力以外，也产生了如改善客户互动、提高运营效率等其它同样重要的价值。

实践 2: SaaS 客户运营 on 亚马逊云科技

这是一个云上面很典型的 SaaS 服务数字化运营实践。我们的客户是建站 SaaS 服务供应商 Strikingly，它帮助客户在几分钟之内建立个人/个人公司的网站，目前已经服务了全球 200+  国家，用户数超过百万。

Strikingly 业务背后的场景和痛点比较经典。因为它的场景是网站的流量分析，所以它的业务模型相对比较稳定，在业务模型层有很多现有的、可以参考的模型，但是它的技术挑战比较大。Strikingly 早在 2017 年开始就用 Apache Kylin 来做它名为 Analytics Platform 的工具，其中的能力包括点击流分析，网页的 PV、UV、访问设备、来源等这些经典的客户流量、网站行为以及包括留存的分析场景和模型，难点在于它需要有亚秒级的响应能力和高并发的能力，因为它全球的客户数量众多。

对 Strikingly 的管理层来说提供这样的分析服务的运维难度很大，因为它的服务不能中断，需要持续 7 × 24 小时。开源 Kylin 的工具和服务在可靠性方面相对而言会更有挑战一些，并且它的总体成本（ TCO ）会一直很高，不仅仅是云上的资源成本，更多的是我们说到的大数据技术人员的成本，也就是在传统的烟囱式建设下需要的很多的数据工程师。

我们给到 Strikingly 的能力就是在它迁移到 Kyligence Cloud 平台上后，赋予它 AI 增强的建模和自动优化的能力，这样就可以释放它的 IT 生产力。

这其中就包括通过 SQL 的查询来自动优化业务模型。可能很多偏技术型的公司，以 Strikingly 为例，它们的公司人员构成中，还是以技术人员为主，因此很多的创新可以从 SQL 起步，还包括动态的模型调整能力。在模型使用过程的任意时间段，均可以人工灵活调整模型的设计，如增减关系表或分析维度，指标等。这是一种开源 Kylin 并不具备的能力。

经过对 Strikingly 用传统的部署方式（ 即云上的 Hadoop + Kylin ）与更新后用 Kyligence Cloud 的总体运营成本进行对比，可以看到仅硬件部分（云上资源部分）就会有很大的提升。这里提升的主要来源是 Hadoop 这个集群得到了优化，在新的 Kyligence Cloud 上有一个云原生的架构，不再需要 Hadoop 的传统大数据层。这不仅减少了很多硬件成本，更多的是减少了大量的运维成本。

再来看下高并发能力的效果。在 AI 自动的模型调优和索引优化下，我们很容易地就能做到单个查询节点入口 100T/S 的客户的业务目标。并且随着数据量的增长，我们查询的性能可以保持平稳。这就是 Apache Kylin 或者是 Kyligence Cloud 背后的多维模型底下的预计算的能力提供的支撑。我们大部分的查询计算都是预先完成的，在线服务时的计算量就能够保持稳定，并且与原始的数据量几乎无关。Kyligence 在 Strikingly 这个方案中的优势可以总结如下：

综上所述，Kyligence 在亚马逊云科技技术平台上赋予了企业业务数字模型的能力，它是一个 AI 增强的数据服务和管理平台，通过集中的业务数据模型进行管理，能够统一业务口径，让每个业务员都能自助地使用数据和数据创新。此外，AI 增强的自动化数据准备还能进行系统自动调优，通过节省人力和物力极大地降低整体 TCO 。