共计 5428 个字符，预计需要花费 14 分钟才能阅读完成。
近日，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。
对于 Kyligence
Kyligence 由 Apache Kylin 开创团队创立，致力于打造下一代智能数据云平台，为企业实现自动化的数据服务和治理。基于机器学习和 AI 技术，Kyligence 从多云的数据存储中辨认和治理最有价值数据，并提供高性能、高并发的数据服务以撑持各种数据分析与利用，同时一直升高 TCO。Kyligence 已服务中国、美国及亚太的多个银行、保险、制作、批发等客户，包含建设银行、浦发银行、招商银行、安全银行、宁波银行、太平洋保险、中国银联、上汽、一汽、安踏、YUM、Costa、UBS、Metlife、AppZen 等寰球知名企业和行业领导者。公司已通过 ISO9001，ISO27001 及 SOC2 Type1 等各项认证及审计，并在寰球范畴内领有泛滥生态合作伙伴。