作者海向，Java知音撰稿人，前58同城后端研发工程师，现某知名金融科技类公司Java工程师，热爱技术研究，技术分享。如果您有好的作品分享，公众号菜单栏“关于我们”中查看投稿方式。什么是elasticsearchElasticsearch 是一个开源的高度可扩展的全文搜索和分析引擎，拥有查询近实时的超强性能。大名鼎鼎的Lucene 搜索引擎被广泛用于搜索领域，但是操作复杂繁琐，总是让开发者敬而远之。而 Elasticsearch将 Lucene 作为其核心来实现所有索引和搜索的功能，通过简单的 RESTful 语法来隐藏掉 Lucene 的复杂性，从而让全文搜索变得简单ES在Lucene基础上，提供了一些分布式的实现：集群，分片，复制等。搜索为什么不用MySQL而用es我们本文案例是一个迷你商品搜索系统，为什么不考虑使用MySQL来实现搜索功能呢？原因如下：MySQL默认使用innodb引擎，底层采用b+树的方式来实现，而Es底层使用倒排索引的方式实现，使用倒排索引支持各种维度的分词，可以掌控不同粒度的搜索需求。（MYSQL8版本也支持了全文检索，使用倒排索引实现，有兴趣可以去看看两者的差别）如果使用MySQL的%key%的模糊匹配来与es的搜索进行比较，在8万数据量时他们的耗时已经达到40:1左右，毫无疑问在速度方面es完胜。es在大厂中的应用情况es运用最广泛的是elk组合来对日志进行搜索分析58安全部门、京东订单中心几乎全采用es来完成相关信息的存储与检索es在tob的项目中也用于各种检索与分析在c端产品中，企业通常自己基于Lucene封装自己的搜索系统，为了适配公司营销战略、推荐系统等会有更多定制化的搜索需求es客户端选型spring-boot-starter-data-elasticsearch我相信你看到的网上各类公开课视频或者小项目均推荐使用这款springboot整合过的es客户端，但是我们要say no！elasticsearch-rest-high-level-client这是官方推荐的客户端，支持最新的es，其实使用起来也很便利，因为是官方推荐所以在特性的操作上肯定优于前者。而且该客户端与TransportClient不同，不存在并发瓶颈的问题，官方首推，必为精品！搭建自己的迷你搜索系统引入es相关依赖，除此之外需引入springboot-web依赖、jackson依赖以及lombok依赖等。<properties> <es.version>7.3.2</es.version> </properties> <!-- high client--> <dependency> <groupId>org.elasticsearch.client</groupId> <artifactId>elasticsearch-rest-high-level-client</artifactId> <version>${es.version}</version> <exclusions> <exclusion> <groupId>org.elasticsearch.client</groupId> <artifactId>elasticsearch-rest-client</artifactId> </exclusion> <exclusion> <groupId>org.elasticsearch</groupId> <artifactId>elasticsearch</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.elasticsearch</groupId> <artifactId>elasticsearch</artifactId> <version>${es.version}</version> </dependency> <!--rest low client high client以来低版本client所以需要引入--> <dependency> <groupId>org.elasticsearch.client</groupId> <artifactId>elasticsearch-rest-client</artifactId> <version>${es.version}</version> </dependency>es配置文件es-config.propertieses.host=localhost es.port=9200 es.token=es-token es.charset=UTF-8 es.scheme=http es.client.connectTimeOut=5000 es.client.socketTimeout=15000封装RestHighLevelClient@Configuration @PropertySource("classpath:es-config.properties") public class RestHighLevelClientConfig { @Value("${es.host}") private String host; @Value("${es.port}") private int port; @Value("${es.scheme}") private String scheme; @Value("${es.token}") private String token; @Value("${es.charset}") private String charSet; @Value("${es.client.connectTimeOut}") private int connectTimeOut; @Value("${es.client.socketTimeout}") private int socketTimeout; @Bean public RestClientBuilder restClientBuilder() { RestClientBuilder restClientBuilder = RestClient.builder( new HttpHost(host, port, scheme) ); Header[] defaultHeaders = new Header[]{ new BasicHeader("Accept", "*/*"), new BasicHeader("Charset", charSet), //设置token 是为了安全 网关可以验证token来决定是否发起请求 我们这里只做象征性配置 new BasicHeader("E_TOKEN", token) }; restClientBuilder.setDefaultHeaders(defaultHeaders); restClientBuilder.setFailureListener(new RestClient.FailureListener(){ @Override public void onFailure(Node node) { System.out.println("监听某个es节点失败"); } }); restClientBuilder.setRequestConfigCallback(builder -> builder.setConnectTimeout(connectTimeOut).setSocketTimeout(socketTimeout)); return restClientBuilder; } @Bean public RestHighLevelClient restHighLevelClient(RestClientBuilder restClientBuilder) { return new RestHighLevelClient(restClientBuilder); } }封装es常用操作@Service public class RestHighLevelClientService { @Autowired private RestHighLevelClient client; @Autowired private ObjectMapper mapper; /** * 创建索引 * @param indexName * @param settings * @param mapping * @return * @throws IOException */ public CreateIndexResponse createIndex(String indexName, String settings, String mapping) throws IOException { CreateIndexRequest request = new CreateIndexRequest(indexName); if (null != settings && !"".equals(settings)) { request.settings(settings, XContentType.JSON); } if (null != mapping && !"".equals(mapping)) { request.mapping(mapping, XContentType.JSON); } return client.indices().create(request, RequestOptions.DEFAULT); } /** * 判断 index 是否存在 */ public boolean indexExists(String indexName) throws IOException { GetIndexRequest request = new GetIndexRequest(indexName); return client.indices().exists(request, RequestOptions.DEFAULT); } /** * 搜索 */ public SearchResponse search(String field, String key, String rangeField, String from, String to,String termField, String termVal, String ... indexNames) throws IOException{ SearchRequest request = new SearchRequest(indexNames); SearchSourceBuilder builder = new SearchSourceBuilder(); BoolQueryBuilder boolQueryBuilder = new BoolQueryBuilder(); boolQueryBuilder.must(new MatchQueryBuilder(field, key)).must(new RangeQueryBuilder(rangeField).from(from).to(to)).must(new TermQueryBuilder(termField, termVal)); builder.query(boolQueryBuilder); request.source(builder); log.info("[搜索语句为:{}]",request.source().toString()); return client.search(request, RequestOptions.DEFAULT); } /** * 批量导入 * @param indexName * @param isAutoId 使用自动id 还是使用传入对象的id * @param source * @return * @throws IOException */ public BulkResponse importAll(String indexName, boolean isAutoId, String source) throws IOException{ if (0 == source.length()){ //todo 抛出异常 导入数据为空 } BulkRequest request = new BulkRequest(); JsonNode jsonNode = mapper.readTree(source); if (jsonNode.isArray()) { for (JsonNode node : jsonNode) { if (isAutoId) { request.add(new IndexRequest(indexName).source(node.asText(), XContentType.JSON)); } else { request.add(new IndexRequest(indexName) .id(node.get("id").asText()) .source(node.asText(), XContentType.JSON)); } } } return client.bulk(request, RequestOptions.DEFAULT); }创建索引，这里的settings是设置索引是否设置复制节点、设置分片个数，mappings就和数据库中的表结构一样，用来指定各个字段的类型，同时也可以设置字段是否分词（我们这里使用ik中文分词器）、采用什么分词方式。@Test public void createIdx() throws IOException { String settings = "" + " {\n" + " \"number_of_shards\" : \"2\",\n" + " \"number_of_replicas\" : \"0\"\n" + " }"; String mappings = "" + "{\n" + " \"properties\": {\n" + " \"itemId\" : {\n" + " \"type\": \"keyword\",\n" + " \"ignore_above\": 64\n" + " },\n" + " \"urlId\" : {\n" + " \"type\": \"keyword\",\n" + " \"ignore_above\": 64\n" + " },\n" + " \"sellAddress\" : {\n" + " \"type\": \"text\",\n" + " \"analyzer\": \"ik_max_word\", \n" + " \"search_analyzer\": \"ik_smart\",\n" + " \"fields\": {\n" + " \"keyword\" : {\"ignore_above\" : 256, \"type\" : \"keyword\"}\n" + " }\n" + " },\n" + " \"courierFee\" : {\n" + " \"type\": \"text\n" + " },\n" + " \"promotions\" : {\n" + " \"type\": \"text\",\n" + " \"analyzer\": \"ik_max_word\", \n" + " \"search_analyzer\": \"ik_smart\",\n" + " \"fields\": {\n" + " \"keyword\" : {\"ignore_above\" : 256, \"type\" : \"keyword\"}\n" + " }\n" + " },\n" + " \"originalPrice\" : {\n" + " \"type\": \"keyword\",\n" + " \"ignore_above\": 64\n" + " },\n" + " \"startTime\" : {\n" + " \"type\": \"date\",\n" + " \"format\": \"yyyy-MM-dd HH:mm:ss\"\n" + " },\n" + " \"endTime\" : {\n" + " \"type\": \"date\",\n" + " \"format\": \"yyyy-MM-dd HH:mm:ss\"\n" + " },\n" + " \"title\" : {\n" + " \"type\": \"text\",\n" + " \"analyzer\": \"ik_max_word\", \n" + " \"search_analyzer\": \"ik_smart\",\n" + " \"fields\": {\n" + " \"keyword\" : {\"ignore_above\" : 256, \"type\" : \"keyword\"}\n" + " }\n" + " },\n" + " \"serviceGuarantee\" : {\n" + " \"type\": \"text\",\n" + " \"analyzer\": \"ik_max_word\", \n" + " \"search_analyzer\": \"ik_smart\",\n" + " \"fields\": {\n" + " \"keyword\" : {\"ignore_above\" : 256, \"type\" : \"keyword\"}\n" + " }\n" + " },\n" + " \"venue\" : {\n" + " \"type\": \"text\",\n" + " \"analyzer\": \"ik_max_word\", \n" + " \"search_analyzer\": \"ik_smart\",\n" + " \"fields\": {\n" + " \"keyword\" : {\"ignore_above\" : 256, \"type\" : \"keyword\"}\n" + " }\n" + " },\n" + " \"currentPrice\" : {\n" + " \"type\": \"keyword\",\n" + " \"ignore_above\": 64\n" + " }\n" + " }\n" + "}"; clientService.createIndex("idx_item", settings, mappings); }分词技巧：索引时最小分词，搜索时最大分词，例如"Java知音"索引时分词包含Java、知音、音、知等，最小粒度分词可以让我们匹配更多的检索需求，但是我们搜索时应该设置最大分词，用“Java”和“知音”去匹配索引库，得到的结果更贴近我们的目的，对分词字段同时也设置keyword，便于后续排查错误时可以精确匹配搜索，快速定位。我们向es导入十万条淘宝双11活动数据作为我们的样本数据，数据结构如下所示{ "_id": "https://detail.tmall.com/item.htm?id=538528948719\u0026skuId=3216546934499", "卖家地址": "上海", "快递费": "运费: 0.00元", "优惠活动": "满199减10,满299减30,满499减60,可跨店", "商品ID": "538528948719", "原价": "2290.00", "活动开始时间": "2016-11-11 00:00:00", "活动结束时间": "2016-11-11 23:59:59", "标题": "【天猫海外直营】 ReFa CARAT RAY 黎珐 双球滚轮波光美容仪", "服务保障": "正品保证;赠运费险;极速退款;七天退换", "会场": "进口尖货", "现价": "1950.00" }调用上面封装的批量导入方法进行导入@Test public void importAll() throws IOException { clientService.importAll("idx_item", true, itemService.getItemsJson()); }我们调用封装的搜索方法进行搜索，搜索产地为武汉、价格在11-149之间的相关酒产品，这与我们淘宝中设置筛选条件搜索商品操作一致。@Test public void search() throws IOException { SearchResponse search = clientService.search("title", "酒", "currentPrice", "11", "149", "sellAddress", "武汉"); SearchHits hits = search.getHits(); SearchHit[] hits1 = hits.getHits(); for (SearchHit documentFields : hits1) { System.out.println( documentFields.getSourceAsString()); } }我们得到以下搜索结果，其中_score为某一项的得分，商品就是按照它来排序。{ "_index": "idx_item", "_type": "_doc", "_id": "Rw3G7HEBDGgXwwHKFPCb", "_score": 10.995819, "_source": { "itemId": "525033055044", "urlId": "https://detail.tmall.com/item.htm?id=525033055044&skuId=def", "sellAddress": "湖北武汉", "courierFee": "快递: 0.00", "promotions": "满199减10,满299减30,满499减60,可跨店", "originalPrice": "3768.00", "startTime": "2016-11-01 00:00:00", "endTime": "2016-11-11 23:59:59", "title": "酒嗨酒 西班牙原瓶原装进口红酒蒙德干红葡萄酒6只装整箱送酒具", "serviceGuarantee": "破损包退;正品保证;公益宝贝;不支持7天退换;极速退款", "venue": "食品主会场", "currentPrice": "151.00" } }扩展性思考商品搜索权重扩展，我们可以利用多种收费方式智能为不同店家提供增加权重，增加曝光度适应自身的营销策略。同时我们经常发现淘宝搜索前列的商品许多为我们之前查看过的商品，这是通过记录用户行为，跑模型等方式智能为这些商品增加权重。分词扩展，也许因为某些商品的特殊性，我们可以自定义扩展分词字典，更精准、人性化的搜索。高亮功能，es提供highlight高亮功能，我们在淘宝上看到的商品展示中对搜索关键字高亮，就是通过这种方式来实现。项目地址https://github.com/Motianshi/alldemo/tree/master/demo-searchEND

前言2021年双十一刚刚落幕，已连续多年稳定支持双十一大促的云原生数据仓库AnalyticDB，今年双十一期间仍然一如既往的稳定。除了稳定顺滑的基本盘之外，AnalyticDB还有什么亮点呢？下面我们来一一揭秘。长风破浪 | AnalyticDB再战双十一今年双十一，AnalyticDB的战场横跨阿里数字经济体、公共云和混合云，三个战场都稳如泰山、成绩斐然。在阿里数字经济体内，AnalyticDB支撑的业务几乎覆盖了所有BU，诸如手淘订单搜索、菜鸟、淘特、盒马、飞猪、猫超、阿里云等近200个双11相关的核心业务；在公有云上，AnalyticDB支撑着数云、聚水潭等诸多电商相关的核心业务；在专有云上，AnalyticDB主要支持中国邮政集团的各类业务。今年AnalyticDB支撑的业务负载特别多元化，从单库百万级峰值TPS的实时数据写入到核心交易链路的高并发在线订单检索和关键字精准推荐，从各种业务场景下的复杂实时分析到各种人群和标签数据的大批量离线Batch&ETL任务以及数据导入导出任务，这种五花八门的业务负载，甚至离在线混合负载同时执行的场景，对AnalyticDB提出了巨大的挑战。面对这些业务场景和技术挑战，AnalyticDB迎难而上，今年以来，全面拥抱云原生构建极致弹性，全面推进存储计算分离架构，通过冷热温分层存储大幅降低存储成本，通过升级向量化引擎和优化器框架大幅提升计算性能，全面推进离在线一体化架构，进一步提升在一套技术架构下同时稳定运行在线实时查询和离线批量计算任务的能力。正是有了这些技术积累和沉淀，AnalyticDB在今年的双十一战场上才能更加稳定从容，各项业务指标继续再创新高，今年双十一期间累计实时写入21万亿条数据，批量导入113万亿条数据，完成350亿次在线查询和2500万个离线任务，累计590PB数据参与计算。不论是从支持业务场景的复杂度上看，还是从数据规模和计算规模上看，AnalyticDB作为离在线一体化架构下的新一代云原生数据仓库已经越来越成熟，可以为各种业务提供核心报表计算、实时分析决策、活动大屏与系统监控、智能营销等通用能力。同时，今年AnalyticDB重点结合手淘订单搜索和推荐、实时订单同步等核心业务场景，以技术创新为核心，帮助业务解决了不少长期困扰的棘手问题，助力业务在用户体验、绿色低碳、业务创新、安全稳定等方面取得新突破。1  体验第一：看AnalyticDB如何优化手淘交易订单搜索手淘订单搜索支持用户输入关键词或订单号查询历史订单，是通过历史订单关联商品和店铺从而产生复购的重要流量入口之一。不过由于用户的历史订单信息量非常大，达数千亿之多，而用户往往仅记得商品或店铺的模糊信息，导致用户输入的关键词要么不准确可能搜不到订单，要么关键字很短导致查找到订单很多响应时间很长，极大影响手淘用户的产品体验，长期为用户所诟病。AnalyticDB基于新实时引擎+行存表+非结构化索引+宽表检索的在线能力，首次实现了在线和历史交易订单的统一存储、分析，赋能交易业务中台对全网用户十年全量的交易订单进行多维搜索，并根据用户的搜索关键字进行精准推荐。大促峰值期间用户反馈“订单查不到”的舆情同比大幅下降，查询性能也得到大幅提升，大大提升了手淘订单搜索的用户体验。2  绿色低碳：看AnalyticDB如何助力业务降本增效公共云客户数云赢家2.0全域CRM平台通过采用以云原生数据仓库AnalyticDB为核心的整体方案，在双11期间对客户洞察和细分、自动化营销等核心功能进行全面升级。基于云原生、资源池化和冷热数据分离能力，业务研发周期比往常缩短39%，整体成本下降50%，运营效率提升3倍，解决了采购实施成本过高难题，助力商家快速响应业务变化，降本增效成果显著。阿里集团内部一个核心业务的数据分析服务每天需要执行大量ETL离线作业，同时需要支持大量实时数据写入，以满足准实时的人群圈选服务和在线人群透视服务需求，支持数据实时写入和离在线混合负载的AnalyticDB一直是该服务的不二之选。今年双十一期间，AnalyticDB 承担了该服务数十PB数据读写请求，数百万次的离在线混合查询，完成PB级数据量的ETL作业。得益于 AnalyticDB 3.0的云原生弹性能力，结合存储/计算/优化器 的全链路优化，成本同比去年双十一下降近50%。3  唯快不破：看库仓一体化架构如何支持高吞吐实时业务今年双十一首次采用AnalyticDB+DMS库仓一体化架构替换了DRC+ESDB实现全实时历史订单搜索等核心场景，快速搭建毫秒级延迟的实时数据链路和数据应用，让实时数据的价值得到充分发挥，助力业务在更加实时的数据应用场景和更加极致的用户体验上产生新变化、取得新突破。在交易订单搜索业务中，根据交易业务特点搭建了多路数据同步链路并采用AnalyticDB主备容灾部署方案，双十一大促期间轻松支持RPS达数百万的峰值流量，全程毫秒级延迟。常胜之秘 | AnalyticDB最新核心技术解析1  离在线服务化存储AnalyticDB的存储层今年完成了服务化改造，具备一份数据、一套存储格式同时支持实时更新、交互式查询、离线ETL及明细点查多场景一体化能力。基于存储服务层、行列混存、分层存储、自适应索引等技术，可同时支持在线低延迟+强一致和离线高吞吐两种数据读写场景。存储服务：离在线统一访问接口接口层方面，AnalyticDB存储向上提供统一的数据访问接口，数据交互采用Apache Arrow[1]数据格式，基于零拷贝技术实现高效传输，计算层可以基于Arrow内存列式的接口进行CPU友好的向量化计算加速；元数据兼容Hive MetaService的Thrift交互协议，开源计算引擎可以无缝对接AnalyticDB存储系统。服务层方面，AnalyticDB存储采用类LSM架构[2]，把存储分为实时数据和历史数据两部分，实时数据存储在在线存储节点上，作为“热”数据，支持低延迟数据访问，且支持强一致CURD。历史数据存储在OSS或HDFS等低成本的分布式文件系统上，作为“冷”数据，支持高吞吐数据访问。同时，AnalyticDB存储服务层还支持谓词、投影、聚合、Top N等计算下推能力，减少数据的扫描和读取量，进一步加速查询。行列混存：离在线统一存储格式既然提供了一体化的存储服务，必然会涉及到在线低延迟查询和离线高吞吐计算场景，AnalyticDB存储格式采用PAX格式[3]兼顾了离在线两种场景。在线场景，与索引配合提供高效的检索查找能力。AnalyticDB的存储格式每个Chunk定长存储，能够和索引深度融合，可以基于行号随机查找，保证高效的随机读性能，可以很好地满足在线多维度筛选的场景。此外，还提供了丰富的统计信息，可以和索引配合做叠加优化，从而进一步加速查询。离线场景，AnalyticDB的存储格式可以按照Chunk粒度切分数据读取的并行度，多Chunk并行访问，提高离线读的吞吐性能。AnalyticDB的一张表支持多个分区，且分区内支持多Segment，可以通过切分Segment来提高数据写入的并行度，从而提高离线写的吞吐性能。此外，每个Chunk提供了Min/Max等粗糙集索引信息，可以利用这些索引信息减少离线读的数据扫描量和IO资源消耗。自适应索引AnalyticDB另一个特色之一是自研自适应索引框架，支持五种索引类型：字符串倒排索引、Bitmap索引、数字类型KDTree索引、JSON索引和向量索引；不同类型的索引可以支持多种条件（交、并、差）下列级索引的任意组合；相较于传统数据库，AnalyticDB的优势在于，无需手工构建组合索引（组合索引需要精巧的设计、且容易引起索引数据的空间膨胀）、且支持OR/NOT等更多条件的索引下推。为了降低用户使用门槛，AnalyticDB在建表时可以一键自动开启全列索引，查询时通过Index CBO自适应动态筛选索引下推，确定下推的索引链会通过谓词计算层进行流式渐进多路归并输出。冷热分层：降低用户成本、按量计费AnalyticDB提供的冷热分层存储能力[4][5]可以为用户带来更高性价比的体验。用户可以按表粒度、表的二级分区粒度独立选择冷、热存储介质，比如指定用户表数据全部存储在热存储介质，或指定表数据全部存储在冷存储介质，或指定表的一部分分区数据存储在热存储介质，另一部分分区数据存储在冷存储介质，完全可以按业务需求自由指定，并且冷热策略可以自由转换。同时，热数据和冷数据的空间使用是按量计费的。业务可以根据自己的业务特点，基于AnalyticDB的冷热存储分层技术管理业务数据的生命周期，需要频繁访问的数据分区指定为热数据存储在热存储介质以加速查询，不需要频繁访问的数据分区指定为冷数据存储在冷存储介质以降低存储成本，通过数据分区的生命周期管理机制自动清理过期的数据。2  离在线混合负载在线场景的计算负载（比如在线查询）对响应时间要求高，对数据读取和计算引擎的要求就是快；而离线场景的计算负载（比如ETL任务）对响应时间不敏感，但对计算吞吐有较高要求，不仅数据计算量大，数据读取和写入量也可能很大，任务执行时间长。离在线两种完全不同场景的负载要在一套系统、一个平台上同时执行一直以来都是一个巨大的挑战。目前业界的主流解决方案仍然是：离线任务运行在离线大数据计算平台（比如hadoop/spark/hive）上，在线查询运行在另外一个或多个单独的OLAP系统（比如ClickHouse/Doris）上。不过在这种架构下，多个系统内部的数据存储和格式不统一，计算逻辑表示（比如SQL标准）也不统一，导致数据需要在多个系统之间相互导入导出，计算逻辑也需要分别适配对应的系统，数据链路冗长，数据计算和使用成本高，数据的时效性也不好。为了解决此类问题，AnalyticDB今年全面升级离在线混合负载能力，除了存储层提供离在线统一存储格式和统一访问接口用以解决离在线混合负载的数据读取和写入问题，计算层也完成了全面升级，相同的SQL查询可以同时支持Interactive和Batch两种执行模式，通过资源组、读写负载分离、多队列隔离和查询优先级等机制对不同类型的负载进行资源隔离和管控，通过分时弹性满足不同负载的扩缩容和错峰需求。同时，计算引擎全面升级为向量化引擎，大幅提升计算性能。相同SQL两种执行模式AnalyticDB支持Interactive和Batch两种执行模式，以分别满足在线查询和离线计算的不同场景需求。Interactive模式下，查询以MMP(Massive Parallel Processing)方式执行，所有Task同时调度启动，流式读取数据并计算输出结果，所有计算都在内存中进行，尽可能减少查询执行时间，适合在线场景负载。Batch模式下，计算任务以BSP(Bulk Synchronous Parallel)方式执行，整个任务会根据语义切分成多个阶段（Stage），根据Stage间的依赖关系进行调度和执行，上游Stage执行完才会执行下游Stage，Stage之间的数据传递需要落盘，计算过程中内存不足时也会将中间状态落盘，因此任务整体的执行时间会较长，但对CPU和内存等计算资源的需求相对较少，适合数据大、计算资源相对有限的离线场景。在AnalyticDB内部，不论是Interactive模式还是Batch模式，表达计算逻辑的SQL是统一，产生的逻辑执行计划也是完全一样的，只是根据不同的模式生成不同的物理执行计划，且计算引擎中绝大部分的算子实现也是相同的，也为统一升级到向量化计算引擎奠定架构基础。全新向量化查询引擎向量化是当代查询引擎优化查询性能的热点技术之一，相关思路最早可以追溯到Array programming在科学计算领域的研究，在数据库领域的探索则缘起于MonetDB/X100[6]。目前工业界各主流系统都拥有自己的向量化实践，但仍缺乏标准的形式化定义。一般来讲，它被认为是查询引擎面向CPU microarchitecture一系列优化方案的统称，涉及Batch based iterator model[7]，CodeGen，Cache-awareness算法[8]以及SIMD指令集应用等技术应用，以及计算/存储一体化的架构设计。而探索并识别这些技术间正交/依赖的关系是利用好向量化技术取得显著性能提升的关键问题。AnalyticDB实现了核心算子的全面向量化，包括Scan，Exchange，Group-by/Agg，以及Join算子；方案里结合应用了Batch Processing，Adaptive Strategy，Codegen以及Cache-awareness算法，并通过与JVM团队共建，基于AJDK intrinsic能力[9]创新地实现了算法关键路径上SSE2，AVX512等指令集的应用。显著提升查询执行过程中CPU IPL和MPL，热点算子Agg/Join的吞吐性能提升2x-15x。混合负载隔离和稳定性保障多种负载在同一架构下运行，甚至在同一时刻运行，不可避免存在资源竞争、相互影响的问题。AnalyticDB有一套较为完整的的机制和策略来保证集群的稳定性，并且尽可能满足不同业务负载的SLA要求。首先，在混合负载场景或实例内部多租户场景下，可以通过资源组进行有效的业务负载隔离。不同资源组之间的计算资源在物理上完全隔离，避免不同类型或业务的负载之间产生相互影响。不同的业务可以通过绑定账号、提交查询时指定资源组等多种方式指定运行在对应的资源组上。其次，AnalyticDB内部会自动区分写入负载（部分insert和delete）、查询负载（比如select查询）和读写负载（部分insert/update/delete），不同类型的负载任务自动分派到不同的队列上，且分配不同的执行优先级和计算资源。具体来看，写入请求有单独的加速写入链路和资源保证，查询负载默认有较高的执行优先级，而读写负载则默认是较低的执行优先级。另外，在执行过程中，AnalyticDB会根据集群的当前负载情况和查询任务已运行的时长，动态降低运行时间较长的查询任务的执行优先级，以缓解Slow Query或Bad Query对其它查询产生的不利影响。最后，很多业务都有非常明显的呈现周期性的波峰波谷，特别是离线计算任务往往是周期性进行调度和执行的，业务高峰期时资源需求暴增可能导致业务不稳定，业务低峰期时资源闲置又导致额外的成本。AnalyticDB提供分时弹性功能，可以帮助用户在业务高峰期资源不足时扩容资源以保证业务负载稳定执行，在业务低峰期时缩减资源以节约成本。通过合理的业务规划和资源组管理，用户甚至可以让某些资源组在低峰期时释放所有资源，极大地节约成本。3  全新优化器框架近年来，自治（Autonomous）能力已经成为数据库发展的重要方向和趋势。与传统数据库相比，云数据库提供一站式托管服务，也对自治能力提出了更高的要求。为此，AnalyticDB 研发了全新的优化器架构，向更加智能化的自治数据库方向迈进，为用户带来更好的体验。AnalyticDB 优化器进行了大面积的重构升级，主体上拆分成 RBO (Rule-based optimizer) 和 CBO (Cost-based optimizer)。RBO 负责做确定性的优化。比如，将过滤条件尽可能下推，以减少后续算子的运算量。CBO 负责做不确定性的优化。比如，调整 JOIN 运算的顺序。调整的收益是不确定的，所以需要通过代估模块来决策。为了让这两大模块更好的工作，给予用户更好的体验，AnalyticDB 引入了全新的四大特性。特性1：Histogram直方图的引入，可以有效提升代估的质量，让 CBO 选出更好的计划。直方图可以有效解决用户数据值的分布不均问题，有效解决代估中“均匀分布假设”问题。为了验证直方图效果，AnalyticDB还构建了一套代估质量评价系统。在灰度实例中，代估综合错误率降幅可达50%以上。特性2：Autonomous statistics如何管理好表的统计信息，也是一个非常头疼的问题。如果把这个问题抛给用户，让用户执行命令去收集统计信息，会给用户带来巨大的困扰。为此，AnalyticDB引入了统计信息自治框架，来管理这个事情。AnalyticDB会尽可能降低收集动作对用户的影响，带来最好的体验。AnalyticDB会识别出每一列需要收集的统计信息等级，不同等级收集开销不同。同时也会识别出统计信息是否过期，来决定是否要重新收集。特性3：Incremental statistics传统的统计信息收集方式，需要进行全表扫描。全表扫描开销大，对用户影响大，不符合提升用户体验的初衷。为此，AnalyticDB引入了增量统计信息框架，可以只更新单个分区的统计信息，然后通过全局合并技术，得到整个表全局的统计信息。这样可以大幅降低收集的开销，减少对用户的影响。特性4：Property derivation如何让计划变得更优，属性推导对此有着重要的意义。它就像电影中的彩蛋，需要你去发掘。我们通过这个特性可以发掘SQL中隐含的信息，从而进一步优化计划。比如，用户 SQL 写了 “A=B” 条件，之后又做了一次 “GROUP BY A,B”，那么其实是可以简化成 “GROUP BY A” 或 “GROUP BY B”。因为我们通过属性推导，知道了A等价于B。4  智能诊断和优化智能诊断AnalyticDB的智能诊断功能融合逻辑执行计划和物理执行计划，从「Query级别」,「Stage级别」，「算子级别」三个层次诊断分析，帮用户快速定位问题Query、Stage和算子，直接给出直观的问题分析，如数据倾斜、索引不高效、条件没下推等，并给出对应的调优建议。目前已经有20+诊断规则上线，涉及查询相关的内存消耗、耗时、数据倾斜、磁盘IO以及执行计划等多个方面，后续还有更多诊断规则陆续上线。智能优化AnalyticDB的智能优化功能提供针对数据库、表结构的优化功能，为用户提供降低集群使用成本、提高集群使用效率的调优建议。该功能基于SQL查询的性能指标以及使用到的数据表、索引等信息进行算法统计分析，自动给出调优建议，减少用户手动调优的负担。智能优化目前提供三种类型的优化建议：1） 冷热数据优化：分析数据表的使用情况，对长期未使用的数据表，建议将其迁移至冷盘存储，约60%的实例可以通过该建议的提示，将 15 天未使用的数据表移至冷存，节省 3 成以上的热存空间；2）索引优化：分析数据索引的使用情况，对长期未使用的数据索引，建议将其删除，约50%的实例可以通过该建议的提示，将 15 天未使用的索引进行删除，节省 3 成以上的热存空间；3）分区优化：分析数据查询实际需要使用的分布键与数据表定义的分布列之间的差异，对设计不合理的分布键，建议变更该数据表的分布键，以提高数据的查询性能。总结和展望经过多年双十一的淬炼，AnalyticDB不仅抗住了一年高过一年的的极端负载和流量，也在不断丰富的业务场景中逐步成长，不断赋能到集团内外各种新老业务和场景中，逐步成长为新一代云原生数据仓库的佼佼者。接下来AnalyticDB将继续以“人人可用的数据服务”为使命，进一步拥抱云原生，构建数据库+大数据一体化架构，建设极致弹性、离在线一体、高性价比、智能自治等企业级能力，进一步赋能用户挖掘数据背后的商业价值。参考文献

阿里云数据库已连续多年稳定支撑天猫双11，历经极端流量场景淬炼。除了保障稳定顺滑的基本盘，今年大促期间数据库通过全面云原生化，大幅提升用户体验，让技术帮助业务产生更有价值的消费者体验，持续通过技术创新赋能用户，引领技术发展路径。双11已圆满落幕，但技术的探索，仍未止步。“阿里云数据库” 公众号特此推出《好科技的新起点——2021双11阿里云数据库技术揭秘》系列干货文章，为你讲述年度“技术大考”背后的故事，敬请关注！一  前言2021年双十一刚刚落幕，已连续多年稳定支持双十一大促的云原生数据仓库AnalyticDB，今年双十一期间仍然一如既往的稳定。除了稳定顺滑的基本盘之外，AnalyticDB还有什么亮点呢？下面我们来一一揭秘。二  长风破浪 | AnalyticDB再战双十一今年双十一，AnalyticDB的战场横跨阿里数字经济体、公共云和混合云，三个战场都稳如泰山、成绩斐然。在阿里数字经济体内，AnalyticDB支撑的业务几乎覆盖了所有BU，诸如手淘订单搜索、菜鸟、淘特、盒马、飞猪、猫超、阿里云等近200个双11相关的核心业务；在公有云上，AnalyticDB支撑着数云、聚水潭等诸多电商相关的核心业务；在专有云上，AnalyticDB主要支持中国邮政集团的各类业务。今年AnalyticDB支撑的业务负载特别多元化，从单库百万级峰值TPS的实时数据写入到核心交易链路的高并发在线订单检索和关键字精准推荐，从各种业务场景下的复杂实时分析到各种人群和标签数据的大批量离线Batch&ETL任务以及数据导入导出任务，这种五花八门的业务负载，甚至离在线混合负载同时执行的场景，对AnalyticDB提出了巨大的挑战。面对这些业务场景和技术挑战，AnalyticDB迎难而上，今年以来，全面拥抱云原生构建极致弹性，全面推进存储计算分离架构，通过冷热温分层存储大幅降低存储成本，通过升级向量化引擎和优化器框架大幅提升计算性能，全面推进离在线一体化架构，进一步提升在一套技术架构下同时稳定运行在线实时查询和离线批量计算任务的能力。正是有了这些技术积累和沉淀，AnalyticDB在今年的双十一战场上才能更加稳定从容，各项业务指标继续再创新高，今年双十一期间累计实时写入21万亿条数据，批量导入113万亿条数据，完成350亿次在线查询和2500万个离线任务，累计590PB数据参与计算。 不论是从支持业务场景的复杂度上看，还是从数据规模和计算规模上看，AnalyticDB作为离在线一体化架构下的新一代云原生数据仓库已经越来越成熟，可以为各种业务提供核心报表计算、实时分析决策、活动大屏与系统监控、智能营销等通用能力。同时，今年AnalyticDB重点结合手淘订单搜索和推荐、实时订单同步等核心业务场景，以技术创新为核心，帮助业务解决了不少长期困扰的棘手问题，助力业务在用户体验、绿色低碳、业务创新、安全稳定等方面取得新突破。1  体验第一：看AnalyticDB如何优化手淘交易订单搜索手淘订单搜索支持用户输入关键词或订单号查询历史订单，是通过历史订单关联商品和店铺从而产生复购的重要流量入口之一。不过由于用户的历史订单信息量非常大，达数千亿之多，而用户往往仅记得商品或店铺的模糊信息，导致用户输入的关键词要么不准确可能搜不到订单，要么关键字很短导致查找到订单很多响应时间很长，极大影响手淘用户的产品体验，长期为用户所诟病。AnalyticDB基于新实时引擎+行存表+非结构化索引+宽表检索的在线能力，首次实现了在线和历史交易订单的统一存储、分析，赋能交易业务中台对全网用户十年全量的交易订单进行多维搜索，并根据用户的搜索关键字进行精准推荐。大促峰值期间用户反馈“订单查不到”的舆情同比大幅下降，查询性能也得到大幅提升，大大提升了手淘订单搜索的用户体验。2  绿色低碳：看AnalyticDB如何助力业务降本增效公共云客户数云赢家2.0全域CRM平台通过采用以云原生数据仓库AnalyticDB为核心的整体方案，在双11期间对客户洞察和细分、自动化营销等核心功能进行全面升级。基于云原生、资源池化和冷热数据分离能力，业务研发周期比往常缩短39%，整体成本下降50%，运营效率提升3倍，解决了采购实施成本过高难题，助力商家快速响应业务变化，降本增效成果显著。阿里集团内部一个核心业务的数据分析服务每天需要执行大量ETL离线作业，同时需要支持大量实时数据写入，以满足准实时的人群圈选服务和在线人群透视服务需求，支持数据实时写入和离在线混合负载的AnalyticDB一直是该服务的不二之选。今年双十一期间，AnalyticDB 承担了该服务数十PB数据读写请求，数百万次的离在线混合查询，完成PB级数据量的ETL作业。得益于 AnalyticDB 3.0的云原生弹性能力，结合存储/计算/优化器 的全链路优化，成本同比去年双十一下降近50%。3  唯快不破：看库仓一体化架构如何支持高吞吐实时业务今年双十一首次采用AnalyticDB+DMS库仓一体化架构替换了DRC+ESDB实现全实时历史订单搜索等核心场景，快速搭建毫秒级延迟的实时数据链路和数据应用，让实时数据的价值得到充分发挥，助力业务在更加实时的数据应用场景和更加极致的用户体验上产生新变化、取得新突破。在交易订单搜索业务中，根据交易业务特点搭建了多路数据同步链路并采用AnalyticDB主备容灾部署方案，双十一大促期间轻松支持RPS达数百万的峰值流量，全程毫秒级延迟。三  常胜之秘 | AnalyticDB最新核心技术解析1  离在线服务化存储AnalyticDB的存储层今年完成了服务化改造，具备一份数据、一套存储格式同时支持实时更新、交互式查询、离线ETL及明细点查多场景一体化能力。基于存储服务层、行列混存、分层存储、自适应索引等技术，可同时支持在线低延迟+强一致和离线高吞吐两种数据读写场景。存储服务：离在线统一访问接口接口层方面，AnalyticDB存储向上提供统一的数据访问接口，数据交互采用Apache Arrow[1]数据格式，基于零拷贝技术实现高效传输，计算层可以基于Arrow内存列式的接口进行CPU友好的向量化计算加速；元数据兼容Hive MetaService的Thrift交互协议，开源计算引擎可以无缝对接AnalyticDB存储系统。服务层方面，AnalyticDB存储采用类LSM架构[2]，把存储分为实时数据和历史数据两部分，实时数据存储在在线存储节点上，作为“热”数据，支持低延迟数据访问，且支持强一致CURD。历史数据存储在OSS或HDFS等低成本的分布式文件系统上，作为“冷”数据，支持高吞吐数据访问。同时，AnalyticDB存储服务层还支持谓词、投影、聚合、Top N等计算下推能力，减少数据的扫描和读取量，进一步加速查询。行列混存：离在线统一存储格式既然提供了一体化的存储服务，必然会涉及到在线低延迟查询和离线高吞吐计算场景，AnalyticDB存储格式采用PAX格式[3]兼顾了离在线两种场景。在线场景，与索引配合提供高效的检索查找能力。AnalyticDB的存储格式每个Chunk定长存储，能够和索引深度融合，可以基于行号随机查找，保证高效的随机读性能，可以很好地满足在线多维度筛选的场景。此外，还提供了丰富的统计信息，可以和索引配合做叠加优化，从而进一步加速查询。离线场景，AnalyticDB的存储格式可以按照Chunk粒度切分数据读取的并行度，多Chunk并行访问，提高离线读的吞吐性能。AnalyticDB的一张表支持多个分区，且分区内支持多Segment，可以通过切分Segment来提高数据写入的并行度，从而提高离线写的吞吐性能。此外，每个Chunk提供了Min/Max等粗糙集索引信息，可以利用这些索引信息减少离线读的数据扫描量和IO资源消耗。自适应索引AnalyticDB另一个特色之一是自研自适应索引框架，支持五种索引类型：字符串倒排索引、Bitmap索引、数字类型KDTree索引、JSON索引和向量索引；不同类型的索引可以支持多种条件（交、并、差）下列级索引的任意组合；相较于传统数据库，AnalyticDB的优势在于，无需手工构建组合索引（组合索引需要精巧的设计、且容易引起索引数据的空间膨胀）、且支持OR/NOT等更多条件的索引下推。为了降低用户使用门槛，AnalyticDB在建表时可以一键自动开启全列索引，查询时通过Index CBO自适应动态筛选索引下推，确定下推的索引链会通过谓词计算层进行流式渐进多路归并输出。冷热分层：降低用户成本、按量计费AnalyticDB提供的冷热分层存储能力[4][5]可以为用户带来更高性价比的体验。用户可以按表粒度、表的二级分区粒度独立选择冷、热存储介质，比如指定用户表数据全部存储在热存储介质，或指定表数据全部存储在冷存储介质，或指定表的一部分分区数据存储在热存储介质，另一部分分区数据存储在冷存储介质，完全可以按业务需求自由指定，并且冷热策略可以自由转换。同时，热数据和冷数据的空间使用是按量计费的。业务可以根据自己的业务特点，基于AnalyticDB的冷热存储分层技术管理业务数据的生命周期，需要频繁访问的数据分区指定为热数据存储在热存储介质以加速查询，不需要频繁访问的数据分区指定为冷数据存储在冷存储介质以降低存储成本，通过数据分区的生命周期管理机制自动清理过期的数据。2  离在线混合负载在线场景的计算负载（比如在线查询）对响应时间要求高，对数据读取和计算引擎的要求就是快；而离线场景的计算负载（比如ETL任务）对响应时间不敏感，但对计算吞吐有较高要求，不仅数据计算量大，数据读取和写入量也可能很大，任务执行时间长。离在线两种完全不同场景的负载要在一套系统、一个平台上同时执行一直以来都是一个巨大的挑战。目前业界的主流解决方案仍然是：离线任务运行在离线大数据计算平台（比如hadoop/spark/hive）上，在线查询运行在另外一个或多个单独的OLAP系统（比如ClickHouse/Doris）上。不过在这种架构下，多个系统内部的数据存储和格式不统一，计算逻辑表示（比如SQL标准）也不统一，导致数据需要在多个系统之间相互导入导出，计算逻辑也需要分别适配对应的系统，数据链路冗长，数据计算和使用成本高，数据的时效性也不好。为了解决此类问题，AnalyticDB今年全面升级离在线混合负载能力，除了存储层提供离在线统一存储格式和统一访问接口用以解决离在线混合负载的数据读取和写入问题，计算层也完成了全面升级，相同的SQL查询可以同时支持Interactive和Batch两种执行模式，通过资源组、读写负载分离、多队列隔离和查询优先级等机制对不同类型的负载进行资源隔离和管控，通过分时弹性满足不同负载的扩缩容和错峰需求。同时，计算引擎全面升级为向量化引擎，大幅提升计算性能。相同SQL两种执行模式AnalyticDB支持Interactive和Batch两种执行模式，以分别满足在线查询和离线计算的不同场景需求。Interactive模式下，查询以MMP(Massive Parallel Processing)方式执行，所有Task同时调度启动，流式读取数据并计算输出结果，所有计算都在内存中进行，尽可能减少查询执行时间，适合在线场景负载。Batch模式下，计算任务以BSP(Bulk Synchronous Parallel)方式执行，整个任务会根据语义切分成多个阶段（Stage），根据Stage间的依赖关系进行调度和执行，上游Stage执行完才会执行下游Stage，Stage之间的数据传递需要落盘，计算过程中内存不足时也会将中间状态落盘，因此任务整体的执行时间会较长，但对CPU和内存等计算资源的需求相对较少，适合数据大、计算资源相对有限的离线场景。在AnalyticDB内部，不论是Interactive模式还是Batch模式，表达计算逻辑的SQL是统一，产生的逻辑执行计划也是完全一样的，只是根据不同的模式生成不同的物理执行计划，且计算引擎中绝大部分的算子实现也是相同的，也为统一升级到向量化计算引擎奠定架构基础。全新向量化查询引擎向量化是当代查询引擎优化查询性能的热点技术之一，相关思路最早可以追溯到Array programming在科学计算领域的研究，在数据库领域的探索则缘起于MonetDB/X100[6]。目前工业界各主流系统都拥有自己的向量化实践，但仍缺乏标准的形式化定义。一般来讲，它被认为是查询引擎面向CPU microarchitecture一系列优化方案的统称，涉及Batch based iterator model[7]，CodeGen，Cache-awareness算法[8]以及SIMD指令集应用等技术应用，以及计算/存储一体化的架构设计。而探索并识别这些技术间正交/依赖的关系是利用好向量化技术取得显著性能提升的关键问题。AnalyticDB实现了核心算子的全面向量化，包括Scan，Exchange，Group-by/Agg，以及Join算子；方案里结合应用了Batch Processing，Adaptive Strategy，Codegen以及Cache-awareness算法，并通过与JVM团队共建，基于AJDK intrinsic能力[9]创新地实现了算法关键路径上SSE2，AVX512等指令集的应用。显著提升查询执行过程中CPU IPL和MPL，热点算子Agg/Join的吞吐性能提升2x-15x。混合负载隔离和稳定性保障多种负载在同一架构下运行，甚至在同一时刻运行，不可避免存在资源竞争、相互影响的问题。AnalyticDB有一套较为完整的的机制和策略来保证集群的稳定性，并且尽可能满足不同业务负载的SLA要求。首先，在混合负载场景或实例内部多租户场景下，可以通过资源组进行有效的业务负载隔离。不同资源组之间的计算资源在物理上完全隔离，避免不同类型或业务的负载之间产生相互影响。不同的业务可以通过绑定账号、提交查询时指定资源组等多种方式指定运行在对应的资源组上。其次，AnalyticDB内部会自动区分写入负载（部分insert和delete）、查询负载（比如select查询）和读写负载（部分insert/update/delete），不同类型的负载任务自动分派到不同的队列上，且分配不同的执行优先级和计算资源。具体来看，写入请求有单独的加速写入链路和资源保证，查询负载默认有较高的执行优先级，而读写负载则默认是较低的执行优先级。另外，在执行过程中，AnalyticDB会根据集群的当前负载情况和查询任务已运行的时长，动态降低运行时间较长的查询任务的执行优先级，以缓解Slow Query或Bad Query对其它查询产生的不利影响。最后，很多业务都有非常明显的呈现周期性的波峰波谷，特别是离线计算任务往往是周期性进行调度和执行的，业务高峰期时资源需求暴增可能导致业务不稳定，业务低峰期时资源闲置又导致额外的成本。AnalyticDB提供分时弹性功能，可以帮助用户在业务高峰期资源不足时扩容资源以保证业务负载稳定执行，在业务低峰期时缩减资源以节约成本。通过合理的业务规划和资源组管理，用户甚至可以让某些资源组在低峰期时释放所有资源，极大地节约成本。3  全新优化器框架近年来，自治（Autonomous）能力已经成为数据库发展的重要方向和趋势。与传统数据库相比，云数据库提供一站式托管服务，也对自治能力提出了更高的要求。为此，AnalyticDB 研发了全新的优化器架构，向更加智能化的自治数据库方向迈进，为用户带来更好的体验。AnalyticDB 优化器进行了大面积的重构升级，主体上拆分成 RBO (Rule-based optimizer) 和 CBO (Cost-based optimizer)。RBO 负责做确定性的优化。比如，将过滤条件尽可能下推，以减少后续算子的运算量。CBO 负责做不确定性的优化。比如，调整 JOIN 运算的顺序。调整的收益是不确定的，所以需要通过代估模块来决策。为了让这两大模块更好的工作，给予用户更好的体验，AnalyticDB 引入了全新的四大特性。特性1：Histogram直方图的引入，可以有效提升代估的质量，让 CBO 选出更好的计划。直方图可以有效解决用户数据值的分布不均问题，有效解决代估中“均匀分布假设”问题。为了验证直方图效果，AnalyticDB还构建了一套代估质量评价系统。在灰度实例中，代估综合错误率降幅可达50%以上。特性2：Autonomous statistics如何管理好表的统计信息，也是一个非常头疼的问题。如果把这个问题抛给用户，让用户执行命令去收集统计信息，会给用户带来巨大的困扰。为此，AnalyticDB引入了统计信息自治框架，来管理这个事情。AnalyticDB会尽可能降低收集动作对用户的影响，带来最好的体验。AnalyticDB会识别出每一列需要收集的统计信息等级，不同等级收集开销不同。同时也会识别出统计信息是否过期，来决定是否要重新收集。特性3：Incremental statistics传统的统计信息收集方式，需要进行全表扫描。全表扫描开销大，对用户影响大，不符合提升用户体验的初衷。为此，AnalyticDB引入了增量统计信息框架，可以只更新单个分区的统计信息，然后通过全局合并技术，得到整个表全局的统计信息。这样可以大幅降低收集的开销，减少对用户的影响。特性4：Property derivation如何让计划变得更优，属性推导对此有着重要的意义。它就像电影中的彩蛋，需要你去发掘。我们通过这个特性可以发掘SQL中隐含的信息，从而进一步优化计划。比如，用户 SQL 写了 “A=B” 条件，之后又做了一次 “GROUP BY A,B”，那么其实是可以简化成 “GROUP BY A” 或 “GROUP BY B”。因为我们通过属性推导，知道了A等价于B。4  智能诊断和优化智能诊断AnalyticDB的智能诊断功能融合逻辑执行计划和物理执行计划，从「Query级别」,「Stage级别」，「算子级别」三个层次诊断分析，帮用户快速定位问题Query、Stage和算子，直接给出直观的问题分析，如数据倾斜、索引不高效、条件没下推等，并给出对应的调优建议。目前已经有20+诊断规则上线，涉及查询相关的内存消耗、耗时、数据倾斜、磁盘IO以及执行计划等多个方面，后续还有更多诊断规则陆续上线。智能优化AnalyticDB的智能优化功能提供针对数据库、表结构的优化功能，为用户提供降低集群使用成本、提高集群使用效率的调优建议。该功能基于SQL查询的性能指标以及使用到的数据表、索引等信息进行算法统计分析，自动给出调优建议，减少用户手动调优的负担。智能优化目前提供三种类型的优化建议：1） 冷热数据优化：分析数据表的使用情况，对长期未使用的数据表，建议将其迁移至冷盘存储，约60%的实例可以通过该建议的提示，将 15 天未使用的数据表移至冷存，节省 3 成以上的热存空间；2）索引优化：分析数据索引的使用情况，对长期未使用的数据索引，建议将其删除，约50%的实例可以通过该建议的提示，将 15 天未使用的索引进行删除，节省 3 成以上的热存空间；3）分区优化：分析数据查询实际需要使用的分布键与数据表定义的分布列之间的差异，对设计不合理的分布键，建议变更该数据表的分布键，以提高数据的查询性能。四  总结和展望经过多年双十一的淬炼，AnalyticDB不仅抗住了一年高过一年的的极端负载和流量，也在不断丰富的业务场景中逐步成长，不断赋能到集团内外各种新老业务和场景中，逐步成长为新一代云原生数据仓库的佼佼者。接下来AnalyticDB将继续以“人人可用的数据服务”为使命，进一步拥抱云原生，构建数据库+大数据一体化架构，建设极致弹性、离在线一体、高性价比、智能自治等企业级能力，进一步赋能用户挖掘数据背后的商业价值。参考文献[1] Apache Arrow. https://arrow.apache.org.[2] O'Neil P , Cheng E , Gawlick D , et al. The log-structured merge-tree (LSM-tree)[J]. Acta Informatica, 1996, 33(4):351-385.[3] Ailamaki A , Dewitt D J , Hill M D , et al. Weaving Relations for Cache Performance. 2001.[4] Kakoulli E , Herodotou H . OctopusFS: A Distributed File System with Tiered Storage Management[C]. ACM, 2017.[5] Herodotou H , Kakoulli E . Automating Distributed Tiered Storage Management in Cluster Computing[J]. Proceedings of the VLDB Endowment, 2019.[6] Boncz P A , Zukowski M , Nes N J . MonetDB/X100: Hyper-Pipelining Query Execution[J]. CIDR, 2005.[7] Zhou J , Ross K A . Buffering database operations for enhanced instruction cache performance. SIGMOD, 2004.[8] S. Manegold, P. A. Boncz, and M. L. Kersten. Optimizing database architecture for the new bottleneck: Memory access. The VLDB Journal, 9(3):231-246, 2000.[9] JVM intrinsic. https://www.baeldung.com/jvm-intrinsics.

编者按：iLogtail 的核心定位就是可观测数据采集的基础设施，广泛应用于线上监控、问题分析/定位、运营分析、安全分析等多种场景。本文整理自龙蜥SIG技术周会直播，主要介绍 iLogtail 的开源背景、功能、优势以及它的发展历程，视频回顾里还为大家演示如何使用 iLogtail 采集各类可观测数据，直播视频回放已上线至龙蜥社区官网：首页-支持-视频，欢迎观看。文/张诚，iLogtail  SIG核心成员、阿里云技术专家iLogtail 是阿里已开源可观测数据采集器，作为阿里内部可观测数据采集的基础设施，iLogtail 承载了阿里巴巴集团、蚂蚁的日志、监控、Trace、事件等多种可观测数据的采集工作。iLogtail 运行在服务器、容器、K8s、嵌入式等多种环境，支持采集数百种可观测数据，目前已经有千万级的安装量，每天采集数 十PB 的可观测数据，广泛应用于线上监控、问题分析/定位、运营分析、安全分析等多种场景。一、iLogtail 与可观测性可观测性并不是一个全新的概念，而是从 IT 系统中的监控、问题排查、稳定性建设、运营分析、BI、安全分析等逐渐演化而来，可观测性相比传统监控，最核心的演进是尽可能多的收集各类可观测数据，来实现目标的白盒化。而 iLogtail 的核心定位就是可观测数据的采集器，能够尽可能多的采集各类可观测性数据，助力可观测平台打造各种上层的应用场景。二、阿里可观测数据采集的挑战对于可观测数据的采集，有很多开源的 Agent，例如 Logstash、Filebeats、Fluentd、Collectd、Telegraf 等。这些 Agent 的功能非常丰富，使用这些 Agent 的组合再进行一定的扩展，基本可以满足内部各类数据的采集需求。但由于一些性能、稳定性、管控能力等关键性的挑战无法满足，最终我们还是选择自研：1、资源消耗。目前阿里内部有数百万的主机（物理机/虚拟机/容器），每天会产生几十 PB 的可观测数据，每 1 M的内存减少、每 1M/s 的性能提升对于我们的资源节省都是巨大的，带来的成本节约可能是数百万甚至上千万。目前众多开源 Agent 的设计更多的是偏重功能而非性能，基于现有开源 Agent 改造基本不可行。例如：开源 Agent 普遍单核处理性能在 2-10M/s 左右，而我们希望有一个能达到 100M/s 的性能在采集目标增加、数据量增加、采集延迟、服务端异常等情况下，开源 Agent 内存都会呈现爆炸式增长，而我们希望即使在各种环境下，内存也能处在较低的水位开源 Agent 的资源消耗没办法控制，只能通过 cgroup 强行限制，最终的效果就是不断 OOM，不断重启，数据一直采集不上来。而我们希望在指定一个 CPU、内存、流量等资源限制后，Agent 能一直在这个限制范围内正常工作2、稳定性。稳定性是永恒的话题，数据采集的稳定性，除了保证数据本身采集的准确性外，还需要保证采集的 Agent 不能影响业务应用，否则带来的影响将是灾难性的。而稳定性建设，除了 Agent 自身的基础稳定性外，还有很多特性目前开源的 Agent 还没有提供：Agent自恢复：Agent遇到Critical的事件后能够自动恢复，并且提供多个维度的自恢复能力，例如进程自身、父子进程、守护进程全局的多维度监控：能够从全局的角度监控各个不同版本、不同采集配置、不同压力、不同地域/网络等属性的Agent的稳定性问题问题隔离：作为Agent，无论怎样出现问题，都需要尽可能的隔离问题，例如一个Agent上有多个采集配置，一个配置出问题，不能影响其他配置；Agent自身出现问题，不能影响机器上的应用进程的稳定性回滚能力：版本更新和发布是再所难免的问题，在出现问题的时候如何快速回滚，而且保证出问题和回滚期间的数据采集还是 at least once甚至是 exactly once3、可管控。可观测数据的应用范围非常的广，几乎所有的业务、运维、BI、安全等部门都会要用，而一台机器上也会产生各种数据，同一台机器产生的数据上也会有多个部门的人要去使用，例如在 2018 年我们统计，平均一台虚拟机上有 100 多个不同类型的数据需要采集，设计 10 多个不同部门的人要去使用这些数据。除了这些之外，还会有其他很多企业级的特性需要支持，例如：配置的远程管理：在大规模场景下，手工登录机器修改配置基本没有可行性，因此需要一套配置的图形化管理、远程存储、自动下发的机制，而且还要能够区分不同的应用、不同的 Region、不同的归属方等信息。同时因为涉及到远程配置的动态加卸载，Agent还需要能够保证配置 Reload 期间数据不丢不重采集配置优先级：当一台机器上有多个采集配置在运行时，如果遇到资源不足的情况，需要区分每个不同的配置优先级，资源优先供给高优先级的配置，同时还要确保低优先级的配置不被“饿死”降级与恢复能力：在阿里，大促、秒杀是家常便饭，在这种波峰期间，可能有很多不重要的应用被降级，同样对应应用的数据也需要降级，降级后，在凌晨波峰过后，还需要有足够的Burst能力快速追齐数据数据采集齐全度：监控、数据分析等场景都要求数据准确度，数据准确的前提是都能及时采集到服务端，但如何在计算前确定每台机器、每个文件的数据都采集到了对应的时间点，需要一套非常复杂的机制去计算基于以上的背景和挑战下，我们从 2013 年开始，不断逐渐优化和改进 iLogtail 来解决性能、稳定性、可管控等问题，并经历了阿里多次双十一、双十二、春晚红包等项目的考验。目前 iLogtail 支持包括 Logs、Traces、Metrics 多种类型数据的统一收集，核心的特点主要如下：支持多种 Logs、Traces、Metrics 数据采集，尤其对容器、Kubernetes 环境支持非常友好数据采集资源消耗极低，单核采集能力 100M/s，相比同类可观测数据采集的 Agent 性能好 5-20 倍高稳定性，在阿里巴巴以及数万阿里云客户生产中使用验证，部署量近千万，每天采集数十 PB 可观测数据支持插件化扩展，可任意扩充数据采集、处理、聚合、发送模块支持配置远程管理，支持以图形化、SDK、K8s Operator 等方式进行配置管理，可轻松管理百万台机器的数据采集支持自监控、流量控制、资源控制、主动告警、采集统计等多种高级管控特性三、iLogtail 发展历程秉承着阿里人简单的特点，iLogtail 的命名也非常简单，我们最开始期望的就是能够有一个统一去 Tail 日志的工具，所以就叫做 Logtail，添加上“i”的原因主要当时使用了 inotify 的技术，能够让日志采集的延迟控制在毫秒级，因此最后叫做 iLogtail。从 2013 年开始研发，iLogtail 整个发展历程概括起来大致可以分为三个阶段，分别是飞天 5K 阶段、阿里集团阶段和云原生阶段。1.飞天 5K 阶段作为中国云计算领域的里程碑，2013 年 8 月 15 日，阿里巴巴集团正式运营服务器规模达到 5000（5K）的“飞天”集群，成为中国第一个独立研发拥有大规模通用计算平台的公司，也是世界上第一个对外提供5K云计算服务能力的公司。飞天 5K 项目从 2009 年开始，从最开始的 30 台逐渐发展到 5000，不断解决系统核心的问题，比如说规模、稳定性、运维、容灾等等。而 iLogtail 在这一阶段诞生，最开始就是要解决 5000 台机器的监控、问题分析、定位的工作（如今的词语叫做“可观测性”）。从 30 到 5000 的跃升中，对于可观测问题有着诸多的挑战，包括单机瓶颈、问题复杂度、排查便捷性、管理复杂度等。在 5K 阶段，iLogtail 本质上解决的是从单机、小规模集群到大规模的运维监控挑战，这一阶段 iLogtail 主要的特点有：功能：实时日志、监控采集，日志抓取延迟毫秒级性能：单核处理能力 10M/s，5000 台集群平均资源占用 0.5%CPU 核可靠性：自动监听新文件、新文件夹，支持文件轮转，处理网络中断管理：远程 Web 管理，配置文件自动下发运维：加入集团 yum 源，运行状态监控，异常自动上报规模：3W+ 部署规模，上千采集配置项，日 10TB 数据2. 阿里集团阶段iLogtail 在阿里云飞天 5K 项目中的应用解决了日志、监控统一收集的问题，而当时阿里巴巴集团、蚂蚁等还缺少一套统一、可靠的日志采集系统，因此我们开始推动 iLogtail 作为集团、蚂蚁的日志采集基础设施。从 5K 这种相对独立的项目到全集团应用，不是简单复制的问题，而我们要面对的是更多的部署量、更高的要求以及更多的部门：百万规模运维问题：此时整个阿里、蚂蚁的物理机、虚拟机超过百万台，我们希望只用 1/3 的人力就可以运维管理百万规模的 Logtail。更高的稳定性：iLogtail 最开始采集的数据主要用于问题排查，集团广泛的应用场景对于日志可靠性要求越来越高，例如计费计量数据、交易数据，而且还需要满足双十一、双十二等超大数据流量的压力考验。多部门、团队：从服务 5K 团队到近千个团队，会有不同的团队使用不同的iLogtail，而一个 iLogtail 也会被多个不同的团队使用，在租户隔离上对 iLogtail 是一个新的挑战。经过几年时间和阿里集团、蚂蚁同学的合作打磨，iLogtail 在多租户、稳定性等方面取得了非常大的进步，这一阶段 iLogtail 主要的特点有：功能：支持更多的日志格式，例如正则、分隔符、JSON 等，支持多种日志编码方式，支持数据过滤、脱敏等高级处理性能：极简模式下提升到单核 100M/s，正则、分隔符、JSON 等方式 20M/s+可靠性：采集可靠性支持 Polling、轮转队列顺序保证、日志清理保护、CheckPoint 增强；进程可靠性增加 Critical 自恢复、Crash 自动上报、多级守护日志保序采集方案原理（细节可参考《iLogtail 技术分享(一) : Polling + Inotify 组合下的日志保序采集方案》）多租户：支持全流程多租户隔离、多级高低水位队列、采集优先级、配置级/进程级流量控制、临时降级机制多租户隔离整体流程（细节可参考《iLogtail 技术分享(二)：多租户隔离技术+双十一实战效果》）运维：基于集团 StarAgent 自动安装与守护，异常主动通知，提供多种问题自查工具规模：百万+部署规模，千级别内部租户，10 万+采集配置，日采集 PB 级数据3. 云原生阶段随着阿里所有 IT 基础设施全面云化，以及 iLogtail 所属产品 SLS（日志服务）正式在阿里云上商业化，iLogtail 开始全面拥抱云原生。从阿里内部商业化并对外部各行各业的公司提供服务，对于 iLogtail 的挑战的重心已经不是性能和可靠性，而是如何适应云原生（容器化、K8s，适应云上环境）、如何兼容开源协议、如何去处理碎片化需求。这一阶段是iLogtail发展最快的时期，经历了非常多重要的变革：统一版本：iLogtail 最开始的版本还是基于 GCC4.1.2 编译，代码还依赖飞天基座，为了能适用更多的环境，iLogtail 进行了全版本的重构，基于一套代码实现Windows/Linux、X86/Arm、服务器/嵌入式等多种环境的编译发版全面支持容器化、K8s：除了支持容器、K8s 环境的日志、监控采集外，对于配置管理也进行了升级，支持通过 Operator 的方式进行扩展，只需要配置一个AliyunLogConfig的K8s自定义资源就可以实现日志、监控的采集iLogtail Kubernetes日志采集原理（细节可参考《Kubernetes日志采集原理剖析》）插件化扩展：iLogtail 增加插件系统，可自由扩展 Input、Processor、Aggregator、Flusher 插件用以实现各类自定义的功能iLogtail 插件系统整体流程（细节可参考《iLogtail 插件系统简介》）规模：千万部署规模，数万内外部客户，百万+采集配置项，日采集数十PB数据四、开源背景与期待闭源自建的软件永远无法紧跟时代潮流，尤其在当今云原生的时代，我们坚信开源才是 iLogtail 最优的发展策略，也是释放其最大价值的方法。iLogtail 作为可观测领域最基础的软件，我们将之开源，也希望能够和开源社区一起共建，持续优化，争取成为世界一流的可观测数据采集器。对于未来 iLogail 的发展，我们期待：iLogtail 在性能和资源占用上相比其他开源采集软件具备一定优势，相比开源软件，在千万部署规模、日数十 PB 数据的规模性下为我们减少了 100TB 的内存和每年 1 亿的 CPU 核小时数。我们也希望这款采集软件可以为更多的企业带来资源效率的提升，实现可观测数据采集的“共同富裕”。目前 iLogtail 还只是在阿里内部以及很小一部分云上企业（虽然有几万家，但是面对全球千万的企业，这个数字还很小），面对的场景相对还较少，我们希望有更多不同行业、不同特色的公司可以使用 iLogtail 并对其提出更多的数据源、处理、输出目标的需求，丰富 iLogtail 支持的上下游生态。性能、稳定性是 iLogtail 的最基本追求，我们也希望能够通过开源社区，吸引更多优秀的开发者（钉钉扫面下方二维码或搜索钉钉群号：35576244 入群交流），一起共建 iLogtail，持续提升这款可观测数据采集器的性能和稳定性。敲重点！本次直播视频回放已上线至龙蜥社区官网（首页-支持-视频），直播 PPT 获取方式：关注龙蜥社区公众号，后台回复【龙蜥课件】或【龙蜥视频回放】即可。链接汇总：1）阿里正式开源可观测数据采集器 iLogtail：https://github.com/alibaba/ilogtail2）《iLogtail技术分享(一) : Polling + Inotify 组合下的日志保序采集方案》：https://zhuanlan.zhihu.com/p/293036003）《iLogtail技术分享(二)：多租户隔离技术+双十一实战效果》：https://www.sohu.com/a/205324880_4659594）《Kubernetes日志采集原理剖析》：https://developer.aliyun.com/article/8063695）《iLogtail插件系统简介》：https://github.com/alibaba/ilogtail/blob/main/docs/zh/concept%26designs/Overview.md6）《龙蜥社区 SIG 地址链接》：https://openanolis.cn/sig/ilogtail—— 完 ——加入龙蜥社群加入微信群：添加社区助理-龙蜥社区小龙（微信：openanolis_assis），备注【龙蜥】与你同在；加入钉钉群：扫描下方钉钉群二维码。欢迎开发者/用户加入龙蜥社区（OpenAnolis）交流，共同推进龙蜥社区的发展，一起打造一个活跃的、健康的开源操作系统生态！关于龙蜥社区龙蜥社区（OpenAnolis）是由企事业单位、高等院校、科研单位、非营利性组织、个人等在自愿、平等、开源、协作的基础上组成的非盈利性开源社区。龙蜥社区成立于 2020 年 9 月，旨在构建一个开源、中立、开放的Linux 上游发行版社区及创新平台。龙蜥社区成立的短期目标是开发龙蜥操作系统(Anolis OS)作为 CentOS 停服后的应对方案，构建一个兼容国际 Linux 主流厂商的社区发行版。中长期目标是探索打造一个面向未来的操作系统，建立统一的开源操作系统生态，孵化创新开源项目，繁荣开源生态。目前，龙蜥OS 8.4已发布，支持 X86_64 、Arm64、LoongArch 架构，完善适配飞腾、海光、兆芯、鲲鹏、龙芯等芯片，并提供全栈国密支持。欢迎下载：https://openanolis.cn/download加入我们，一起打造面向未来的开源操作系统！https://openanolis.cn

更多前沿分享，点击云栖大会视频回放链接即可获取。本篇内容将通过三个部分来介绍基于云原生数据仓库AnalyticDB MySQL的最佳实践。一、零售行业的发展趋势二、AnalyticDB的核心能力三、AnalyticDB在零售中的应用 一、零售行业的发展趋势从最早的商超、百货以及到现在的电商、新零售，都是围绕三个核心要素来开展的：人、货、场。传统的零售大都是从场开始的：先有零售场所的创建，然后再等用户前来消费；消费行为始于零售场所，也终止于零售场所。但是随着数字化和信息化的应用，人、货、场之间的关系正在被数据所重构发生了深刻的变化：零售重新回归到“以人为本”的理念上——用户的需求在哪里，零售就发生的哪里，如办公室的无人货柜、共享充电宝等等；同时逐渐形成了以“人为核心”的立体网络——交易行为突破了时空的限制，变得随时随地都可以发生，而且消费行为的生命周期也会更长。零售行业的数字化体现在三个地方：第一，“人”的数字化。不管是线下万达商铺还是线上的淘宝商城，它本质都在于吸引用户流量——吸引用户进店，之后分析用户流量，最后消费用户流量，所以人的数字化其实就在于用户流量的分析和消费。商家可以通过不同的途径去获取到用户数据，比如自有电商平台的数据、微博粉丝数据或者微信公众号朋友圈等等。在完成数据收集之后，商家会借助不同的数据挖掘算法，从各种维度对用户画像进行分析，提取用户行为标签进行分类，最后针对不同的客户群体制定不同的营销方案。如何实现人群的精准分析将会给零售产生非常重要的影响，如客流将决定着店铺的位置选择。第二，“货”的数字化。货的数字化主要围绕整个供应链的优化开展的，包括多渠道铺货/下单、订单管理以及履约交付等各环节的数字化。全域打通与管理就会给零售行业带了一些挑战：包括线上/线下多个渠道之间采用怎样的铺货策略/销售策略、库存如何统一管理、如何实现快速交付、如何提升回购等等。比如每年双11从发货到交付到消费者手上的速度是越来越快，这背后正是货的数字化发挥着神奇的力量：双11前，淘宝/天猫/京东等电商平台，会分析用户最近一段时间的消费行为，并进行提前预判——分析哪些商品复购率比较高、哪些商品的购买具有地域属性等等，然后就会提前将这些商品放置到离消费者更近的前置仓；消费者下单后，直接从前置仓进行发货。同时，物流行业里面，通用的电子面单系统，也是将物流的各个环节进行了数字化，这也极大提升了货物的流通速度。第三，“场”的数字化。主要比较线上和线下不同渠道之间各自的优势/劣势，然后利用彼此的优势完成信息流和资金流的重构。线下门店可以充分体验产品，但整体成本缺比线上店铺高很多。于是很多企业就将线下门店和线上电商店铺结合起来一起做，比如小米之家&小米商城、TATA木门的线下体验店&天猫旗舰店等，都极大提升了坪效。 零售行业的数字化，实现了全渠道商品/订单的统一管理、也积累了大量用户数据、使得营销效果更加直观，但是也导致了数据量的极速增长。如何在海量数据中实现用户数据的实时/精准分析、商品报表以及营销效果的及时快速展现，也是零售商家所面临的问题和挑战。二、AnalyticDB的核心能力上述是原生数据仓库AnalyticDB在整个数据链路的架构图。自下而上，数据如结构化/非结构化数据、日志数据、对象存储上的文件数据，都可以通过不同的工具，实时或者离线汇聚到AnalyticDB中；然后利用AnalyticDB复杂查询的性能优势完成数据统计分析；最后借助开源或商业化的BI展示工具，或者业务程序，进行图形化或者交互式展现。当然，也可以借助数据开发/调度工具，如DMS、DataWorks实现数据的ETL批处理，实现在/离线一体化数仓。AnalyticDB的核心能力主要体现在三块：查询性能快，可以实现实时化分析以及简单易用。AnalyticDB运用新一代超大规模的MPP+DAG融合引擎，采用行列混存、智能索引等技术，极大了提升查询性能。复杂SQL查询速度相比传统的关系型数据库快10倍以上，较传统数仓产品也有几倍的提升。借助DTS实时同步工具，可以讲业务库的变更及时地被传输到ADB里面，从数据变更到分析再到展现，整个链路延迟在秒级。高度兼容MySQL和PG协议，通过标准SQL和常用BI工具、以及ETL工具平台即可轻松使用，极大降低了数仓的构建成本以及维护成本。AnalyticDB作为一款新型的OLAP产品，通常有两个常见的应用场景：交互式BI分析。如天猫双11大屏，涵盖总的交易额、类目的TOP、地域等相关统计。优势：查询性能高，可以达到万亿级数据分析亳秒级响应，查询速度约为MySQL100倍。l  日志分析。如游戏运营分析和IT运维日志分析等。优势：实现结构化和非结构化数据的融合分析，同时冷热分离使得存储成本极大降低。三、AnalyticDB在零售中的应用AnalyticDB是如何帮助零售行业客户提升业务价值的呢？我们来看几个客户案例。第一个案例来自于客户云。客如云是给餐饮、零售、美业等本地生活服务业商家提供SAAS方案的服务商。客户主要有三个诉求：报表实时展现。传统数据仓库一般只能做到T+1展现，可能会导致商家隔天才能查看运营情况，进而导致补货、资源调配存在延迟影响正常销售。画像分析增值服务。客如云的商家希望其提供更加精准的画像分析服务，这样可以为不同的目标群体提供更贴心的餐饮服务，例如情侣套餐、经济套餐、满减打折券等。稳定性和扩展性。比如情人节、七夕、圣诞节等节假日用餐高峰，需要保证系统的顺畅。这个是架构升级之后的架构图。PolarDB MySQL替代了传统MySQL，承担业务流量，具备极致弹性能力。DTS将业务库中的数据变更实时地同步到AnalyticDB里面，实现业务库跟分析库的解藕及实时同步。AnalyticDB帮助客户实现了实时报表分析、复杂交互式查询和用户画像分析等功能。 通过这个架构升级，AnalyticDB帮助客如云拓展了商业边界，找到了新的营收增长点：推出商户报表VIP套餐，报表更新从天降低到小时级别；同时也开发了用户画像精准营销服务，两项新功能给客如云每年新增几亿的营收。同时七夕、国庆、圣诞节等节假日用餐高峰，系统运行非常的流畅，没有任何卡顿。第二个案例来自于北京蜂创科技。北京蜂创科技中国企业级营销一体化管理 SaaS 平台。旗下拥有营销活动管理平台、CRM用户关系管理平台、社区运营系统、精准营销投放平台等多个产品平台。主要面临几个问题：查询性能差。表数据量大，单表数据量过亿甚至数十亿，并且多表关联/多维交互查询场景较多。而且广告主对于营销展现时效性要求非常高。传统数仓架构复杂。涉及的组件多、数据链路长、人员学习成本运维成本大。扩展性。可以承载未来3-5年数据的增长，不需要做架构再次升级。结合业务场景，采用了PolarDB-X+DTS+AnalyticDB的解决方案：分布式PolarDB-X做分库分表承担业务高并发；数据通过DTS实时传输到AnalyticDB；同时AnalyticDB也可以直接读取OSS上数据进行联合查询。这样就构建了一个数据汇聚、数据清洗、ETL计算和实时查询服务的数据分析平台。架构完成之后，AnalyticDB的引入使得多维分析查询性能都在秒级返回，营销效果展示更加及时。同时，AnalyticDB的快速弹性以及数据冷热分离，使得整体成本更可控。第三个案例来自于上海分尚网络，国内鲜花电商领导品牌，创造了“线上订阅+产地直送+增值服务”的日常鲜花订阅模式。主要面临的问题是：业务库和分析库都使用传统MySQL，分析场景如订单、商品流量、采购、业务转化率、商品售罄报警等查询速度较慢甚至查询不出来的情况；业务发展很快，数据量增长迅猛；技术团队对MySQL生态比较熟悉，传统数仓组件多学习成本高；另外就是考虑未来数据进一步增长的情况下，系统的扩展性。后来OLAP分析放置到了AnalyticDB上：利用AnalyticDB优异的查询性能，报表和BI分析速度有2-10倍的提升，整体业务响应度和顾客服务体验也得到很大提升。同时，利用ADB的数据冷热分离以及资源组弹性功能，更高的扩展性和灵活性，IT支出成本降低30%以上。 还有更多的零售行业的客户，如飞鹤、居然之家、生意参谋等等，也都在使用AnalyticDB承载复杂的报表统计以及交互式分析场景，通过数字化转型挖掘更多的商业价值。

开发者学堂课程【Serverless 在各行业的实践：世纪联华的 Serverless 之路】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/848/detail/14021世纪联华的 Serverless 之路内容简介一、世纪联华超市简介二、技术架构演进三、架构演进总结四、函数计算简介 一、世纪联华超市简介业务技术结构:世纪联华主要技术业务1.充值支付实体卡注册>实体卡充值>实体卡解锁>实体卡支付扣费>注销2. 会员管理线上注册>信息查询>积分优惠>定时通知3.营销系统广告投放>秒杀活动>公众号推广>优惠券发放>用户行为分析4.交易流水高品价格查询>数据库读写>优惠全额计算5.商品管理补货>进货>价格调整>商品动态 二、技术架构演进世纪联华技术架构演进方案2002 公司成立，物理单机架构2014 迁移中央机房，发生双十二事件2018 开始部署全面上云2019 年 6 月 数据库事件，开始探索新的架构方式2019 年 11 月 Serverless 的尝试，在双十表现优异2020 年 11 月 All in Serverless 开发效率提高，成本大幅节省物理单机架构：2014 及其以前单机架构优劣势比较优势>架构简洁>不受外界网络环境影响>POS 机分散后单机冲击相对小劣势>单点故障容灾困难>数据迁移查询汇总困难>升级困难>数据分发靠定期同步>新业务部署在单机上冲击巨大>故障时很难第一时间维护修复物理单机架构的灾难2014 年双十二支付系统故障中央机房部署架构的演进2014-2018 年：新的架构与设计改进>问题可集中维护处理>商品价格调整下发全部走网络>数据可集中查询统计汇总不足>需要提前采购大量硬件备灾>管理员需要掌控机器细节>宕机断网事件调查困难，应急方案薄弱>软件、系统批量部署成本高>资源预算困难>硬件升级成本高全面上云改进>不再需要关心网络、操作系统、硬件细节>硬件升级快捷简单>机器扩容时间大为缩短不足：>资源预算困难>水平扩展>水位监控>财务预算困难>数据库单点故障>升级成本高全面上云年中大促，数据库被打爆线上业务用户访问不可控会员查询数据访问量过大MySQL 单机访问被打爆影响到多个系统三、架构演进总结Serverless 的探索和尝试多次架构演进后的思考1.研发>资源粒度>横向扩容>链路追踪2.运维>Failover>资源扩容>流量观测>异常报警>API 灰度>资源扩容>平滑升级>安全管控>异常流控3.成本>采购预算>大促预留>备灾预留Serverless 的探索和尝试线上不可控业务上的预防1.API 网关·针对不同渠道商做API管控发布·流量控制·客户端流量管控2.函数计算·会员查询·定时抢购、优惠券投放并发 burst 冲击巨大·数据观测·异常报警3.表格存储·数据高并发读取·低峰期成本控制SeServerless 的探索和尝试Serverless 带来的新曙光快速迭代部署>开发效率>运维效率>架构解耦高并发、高弹性>免人工扩容>定点投放稳定、可靠、安全>抢购体验>抢购体验数据、运营、成本控制>运维观测>报警监控>人效、资源成本优化 四、函数计算 2.0 及 Al in Serverless预留模式的使用免运维资源管理革命从人工运维>到云平台工具运维>到 Serverless 免运维高弹性资源利用率革命从预算采购低利用率>到有限弹性高利用率>到 Serverless 100%资源利用率低成本资源成本革命从固定成本支出>到根据资源策略伸缩>到 Serverless 根据业务策路适配世纪联华快速上云，将"线上核心业务"，改造为全 Serverless 架构的中台模式，采用"函数计算 +API 网关＋OTS"作为计算网络存储核心.弹性支撑日常和大促峰谷所需资源，轻松支撑618/双11/双12大 促。核心价值1.全 Serverless 架构∶ FC+API 网关＋OTS Serverless 解决方案2.弹性高可用∶毫秒级弹性扩容、充足的资源池水位、跨可用区高可用3.敏捷开发免运维∶函数式极简编程可专注于业务创新，无采购和部署成本、提供监控报警等完备的可观测能力设计架构演进总结从物理单机到 All in Serverless 的架构演进1.物理单机·架构简单·高度耦合·数据同步难·升级困难·无法横向扩容2.自建机房·统一维护升级·数据同步统一·系统部署困难·硬件成本高·非业务调查难·临时扩容难3.全面上云·硬件升级简单·扩容能力提升·备灾能力提升·设计要求高·监控告警原始·数据库单点·流控问题4.Serverless 尝试·数据库单点问题·流控问题解决·横向扩容·监测告警·费用免预算·部分延迟较大5.All in Serverless· 解耦· 冷启动体验提升·研发效率提升·成本费用下降阿里云函数计算产品全景函数计算是国内生态最完整、功能最丰富的 Serverless 产品，开发者一步上云、一键 Serverless 化将成为现实业界发展趋势谁在使用函数计算

开发者学堂课程【玩转云上智能运维：云上高弹性，低成本的解决方案】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/118/detail/1970云上高弹性，低成本的解决方案内容介绍：一、ECS 计算产品家族谱二、ECS 付费选择三、低成本的最佳实践四、ECS 资源弹性交付方式五、云上弹性面临的挑战六、弹性伸缩概括七、弹性伸缩的核心概念八、多种伸缩模式九、多种伸缩模式灵活组合十、事件驱动十一、弹性供应（Auto provisioning)十二、弹性供应的基本组件十三、弹性供应的产品优势十四、产品链接 l ECS计算产品家族谱l ECS 付费选择付费方式的灵活使用是获得业务敏捷性的基础，也是降低 IT 成本的最核心手段，阿里云 ECS 提供极多样的资源付费方式：l 低成本的最佳实践抢占式实例：支撑无状态且可容错的业务负载按量实例：支撑有状态且动态变化的业务负载包年包月、预留实例：支撑稳定的业务负载（多种付费类型组合最低成本完成业务支撑） l ECS 资源弹性交付方式Ø CreateInstance ECS OpenApi：最早期提供的接口能力：单实例的交付方式；附加后续流程实例最终运行起来Ø RunInstances ECS OpenApi：批量实例交付方式（100+)；一次调用满足交付；单可用区+单实例规格Ø 弹性伸缩 Auto Scaling：自动化的交付工具；批量实例交付方式(2000/50000)；一次配置重复使用；定时+监控触发+主动触发+预测；多实例规格+多可用区；成本优化Ø 弹性供应 ECS Auto Provisioning.：ECS原生大规划交付；交付资源->交付计算力；批量实例交付方式(2000/50000)；一次配置重复使用；按量+Spot+RI；多实例规格+多可用区 l 云上弹性面临的挑战1) 用户增长，对系统容量需求增加（比如创业公司app爆红后频繁无法访问）2) 有高峰和低谷，日常定时扩容缩容（比如在线视频网站晚上8-12点会迎来高峰期3) 热点活动爆发，紧急扩容（比如艺人爆出八卦引发社交用户热议）4) 年度大促，临时扩容（比如电商会在双11进行大促销）5) 业务低谷期也保有全量资源，闲置成本高（比如所有资源都包年包月购买 l 弹性伸缩概括Ø 伸缩组最大实例：2000-50000Ø 组合方式：多可用区（5)+多实例规格（10)Ø 3种策略：优先级|均衡|成本优化Ø 5种伸缩模式：定时|动态（简单+目标追踪+预测）人工|固定|健康检查Ø 通过云监控实现弹性：17 种metrics(ongoing:ARMS、SLS)Ø 事件通知能力：事中+事后（Hook+Notification)l 弹性伸缩的核心概念1) 伸缩组：伸缩组实例数设置；多可用区；优先级和均衡分布；SLB 和 RDS，附加+分离操作；健康检查2) 伸缩配置：实例规格，镜像预设密码；支持 Tag,支持 RamRole 和 Userdata；支持修改配置功能，无需重建3) 伸缩规则和通知：调整至|增加|减少；伸缩活动成功、失败、拒绝实时通知；对接云监控系统事件&MNS 主题/队列4) 伸缩任务：定时任务，支持1年+临期提醒；报警任务；自动或手动触发 l 多种伸缩模式不同伸缩规则对应了不同的伸缩模式，伸缩组支持多种模式组合使用1. 健康模式：² 释放或移出不健康的 ECS 实例（非保护状态或备用状态的 ECS 实例）² 伸缩组对所有模式默认提供2. 固定模式：² 通过指定 MinSize 来保证固定数量的 ECS 实例² 适合业务波动不大但有高可用要求的场景，一般与监控模式一起使用3. 手工模式：² 根据人工观察监控数据或者用户自有的监控系统，通过API手工伸缩ECS实例² 手工执行伸缩规则² 手工添加/移出既有的 ECS 实例² 手工调整 MinSize/MaxSize 后自动创建或释放 ECS 实例，将实例数量维持在Min~Max 之间4. 定时模式：² 根据配置定时（如周五13:00:00)地增加或减少 ECS 实例² 适合业务波动具有一定规律的场景5. 动态模式：² 基于监控指标（如 CPU 利用率）的负载情况，根据配置自动创建或释放ECS实例² 适合业务波动没有明显规律的场景 l 多种伸缩模式灵活组合Ø 定时模式:根据配置定时（如周五13:00:00)地增加或减少 ECS 实例Ø 动态模式:基于云监控指标（比如 CPU 使用率）负载情况，根据配置自动伸缩Ø 手动+动态模式:手动添加包年包月实例（不会被移出伸缩组）确保业务基座Ø 定时+动态模式:在定时配置进行扩缩容的基础上，根据监控指标动态进一步调整ECS 实例数Ø 动态模式-预测模式：根据用户伸缩组最近1-14天的CPU使用情况和实例个数数据进行建模然后通过机器学习预测算法预测未来2天整体的使用情况，并自动进行扩缩容操作l 事件驱动OpenApi（开放接口）+Notification（事件通知）+Hook（生命周期挂钩）l 弹性供应（Auto provisioning)·一种全新算力交付方式，一键开启跨售卖方式、跨规格族、跨可用区的计算集群交付，一次配置自动托管·通过动态规划算法，根据用户设定的购买量和策略，自动帮用户选择最合适的资源，并持续维持目标算力 l 弹性供应的基本组件①　目标容量：指算力的总数量，单位可以是 VCPU 个数，也可以是实例个数②　实例权重：指每个实例规格对目标容量的贡献度，权重越大，单台实例满足计算力需求的能力越大，所需的实例数量越小。权重根据指定实例规格的计算力与集群单节点最低计算力得出，假设单节点最低算力为 8 VCPU/60GB, 则 8 VCPU/60GB的实例权重为1,16VCPU/120GB 实例规格权重为 2,也可以将每个实例规格的权重与其 VCPU 数量保持一致③　实例优先级：指交付算力时选择每种实例规格的先后顺序，优先创建优先级高的实例；与按量实例的优先级策略配合使用，0 表示优先级最高，随着数字增大而降低④　InstancePoolToUseCount :指在成本优化策略时，希望选择最便宜的实例规格数量 l 弹性供应的产品优势①　超低成本：低至1折；按秒计费，可全部使用 spot 实例交付，最高可省 90% 成 本；支持设置全局和单个实例规格价格上限②　灵活丰富：多种策略组合，可分别指定 spot 和按量实例的交付策略，以及差额补足的策略，包括成本最低、打散和折中③　超高效率：快速交付，单个供应组支持 20 种实例规格+多可用区部署，可分钟级快速交付 2000 实例④　稳定可靠：智能打散，多个资源池之间进行打散，降低 spot 被集体释放的风险；自动托管，分钟级巡检，动态保证集群的算力. l 产品链接Ø 弹性伸缩产品介绍：https://www.aliyun.com/product/ecs/ess产品文档：https://help.aliyun.com/document detail/25857.html产品控制台：https://essnew.console.aliyun.com/Ø 弹性供应产品文档：https://help.aliyun.com/document detail/120020.html产品控制台:https://ecs.console.aliyun.com/#/fleet/region/

