StarRocks 又發(fā)新版本了，這次動(dòng)作有點(diǎn)大。
8 月 7 日，StarRocks 3.1 重磅發(fā)布。新版本中，StarRocks 將影響性能表現(xiàn)的技術(shù)要素全部從存算一體架構(gòu)引入到了存算分離架構(gòu)，并針對(duì)云原生環(huán)境里的易用性、穩(wěn)定性進(jìn)行了一系列的優(yōu)化。
最終的結(jié)果是，這一版本的 StarRocks，已經(jīng)讓存算分離架構(gòu)下的數(shù)據(jù)查詢、導(dǎo)入像在一體架構(gòu)下一樣絲滑，兩者性能已基本持平。
如果說 4 個(gè)月前 StarRocks3.0 的發(fā)布是 StarRocks 向存算分離的一次華麗轉(zhuǎn)身，那么 3.1 版本的發(fā)布則宣告StarRocks 已徹底投入云原生湖倉大潮，踏上了新的臺(tái)階。
鑒于 StarRocks 歷來在性能方面的生猛表現(xiàn)，3.1 版本無疑將對(duì)整個(gè)行業(yè)產(chǎn)生深遠(yuǎn)影響。
主動(dòng)擁抱存算分離大勢(shì)，StarRocks 華麗轉(zhuǎn)身
在 3.0 版本之前，StarRocks 基于存算一體架構(gòu)構(gòu)建的產(chǎn)品能力其實(shí)已經(jīng)非常強(qiáng)悍，不僅在技術(shù)上擁有傲視業(yè)界的性能，在商業(yè)上，全場(chǎng)景的 OLAP 解決方案也已得到 260 家市值 70 億元以上的頭部企業(yè)用戶的認(rèn)可。
但在存算分離架構(gòu)越來越成為行業(yè)趨勢(shì)的背景下，StarRocks 并未因既有的成功而遲疑，而是理性看待原有架構(gòu)中存中的彈性不足、計(jì)算資源浪費(fèi)等問題，毅然選擇主動(dòng)擁抱潮流。
在 3.0 版本中，StarRocks 構(gòu)建了統(tǒng)一的存算分離平臺(tái) StarOS，將存儲(chǔ)與計(jì)算解耦，從根本上突破了原有架構(gòu)的局限性。
需要指出的是，盡管存算分離概念并不新鮮，但僅就國內(nèi) OLAP 數(shù)據(jù)庫領(lǐng)域而言，在 StarRocks3.0 以前，業(yè)界尚無成熟好用的基于存算分離架構(gòu)的分析型數(shù)據(jù)庫。
StarRocks3.0 一經(jīng)發(fā)布，就引發(fā)了全行業(yè)的關(guān)注，其支撐的低成本、高彈性的云原生 OLAP 方案也在短時(shí)間內(nèi)就吸引了眾多用戶嘗鮮使用，現(xiàn)在更已深度融入到各種分析運(yùn)維場(chǎng)景之中。
從轉(zhuǎn)身到蛻變，StarRocks 全面擁抱云原生
在從一體架構(gòu)向分離架構(gòu)的遷移中，涉及到極其繁雜的架構(gòu)改造工作.
3.1 版本中，原有架構(gòu)中主鍵表模型、自增列屬性、時(shí)間函數(shù)表達(dá)式分區(qū)等影響到性能體驗(yàn)的技術(shù)要素都已全部遷移到新架構(gòu)。
現(xiàn)在的 StarRocks，在打開 Data cache 的情況下，存算分離架構(gòu)與存算一體架構(gòu)在查詢性能、導(dǎo)入性能上都已基本持平。
與此同時(shí)，3.1 版本還進(jìn)一步加強(qiáng)了與其它數(shù)據(jù)組件的連接，新增支持了 Elasticsearch catalog、Paimon catalog，并增強(qiáng)了 Trino 語法兼容性，強(qiáng)化了與Iceberg Catalog 的連通性，這些都使得 StarRocks 在云原生環(huán)境下的數(shù)據(jù)運(yùn)維變得更加方便。
不忘初心，StarRocks 仍在探測(cè)性能極限
StockRocks 的核心優(yōu)勢(shì)是極致性能、使用簡(jiǎn)便、穩(wěn)定可靠，在新架構(gòu)下，StarRocks 仍然以性能、易用性、高可用為設(shè)計(jì)開發(fā)導(dǎo)向，堅(jiān)定有力地提升著產(chǎn)品體驗(yàn)和能力邊界。
在新版本中，異步物化視圖的使用更簡(jiǎn)單了，同步物化視圖則已支持所有算子，而對(duì)分桶功能的優(yōu)化則讓用戶不必再關(guān)心分桶配置……種種深入到微觀運(yùn)維層面的產(chǎn)品細(xì)節(jié)，共同構(gòu)筑出了幅近乎完美的使用圖景。
此外，3.1 版本還新增了生成列功能、基數(shù)保持 JOIN 表裁剪等加速手段，進(jìn)一步發(fā)掘了新架構(gòu)下的性能潛力。
毫無疑問，在存算一體架構(gòu)分析型數(shù)據(jù)庫領(lǐng)域“跑得最快”的 StarRocks，遷移到存算分離架構(gòu)后，依然是那個(gè)讓人熟悉的領(lǐng)跑者。
新增核心功能介紹
主鍵模型表也有了，存算分離架構(gòu)下查詢導(dǎo)入都更絲滑
業(yè)界領(lǐng)先的極致性能體驗(yàn)一直是StarRocks 引以為傲的核心優(yōu)勢(shì)之一，在向存算分離架構(gòu)遷移之初，StarRocks 就在極力還原分離架構(gòu)中的性能優(yōu)勢(shì)。
3.1 版本，StarRocks 已經(jīng)基本將影響性能表現(xiàn)的技術(shù)要素全部引入到了分離架構(gòu)，相對(duì)于3.0版本，主鍵模型表(包括支持部分列更新，但暫不支持持久化索引)、自增列屬性 AUTO_INCREMENT、時(shí)間函數(shù)表達(dá)式分區(qū)及導(dǎo)入時(shí)自動(dòng)創(chuàng)建分區(qū)都已得到完美支持。
此外，專門針對(duì)分離架構(gòu)打造的數(shù)據(jù)緩存功能在新版本也實(shí)現(xiàn)了進(jìn)一步的優(yōu)化，通過對(duì)熱數(shù)據(jù)緩存范圍的個(gè)性化調(diào)節(jié)，即能靈活適配實(shí)際使用場(chǎng)景中冷熱數(shù)據(jù)的界定，有效減少冷數(shù)據(jù)對(duì)緩存的占用，從而提升熱數(shù)據(jù)查詢性能。
在打開 Data cache 的情況下，存算分離架構(gòu)與存算一體架構(gòu)在查詢性能、導(dǎo)入性能上都已基本持平。也就是說，StarRocks3.1的存算分離架構(gòu)，在大幅降低用戶存儲(chǔ)成本的同時(shí)，查詢、導(dǎo)入都已經(jīng)像一體架構(gòu)一樣絲滑。
在 Icerberg 內(nèi)也能建表了，數(shù)據(jù)湖分析運(yùn)維越來越輕松
StarRocks 一直在強(qiáng)調(diào)對(duì)大數(shù)據(jù)生態(tài)的融合，從一線運(yùn)維人員的視角出發(fā)，細(xì)微關(guān)注 StarRocks 與其它優(yōu)秀的、主流的數(shù)據(jù)組件的連接需求，不斷提升易用性，讓運(yùn)維變得越來越輕松。
3.1 版本著重增強(qiáng)了與Iceberg Catalog 的連通性，相對(duì)于3.0版本，3.1版本不僅支持對(duì) Parquet 格式的 Icerberg v2 MOR 表的查詢?cè)L問，還新增了對(duì) Iceberg 元數(shù)據(jù)的內(nèi)存+磁盤的兩級(jí)緩存，有效提升了查詢性能，在元數(shù)據(jù)文件較大的情況下性能升級(jí)效果尤其顯著。
在寫入能力上，則是新增支持了在 Icerberg 內(nèi)創(chuàng)建數(shù)據(jù)庫、表，并通過 INSERT INTO/OVERWRITE 寫入 Parquet 格式數(shù)據(jù)。通過開放數(shù)據(jù)格式，用戶即可以將 StarRocks 的處理結(jié)果無縫接入到生態(tài)內(nèi)的其他組件。
除Iceberg Catalog外，3.1 版本還新增支持了 Elasticsearch catalog[5]、Paimon catalog[6]，并進(jìn)一步增強(qiáng)了 Trino語法兼容性。
執(zhí)行策略可以單獨(dú)配置了，物化視圖應(yīng)用場(chǎng)景大大拓展
物化視圖因其強(qiáng)大的加速效果，是 StarRocks 的核心功能之一，在歷個(gè)版本中，StarRocks 都對(duì)物化視圖進(jìn)行了大量的優(yōu)化、升級(jí)，不斷提升著易用性、靈活性，使其變得更好用、更管用。
在3.1版本中，不管是同步物化視圖，還是異步物化視步，同樣都作了大量的優(yōu)化，使用體驗(yàn)和適用場(chǎng)景都有質(zhì)的提升。
異步物化視圖
自 2.4 版本推出異步物化視圖以來，這一功能已深度融入用戶的查詢加速、數(shù)倉建模等場(chǎng)景，而StarRocks 也致力于讓異步物化視圖擁有與內(nèi)表相同的加速和管理能力，在 3.1 版本中：
支持通過ORDER BY 指定排序鍵，支持設(shè)置colocate_group，進(jìn)一步利用 StarRocks 原生存儲(chǔ)的優(yōu)化來加速物化視圖的查詢性能。
支持配置存儲(chǔ)介質(zhì)和降冷時(shí)間(storage_medium 、cooldown_time )，方便數(shù)據(jù)的生命周期管理。
支持不指定分桶，默認(rèn)采用隨機(jī)分桶，提升創(chuàng)建物化視圖的易用性。
并且為了使異步物化視圖更加靈活，在 3.1 版本中：
支持為物化視圖的刷新配置會(huì)話變量 (Session Variable)，用戶可以方便地為物化視圖配置單獨(dú)的執(zhí)行策略，如查詢超時(shí)時(shí)間、并行度、內(nèi)存限制、是否開啟算子落盤等。讓物化視圖的刷新不受集群整體變量的限制。
支持基于視圖(View)創(chuàng)建物化視圖，分層建模選擇更加靈活。
支持通過 SWAP 原子替換物化視圖，從而實(shí)現(xiàn)物化視圖的 Schema Change 而不影響嵌套的血緣關(guān)系。
支持手動(dòng)激活失效的物化視圖，從而在基表重建后仍舊復(fù)用歷史物化視圖。
在查詢改寫上，StarRocks 致力于讓更多場(chǎng)景能夠被智能改寫，更多發(fā)揮物化視圖的加速效果。在 3.1 版本中：
新增支持 Join 派生改寫、Count Distinct、time_slice 函數(shù)等場(chǎng)景的改寫，并優(yōu)化了 Union 改寫能力。
新增支持 Stale Rewrite，即在一定時(shí)間內(nèi)允許改寫至還未刷新的物化視圖上。從而在允許一定數(shù)據(jù)延遲的實(shí)時(shí)場(chǎng)景下，通過物化視圖提高查詢并發(fā)。
新增支持 View Delta Join，提升如指標(biāo)平臺(tái)、面向主題的寬表場(chǎng)景下的改寫能力，降低物化視圖的維護(hù)成本。
在刷新能力上，在 3.1 版本中：
支持全新同步物化視圖刷新接口，同步獲取刷新結(jié)果。
基于 Hive Catalog 創(chuàng)建的外表異步物化視圖可以感知分區(qū)變動(dòng)，按分區(qū)增量刷新，加速刷新的同時(shí)降低成本。
同步物化視圖
擁有同步更新、增量計(jì)算能力，并且性能卓越的同步物化視圖一直廣受 StarRocks 用戶喜愛，美中不足的是，歷史版本中，其支持的算子還不完整，導(dǎo)致應(yīng)用場(chǎng)景也受到了一定限制。
在 3.1 版本中，這一局限已不再存在。新版本不僅支持了所有的聚合函數(shù)，也支持了CASE-WHEN、CAST、數(shù)學(xué)運(yùn)算等表達(dá)式。
此外，3.1 版本還支持在單個(gè)物化視圖內(nèi)設(shè)置多個(gè)聚合列，并且可以使用 HINT 來對(duì)同步物化視圖進(jìn)行直接查詢。
可以說，這一版本的StarRocks，已經(jīng)大幅拓寬了同步物化視圖能力邊界。
SQL
CREATE MATERIALIZED VIEW v1 AS
SELECT b, sum(a + 1) as sum_a1, min(cast (a as bigint)) as min_a
FROM base_table
GROUP BY b;
加速手段更多了，查詢性能繼續(xù)奔跑
眾所周知，StarRocks 對(duì)查詢性能的追求近乎狂熱，3.1版本中，這一點(diǎn)又得到了充分體現(xiàn)。
3.1 版本新增了生成列(Generated Column)功能，StarRocks 會(huì)根據(jù)生成列表達(dá)式自動(dòng)計(jì)算表達(dá)式的值并在導(dǎo)入時(shí)即存儲(chǔ)，在查詢時(shí)會(huì)自動(dòng)判斷并進(jìn)行改寫，在無需增加查詢復(fù)雜性的情況下，再一步提升查詢性能。
這一設(shè)計(jì)尤其適用對(duì) JSON、Array、Map、Struct 等半結(jié)構(gòu)數(shù)據(jù)的查詢加速和對(duì)復(fù)雜表達(dá)式的計(jì)算加速。
并且，如果生成列的類型是簡(jiǎn)單類型，還能利用上 zonemap 等索引，會(huì)更進(jìn)一步加速查詢性能。
如下所示，newcol1、newcol2 是兩個(gè)分別是對(duì) data_array、data_json 列做了一些函數(shù)操作的生成列。
SQL
CREATE TABLE t (
id INT NOT NULL,
data_array ARRAY < int > NOT NULL,
data_json JSON NOT NULL,
newcol1 DOUBLE ASarray_avg(data_array),
newcol2 STRING ASget_json_string(json_string(data_json), '$.a')
);
插入數(shù)據(jù)時(shí)正常插入即可(不用關(guān)心生成列)，newcol1、newcol2 會(huì)自動(dòng)計(jì)算并存儲(chǔ)。
SQL
INSERT INTO t VALUES (1, [1,2], parse_json('{"a" : 1, "b" : 2}')),
(2, [3,5], parse_json('{"a" : 8, "b" : 3}'))
查詢時(shí)也正常查詢即可，StarRocks 會(huì)自動(dòng)改寫 Query，變成對(duì) newcol1、newcol2 的使用。
SQL
SELECT max(get_json_string(json_string(data_json),”$.a”)) AS a,
min(array_avg(data_array)) AS b
FROM t;
同時(shí)，StarRocks 優(yōu)化了主鍵模型的部分列更新功能，執(zhí)行 UPDATE [8]語句時(shí)會(huì)開啟列模式(column mode)，在更新少部分列但是有大量行的場(chǎng)景下，可提升十倍性能。
在原來的「行模式」下，部分列更新時(shí)，StarRocks 會(huì)需要重寫整行數(shù)據(jù)。
在新的「列模式」下，只需要重寫更新的列數(shù)據(jù)即可。
還有，StarRocks 支持了基數(shù)保持 JOIN 表(Cardinality-preserving Joins)的裁剪，優(yōu)化了點(diǎn)查查詢性能、統(tǒng)計(jì)信息收集、并行 merge 算法、優(yōu)化內(nèi)部鎖使用的邏輯等等，進(jìn)一步提升各類細(xì)分場(chǎng)景下的查詢性能。
其中「基數(shù)保持 JOIN 表的裁剪」功能在較多表的星型模型(比如 SSB)和雪花模型(TPC-H)中會(huì)有用武之地，當(dāng) JOIN 的表存在主鍵或者外鍵約束，且可以滿足基數(shù)保持 JOIN 表裁剪的條件，一些經(jīng)過裁剪后的 JOIN 的性能能加速 10X 倍以上。
在風(fēng)控領(lǐng)域進(jìn)行多種組合的特征選擇時(shí)，往往采用直接查詢由較多表 JOIN 后的 View，此時(shí)的裁剪就會(huì)起到不錯(cuò)的效果。
??SELECT view 時(shí)，view 中不需要用到的 Table-C 被自動(dòng)裁剪掉了。使用中需要額外設(shè)置一些約束。
Spill To Disk 加強(qiáng)
除了卓越的查詢性能，在大規(guī)模的數(shù)據(jù)集上查詢時(shí)的穩(wěn)定性也是很重要的一個(gè)方面。對(duì)此，3.1 版本中，StarRocks 正式支持了部分阻塞算子的 Spill(中間數(shù)據(jù)落盤)能力，當(dāng)查詢中包括聚合、排序或者連接算子時(shí)，開啟 Spill 功能將允許相關(guān)的算子將計(jì)算的中間結(jié)果緩存到磁盤上，從而降低內(nèi)存占用，盡量避免查詢因內(nèi)存不足而失敗。
在物化視圖構(gòu)建、數(shù)據(jù) ETL 處理等內(nèi)存密集型的場(chǎng)景中，開啟 Spill 會(huì)極大地提升查詢的穩(wěn)定性。
在 3 個(gè) BE、每個(gè) BE 16core/20G 內(nèi)存的測(cè)試環(huán)境中，開啟 Spill 功能后，StarRocks 能完整地跑完 TPCH-10TB 測(cè)試集。
分桶鍵可以不用設(shè)了，建表與導(dǎo)入更方便
在不斷優(yōu)化查詢性能的同時(shí)，StarRocks 持續(xù)在建表和導(dǎo)入方面提升產(chǎn)品易用性、提供更多實(shí)用功能。
在建表時(shí)，用戶可以配置隨機(jī)分桶(Random Bucketing)[9]方式(默認(rèn))，不再需要設(shè)置分桶鍵，StarRocks 會(huì)將導(dǎo)入數(shù)據(jù)隨機(jī)分發(fā)到各個(gè)分桶中，同時(shí)配合使用 2.5.7 版本起支持的自動(dòng)設(shè)置分桶數(shù)量功能(默認(rèn))，用戶可以不再需要關(guān)心分桶配置。
SQL
CREATE TABLE site_access(
event_day DATE,
site_id INT DEFAULT '10',
...
) DUPLICATE KEY(event_day, site_id)
PARTITION BY date_trunc('day', event_day)
DISTRIBUTED BY HASH(event_day,site_id) BUCKETS 10; -- 可以不再需要指定
在導(dǎo)入數(shù)據(jù)時(shí)，如果數(shù)據(jù)是存儲(chǔ)在 AWS S3/HDFS 上的 Parquet/ORC 格式文件，用戶可以很簡(jiǎn)單地直接采用 INSERT+ FILES()表函數(shù)來導(dǎo)入數(shù)據(jù)，F(xiàn)ILES 表函數(shù)會(huì)自動(dòng)進(jìn)行 table schema 推斷，做到數(shù)據(jù)拿來即可 SELECT，用戶甚至還可以使用 CTAS + FILES 一鍵式導(dǎo)入數(shù)據(jù)，在前期測(cè)試數(shù)據(jù)導(dǎo)入階段尤其適用。
SQL
CREATE TABLE insert_wiki_edit AS
SELECT * FROM FILES(
'path' = 's3://inserttest/parquet/insert_wiki_edit_append.parquet',
'format' = 'parquet');
同時(shí)，關(guān)于建表時(shí)的分區(qū)設(shè)置，一般直接設(shè)置日期時(shí)間字段作為分區(qū)列即可，如果用戶想要根據(jù)自己的數(shù)據(jù)更靈活地配置，也可以使用 StarRocks 新支持的表達(dá)式分區(qū)和LIST 分區(qū)方式，其中配置表達(dá)式分區(qū)后，StarRocks 會(huì)根據(jù)數(shù)據(jù)和分區(qū)表達(dá)式的定義規(guī)則自動(dòng)創(chuàng)建分區(qū)。
并且，繼 3.0 版本中湖分析支持查詢 Map、Struct 類型數(shù)據(jù)后，3.1 版本中導(dǎo)入數(shù)據(jù)時(shí)也支持導(dǎo)入 Parquet/ORC 格式數(shù)據(jù)中的 Map、Struct 字段類型，為導(dǎo)入提供了更多選項(xiàng)。
StarRocks 在簡(jiǎn)化建表、簡(jiǎn)化導(dǎo)入方面將持續(xù)地進(jìn)行端到端的優(yōu)化，不斷提升產(chǎn)品易用性和功能的完善性。
Struct 數(shù)據(jù)也能用了，半結(jié)構(gòu)化分析能力非常強(qiáng)
3.1 版本中，StarRocks 正式原生支持了 Map 和 Struct 數(shù)據(jù)類型。除了基于湖上的半結(jié)構(gòu)化數(shù)據(jù)分析，也支持建表、導(dǎo)入、創(chuàng)建物化視圖。同時(shí)也補(bǔ)充了 Map 和 Struct 的更多函數(shù)，包括標(biāo)量、聚合以及更多的 Map 高階函數(shù)。
Array 數(shù)據(jù)類型支持了 Fast Decimal，并且 Array 函數(shù)支持了嵌套結(jié)構(gòu)類型 Map、Struct 和 Array。讓用戶的查詢分析體驗(yàn)更加靈活。
并且結(jié)合生成列的能力，可以進(jìn)一步加速對(duì)復(fù)雜數(shù)據(jù)類型的計(jì)算與查詢。例如對(duì) JSON 內(nèi)的對(duì)象的查詢、大 ARRAY 的聚合計(jì)算等場(chǎng)景，均可以通過生成列在導(dǎo)入時(shí)預(yù)先完成計(jì)算，并在后續(xù)查詢中通過自動(dòng)改寫完成查詢加速。
可以認(rèn)為，不論是從導(dǎo)入到查詢的功能上、還是用生成列來優(yōu)化性能上，StarRocks 基本完整地支持了 Array、JSON、Map、Struct 這類半結(jié)構(gòu)化數(shù)據(jù)的能力。
最后，如你希望更加了解 StarRocks 3.1 版本，歡迎觀看視頻解說。
StarRocks Feature Groups：
StarRocks 社區(qū)為了讓用戶在使用新 features 時(shí)能更加得心應(yīng)手，設(shè)立了包含”物化視圖“、”湖倉分析“和”存算分離“等的用戶群，歡迎小伙伴們?nèi)肴簩?duì)特定 feature 進(jìn)行深入交流！
在這個(gè)版本中，117 位貢獻(xiàn)者 一共提交了 2785 個(gè) Commits，感謝他們：
stdpain, Astralidea, mofeiatwork, yandongxiao, kevincai, Seaven, hellolilyliuyi, EsoragotoSpirit, Youngwb, andyziye, packy92, sduzh, meegoo, zaorangyang, caneGuy, silverbullet233, chaoyli, LiShuMing, trueeyu, srlch, liuyehcf, ABingHuang, luohaha, amber-create, miomiocat, sevev, letian-jiang, stephen-shelby, zombee0, nshangyiming, satanson, fzhedu, Smith-Cruise, gengjun-git, decster, TszKitLo40, starrocks-xupeng, evelynzhaojie, ZiheLiu, zhenxiao, wyb, rickif, HangyuanLiu, liuzhongjun89, dirtysalt, abc982627271, wanpengfei-git, SilvaXiang, hongli-my, kangkaisen, liuyufei9527, ggKe, xuzifu666, ucasfl, GavinMar, jkim650, JackeyLee007, tracymacding, huzhichengdd, Moonm3n, silly-carbon, imay, szza, you06, leoyy0316, Johnsonginati, smartlxh, xiangguangyxg, vendanner, QingdongZeng3, zhangruchubaba, wxl24life, banmoy, matchyc, predator4ann, huangfeng1993, dengliu, choury, bowenliang123, sebpop, RamaMalladiAWS, dustinlineweber, jiacheng-celonis, chen9t, blanklin030, wangsimo0, howrocks, qmengss, alberttwong, before-Sunrise, chenjian2664, wangruin, kobebryantlin0, wangxiaobaidu11, creatstar, kateshaowanjou, huandzh, mlimwxxnn, goldenbean, Jay-ju, ss892714028, mchades, cbcbq, shileifu, xiaoyong-z, sfwang218, uncleGen, r-sniper, blackstar-baba, ldsink, gddezero, fieldsfarmer, even986025158, idomic, yangrong688, padmejin, zuyu
（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）
