昆山建设局网站查预售北京尚层装饰总部电话

当前位置： 首页 > news >正文

昆山建设局网站查预售,北京尚层装饰总部电话,如何网上销售自己的产品,淘宝电商网站怎么做的作者介绍#xff1a;肖康#xff0c;SelectDB 技术副总裁 导语 日志数据的处理与分析是最典型的大数据分析场景之一#xff0c;过去业内以 Elasticsearch 和 Grafana Loki 为代表的两类架构难以同时兼顾高吞吐实时写入、低成本海量存储、实时文本检索的需求。Apache Doris…作者介绍肖康SelectDB 技术副总裁 导语 日志数据的处理与分析是最典型的大数据分析场景之一过去业内以 Elasticsearch 和 Grafana Loki 为代表的两类架构难以同时兼顾高吞吐实时写入、低成本海量存储、实时文本检索的需求。Apache Doris 借鉴了信息检索的核心技术在存储引擎上实现了面向 AP 场景优化的高性能倒排索引对于字符串类型的全文检索和普通数值、日期等类型的等值、范围检索具有更高效的支持相较于 Elasticsearch 实现性价比 10 余倍的提升以此为日志存储与分析场景提供了更优的选择。 日志数据分析的需求与特点 日志数据在企业大数据中非常普遍其体量往往在企业大数据体系中占据非常高的比重包括服务器、数据库、网络设备、IoT 物联网设备产生的系统运维日志与此同时还包含了用户行为埋点等业务日志。 日志数据对于保障系统稳定运行和业务发展至关重要基于日志的监控告警可以发现系统运行风险及时预警在故障排查过程中实时日志检索能帮助工程师快速定位到问题尽快恢复服务日志报表能通过长历史统计发现潜在趋势。而用户埋点日志数据则是用户行为分析以及智能推荐业务所依赖的决策基础有助于用户需求洞察与体验优化以及后续的业务流程改进。 由于其在业务中能发挥的重要意义因此构建统一的日志分析平台提供对日志数据的存储、高效检索以及快速分析能力成为企业挖掘日志数据价值的关键一环。而日志数据和应用场景往往呈现如下的特点 数据增长快每一次用户操作、系统事件都会触发新的日志产生很多企业每天新增日志达到几十甚至几百亿条对日志平台的写入吞吐要求很高数据总量大由于自身业务和监管等需要日志数据经常要存储较长的周期因此累积的数据量经常达到几百 TB 甚至 PB 级而较老的历史数据访问频率又比较低面临沉重的存储成本压力时效性要求高在故障排查等场景需要能快速查询到最新的日志分钟级的数据延迟往往无法满足业务极高的时效性要求因此需要实现日志数据的实时写入与实时查询。 这些日志数据和应用场景的特点为承载存储和分析需求的日志平台提出了如下挑战 高吞吐实时写入既需要保证日志流量的大规模写入又要支持低延迟可见低成本大规模存储既要存储大量的数据又要降低存储成本支持文本检索的实时查询既要能支持日志文本的全文检索又要做到实时查询响应 业界日志存储分析解决方案 当前业界有两种比较典型的日志存储与分析架构分别是以 Elasticsearch 为代表的倒排索引检索架构以及以 Loki 为代表的轻量索引/无索引架构如果我们从实时写入吞吐、存储成本、实时交互式查询性能等几方面进行对比不难发现以下结论 以 ES 为代表的倒排索引检索架构支持全文检索、查询性能好因此在日志场景中被业内大规模应用但其仍存在一些不足包括实时写入吞吐低、消耗大量资源构建索引且需要消耗巨大存储成本以 Loki 为代表的轻量索引或无索引架构实时写入吞吐高、存储成本较低但是检索性能慢、关键时候查询响应跟不上性能成为制约业务分析的最大掣肘。 ES 在日志场景的优势在于全文检索能力能快速从海量日志中检索出匹配关键字的日志其底层核心技术是倒排索引Inverted Index。 倒排索引是一种用于快速查找文档中包含特定单词或短语的数据结构最早应用于信息检索领域。如下图所示在数据写入时倒排索引可以将每一行文本进行分词变成一个个词Term然后构建词Term - 行号列表Posting List 的映射关系将映射关系按照词进行排序存储。当需要查询某个词在哪些行出现的时候先在 词 - 行号列表 的有序映射关系中查找词对应的行号列表然后用行号列表中的行号去取出对应行的内容。这样的查询方式可以避免遍历对每一行数据进行扫描和匹配只需要访问包含查找词的行在海量数据下性能有数量级的提升。 图倒排索引原理示意 倒排索引为 ES 带来快速检索能力的同时也付出了写入速度吞吐低和存储空间占用高的代价——由于数据写入时倒排索引需要进行分词、词典排序、构建倒排表等 CPU 和内存密集型操作导致写入吞吐大幅下降。而从存储成本角度考虑ES 会存储原始数据和倒排索引为了加速分析可能还需要额外存储一份列存数据因此 3 份冗余也会导致更高的存储空间占用。 Loki 则放弃了倒排索引虽然带来来写入吞吐和存储空间的优势但是损失了日志检索的用户体验在关键时刻不能发挥快速查日志的作用。成本虽然有所降低但是没有真正解决用户的问题。 更高性价比的日志存储分析解决方案 从以上方案对比可知以 Elasticsearch 为代表的倒排索引检索架构以及以 Loki 为代表的轻量索引/无索引架构无法同时兼顾 高吞吐、低存储成本和实时高性能的要求只能在某一方面或某几方面做权衡取舍。如果在保持倒排索引的文本检索性能优势的同时大幅提升系统的写入速度与吞吐量并降低存储资源成本是否日志场景所面临的困境就迎刃而解呢答案是肯定的。 如果我们希望使用 Apache Doris 来更好解决日志存储与分析场景的痛点其实现路径也非常清晰——在数据库内部增加倒排索引、以满足字符串类型的全文检索和普通数值/日期等类型的等值、范围检索同时进一步优化倒排索引的查询性能、使其更加契合日志数据分析的场景需求。 在同样实现倒排索引的情况下相较于 ES Apache Doris 怎么做到更高的性能表现呢或者说现有倒排索引的优化空间有哪些呢 ES 基于 Apache Lucene 构建倒排索引Apache Lucene 自 2000 年开源至今已有超过 20 年的历史设计之初主要面向信息检索领域、功能丰富且复杂而日志和大多数 OLAP 场景只需要其核心功能包括分词、倒排表等而相关度排序等并非强需求因此存在进一步功能简化和性能提升的空间ES 和 Apache Lucene 均采用 Java 实现而 Apache Doris 存储引擎和执行引擎采用 C 开发并且实现了全面向量化相对于 Java 实现具有更好的性能倒排索引并不能决定性能表现的全部作为一个高性能、实时的 OLAP 数据库Apache Doris 的列式存储引擎、MPP 分布式查询框架、向量化执行引擎以及智能 CBO 查询优化器相较于 ES 更为高效。 通过在 Apache Doris 2.0.0 最新版本的探索与持续优化在相同硬件配置和数据集的测试表现上Apache Doris 在数据库内核实现高性能倒排索引后相对于 ES 实现了日志数据写入速度提升 4 倍、存储空间降低 80%、查询性能提升 2 倍再结合 Apache Doris 2.0.0 版本引入的冷热数据分离特性整体性价比提升 10 倍以上 接下来我们进一步介绍设计与实现细节。 高性能倒排索引的设计与实现 业界各类系统为了支持全文检索和任意列索引往往有两种实现方式一是通过外接索引系统来实现原始数据存储在原系统中、索引存储在独立的索引系统中两个系统通过数据的 ID 进行关联。数据写入时会同步写入到原系统和索引系统索引系统构建索引后不存储完整数据只保留索引。查询时先从索引系统查出满足过滤条件的数据 ID 集合然后用 ID 集合去原系统查原始数据。 这种架构的优势是实现简单借力外部索引系统对原有系统改动小。但是问题也很明显 数据写入两个系统异常有数据不一致的问题也存在一定冗余存储查询需在两个系统进行网络交互有额外开销数据量大时用 ID 集合去原系统查性能比较低维护两套系统的复杂度高将系统的复杂性从开发测转移到运维测 而另一种方式则是直接在系统中内置倒排索引尽管技术难度更高但性能更好、且无需花费额外的系统维护成本对用户更加友好这也是 Apache Doris 所选择的方式。 数据库内置倒排索引 在选择了在数据库内核中内置倒排索引后我们需要进一步对 Apache Doris 索引结构进行分析判断能否通过在已有索引基础上进行拓展来实现。 Apache Doris 现有的索引存储在 Segment 文件的 Index Region 中按照适用场景可以分为跳数索引和点查索引两类 跳数索引包括 ZoneMap 索引和 Bloom Filter 索引。 ZoneMap 索引对每一个数据块和文件保存 Min/Max/isnull 等汇总信息可以用于等值、范围查询的粗粒度过滤只能排除不满足查询条件的数据块和文件不能定位到行也不支持文本分词。BloomFilter 索引也是数据块和文件级别的索引通过 Bloom Filter 判断某个值是否在数据块和文件中同样不能定位到行、不支持文本分词 点查索引包括 ShortKey 前缀排序索引和 Bitmap 索引。 ShortKey 在排序的基础上根据给定的前缀列实现快速查询数据的索引方式能够对前缀索引的列进行等值、范围查询但不支持文本分词另外由于数据要按前缀索引排序、因此一个表只允许一组前缀索引。Bitmap 索引记录数据值 - 行号 Bitmap 的有序映射是一种很基础的倒排索引但是索引结构比较简单、查询效率不高、不支持文本分词。
原有索引结构很难满足日志场景实时文本检索的需求因此设计了全新的倒排索引。倒排索引在设计和实现上我们采取了无侵入的方式、不改变 Segment 数据文件格式而是增加了新的 Inverted Index File逻辑上在 Table 的 Column 级别。具体流程如下 数据写入和 Compaction 阶段在写 Segment 文件的同时同步写入一个 Inverted Index 文件文件路径由 Segment ID Index ID 决定。写入 Segment 的 Row 和 Index 中的 Doc 一一对应由于同步顺序写入Segment 中的 Rowid 和 Index 中的 Docid 完全对应。查询阶段如果查询 Where 条件中有建了倒排索引的列会自动去 Index 文件中查询返回满足条件的 Docid List将 Docid List 一一对应的转成 Rowid Bitmap然后走 Doris 通用的 Rowid 过滤机制只读取满足条件的行达到查询加速的效果。 图Doris倒排索引架构图 这个设计的好处是已有的数据文件无需修改可以做到兼容升级而且增减索引不影响数据文件和其他索引用户增建索引没有负担。 通用倒排索引优化 C和向量化实现 Apache Doris 使用 CLucene 作为底层的倒排索引库CLucene 是一个用 C 实现的高性能、稳定的 Lucene 倒排索引库它的功能比较完整支持分词和自定义分词算法支持全文检索查询和等值、范围查询。 Apache Doris 的存储模块和 CLucene 都用 C 实现避免了Java Lucene 的 JVM GC 等开销同样的计算 C 实现相对于 Java 性能优势明显而且更利于做向量化加速。Doris 倒排索引进行了向量化优化包括分词、倒排表构建、查询等性能得到进一步提升。整体来看 Doris 的倒排索引写入速度可以超过单核 20MB/s而 ES 的单核写入速度不到 5MB/s有 4 倍的性能优势。 列式存储和压缩 Lucene 本身是文档存储模型主数据采用行存而 Doris 中不同列的倒排索引是相互独立的因此倒排索引文件也采用列式存储有利于向量化构建索引和提高压缩率。 采用压缩比高且速度快的 ZSTD通常可以达到 5 ~10倍的压缩比与常用的GZIP压缩相比有50%以上的空间节省且速度更快。 BKD 索引与 数值、日期类型 列优化 针对数值、日期类型的列我们还实现了 BKD 索引可以对范围查询提高性能存储空间也相对于转成定长字符串更加高效具有以下主要特性和优势 高效范围查询BKD 索引采用多维数据结构为范围查询带来高效率。它能迅速定位数值或日期类型列中所需的数据范围降低查询时间复杂度。存储空间优化与其他索引方法相比BKD 索引在存储空间使用上更高效。通过聚合并压缩相邻数据块减少索引所需存储空间降低存储成本。多维数据支持BKD 索引具备良好扩展性支持多维数据类型如地理坐标GEO point和范围Range使其在处理复杂数据类型时具有高适应性。 此外我们在原有 BKD 索引能力基础上进行了进一步拓展 优化低基数场景针对数值分布集中、单个数值倒排列表较多的低基数场景我们调整了针对性的压缩算法降低大量倒排表解压缩和反序列化所带来的CPU性能消耗。预查询技术针对查询结果命中数较高的场景我们采用预查询技术进行命中数预估。若命中数显著超过阈值可跳过索引查询直接利用Doris在大数据量查询下的技术优势进行数据过滤。 面向 OLAP 的倒排索引优化 日志存储和分析场景对检索的需求很简单不需要特别复杂的功能比如相关性排序更需要降低存储成本和快速按照条件查出数据。因此在面对海量数据的写入和查询时Apache Doris 还针对 OLAP 数据库的特点优化了倒排索引的结构使其更加简洁高效。例如 在写入流程保证不会多个线程写入一个索引从而避免写入时多线程锁竞争的开销在存储结构上去掉了不必要的正排、norm 等文件减少写入 IO 开销和存储空间占用查询过程中简化相关性打分和排序逻辑降低不必要的开销提升查询性能。 针对日志等数据有按时间分区、历史数据访问频度低的特点基于独立的索引文件设计Apache Doris 还将在后续的版本中提供更细粒度、更灵活的索引管理功能 指定分区构建倒排索引比如新增一个索引的时候指定最近7天的日志构建索引历史数据不建索引指定分区删除倒排索引比如删除超过1个月的日志的索引释放访问频度低的索引存储空间 性能测试 高性能是 Apache Doris 倒排索引设计和实现的首要出发点我们通过公开的测试数据集分别与 ES 以及 Clickhouse 进行性能测试测试效果如下 vs Elasticsearch 我们采用了 ES 官方的性能测试 Benchmark esrally 并使用其中的 HTTP Logs 日志在同样的硬件资源、数据、测试Case 以及测试工具下记录并对比各自的数据写入时间、吞吐以及查询延迟。 测试数据esrally HTTP Logs track 中自带测试数据集1998 年 World Cup HTTP Server Logs未压缩前 32G、共 2.47 亿行、单行平均长度 134 字节测试查询esrally HTTP Logs 测试关键词检索、范围查询、聚合、排序等 11 个 Query所有查询跑 100 次串行执行测试环境3 台 16C 64G 云主机组成的集群。 在最终的测试结果中Doris 写入速度是 ES 的 4.2 倍、达到 550 MB/s写入后的数据压缩比接近 1:10、存储空间 节省 超 ****80% 查询耗时下降 57%、查询性能是 ES 的 2.3 倍。加上冷热数据分离降低冷数据存储成本整体相较 ES 实现 10倍以上的性价比提升。 vs Clickhouse Clickhouse 近期的 v23.1 版本也引入了类似 Feature将倒排索引作为实验性功能发布因此我们同样进行了跟 Clickhouse 倒排索引的性能对比。在本次测试中我们采用了 Clickhouse 官方 Inverted Index 介绍博客中使用的 Hacker News 样例数据以及查询 SQL 同样保持相同的物理资源、数据、测试 Case 以及测试工具。 参考文章https://clickhouse.com/blog/clickhouse-search-with-inverted-indices 测试数据Hacker News 2873 万条数据6.7GParquet 格式测试查询3 个查询分别查询 ‘clickhouse’、‘olap’ OR ‘oltp’、‘avx’ AND ‘sve’ 等关键字出现的次数测试机器1 台 16C 64G 云主机 在最终的测试结果中3 个 SQL Apache Doris 的查询性能分别是 Clickhouse 的 4.7 倍、12.0 倍以及 18.5 倍有明显的性能优势。 如何使用 下面以一个 Hacker News 100 万条测试数据的示例展示 Doris 如何利用倒排索引实现高效的日志分析。 建表时指定索引 INDEX idx_comment (comment) 指定对 comment 列建一个名为 idx_comment 的索引USING INVERTED 指定索引类型为倒排索引PROPERTIES(“parser” “english”) 指定分词类型为英文分词
CREATE TABLE hackernews_1m (id BIGINT,deleted TINYINT,type String,author String,timestamp DateTimeV2,comment String,dead TINYINT,parent BIGINT,poll BIGINT,children ArrayBIGINT,url String,score INT,title String,parts ArrayINT,descendants INT,INDEX idx_comment (comment) USING INVERTED PROPERTIES(parser english) COMMENT inverted index for comment ) DUPLICATE KEY(id) DISTRIBUTED BY HASH(id) BUCKETS 10 PROPERTIES (replication_num 1);注对于已经存在的表也可以通过 ADD INDEX idx_comment ON hackernews_1m(comment) USING INVERTED PROPERTIES(parser english) 来增加索引。值得一提的是和 Doris 原先存储在 Segment 数据文件中的智能索引和二级索引相比增加倒排索引的过程只会读 comment 列构建新的倒排索引文件不会读写原有的其他数据效率有明显提升。 导入数据后查询使用 MATCH_ALL 在 comment 这一列上匹配 OLAP 和 OLTP 两个词和 LIKE 扫描硬匹配相比查询性能有十余倍的提升。这仅是 100 万条数据下的测试效果而随着数据量增大、性能提升越明显

