整合營銷服務(wù)商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
文分享自華為云社區(qū)《GaussDB(DWS)性能調(diào)優(yōu)系列實戰(zhàn)篇七：十八般武藝之GUC參數(shù)調(diào)優(yōu)-云社區(qū)-華為云》，作者： 黎明的風(fēng)。
GaussDB(DWS)性能調(diào)優(yōu)系列專題文章，介紹了數(shù)據(jù)庫性能調(diào)優(yōu)的思路和總體策略。在系統(tǒng)級調(diào)優(yōu)中數(shù)據(jù)庫全局的GUC參數(shù)對整體性能的提升至關(guān)重要，而在語句級調(diào)優(yōu)中GUC參數(shù)可以調(diào)整估算模型，選擇查詢計劃中算子的類型，或者選擇不同的執(zhí)行計劃。因此在SQL調(diào)優(yōu)過程中合理的設(shè)置GUC參數(shù)十分重要。
在GaussDB(DWS)中，SQL語句的執(zhí)行所需要經(jīng)歷的步驟如下圖所示，其中紅色部分為DBA可以介入實施調(diào)優(yōu)的環(huán)節(jié)。
查詢計劃的生成是基于一定的模型和統(tǒng)計信息進行代碼估算，在某些場景由于統(tǒng)計信息不準(zhǔn)確或者代價估算有偏差時，就需要通過GUC參數(shù)設(shè)置的的方式選擇更優(yōu)的查詢計劃。
在GaussDB(DWS)中，和SQL執(zhí)行性能相關(guān)的GUC參數(shù)主要有以下幾個：
GaussDB(DWS)是分布式的數(shù)據(jù)庫集群，數(shù)據(jù)計算盡量在各個DN上并行計算，可以得到最優(yōu)的性能，在Stream框架下Agg操作可以分為兩個場景。
Agg下層算子輸出結(jié)果集的分布列是Group By列的子集。
這種場景，直接對下層結(jié)果集進行匯聚的結(jié)果就是正確的匯聚結(jié)果，生成算子直接使用即可。例如以下語句，lineitem的分布列是l_orderkey，它是Group By的列。
select
l_orderkey,
count(*) as count_order
from
lineitem
group by
l_orderkey;
查詢計劃如下：
Agg下層算子輸出結(jié)果集的分布列不是Group By列的子集。
對于這種場景Stream下的聚集（Agg）操作，優(yōu)化器可以生成以下三種形態(tài)的查詢計劃：
通常優(yōu)化器總會選擇最優(yōu)的執(zhí)行計劃，但是眾所周知代價估算，尤其是中間結(jié)果集的代價估算有時會有比較大的偏差。這種比較大的偏差就可能會導(dǎo)致聚集（agg）的計算方式出現(xiàn)比較大的偏差，這時候就需要通過best_agg_plan參數(shù)進行聚集計算模型的干預(yù)。
以下通過TPC-H Q1語句分析三種形態(tài)的查詢計劃：
-- TPC-H Q1
select
l_returnflag,
l_linestatus,
sum(l_quantity) as sum_qty,
sum(l_extendedprice) as sum_base_price,
sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,
sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,
avg(l_quantity) as avg_qty,
avg(l_extendedprice) as avg_price,
avg(l_discount) as avg_disc,
count(*) as count_order
from
lineitem
where
l_shipdate <=date '1998-12-01' - interval '90' day (3)
group by
l_returnflag,
l_linestatus
order by
l_returnflag,
l_linestatus;
}
當(dāng)best_agg_plan=1時，在DN上進行了一次聚集，然后結(jié)果通過GATHER算子匯總到CN上進行了二次聚集，對應(yīng)的查詢計劃如下：
該方法適用于DN第一次聚集后結(jié)果集較少并且DN數(shù)較少的場景，在CN上進行第二次聚集時的結(jié)果集小，CN不會成為計算瓶頸。
當(dāng)best_agg_plan=2時，在DN上先按照Group By的列進行數(shù)據(jù)重分布，然后在DN上進行聚集操作，將匯總的結(jié)果返回給CN，對應(yīng)的查詢計劃如下：
該方法適用于DN第一次聚集后結(jié)果集縮減不明顯的場景，因為這樣可以省略DN上的第一次聚集操作。
當(dāng)best_agg_plan=3時，在DN上進行一次聚集，然后將聚集結(jié)果按照Group By的列進行數(shù)據(jù)重分布，之后在DN上進行二次聚集得到結(jié)果，對應(yīng)的查詢計劃如下：
該方法使用于DN第一次聚集后中間結(jié)果縮減明顯，但最終結(jié)果行數(shù)比較大的場景。
GaussDB(DWS)中，以上三種方法的選擇是根據(jù)代價來自動選擇。在實際的SQL調(diào)優(yōu)時，如果遇到有聚集方式不合理的場景，可以通過嘗試設(shè)置best_agg_plan參數(shù)，選擇最優(yōu)的聚集方式。
GaussDB(DWS)中實現(xiàn)分組聚集操作有兩種方法：
以下面的SQL為例：
select
l_orderkey,
count(*) as count_order
from
lineitem
group by
l_orderkey;
如果使用Sort + GroupAgg的方式，在Sort排序算子里執(zhí)行時間比較長，因為需要對大量數(shù)據(jù)進行排序操作。
以上這種場景，可以關(guān)閉enable_sort參數(shù)，選擇使用HashAgg的方式來實現(xiàn)聚集操作，可以獲得較好的執(zhí)行性能。
GaussDB(DWS)中通過count distinct來統(tǒng)計多個列的數(shù)據(jù)時，通常會使用HashAgg來實現(xiàn)每一個列的統(tǒng)計聚集操作，然后將結(jié)果通過Join方式關(guān)聯(lián)起來得到最終結(jié)果。
以下面的SQL為例：
select
l_orderkey,
count(distinct l_partkey) as count_partkey,
count(distinct l_suppkey) as count_suppkey,
count(distinct l_linenumber) as count_linenumber,
count(distinct l_returnflag) as count_returnflag,
count(distinct l_linestatus) as count_linestatus,
count(distinct l_shipmode) as count_shipmode
from
lineitem
group by
l_orderkey;
從查詢計劃來看，通過count distinct統(tǒng)計了lineitem表中的6列數(shù)據(jù)，是通過6個HashAgg操作來實現(xiàn)的，該SQL執(zhí)行時消耗的資源相對較高。
如果關(guān)閉enable_hashagg參數(shù)，優(yōu)化器會選擇Sort + GroupAgg的方式，該SQL執(zhí)行時消耗的資源相對較少。
在應(yīng)用開發(fā)時，可以根據(jù)SQL并發(fā)和資源使用情況，通過設(shè)置enable_hashagg參數(shù)來選擇合適的執(zhí)行計劃。
GaussDB(DWS)支持行存儲和列存儲兩種存儲模型，用戶可以根據(jù)應(yīng)用場景，建表的時候選擇行存儲還是列存儲表。向量化執(zhí)行將傳統(tǒng)的執(zhí)行模式由一次一元組的模型修改為一次一批元組，配合列存特性，可以帶來巨大的性能提升。
如果使用行存表或者是行列混存的場景，由于行存表默認走的是行存執(zhí)行引擎，最終查詢無法走向量化執(zhí)行引擎。
以下面的SQL為例：
select
l_orderkey,
sum(l_extendedprice * (1 - l_discount)) as revenue,
o_orderdate,
o_shippriority
from
customer_row,
orders,
lineitem
where
c_mktsegment='BUILDING'
and c_custkey=o_custkey
and l_orderkey=o_orderkey
and o_orderdate < date '1995-03-15'
and l_shipdate > date '1995-03-15'
group by
l_orderkey,
o_orderdate,
o_shippriority
order by
revenue desc,
o_orderdate
limit 10;
SQL語句中的customer_row表為行存表，orders和lineitem為列存表，該場景在默認參數(shù)的情況下無法走向量化引擎，Row Adapter算子表示將列存數(shù)據(jù)轉(zhuǎn)為行存數(shù)據(jù)，對應(yīng)的查詢計劃為：
這種場景，可以選擇開啟enable_force_vector_engine參數(shù)，通過向量化執(zhí)行引擎來執(zhí)行，Vector Adapter算子表示將行存數(shù)據(jù)轉(zhuǎn)換為列存數(shù)據(jù)，每個算子前面的Vector表示改算子為向量化引擎的執(zhí)行器算子，對應(yīng)的查詢計劃為：
從上述計劃可以看出，向量化引擎相比行執(zhí)行引擎，執(zhí)行性能有數(shù)倍的提升效果。
GaussDB(DWS)支持并行計算技術(shù)，當(dāng)系統(tǒng)的CPU、內(nèi)存、I/O和網(wǎng)絡(luò)帶寬等資源充足時，可以充分利用富余硬件資源，提升語句的執(zhí)行速度。在GaussDB(DWS)中，通過query_dop參數(shù)，來控制語句的并行度，取值如下：
query_dop參數(shù)設(shè)置的一些原則：
設(shè)置query_dop=0可以實現(xiàn)自適應(yīng)調(diào)優(yōu)，在部分場景下語句執(zhí)行的并行度沒有達到最優(yōu)，這種情況可以考慮通過query_dop參數(shù)設(shè)置并行度。
例如下面的SQL：
select count(*) from
(
select
l_orderkey,
count(*) as count_order
from
lineitem
group by
l_orderkey
);
在query_dop=0時使用的并行度為2。
設(shè)置query_dop=4時使用的并行度為4，執(zhí)行時間相比并行度為2時有明顯的提升。
在使用GaussDB(DWS)時，全局的GUC參數(shù)對集群整體性能影響很大，這里介紹一些常用參數(shù)以及推薦的配置。
影響數(shù)據(jù)庫性能的五大內(nèi)存參數(shù)有：max_process_memory、shared_buffers、cstore_buffers、work_mem和maintenance_work_mem。
max_process_memory
max_process_memory是邏輯內(nèi)存管理參數(shù)，主要功能是控制單個CN/DN上可用內(nèi)存的最大峰值。
計算公式：max_process_memory=物理內(nèi)存*0.665/(1+主DN個數(shù))。
shared_buffers
設(shè)置DWS使用的共享內(nèi)存大小。增加此參數(shù)的值會使DWS比系統(tǒng)默認設(shè)置需要更多的System V共享內(nèi)存。
建議設(shè)置shared_buffers值為內(nèi)存的40%以內(nèi)。主要用于行存表scan。計算公式：shared_buffers=(單服務(wù)器內(nèi)存/單服務(wù)器DN個數(shù))0.40.25
cstore_buffers
設(shè)置列存和OBS、HDFS外表列存格式（orc、parquet、carbondata）所使用的共享緩沖區(qū)的大小。
計算公式可參考shared_buffers。
work_mem
設(shè)置內(nèi)部排序操作和Hash表在開始寫入臨時磁盤文件之前使用的內(nèi)存大小。
ORDER BY，DISTINCT和merge joins都要用到排序操作。Hash表在散列連接、散列為基礎(chǔ)的聚集、散列為基礎(chǔ)的IN子查詢處理中都要用到。
對于復(fù)雜的查詢，可能會同時并發(fā)運行好幾個排序或者散列操作，每個都可以使用此參數(shù)所聲明的內(nèi)存量，不足時會使用臨時文件。同樣，好幾個正在運行的會話可能會同時進行排序操作。因此使用的總內(nèi)存可能是work_mem的好幾倍。
計算公式：
對于串行無并發(fā)的復(fù)雜查詢場景，平均每個查詢有5-10關(guān)聯(lián)操作，建議work_mem=50%內(nèi)存/10。
對于串行無并發(fā)的簡單查詢場景，平均每個查詢有2-5個關(guān)聯(lián)操作，建議work_mem=50%內(nèi)存/5。
對于并發(fā)場景，建議work_mem=串行下的work_mem/物理并發(fā)數(shù)。
maintenance_work_mem
maintenance_work_mem用來設(shè)置維護性操作（比如VACUUM、CREATE INDEX、ALTER TABLE ADD FOREIGN KEY等）中可使用的最大的內(nèi)存。
當(dāng)自動清理進程運行時，autovacuum_max_workers倍數(shù)的內(nèi)存將會被分配，所以此時設(shè)置maintenance_work_mem的值應(yīng)該不小于work_mem。
連接相關(guān)的參數(shù)有兩個：max_connections和max_prepared_transactions
max_connections
允許和數(shù)據(jù)庫連接的最大并發(fā)連接數(shù)。此參數(shù)會影響集群的并發(fā)能力。
設(shè)置建議：
CN中此參數(shù)建議保持默認值。DN中此參數(shù)建議設(shè)置為CN的個數(shù)乘以CN中此參數(shù)的值。
增大這個參數(shù)可能導(dǎo)致GaussDB(DWS)要求更多的System V共享內(nèi)存或者信號量，可能超過操作系統(tǒng)缺省配置的最大值。這種情況下，請酌情對數(shù)值加以調(diào)整。
max_prepared_transactions
設(shè)置可以同時處于"預(yù)備"狀態(tài)的事務(wù)的最大數(shù)目。增加此參數(shù)的值會使GaussDB(DWS)比系統(tǒng)默認設(shè)置需要更多的System V共享內(nèi)存。
NOTICE:
max_connections取值的設(shè)置受max_prepared_transactions的影響，在設(shè)
max_connections之前，應(yīng)確保max_prepared_transactions的值大于或等
max_connections的值，這樣可確保每個會話都有一個等待中的預(yù)備事務(wù)。
max_active_statements
設(shè)置全局的最大并發(fā)數(shù)量。此參數(shù)只應(yīng)用到CN，且針對一個CN上的執(zhí)行作業(yè)。
需根據(jù)系統(tǒng)資源（如CPU資源、IO資源和內(nèi)存資源）情況，調(diào)整此數(shù)值大小，使得系統(tǒng)支持最大限度的并發(fā)作業(yè)，且防止并發(fā)執(zhí)行作業(yè)過多，引起系統(tǒng)崩潰。
當(dāng)取值-1或者0時，不限制全局并發(fā)數(shù)。
在點查詢的場景下，參數(shù)建議設(shè)置為100。
在分析類查詢的場景下，參數(shù)的值設(shè)置為CPU的核數(shù)除以DN個數(shù)，一般可以設(shè)置5~8個。
bulk_write_ring_size
數(shù)據(jù)并行導(dǎo)入使用的環(huán)形緩沖區(qū)大小。
該參數(shù)主要影響入庫性能，建議導(dǎo)入壓力大的場景增加DN上的該參數(shù)配置。
checkpoint_completion_target
指定檢查點完成的目標(biāo)。
含義是每個checkpoint需要在checkpoints間隔時間的50%內(nèi)完成。
默認值為0.5，為提高性能可改成0.9。
data_replicate_buffer_size
發(fā)送端與接收端傳遞數(shù)據(jù)頁時，隊列占用內(nèi)存的大小。此參數(shù)會影響主備之間復(fù)制的緩沖大小。
默認值為128MB，若服務(wù)器內(nèi)存為256G，可適當(dāng)增大到512MB。
wal_receiver_buffer_size
備機與從備接收Xlog存放到內(nèi)存緩沖區(qū)的大小。
默認值為64MB，若服務(wù)器內(nèi)存為256G，可適當(dāng)增大到128MB
本篇文章主要介紹了GaussDB(DWS)性能調(diào)優(yōu)涉及到的優(yōu)化器和系統(tǒng)級GUC參數(shù)，通過合理配置這些GUC參數(shù)，能夠充分利用好CPU、內(nèi)存、磁盤IO和網(wǎng)絡(luò)IO等資源，提升語句的執(zhí)行性能和GaussDB(DWS)集群的整體性能。
關(guān)注@華為云開發(fā)者聯(lián)盟點擊下方，第一時間了解華為云新鮮技術(shù)~
華為云博客_大數(shù)據(jù)博客_AI博客_云計算博客_開發(fā)者中心-華為云
器之心報道
作者：蛋醬
在近日公布的 MSU 2020 比賽結(jié)果中，首次亮相的字節(jié)跳動 BVC2.0 編碼器一舉收獲了「四個第一」。
首先，讓我們看兩張圖片：
(a) BVC2.0 處理后的圖像。
(b) x265 處理后的圖像。
上面兩張圖片是在相同壓縮比情況下，x265 和 BVC2.0 的壓縮圖像效果。這樣的對比場景，是否似曾相識？
沒錯，讓人想起了視頻網(wǎng)站中「流暢」和「高清」的對比。受移動互聯(lián)網(wǎng)發(fā)展、移動智能終端普及等因素的推動，短視頻和直播行業(yè)近年來實現(xiàn)了爆發(fā)式的增長，但對于業(yè)務(wù)方來說，存儲空間和帶寬資源的成本仍然高昂；對于普通用戶來說，不清晰的畫質(zhì)和卡頓問題還十分普遍。這些目前所存在的挑戰(zhàn)，都對視頻編解碼技術(shù)提出了更高的要求。
從 2005 年開始，俄羅斯莫斯科國立大學(xué)（Mosow State University，MSU）每年定期在全球范圍內(nèi)征集各大公司及相關(guān)機構(gòu)研發(fā)的視頻編碼器，在不同的應(yīng)用場景下對其進行綜合測評。視頻編碼器（Video Codecs Comparison）大賽迄今已連續(xù)舉辦十五屆，是視頻編碼行業(yè)內(nèi)影響力最大的比賽。與往年一樣，今年也有很多國內(nèi)外的頂尖技術(shù)團隊參賽，分別來自谷歌、英特爾、百度、阿里、騰訊等科技公司，且擁有豐富的比賽經(jīng)驗。
在本年度 MSU2020 offline （1fps）視頻編碼器比賽中，字節(jié)跳動先進視頻團隊（Advanced Video Group）自主研發(fā)的 BVC2.0 編碼器從競爭中脫穎而出：在 VMAF、PSNR avg. MSE 兩個準(zhǔn)則測試中摘得第一名的成績。同時也在 PSNR avg. log、SSIM 兩個準(zhǔn)則測試中獲得并列第一的排名。
四個「第一」
近日，MSU2020 主辦方公開了 20 個團隊的測試結(jié)果，在 VMAF 準(zhǔn)則測試中，字節(jié)跳動的 BVC2.0 編碼器領(lǐng)先第二名 8％，領(lǐng)先第三名 15%；在 PSNR avg. MSE 準(zhǔn)則測試中，則是領(lǐng)先第二名 6％。而在 PSNR avg. log 和 SSIM 準(zhǔn)則測試中， BVC2.0 編碼器以極微小的差距與阿里、微幀的產(chǎn)品并列第一。
VMAF 準(zhǔn)則測試，測試數(shù)據(jù)越小表示壓縮率越高，成績越好。
PSNR avg. MSE 準(zhǔn)則測試，測試數(shù)據(jù)越小表示壓縮率越高，成績越好。
上圖為 PSNR avg. log 準(zhǔn)則測試，測試數(shù)據(jù)越小表示壓縮率越高，成績越好。
上圖為 SSIM 準(zhǔn)則測試，測試數(shù)據(jù)越小表示壓縮率越高，成績越好。
據(jù)了解，BVC2.0 編碼器從框架到算法搭建完全由字節(jié)跳動先進視頻團隊自研，盡管參與人員少，開發(fā)周期短，但得益于公司在視頻壓縮標(biāo)準(zhǔn)領(lǐng)域的技術(shù)儲備，以及算法方面的創(chuàng)新，最終表現(xiàn)出了更好的壓縮性能。
目前 BVC2.0 編碼器完全基于傳統(tǒng)視頻編碼和優(yōu)化技術(shù)，隨著學(xué)界和業(yè)界越來越多地使用卷積神經(jīng)網(wǎng)絡(luò)等深度學(xué)習(xí)技術(shù)以提高壓縮效率、編碼優(yōu)化和視頻處理能力。字節(jié)跳動先進視頻團隊表示，團隊的相關(guān)領(lǐng)域成果未來將融合在下一版本的 BVC2.0 編碼器中。
帶寬成本大幅降低，畫質(zhì)更清晰，更流暢
未來，BVC2.0 編碼器可應(yīng)用于字節(jié)跳動旗下大部分產(chǎn)品，包括抖音、西瓜視頻、等 App 的視頻類內(nèi)容處理，以及云計算、云游戲等基礎(chǔ)架構(gòu)領(lǐng)域。
字節(jié)跳動也正在計劃將 BVC2.0 編碼器開放給合作伙伴使用。先進視頻團隊的張莉博士表示：「將 BVC2.0 編碼器應(yīng)用到公司業(yè)務(wù)中后，將能夠節(jié)省 20%-50% 的流量帶寬和存儲成本。假設(shè)一年的帶寬成本為 10 億，那么使用 BVC2.0 編碼器有望比目前最優(yōu)的編碼器節(jié)省 2-5 億。」
除了幫助業(yè)務(wù)節(jié)省成本外，對于短視頻行業(yè)的用戶，BVC2.0 編碼器也很有意義。在有限的網(wǎng)絡(luò)帶寬資源條件下，BVC2.0 的轉(zhuǎn)碼能力，可以讓普通用戶獲得更高畫質(zhì)、更流暢的視頻體驗。例如，原來只能看標(biāo)清的用戶，現(xiàn)在可以獲得高清的體驗。
在國內(nèi)視頻編解碼技術(shù)標(biāo)準(zhǔn)領(lǐng)域，字節(jié)跳動也有著很高的貢獻度。2002 年，數(shù)字音視頻編解碼技術(shù)標(biāo)準(zhǔn)工作組（AVS）的成立標(biāo)志著中國視頻標(biāo)準(zhǔn)化工作的正式起步，迄今 AVS 音視頻編碼標(biāo)準(zhǔn)已經(jīng)發(fā)展到第三代。經(jīng)過十幾年的發(fā)展，AVS 視頻編碼標(biāo)準(zhǔn)的壓縮性已經(jīng)實現(xiàn)了大幅提升。作為 AVS 第三代視頻編碼標(biāo)準(zhǔn)的重要技術(shù)貢獻者之一，字節(jié)跳動一直通過組織 AVS3 技術(shù)研討會、分享 AVS3 先進技術(shù)等各種形式向工業(yè)界和學(xué)術(shù)界推廣 AVS 標(biāo)準(zhǔn)。
去年，字節(jié)跳動先進視頻團隊也曾因視頻編碼國家標(biāo)準(zhǔn) AVS 方面的技術(shù)功效，獲得了「2019 年度 AVS 產(chǎn)業(yè)技術(shù)創(chuàng)新獎」，字節(jié)跳動也是該獎項中的唯一一家互聯(lián)網(wǎng)公司。
此外，字節(jié)跳動先進視頻團隊成員也在多個國際標(biāo)準(zhǔn)化工作組中擔(dān)任重要角色，如 VVC、H.265/HEVC、H.264/AVC 等多項標(biāo)準(zhǔn)文本主編及編委等，同時，也是多項多媒體國際標(biāo)準(zhǔn)的重要貢獻者之一，包括視頻編碼標(biāo)準(zhǔn)、系統(tǒng)標(biāo)準(zhǔn)、傳輸協(xié)議、文件格式等。過去兩年間，字節(jié)跳動先進視頻團隊累計遞交了 260 項以上 H.266/VVC 技術(shù)提案，被采納數(shù)量超過 130 項。
張莉博士表示：「視頻編碼優(yōu)化和傳輸是一項重要且非常有挑戰(zhàn)的工作，只有持續(xù)創(chuàng)新，才能保持不斷推動技術(shù)升級。我們希望與行業(yè)一起，為大家提供更好的視頻編碼技術(shù)能力，提升用戶的視頻體驗。」
參考鏈接：https://www.compression.ru/video/codec_comparison/hevc_2020/main_report.html
譯局是36氪旗下編譯團隊，關(guān)注科技、商業(yè)、職場、生活等領(lǐng)域，重點介紹國外的新技術(shù)、新觀點、新風(fēng)向。
編者按：Marc Andreessen十年前說的“軟件蠶食世界”不僅完全正確，而且似乎不僅如此：軟件正在重塑世界。人類世界的運轉(zhuǎn)已經(jīng)無法離開軟件。在浩如煙海的軟件代碼當(dāng)中，哪些對我們起到了關(guān)鍵作用呢？Slate網(wǎng)站邀請了各方人士對那些改變了一切的代碼進行評選，這里篩選出36個代碼片段。如果你有更好的選項，不妨在評論區(qū)留下你的意見。原文作者是Future Tense，標(biāo)題是：The Lines of Code That Changed Everything。鑒于篇幅太長，我們將分三部分刊出，此為第三部分。
人類歷史上最重要的36個代碼片段（一）
人類歷史上最重要的36個代碼片段（二）
年代：1990年代中期
它讓網(wǎng)站最平凡的元素也能酷炫起來。
JSFX.FireSpark.prototype.changeColour=function
{
var colour="";
r2=Math.random*255;
g2=r2;
b2=0;
if(!(r2 | g2 | b2))
{
r2=255;
g2=255;
b2=0;
}
colour="#" + dec2hex(r2) + dec2hex(g2) + dec2hex(b2);
this.setBgColor(colour);
}
Roy Whittle
Douglas Englebart和Bill English在1960年代后期發(fā)明的鼠標(biāo)改變了我們與計算機溝通的方式。盡管使用鼠標(biāo)很直觀，但當(dāng)時的顯示技術(shù)通常無法跟上鼠標(biāo)的快速移動。操作系統(tǒng)開發(fā)人員于是添加了鼠標(biāo)軌跡，也就是瞬時的陰影圖像，顯示出光標(biāo)在之前的位置，從而更易于跟蹤和查找。
在1990年代中期，GeoCities 是第一個提供免費服務(wù)，讓用戶可以輕松創(chuàng)建自己的Web內(nèi)容的公司。GeoCities 所見即所得（WYSIWYG）的編輯器使得創(chuàng)建者可以輕松地拖拽內(nèi)容，添加自定義的代碼段，包括用于定制訪問者看到的鼠標(biāo)軌跡的代碼。在GeoCities的網(wǎng)頁上，你的光標(biāo)可以留下童話般的灰塵、氣泡或小小的萬圣節(jié)蝙蝠的痕跡。這些絢麗的像素是一個時代的縮影，說明我們已經(jīng)能夠自己建立自己的“網(wǎng)絡(luò)空間”——Nikki Stevens，亞利桑那州立大學(xué)博士研究生
年代：1999
讓大家在一個地方就能閱讀《紐約時報》、Gizmodo 以及Garfield Minus Garfield。
http://www.example.com/main.html
http://www.example.com/blog/post/1
維基百科
通過將新聞報道、博客、blawgs（法律博客）、播客以及其它web內(nèi)容形式發(fā)布成標(biāo)準(zhǔn)格式，RSS代碼讓你可以用一種簡單、有效以及高效的方式去消費各種信息來源。在巔峰時期，大概是從2005年Google Reader推出到2013年Aaron Swartz（致力于RSS 1.0開發(fā)的互聯(lián)網(wǎng)自由主義者）不幸去世的這段時間內(nèi)，RSS幾乎就相當(dāng)于在去中心化的互聯(lián)網(wǎng)上發(fā)布的代名詞。盡管Google Reader已經(jīng)不復(fù)存在，但從新聞聚合器到播客應(yīng)用，RSS依舊站在可用互聯(lián)網(wǎng)的最前沿。——David S. Levine，埃隆大學(xué)法學(xué)院副教授
年代：1999
一個數(shù)學(xué)錯誤導(dǎo)致一項任務(wù)失敗
1999年9月23日，NASA的科學(xué)家與價值1.25億美元的火星氣候軌道器失去了聯(lián)系。經(jīng)過調(diào)查，確定了失聯(lián)的原因：一家承包商用英制單位給軌道器寫了程序，但是NASA的軟件用的卻是公制。就因為兩段代碼之間簡單的溝通錯誤，導(dǎo)致軌道器飛到了未知的地方。
很容易會把這種公制——英制的錯誤當(dāng)作意外錯誤而一筆勾銷，但這說明了當(dāng)今軟件互聯(lián)的世界是多么的脆弱。所有的連接技術(shù)（電話、宇宙飛船、機器人榨汁機等等）都要靠接口來定義與它者的通信方式。哪怕是最小的差錯也會導(dǎo)致混亂。——Charles Duan
年代：大約2000–2001年
開辟了無人機戰(zhàn)爭的先河。
“捕食者”無人機早期版本的武器化是個標(biāo)志性的時刻，不僅在技術(shù)史上如此，在軍事和政治史上亦然。現(xiàn)在，無人系統(tǒng)已經(jīng)遍布整個戰(zhàn)場，重塑了士兵的作戰(zhàn)方式，甚至改變士兵的來源。捕食者的武器化也使得美國進入了“無人機戰(zhàn)爭”的時代。而且，隨著鑒于機器人日益自動化、武器化引起的問題，我們現(xiàn)在才剛剛開始。一個簡單的程序可能就會帶來法律上、道德上甚至是生存性的問題。——PW Singer，《連線戰(zhàn)爭：21世紀的機器人革命與沖突》作者
年代：2002
為技術(shù)（和貓）在現(xiàn)實世界的移動建立了新途徑
(define-behavior (bounce
:start-when (or (bump?)
bounce-trigger? )
:abort-when (bump-edge?)
:onetime? t
)
)
iRobot
你永遠也不會忘記自己的第一臺Roomba：我的大概是在17年前在一個朋友家。當(dāng)它在房子里面嗡嗡地由著自己的性子轉(zhuǎn)來轉(zhuǎn)去時，我正坐在沙發(fā)上哈哈大笑。這是機器人革命的曙光，一場看起來很蠢但是又很認真的革命。（跟炸彈清理機器有著一樣DNA的機器人正在數(shù)百萬個家庭里面吸塵，這一點著實讓人吃驚。）從那以后，別人再也難以復(fù)制它的成功。Roomba證明，盡管我們的注意力重心已經(jīng)開始向硬件傾斜（比如波士頓動力怪異的膝蓋向后彎、會開門的機器狗）上，但軟件對于一件產(chǎn)品的廣泛采用可能更為重要。阿西莫夫化的iRobot并沒有創(chuàng)造出第一個真空吸塵機器人，但是Roomba成為一個必備的利基產(chǎn)品不是因為它吸塵效果好，而是因為它在房間里面的導(dǎo)航效果不錯。就像成千上萬的小貓視頻可以證明那樣，在現(xiàn)代計算時代，幾乎沒有什么東西能比看著Roomba撞到桌腿、轉(zhuǎn)圈一周然后前進更令人滿足的了。——Lowen Liu，Slate
年代：約2003年
令手機網(wǎng)絡(luò)成為可能的解決方案
[~, b_user]=max(drc(i, :)/_avg_thruput(i, :));
avg_thruput(i+1, :)=(i/(i+1))*avg_thruput(i, :);
avg_thruput(i+1, b_user)=(i/(i+1))*avg_thruput(i, b_user)+drc(i, b_user)/(i+1);
“使用路徑分集公平地最大化吞吐量的定向發(fā)射機多接收機系統(tǒng)”，美國專利第6444990號，2002年9月10日
任何時候在任何一個地方，手機的數(shù)量通常都要比基站數(shù)量多。如果不進行調(diào)解的話，所有的傳輸都會相互干擾并阻礙信息的可靠接收。因此，基站需要解決優(yōu)先級問題：確保所有用戶都能完成通話，同時還要考慮到在嘈雜環(huán)境的用戶需要賦予更多資源才能得到同樣服務(wù)質(zhì)量這一點。解決方案？要在個體用戶需求與網(wǎng)絡(luò)整體性能之間進行折衷。比例公平調(diào)度可確保所有用戶至少享有最低級別的服務(wù)，同時最大程度地提高總的網(wǎng)絡(luò)吞吐量。這是通過將較低的優(yōu)先級賦予預(yù)期需要更多資源的用戶來實現(xiàn)的。僅三行代碼就讓全球所有的3G和4G無線網(wǎng)絡(luò)正常工作。——Lav Varshney
年代：2008年
激發(fā)大家對一種貨幣的信心的代碼，沒有它就沒有這種貨幣
double AttackerSuccessProbability(double q, int z)
{
double p=1.0 - q;
double lambda=z * (q / p);
double sum=1.0;
int i, k;
for (k=0; k {
double poisson=exp(-lambda);
for (i=1; i poisson *=lambda / i;
sum -=poisson * (1 - pow(q / p, z - k));
}
return sum;
}
中本聰
不管你是比特幣的布道者還是懷疑者，或者不大確定它是什么，你大概都知道這可是個大事物。比特幣本身已經(jīng)獲得了數(shù)千億美元的直接投資，但是也許更重要的是，其基礎(chǔ)的技術(shù)原理，也就是區(qū)塊鏈，似乎有著無窮無盡的應(yīng)用，從確保民主選舉到結(jié)束非自愿的性接觸等等都在它的應(yīng)用范圍。
這一切始于2008年，當(dāng)匿名的中本聰發(fā)表了一份白皮書，宣布要推出比特幣。上述代碼就是實現(xiàn)的一部分，這些代碼的作用是計算出攻擊者接管比特幣區(qū)塊鏈的可能性極小。這里的數(shù)學(xué)讓世界相信，由不可靠的人組成的系統(tǒng)仍然可以信任，這為至少2777種其他加密貨幣的創(chuàng)建鋪平了道路。——Elena Botella
年代：2008年10月至2009年
把受感染的計算機變成惡意的機器人大軍，同時又保護其他的一些計算機
; BOOL __cdecl HasUkrainianLocale
push ebx
mov ebx, ds:GetKeyboardLayoutList
push ebp
push esi
xor ebp, ebp
push ebp
push ebp
call ebx
mov esi, eax
cmp esi, ebp
jz short loc_37680A
這段代碼是安全研究人員Tillmann Werner和Felix Leder 編寫的，后來還進行了功能等效性測試，為的是理解和對抗Conficker 蠕蟲。
Tillmann Werner和Felix Leder
十年前，感染Conficker的計算機數(shù)量多達1500萬臺。這是一種利用Windows操作系統(tǒng)的漏洞的病毒。這種病毒雖然令人恐懼，但也因為它的老辣而備受推崇：它會邀請每一臺計算機加入到龐大的僵尸大軍，等候命令下達，還會阻止受感染的計算機打開安全程序或下載可以清除病毒的補丁程序。其最早版本還有一個非常有趣且很能說明問題的怪癖：如果駐留在任何使用烏克蘭鍵盤或烏克蘭IP地址的系統(tǒng)就會自毀。多年后，對該病毒進行逆向工程的主管部門和研究人員得出結(jié)論，Conficker的開發(fā)者確實是烏克蘭人，他們這樣設(shè)計病毒是為了避免違反自己國家的法律。幸運的是，這些黑客一直都沒有動用過那支僵尸大軍來作惡，截至到2018年，估計仍有35萬臺計算機感染這種病毒，這提醒我們嫻熟的程序員要想發(fā)動國際攻擊，有選擇地對用戶造成破壞可以是多么的容易。——Jane C. Hu
年代：2009
它催生了監(jiān)視經(jīng)濟。
{"__typename":"PageLikeAction","action_type":"LIKE","label":{"text":"Like"}
2019年9月的Facebook.com 網(wǎng)站
Facebook把點“贊”按鈕當(dāng)作向世界展示我們喜歡辛普森一家或炸薯條的一種手段來兜售。。但實際上，它利用了我們的認知偏見，以及設(shè)計的力量，去誘使我們分享更多的信息。由于有了前面Sara Wachter-Boettcher介紹過的像素跟蹤，它跟蹤我們在互聯(lián)網(wǎng)的行蹤，收集有關(guān)我們?yōu)g覽習(xí)慣的數(shù)據(jù)。Facebook拿走這些信息，再把自己的行為定向廣告算法賣給廣告主。如果一家戶外用品公司想要做廣告，F(xiàn)acebook可以鎖定那些以前“贊”過遠足的文章，訪問過露營網(wǎng)站以及有戶外朋友的人。當(dāng)這些用戶“贊”了相關(guān)公司的廣告時，這些信息就會反饋會定向廣告算法里面。這樣一來，監(jiān)視和商業(yè)操縱就形成了周而復(fù)始的循環(huán)。這一切都是因為一個小小的藍色大拇指。——Ari Ezra Waldman，紐約法學(xué)院教授
年代：2009年左右
默認開啟安全通道來保護網(wǎng)站安全
Strict-Transport-Security: max-age=31536000; includeSubDomains
Mozilla開發(fā)人員指南
當(dāng)你通過普通HTTP協(xié)議將信息發(fā)送到網(wǎng)站時，這是會泄漏的——別人可能會攔截這段信息并竊聽你的信用卡、健康信息以及伴侶的寵物名什么的。HTTPS可以加密你的流量，避免別人窺探信息，但是很長一段時間以來，使用這種更先進的協(xié)議一直都是可選的。因此就有了HTTP Strict Transport Security，此這種安全措施可確保從一開始往來該網(wǎng)站的流量就是加密的。如果你想要訪問http://google.com，它會自動將你重定向到https://google.com。這就是HSTS的作用。
HSTS還沒有普及：估計只有11.1％的網(wǎng)站用到。但2015年春天，重要一刻降臨，美國聯(lián)邦政府和行業(yè)合作伙伴對19個政府領(lǐng)域?qū)嵤〩STS，其中包括Whitehouse.gov，AIDS.gov和donotcall.gov。此后不久，所有聯(lián)邦機構(gòu)均要求采用該標(biāo)準(zhǔn)。——Rusty D. Pickens，奧巴馬政府白宮前代理新媒體總監(jiān)
年代：2012年編寫，2014年被發(fā)現(xiàn)
計算史上傳播最廣、危害最大的安全漏洞之一
buffer=OPENSSL_malloc(1 + 2 + payload + padding);
bp=buffer;
/* Enter response type, length and copy payload */
*bp++=TLS1_HB_RESPONSE;
s2n(payload, bp);
memcpy(bp, pl, payload);
bp +=payload;
/* Random padding */
RAND_pseudo_bytes(bp, padding);
來自Naked Security
2014年，安全研究人員在OpenSSL（一個非常受歡迎的開源庫）中發(fā)現(xiàn)了一個漏洞，大約有三分之二的網(wǎng)站（包括DropBox ，Twitter，Yahoo和GitHub）都用到它——用于在兩臺計算機之間進行在線通信。Heartbleed使得犯罪分子可以通過影響數(shù)百萬臺設(shè)備的緩沖區(qū)讀取漏洞來竊取未加密的機密信息，包括憑據(jù)和加密密鑰等。這讓大家注意到了依靠開源軟件來實現(xiàn)關(guān)鍵安全功能所帶來的風(fēng)險，以及識別已被使用多年的代碼漏洞的挑戰(zhàn)。從更積極的意義上來說，Heartbleed的發(fā)現(xiàn)也引發(fā)了迅速而有效的全球反應(yīng)，包括在全球范圍內(nèi)進行的協(xié)調(diào)宣傳和補救工作，其力度和廣度均遠遠超出了以前針對早期漏洞的許多同類行動。-塔夫茨大學(xué)助理教授Josephine Wolff
年代：2017年推出
軟件錯誤，加上企業(yè)的貪婪，導(dǎo)致數(shù)百人喪生，以及大批飛機停飛。
2018年10月，獅航610航班起飛后不久就發(fā)生了一次似乎非常怪異的事故，然后墜入海中。波音向公眾保證飛機是安全的，并表示需要進行更多的飛行員培訓(xùn)以及“軟件升級”。但是僅僅四個月后，埃塞俄比亞航空的一名飛行員抬升機頭的努力做了20次，但飛機的自動系統(tǒng)仍然把機頭往下推。起飛后的幾分鐘內(nèi)，機上所有人員均告死亡。作為對事故的響應(yīng)，全球的民航當(dāng)局這這一型號的飛機都停飛了。調(diào)查顯示，墜機事故是因為737 Max的設(shè)計引起的，尤其是鮮為人知，了解程度不高的軟件，可能會強制飛機反復(fù)做俯沖動作。——技術(shù)史學(xué)家，《寫入程序的不平等》作者Mar Hicks
譯者：boxi。
*請認真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