1. 问题的来源最近发现很多人被类似秒杀这样的设计困扰，其实这类问题可以很方便地解决，先来说说这类问题的关键点是什么：一定要高性能，不然还能叫秒杀吗？要强一致性，库存只有100个，不能卖出去101个吧？但是库存10000实际只卖了9999是否允许呢？既然这里说了是秒杀，那往往还会针对每个用户有购买数量的限制。总结一下，还是那几个词：高性能强一致性！下文的所有解决方案是在 Mysql InnoDB 下做的。因为用到了很多数据库特性。其他的数据库或其他的数据库引擎会有不同的表现，请注意。2.完全不考虑一致性的方案2.1 表结构2.2 方案表结构很简单，其实就是一个user和deal的关联表。谁买了多少就插入数据呗。首先，还要检查一下传过来的buy_count是否超过单人购买限制。接下来，每次插入前执行以下以下操作检查一下是否超卖即可：select sum(buy_count) from UserDeal where deal_id = ?最后还要检查一下这个用户是否购买过：select count(*) from UserDeal where user_id = ? and deal_id = ?全都没问题了就插入数据：insert into UserDeal (user_id, deal_id, buy_count) values (?, ?, ?)2.3存在的问题大家别笑，这样的设计你一定做过，刚毕业的时候谁没设计过这样的系统啊？而且大部分系统对性能和一致性的要求并没有那么高，所以以上的设计方案还真是普遍存在的。那就说说在什么情况下会出问题吧：如果库存只剩一个，两个用户同时点购买，两个人检查全部成功，最后，就超卖了。如果一个用户同时发起两次请求，检测部分同样可能会同时通过，最后，数据就异常了。那就让我们一步步来解决里面存在的问题吧。3.保证单用户不会重复购买先来解决最简单的问题，保证单用户不会重复购买。其实只要利用数据库特性即可，让我们来加一个索引：alter table UserDeal add unique user_id_deal_id(user_id, deal_id)加上唯一索引后，不仅查询性能提高了，插入的时候如果重复还会自动报错。当然别忘了在业务代码中 catch 一下这个异常，并在页面上给用户友好的提醒。4. 解决超卖问题4.1 方案为了解决这个问题，第一个想到的就是把这几次操作在事务中操作。否则无论怎么改，也都不是原子性的了。但是加完事务后就完了？上面的select语句没有使用for update关键字，所以就算加入了事务也不会影响其他人读写。所以我们只要改一下select语句即可：select sum(buy_count) from UserDeal where deal_id = ? for update4.2 优化刚改完后发现，问题解决了！so easy！步步高点读机，哪里不会点哪里，so easy！但是不对啊！为什么两个用户操作不同的deal也会相互影响呢？原来我们的select语句中的查询条件是where deal_id = ?，你以为只会锁所有满足条件的数据对吧？但实际上，如果你查询的条件不在索引中，那么 InnoDB 会启用表锁！那就加一个索引呗：alter table UserDeal add index ix_deal_id(deal_id)05. 提高性能了好了，到目前为止，无论用户怎没点，无论多少个人买同一单，都不会出现一致性的问题的。而且事务都是行锁，如果你的业务场景不是秒杀，操作是分散在各个单子上的。而且你的压力不大，那么优化到这就够了。但是，如果你真的会有几万人、几十万人同时秒杀一个单子怎么办？很多交易类网站都会有这样的活动。我们现在思考一下，上面的优化好像已经是极致了，不仅满足了一致性，而且性能方面也做了足够的考量，无从下手啊！这时候，只能牺牲一些东西了。06. 鱼与熊掌不可兼得6.1 优化的思路性能和一致性常常同时出现，却又相互排斥。刚才我们为了解决一致性问题带入了性能问题。现在我们又要为了性能而牺牲一致性了。这里想提高性能的话，就要去掉事务了。那么一旦去掉事务，一致性就没办法保证了，但有些一致性的问题并不是那么地严重。所以，这里最关键的就是要想清楚，你的业务场景对什么不能容忍，对什么可以容忍。不同业务场景最后的方案一定是不同的。6.2 秒杀可以容忍什么本文标题说的是秒杀，因为这个业务场景很常见，那么我们就来说说秒杀。秒杀最怕的是超卖，但却可以接受少卖。什么是少卖？我有一万份，卖了9999份，但数据库里却说已经买完了。这个严重吗？只要我们能把这个错误的量控制在一定比例以内并且可以后续修复，那这在秒杀中就不是一个问题了。7. 为了性能牺牲一致性的设计方案7.1 去掉了事务会发生什么在上述的方案中，如果去掉了事务，单用户重复购买是不会有问题的，因为这个是通过唯一索引来实现的。所以这边我们主要是去解决超卖问题。既然去掉了事务，那么for update锁行就无效了，我们可以另辟蹊径，来解决这个问题。7.2 修改表结构刚才一直没有提Deal表，其实它就是存了一下基本信息，包括最大售卖量。之前我们是通过对关联表进行sum(buy_count)操作来得到已经卖掉的数量的，然后进行判断后再进行插入数据。现在没了事务，这样的操作就不是原子性的了。所以让我们来修改一下Deal表，把已经售卖的量也存放在Deal表中，然后巧妙地把操作转换成一行update语句。7.3 修改执行过程如果你继续先把数据查出来到内存中然后再操作，那就不是原子性的了，必定会出问题。这时候，神奇的update语句来了：update Deal set buy_count = buy_count + 1 where id = ? and buy_count + 1 <= buy_max如果一单的buy_max是1000，如果有2000个用户同时操作会发生什么？虽然没有事务，但是update语句天然会有行锁，前1000个用户都会执行成功，返回生效行数1。而剩下的1000人不会报错，但是生效行数为0。所以程序中只要判断update语句的生效行数就知道是否抢购成功了。7.4 还没有结束问题解决了？好像也没牺牲一致性啊，用户根本不会超卖啊？但是，购买的时候有两个关键信息，“剩余多少”和“谁买了”，刚才的执行过程只处理了第一个信息，它根本没存“谁买了”这个信息。而这两个信息其实也是原子性的，但是为了性能，我们不得不牺牲一下了。刚才说到如果update的生效行数是1，就代表购买成功。所以，如果一个用户购买成功了，那么就再去UserDeal表中插入一下数据。可如果一个用户重复购买了，那么这里也会出错，所以如果这里出错的话还需要去操作一下Deal表把刚才购买的还回去：update Deal set buy_count = buy_count - 1 where id = ? and buy_count - 1 >= 0这边理论上不会出现buy_count - 1 < 0的情况，除非你实现的不对。…… 无图无真相，完全混乱了只看文字不清晰，还是来张完整的流程图吧！毫无破绽啊！不是说要牺牲一致性吗？为什么没看到？因为上面的流程图还没有考虑数据库故障或者网络故障，最后还是来一张最完整的流程图吧：仔细看一下整张流程图，最终就这几种情况：执行成功无库存回滚成功损失库存前三种是正常的，只有“损失库存”是有问题的。其实，“损失库存”这种情况其实很难出现，只有在网络故障或者数据库的情况下才可能偶尔。那你的业务可以容忍它吗？最终还是具体问题具体分析了。8. 不要过度优化最后还是提醒一句，千万不要过度优化，第一个使用事务的方案其实已经够好了！除非你的业务特殊，全中国几十万人几百万人会同时来买，那才有必要牺牲一下一致性提升性能。对了，如果是像双十一或者小米这样子的抢购，上面的方案也是不够的…

