共计 6785 个字符，预计需要花费 17 分钟才能阅读完成。
本文整顿自第四范式技术日中 Akulaku 算法总监马宇翔在「高效落地 AI 工具链及开源生态」分论坛的演讲。
大家好，很快乐能和大家一起加入第四范式的技术日，做对于 OpenMLDB 在 Akulaku 数据驱动中利用实际的分享。我是来自 Akulaku 的马宇翔。对于 OpenMLDB 来说，咱们算是一个晚期的关注方，也是对它提供的解决方案存有浓厚兴趣的企业方，所以明天我十分心愿通过和大家分享咱们的应用体验，来抛砖引玉。对于 Akulaku 公司简介 Akulaku 是一家做电商平台以及数字银行的金融科技出海公司。咱们的电商平台在东南亚应该是 TOP 5，数字银行在印尼应该是 TOP 1。这样的业务和市场规模使得咱们有十分多的线上的数据须要解决，同时这些数据又是用来解决电商或金融相干的理论问题，导致 Akulaku 对数据准确性和实时性以及高性能都有比拟高的要求。
场景需要和架构设计
Akulaku 的数据架构如图所示。在特色计算层，有一些第三方和自研的底层工具；在模型计算层，做了一些凋谢架构式的整合，尽可能地形成了一个易扩增且不依赖于某种特定工具的计算模式框架。这两层负责反对智能利用，比如说把行为动作、地理位置、设施指纹，也有银行的一些反洗钱、设施风控，以及基于用户体验的智能客服、智能投顾。这些智能利用基于雷同的数据驱动底座技术栈来提供服务，在设计满足上述条件的计划时咱们发现了 OpenMLDB。场景需要作为 Akulaku 的数据部门，咱们平时会面临各自来自上下游的诉求。上游业务方会要求咱们尽可能反对各种各样的性能，并且要求实时应用。咱们常见的数据利用方会须要同时应用离线计算、异步实时计算和硬实时计算以满足决策须要。这些要害事件的决策不能出错，同时决策的稳定性也要有所保障。对于上游的诉求。比如说运维部门作为资源提供方，存在老本上的诉求，整个计算体系的资源心愿尽可能的少。这里的少，更多也是满足业务前提下的少，也就是要做到全局最优。要求咱们做精细化，可是精细化会带来复杂度的晋升，复杂度的晋升又会升高稳定性。上下游的诉求存在互斥，对于咱们来说是一个挑战。对于外部的数据部门来说，因为大数据工具的频繁迭代，员工的学习老本很大。比如说 Spark 对批量计算敌对，Flink 对流式计算敌对。然而为了每一种计算模式都独自学一个工具，并且依据工具迭代跟进学习，还可能要适应革新去大幅革新现有零碎，会导致从每一个员工到整个部门都难以获得积淀，且十分苦楚。在易用性这边，咱们的应用方是心愿整个平台的设施足够简略不便遍及。既要处处可用，还要应用形式比较简单，不然各类型的服务角色比如说开发者的诉求、分析师的诉求和算法工程师就不太一样，很难都失去满足。其次重要的是可靠性，如果零碎部署艰难、三天两崩，呈现问题无奈自查，测试工夫过长都会给咱们带来很大的影响。所以以上的这些问题，咱们必须逐个防止或缩小。架构设计设计需要那以上种种情景下，Akulaku 的架构设计必须满足上面两个指标。首先咱们须要同时做一个实用于 OLAP 和 OLTP 的一些高效交融计算的计划，它须要同时实现 AI 和 BI 的数据执行，必须保障 AI 和 BI 在整个的生产线上尽可能地应用同一份数据去运行，而不是别离跑出两个两头后果，而后再得出不一样的论断，这个有很高的危险。其次应用的工具须要兼容其余的工具，领有良好的生态。如果没有良好的生态，咱们也很难把它搁置在整个的架构里。
通过大量的二次开发和以上两个指标的筛选，咱们明确了 Akulaku 数据架构中工具须要反对五种条件：
第一，流批一体。它的批处理和实时处理应该是一个雷同的代码能执行，而且执行进去的底层也应该是雷同的逻辑。第二，高性能。因为在线上的大并发和线下大吞吐量的工作都须要做一个撑持。第三，场景无关。场景无关的这种个性，咱们须要它具备一份数据能够处处应用，而后通过一些筛选，或者是说加窗口的形式去扭转它的条件。而不是说它每换一个场景，咱们都要从新去做一遍全量计算，或者全量数据导入导出。第四，语义反对。语义反对更多是因为咱们的流式计算有很多的新的语义，就是像 Flink 每次版本迭代，都会依据具体的大家提的应用需要去迭代一些新的语义。那么对于这些语义，心愿咱们的工具也能失去肯定的反对，它能做一些比较复杂的实时计算场景。第五，工具高效。首先咱们须要搭建计算框架的组件，它自身是能积淀咱们一些上线的流水线和线下剖析的数据逻辑的这些能力。便于咱们后续对它做一些迭代。设计实现
最终成型的特色和数据计算架构如上图。首先咱们数据源可能会来自 HDFS、Kafka，还有其余服务语言的 SDK，或是 Nebula 这种比拟非凡的图计算工具。基于这些不同的数据源，咱们在两头做了流批一体化，最初次要抉择了 OpenMLDB 不同的模式去实现这一套的性能，再通过中间件去屏蔽掉流批一体化的不同组件对于一个逻辑的不同实现，保障接下来的交融计算组件能失去很好的升高复杂度的水平。在 Akulaku，靠近 50% 的、使用量最大的一部分指标对实时性的要求较低，比方经营人员或者管理人员须要的数据指标或是一些对实时性要求比拟差的非凡模型，可能会使用性能或性价比绝对较高、更加普适的 Rocksdb 模式去做。接下来，如果对于生产要求，准确性以及性能、计算速度要求比拟高的批处理，咱们就会应用背地基于 Spark FE 的 OpenMLDB 离线模式，它的性能比 Spark 要好很多倍。如果有一些硬实时的计算，就会采纳 OpenMLDB 的在线模式去做，能够做到大并发上面放弃在几十毫秒级这个程度，基本上是满足 200 毫秒硬实时的门槛。其余的一些补充，例如 Clickhouse 或者数据湖的组件，就会在指标市场或更多的数据大盘上做一些反对，这儿就不赘述了。在交融计算方面，咱们次要基于 Ray 来实现的，Flink 是咱们之前的计划，然而目前是在 Ray 下来做全盘过渡。数据应用层，首先就是因为 OpenMLDB 的离线、在线一体化，所以咱们能够很轻易地去把 MLOPs 做到继续交付到继续部署两头这一步的测试自动化，能够简化十分多步骤，因为代码是统一的。有了 OpenMLDB 之后，咱们就能够比拟轻松地去做 AutoML，其余的一些指标市场和低代码剖析，实现一些更精细化的 BI 的利用。利用细节和应用案例为什么最初抉择把 OpenMLDB 抉择放在咱们的外围地位？
第一，人造地反对流批一体。流批一体是 OpenMLBD 的一个外围，或说主打性能，也是咱们最刚需的性能。第二，高性能。实测 OpenMLDB 的性能时，如果从 Kafka 写入数据最大能够做到 1 万的并发，当然这是一个三节点的集群，可能更多节点的集群会有更好的成果，也就是说 OpenMLDB 的性能还有扩大空间。在离线局部，OpenMLDB 性能超过 Spark 数倍，基本上能满足惯例的一些应用。在实时计算局部，咱们能够轻松地做到靠近 200 的 qps，还能够放弃 99% 的 70 毫秒内的计算。所以能够说，OpenMLDB 是一个十分优良的线上和线下的计算工具，也是一个十分优良的能够同时满足线上计算和线下计算的剖析数据库。第三，场景无关。这个个性，它是能够在内存做一个长久化，以及咱们能够抉择应用长久化内存版本，来确保咱们数据在十分极其的状况下还是可能失去复原。通过这种计划，咱们就能够在一次地把数据写入之后，而后不停地通过 SQL 去管制计算力度，来确保咱们能够不停地复用这些数据。其次就是它本人也反对数据过期。数据过期性能，就是说能够把一些咱们设定好的，过了多久不会应用的数据主动给干掉，那就会省很多的一些空间，而后进步咱们的存储有效性。而且它还反对 Rocksdb 的版本，而后去做到降本增效的成果。第四，语义反对。它反对了常见的流式场景需要，而且能够和批式的语法应用雷同的一些算子。同时它也反对 UDF 或者 UDAF 一些特色工程的函数扩大。这些扩大形式对咱们来说还是很实用的，因为你能够把一些特定的逻辑分装成函数应用。第五，工具高效。咱们目前是应用一些像 Airflow 之 类的工具去把整个的脚本做一些流水线的固化，而后这个固化搁置呢，OpenMLDB 在外面只须要配置一些相似 SQL 脚本就能够实现了，这个形式是比拟便于实现 MLOPs。同时 OpenMLDB 也在打造和很多第三方工具的应用生态，去确保咱们能够更便当地和其余工具买通。利用思考和倡议利用思考接下来的内容想介绍一下 OpenMLDB 的利用思考。
第一是对于规范 SQL，咱们是否肯定要有一个满足规范 SQL 的工具呢？咱们思考的后果是：其实也不那么必要。因为规范 SQL 语法更多的实质目标是为了反对咱们的逻辑一致性，但对于逻辑一致性，咱们还是有其余的计划能够去实现的。比方大家如果是调用一些非标的办法或者说还未反对的办法，咱们就必须调用自我实现的一些性能或者应用软件工程的一些设计模式去解决掉这些分装，或者解决掉多层复用的一些问题。这种形式，能够为咱们换来超过规范 SQL 工具更多效率吧，这个效率其实是咱们目前更为须要的一个货色。以咱们本人的工夫来说，当初是一些简单到可能数百行 SQL 盘活开掘类型的工作，都是能够通过这种计划去解决掉的，它的扩大空间还是十分大。第二就是对于品质和效力的均衡。品质和效力，一般来说咱们心愿它同时晋升，然而更多时候它们也会有一些抵触。比如说每当进步复杂度，那品质就会降落，然而进步复杂度能够精细化整个产品的一个效力。这些时候，咱们就会抉择做一些错位对齐。比如说以 OpenMLDB 的三种实现模式来说，咱们会抉择应用特定的模式去实现尽可能失当的那些特色。比如说 Rocksdb 的版本，咱们就会做通用的指标计算的工具。在线计算的版本，咱们就会用来做一个线上实时模型特色计算的工具。离线版本，咱们就会用来做一些 T+1 的一些十分大批量数据的计算工具。就是说，每种计划我其实都是能够以特定的数据或者说场景尽可能最优匹配。这种形式咱们还使用到一些预计算、及时计算、软加载或者窗口划分之类的计划中，进一步去优化它的品质和效力的均衡。第三是在业务和技术下面，咱们也须要做一些取舍。对技术来说，心愿咱们的技术不产生任何的一些技术债，而后不停地去向上迭代。针对业务来说，它须要的其实就是你的性能的残缺实现以及上线工夫。对于这一点，咱们是之前做了一些低代码的工具去实现这个事件。如果是一个规范的低代码工具，那它可能更多节俭的工夫是业务人员“利落拽”的工夫，这个其实并不是业务真正想要的。他们更想要的其实是缩短上线工夫，这个上线工夫的缩小就须要看你应用的工具是否间接从继续交付停顿到继续部署，这一点就是 OpenMLDB 在这儿起到的作用。就是我在这边“利落拽”实现的一套低代码工具背地实现生成的 SQL，我就能够间接利用在线上的版本去做部署。应用细节接下来，就是想介绍一些具体的应用细节，其实更多是一些 tips，可能会对大家应用这个工具的时候有肯定的帮忙。首先就是在建表环节，咱们可能会提供多种的索引定义形式。支流的形式就是应用 INDEX 外面 Key 的关键字，另外一种就是应用工夫窗口外面的 TS 关键字，工夫窗口的这种关键字就是用于所有基于工夫的流式数据。应用 Key 关键字的，须要咱们本人把这个事件进行序列化，而后定义其中能够帮忙你良好地把序列拆离开的一些字段用来做一个关键字。如果定义十分胜利，就会让咱们应用这个工具的成果失去一个极大的晋升。首先是逻辑会失去简化，其次就是性能也会晋升很多。OpenMLDB 目前反对的工夫字段就是两种数据类型，这个也是须要留神到的。接下来在查问局部，当咱们查问一条数据的时候，并不需要残缺地把一个十分宏大的业务 SQL 传进去。咱们更多的是能够说，只用到我关怀的、所用到的字段和工夫戳。其余不重要的能够应用一些代替值它给占位，有了这个占位之后，OpenMLDB 是曾经能够失常工作。其次就是金融场景尤其常见的，不应用以后行去计算肯定工夫窗口内的数据。Akulaku 应用的解决方案是，咱们排除掉以后这个字典外面所在的毫秒工夫戳外面的第一个字段，而后通过这种形式去把排除以后行的操作解决掉。那么外面其余的字段，因为是一个非工夫戳，而且不是咱们用到的字段，所以就是一个不重要的无所谓的数据，能够轻易的去做一些占位。这些操作是能够比拟简化排除以后行这个问题的实现，不须要做一些非常复杂的逻辑。倡议和瞻望最初想和大家介绍一下，咱们最初应用下来的一些倡议，以及对 OpenMLDB 产品将来迭代的瞻望。应用倡议对于这一块绝对比拟经典的应用倡议的话，首先就是如果咱们的逻辑它很简单，那会导致线上验证和线下失效，这两个事没方法在很短的工夫内判断出逻辑是否统一，或者说最初跑进去的后果能不能是一个数。对这种形式，咱们就会倡议应用 OpenMLDB 来去实现，因为它是人造毁灭这种问题。其次就是说，如果咱们参加计算的数据能够依照工夫或者某个索引十分完满地去切片、做窗口，那咱们也是倡议应用这个工具。因为它的性能会十分的高，那咱们的性价比和效率就会晋升到一个十分可观的一个水平。第三局部就是说，如果咱们逻辑的开发人员不是那么关怀大数据畛域和高性能畛域的一些问题，甚至说包含 SQL 优化也不是很想思考的话。那咱们也倡议应用这个工具来去做这个逻辑的开发。
就目前来说，就咱们应用下来 OpenMLDB 自身的性能、底层的优化曾经做得很到位了。对于 SQL 语义这块特地影响性能的实现，比如说多表联做这种，它是间接不反对的，那么也就是不会让逻辑开发人员写进去一些非常低性能的代码，可能会造成零碎血崩之类的问题。其次就是咱们倡议要应用好 OpenMLDB，咱们心愿企业外部还是须要有比拟清晰的数据治理的能力。不然的话，可能我在第一步的过程中，就是导入 OpenMLDB 外面的数据可能就会绝对比拟乱。它更多也不是一个在外部做数据荡涤的一个工具。如果要用好 OpenMLDB 的强项——计算，那咱们最好是把一个尽可能清晰的，须要用它算的数据输出进去，而后能够间接执行前面的相应逻辑，而不是始终收到报错。
迭代瞻望接下来就是咱们认为 OpenMLDB 前面还会反对的一些性能，而后以便于更加不便咱们的一些应用。第一，就是目前看起来它是有在做一些进一步的反对异构资源，去升高存储老本之类的事件。这个操作后续的衍生，咱们认为就会去做一些更进一步的精细化的应用配置。同样的一个表外面，甚至能够反对某些字段的计算，例如须要用内存版本某些字段的计算，用 Rocksdb 去做就能够了。这种形式，能够让资源的精细化治理做到一个绝对比拟极致的程度。只有所谓的老本和产出的 ROI 能达到更高的话，那 OpenMLDB 的利用场景其实就会更宽。第二，目前它的数据 IO 和 SDK 反对来看，它前面还有很多能够反对的一些工作。比如说目前的离线数据导入，咱们个别是应用 HDFS 或者 CSV。那还有比拟新的一些数据或者说离线的数据湖，或者说在线的一些连接器，那都是它后续能够做一些实现的。其次就是对于 SDK 的反对，咱们目前在 Java SDK 和 Python SDK 应用下面，如果绝对于其余一些更成熟的数据工具，咱们心愿能有一种像是反对 Python 多线程。或者对 Java 来说，可能就是它的生成文件模式能够更敌对，或者说它能够间接有一个非常明显的开关性能，都能够帮忙咱们更好地去便当应用 OpenMLDB。第三，咱们期待有更多来自社区的文档奉献，比如说 OpenMLDB 有很多的宝藏性能，比如说 UDF 函数的一些实现，或者是对于在线和离线两种不同模式底层的数据如何做一致性之类的设计可能给还未入门或者说刚入门的开发者一个更加短缺的介绍，那我置信它的转化和使用量也会失去更迅速的一个增长。第四，咱们认为 OpenMLDB 能够有一个更敌对的 SRE 反对的设计，比如说对于数据过期是一个十分好的性能。然而如果是生产环境下的话，出了一些问题就不太好回溯，也不太好去做进一步的迭代。那这个时候，如果咱们能够有一个选项是把它做一个异步转存，再或者前面再补充一些定时删除，对于 SRE 这边的排查问题或者说后续的性能迭代都会更敌对一些。当然也包含比如说当初命令行日志更细的分级，或者在整个数据库级别做一些管理权限的一些反对。这些都是作为 SRE 可能会关怀到的一些诉求。
对于整个 OpenMLDB，咱们这边的一些倡议和应用实际就到这里了。同时也十分冀望能看到更多的企业来去应用它，通过独特的“踩坑”和“填坑”把 OpenMLDB 做成一个更好的工具。谢谢大家。1END1 写在最初如果想进一步理解 OpenMLDB 或者参加社区技术交换，能够通过以下渠道取得相干信息和互动~Github: https://github.com/4paradigm/… 官网：https://openmldb.ai/Email: c[email protected]OpenMLDB 微信交换群：