mysql SELECT count() FROM hackernews_1m WHERE comment LIKE %OLAP% AND comment LIKE %OLTP%;

1 row in set (0.13 sec)mysql SELECT count() FROM hackernews_1m WHERE comment MATCH_ALL OLAP OLTP;

1 row in set (0.01 sec)更多详细功能介绍和测试步骤可以参考Apache Doris 倒排索引官方文档 。 总结 通过内置高性能倒排索引Apache Doris 对于字符串类型的全文检索和普通数值、日期等类型的等值、范围检索具有更高效的支持进一步提升了数据查询的效率和准确性对于大规模日志数据查询分析有了更好的性能表现为需要检索能力的用户提供了更高性价比的选择。 目前倒排索引已经支持了 String、Int、Decimal、Datetime 等常用 Scalar 数据类型和 Array 数组类型后续还会增加对 JSONB、Map 等复杂数据类型的支持。而 BKD 索引可以支持多维度类型的索引为未来 Doris 增加 GEO 地理位置数据类型和索引打下了基础。与此同时 Apache Doris 在半结构化数据分析方面还有更多能力扩展比如自动根据导入数据扩展表结构的 Dynamic Table、丰富的复杂数据类型Array、Map、Struct、JSONB以及高性能字符串匹配算法等。 除倒排索引以外Apache Doris 在 2.0.0 Alpha 版本中还实现了单节点数万 QPS 的高并发点查询能力、基于对象存储的冷热数据分离、基于代价模型的全新查询优化器以及 Pipeline 执行引擎等欢迎大家下载体验。高并发点查询的详细介绍可以查看 SelectDB 技术团队过往发布的技术博客其他功能的使用介绍请参考社区官方文档同时也敬请持续关注我们后续发布的特性解读系列文章。 为了让用户可以体验社区开发的最新特性同时保证最新功能可以收获到更广范围的使用反馈我们建立了 2.0.0 版本的专项支持群欢迎广大社区用户在使用最新版本过程中多多反馈使用意见帮助 Apache Doris 持续改进[通过此处填写申请加入专项支持群。](