前言今年双十一刚刚落幕开售第一小时，天猫上有超过2600个品牌成交额超去年首日全天，78个去年双11成交额千万级的品牌，今年突破了1亿元大关。在大促狂欢的氛围背后，对于品牌商家而言，双十一的价值已不仅仅是数据大屏上的一串数字，在达成生意目标的同时，商家也在通过数据，持续追踪构建品牌的长期可持续发展能力。将数据更好的融入日常工作中，一个重要的前提条件就是多端多渠道的数据触达和办公协同能力。Quick BI凭借移动端交互体验，帮助用户随时随地便捷查看报表，并通过在线协同方式，追踪策略的执行落地。让数据在企业中流动起来，真正将数据贯穿在业务决策的过程中。【点击查看1分钟功能介绍小视频】Quick BI移动端整体解决方案为了让用户随时随地消费数据，利用数据做决策，Quick BI移动端提供了一套完整的解决方案。数据在企业内的流通本质是一个闭环的过程，从数据内容触达数据消费者到数据消费者基于数据内容进行分析决策，再到决策后进行协同落地，最后又会形成新的数据内容。Quick BI移动端在企业数据流通的不同环节，有针对性地进行了产品能力建设，让数据价值流动起来。数据内容触达数据内容触达数据消费者从动机来看可以分为主动和被动两种：· 数据消费者可以主动从Quick BI的微应用中通过导航/门户/搜索等能力去找到自己想要查看的内容· 也可以通过邮件、监控告警、推送的报表信息等方式被动接收数据内容1. 订阅推送新的一天，从数据早报开始。每天早上，可以借助邮件订阅，让企业内员工都能收到Quick BI自动推送的数据日报。只需简单的配置，即可在邮箱、短信、钉钉工作通知、钉群等多个终端定时开启邮件推送。2. 监控告警还在担心数据异常无法感知？Quick BI能够监控指标异常，当数据发生异常时及时触发通知，手机端就能快速查看异常数据，迅速响应。· 支持小时、日、月粒度的实时监控。· 支持短信、钉钉群、钉钉工作通知等方式告警，随时随地响应告警，处理异常数据。3. 微应用推荐作为数据内容的生产者，IT人员常常面临这样的难题：上新了某个核心数据指标或者核心报表，怎么能够快速通知到所有使用BI的人呢？这个问题的本质其实是内容生产者如何把数据内容分发给合适的消费者。Quick BI的移动端微应用就为消费者提供了一个寻找数据内容的阵地。在微应用的“常用”页面，管理员可以配置企业主推的数据报表或门户导航，将核心数据内容推荐给适合查看的人员。同时，借助banner位和轮播消息，管理员也可以推送重要数据内容和消息通知。类比淘宝首页，每一个用户都能通过搜索/推荐等途径获取想要的商品信息。作为数据消费者在使用Quick BI移动端微应用时，我们也提供了多种路径帮助用户降低数据信息获取的成本。基于数据内容分析决策数据内容触达阅览者之后，希望阅览者能够基于数据内容进行分析决策，而这有两个重要的前提：· 数据内容的生产者（报表开发者）能够基于移动端特性，设计符合需求的移动端交互习惯的样式，且搭建成本要足够低；· 数据内容的消费者（报表查看者）能够在移动端获得较好的看数、查数和分析的体验。1. 搭建成本再降低所见即所得的移动端报表搭建来了！Quick BI支持直接在移动模式下搭建所需移动报表，报表开发者再也不需要为了调整一个样式配置项，在PC和移动模式下来回切换了～想要配置出好看的报表更简单了！Quick BI移动端上新了主题功能，仪表板展示的灵活性更高。报表开发者可以一键切换主题样式，例如双11战报、政务风报表、阿里健康疫情统计等，快速配置出好看的报表。高管查看的移动端报表更需要考虑美观度，我们在主题配置中提供了圆角、背景色&图片、标题边框等个性化功能使仪表板更具风格。2. 样式&分析能力再升级在优化针对重点图表给予移动端特性做了样式和交互优化后，报表查看者看数和分析数据的体验也得到了显著提升。比如基于移动端的展示空间特点，特别设计了适合移动端展示的交叉表样式。通过合并行维度整合相关维度值，尤其适合零售场景中的商品信息展示。Quick BI所有报表&数据门户，设置手机设备横屏后，支持以不同设备方向查看报表数据。能够解决表格类图表（如交叉表）竖屏阅读效率低的问题同时，Quick BI移动端支持联动、钻取、跳转等交互方式，结合查询控件能力升级，整体分析数据体验提升。例如在高层管理者看板中显示各个大区的销售概览数据，单击可在当前页面弹出小浮层，快速查看各个大区的详细数据，单击切换不同的大区，可以快速切换查看各个大区的数据，轻量高效地查看自己感兴趣的数据，而不用跳转到新页面，在多个报表页面中来回切换。分析决策后的协同落地基于数据报表进行分析决策后，如何快速追踪策略执行落地，打通看数据、分析数据、执行落地的业务闭环也是Quick BI在移动端办公协同中的重点思考。得益于和钉钉天然的集成性，Quick BI提供了action打通的特有能力，目前已经打通了钉钉待办、日程、DING的功能，能够支持数据的快速分享，DING到对应的负责人，推动执行落地。比如，老板查看销售数据的KPI情况，发现有问题或对数据不满意，就能直接DING到对应的负责人来排查问题；在群消息里看到每日推送的营收日报，发现某一个大客户申请试用了，于是能够快速进行后续商务对接，及时的响应帮助促成试用到购买的转化。更多关于移动端的内容，欢迎试用Quick BI来体验 https://bi.aliyun.com/

