趋势
我们使用什么数据库来支持我们的人工智能聊天机器人？
在这篇文章中，我将带你了解我们在AISPEECH使用哪些数据工具和技术来支持我们的人工智能服务。
实时与离线：从分离到统一
在2019年之前，我们使用Apache Hive + Apache Kylin来建立我们的离线数据仓库，而Apache
Spark + MySQL作为实时分析数据仓库：
粗略的说，我们有三个数据源：
- 业务数据库，如MySQL
- 应用系统，如K8s容器日志
- 汽车T-Box日志
我们通过MQTT/HTTP协议、业务数据库Binlog和Filebeat日志采集，将这些数据写入Kafka中。然后，这些数据将被分流到两个环节：实时和离线。
实时数据链接：由Kafka缓存的数据将由Spark计算并放入MySQL进行进一步分析。
离线数据链接：由Kafka清理的数据将被放入Hive。然后，我们使用Apache Kylin来创建立方体，但在此之前，我们需要预先构建一个数据模型，其中包含关联表、维度表、索引字段和相关聚合函数。立方体的创建是由调度系统定期触发的。创建的立方体将被存储在HBase中。
这种架构是与Hadoop技术的无缝整合，Apache Kylin在预计算、聚合、精确重复数据删除和高并发场景中提供了出色的性能。但随着时间的推移，一些令人不快的问题暴露出来：
- 太多的依赖性：Kylin 2.x和3.x在很大程度上依赖于Hadoop和HBase。太多的组件带来了更长的开发环节，更高的不稳定性，以及更多的维护成本。
- Kylin中复杂的Cube创建：这是一个繁琐的过程，包括所有的平面表创建、重复数据删除和Cube创建。每天，我们运行1000~2000个任务，但至少有10个任务失败，所以我们不得不花大块的时间来编写自动运行和维护脚本。
- 维度/dictionary扩展：维度扩展是指当数据分析模型涉及太多的字段而不进行数据修剪时，立方体的创建时间延长；当全局精确重复数据删除耗时过长，导致更大的字典和更长的创建时间时，字典就会发生扩展。两者都会拖累整个数据分析的性能。
- 数据分析模型的灵活性低：计算字段或业务场景的任何变化都可能带来数据的回溯。
- 不支持细分查询：我们无法用这个架构来查询数据分解。一个可能的解决方案是将这些查询推给Presto，但Presto的引入意味着更多的运行和维护麻烦。
因此，我们开始寻找一个新的OLAP引擎，以最好地满足我们的需求。后来，我们把选择范围缩小到了ClickHouse和Apache Doris。由于ClickHouse的运行和维护复杂性高，表类型多，而且不支持相关的查询，我们最后选择了Apache Doris。
2019年，我们建立了一个基于Apache Doris的数据处理架构，实时和离线数据都将被倒入Apache Doris进行分析：
我们本可以在Apache Doris中直接创建一个离线数据仓库，但由于传统的原因，很难将所有的数据迁移到那里，所以我们决定保留之前离线数据链接的上半部分。
不同的是，此时Hive中的离线数据将被写入Apache Doris而不是Apache Kylin。Doris的Broker Load方法非常快。每天，将100200G的数据输入Doris需要1020分钟。
至于实时数据链接，我们使用Doris-Spark-Connector将数据从Kafka摄取到Doris。
新架构的好处是什么？
- 简单的运行和维护，不依赖Hadoop组件。 部署Apache Doris很容易，因为它只有前端和后端进程。这两种类型的进程都可以扩展，所以我们可以只创建一个集群来处理数百台机器和几十PB的数据。我们已经使用Apache Doris三年了，但只花了很少的时间进行维护。
- **易于故障排除。**拥有一个能够提供实时数据服务、交互式数据分析和离线数据处理的一站式数据仓库，使得开发环节变得短而简单。如果有什么问题，我们只需要检查几个点就能找到根本原因。
- **支持Runtime格式的JOIN查询。**这类似于MySQL中的表关联。它在需要频繁改变数据分析模型的场景中很有帮助。
- 支持JOIN、聚合和分解查询。
- 支持多种查询加速方法。 这些方法包括卷积索引和物化视图。滚动索引允许我们实现一个二级索引来加速查询。
- 支持跨数据湖的联合查询，如 Hive**、Iceberg、Hudi以及MySQL和Elasticsearch等数据库。**
Apache Doris如何为人工智能赋能
在AISPEECH中，我们将Apache Doris用于实时数据查询和用户定义的对话数据分析。
实时数据查询
实时数据处理管道的工作原理如上。我们通过Broker Load摄入离线数据，通过Doris-Spark-Connector摄入实时数据。我们把几乎所有的实时数据放在Apache Doris中，把部分离线数据放在Airflow中，用于DAG批处理任务。
我们的实时数据量很大，所以我们真的需要一个能保证高查询效率的解决方案。同时，我们有一个20人的团队负责数据操作，我们需要为所有的人提供数据仪表盘的服务。这对于实时数据的编写和要求很高的查询并发来说是一个挑战。幸运的是，Apache Doris可以实现这一切。
用户定义的对话式数据分析
这是我最喜欢的部分，因为我们已经自豪地在数据查询中利用了我们的自然语言处理（NLP）能力。
一个正常的BI场景是这样工作的：数据分析师根据数据用户（例如，财务部门和产品经理）的需求，在BI平台上定制仪表盘。但我们想要的更多。我们希望为数据用户提供更多独特的需求，比如在任何指定的维度上进行滚动和下钻。这就是为什么我们启用了用户定义的对话式数据分析。
与普通的BI案例不同，是数据用户而不是数据分析师在与BI工具对话。他们只需要用自然语言描述他们的要求，而我们，利用我们的NLP能力，会把它们变成SQL。听起来很熟悉？是的，这就像一个特定领域的GPT-4。只是，我们已经对它进行了长期的优化，并对它进行了微调，以便与Apache Doris更好地整合，这样我们的数据用户就可以期待更高的命中率和更准确的解析结果。然后，生成的SQL将被发送到Apache Doris进行执行。通过这种方式，数据用户可以查看任何细分的细节，并卷起或钻取任何字段。
Apache Doris是如何使这个工作顺利进行的？
与Apache Kylin和Apache Druid等预计算的OLAP引擎相比，Apache Doris具有以下优势：
- 灵活的查询模型，支持用户定义的场景
- 支持表关联、聚合计算和分解查询
- 快速的响应时间
我们的内部用户对于这种对话式的数据分析一直给予积极的反馈。
建议
我们积累了一些关于Apache Doris使用的实践经验，相信可以让你少走一些弯路。
表的设计
- 对于小数据量（例如，少于1000万行），使用重复表。复制表同时支持聚合查询和细分查询，所以你不需要用所有的详细数据来制作一个额外的表。
- 对于大数据量，使用聚合表。然后你可以做卷积索引，通过物化视图加快查询速度，并在聚合表之上优化聚合字段。一个缺点是，由于Aggregate表是预先计算过的表，你需要一个额外的分解表来进行详细查询。
- 当处理有许多关联表的海量数据时，通过ETL生成一个平面表，然后将其摄入Apache Doris，在那里你可以根据Aggregate表的类型做进一步优化。或者你可以遵循Doris社区推荐的Join优化方法。
存储
我们在存储中隔离了热数据和温数据。过去一年的数据存储在SSD中，而比这更早的数据则存储在HDD中。Apache Doris允许我们为分区设置一个冷却期，但相关配置只能在分区创建时进行。我们目前的解决方案是自动同步，我们将一定部分的历史数据从SSD迁移到HDD，以确保过去一年的数据全部放在SSD上。
升级
在升级之前，请确保备份元数据。另一种方法是启动一个新的集群，通过Broker将数据文件备份到远程存储系统，如S3或HDFS，然后通过备份恢复的方式将旧集群数据导入新集群。
版本升级后的性能
从Apache Doris 0.12开始，我们一直在追赶Apache Doris的版本。在我们的使用场景中，最新版本可以提供比早期版本高几倍的性能，特别是在涉及多个字段的复杂函数和语句的查询中。我们非常感谢Apache Doris社区的努力，强烈建议你升级到最新版本。
总结
总结一下我们在Apache Doris上的收获：
- Apache Doris可以成为一个实时+离线的数据仓库，所以我们只需要一个ETL脚本。这为我们节省了大量的开发工作和存储成本，也避免了实时和离线指标的不一致。
- Apache Doris 1.1.x支持矢量化，因此可以提供比旧版本高2~3倍的性能。测试结果显示，Apache Doris 1.1.x在平面表查询性能上与ClickHouse相当。
- Apache Doris本身很强大，不依赖其他组件。与Apache Kylin、Apache Druid和ClickHouse不同，Apache Doris不需要其他组件来填补任何技术空白。它支持聚合、分解查询和关联查询。我们已经把90%以上的分析迁移到Apache Doris上，这使得我们的运行和维护变得更加轻巧和容易。
- Apache Doris很容易使用，因为它支持MySQL协议和标准SQL。