为什么有消息中间件前几天阿粉在看关于如何处理分布式事务的解决方案，于是就看到了关于使用最大努力通知来处理分布式事务的问题，而这其中最不可或缺的就是消息中间件了，那么什么是消息中间件呢？1. 什么是消息中间件在百度百科给出的解释是：消息中间件是基于队列与消息传递技术，在网络环境中为应用系统提供同步或异步、可靠的消息传输的支撑性软件系统。大家看上图，实际上就是生产者发给消息中间件一点东西，然后提供给消费者去消费，这样理解是不是就比百度百科要简单了很多了。2. 消息中间件的种类我们在这里先不讨论消息中间件的组成，下面会继续讲解，我们先看看都有哪些消息中间件，以及他们之间都有什么特点1.ActiveMQActiveMQ是Apache软件基金会所研发的开放源代码消息中间件；由于ActiveMQ是一个纯Java程序，因此只需要操作系统支持Java虚拟机，ActiveMQ便可执行。毕竟是Apache来维护的，功能还是非常强大的，支持Java消息服务(JMS)集群 (Clustering)协议支持包括：OpenWire、REST、STOMP、WS-Notification、MQTT、XMPP以及AMQP。但是ActiveMQ的缺点一样也是很明显的，版本更新很缓慢。集群模式需要依赖Zookeeper实现。虽然现在有了Apollo，号称下一代ActiveMQ，目前案例那是少的可怜。2.RabbitMQRabbitMQ是实现了高级消息队列协议（AMQP）的开源消息代理软件（亦称面向消息的中间件）生态丰富，使用者众，有很多人在前面踩坑。AMQP协议的领导实现，支持多种场景3.RocketMQRocketMQ是阿里开源的消息中间件，目前在Apache孵化，使用纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点,如果大家使用过Kafka的话，那么你就会发现RocketMQ其实和Kafka很相似，但是绝对不是单纯的摘出来了一块内容那么简单，目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理、binglog分发等场景，支撑了阿里多次双十一活动。4.KafkaKafka是LinkedIn于2010年12月开发并开源的一个分布式流平台，现在是Apache的顶级项目，是一个高性能跨语言分布式Publish/Subscribe消息队列系统，以Pull的形式消费消息。Kafka自身服务与消息的生产和消费都依赖于Zookeeper，使用Scala语言开发。学习成本有时候会非常的大，不过阿粉也是相信大家对这个东西肯定很好奇，因为毕竟他是大数据生态系统中不可缺少的一环，以后阿粉会陆陆续续的去带着大家学习这块的内容。说完了区分，那么我们就得开始正儿八经的学习RabbitMQ了，安装，使用，整合到项目中，一气呵成。3. RabbitMQ的安装关于安装的教程，阿粉就不再给大家一一的去说了，毕竟网上有的是教程，官网也有指定的教程，【https://www.rabbitmq.com/】 官网在这里，不过大家需要注意一件事情，RabbitMQ如果你想要安装Windows版本的话，那么你一定得先装一个环境，那就是erlang语言的环境，否则，你是装不到Windows上的。安装完成之后，登录上他的后台，IP/port，默认登录进去就是这个样子滴。