python使用深度神經網絡實現識別暹羅與英短，首發于Cobub。

觸發： 提醒人們采取下一步行動

觸發是上癮模型的第一階段，它可促使用戶觸發行動。觸發分為兩種：外部觸發和內部觸發。讓你產生習慣性依賴的那些產品往往是外部觸發最先發揮作用，它通過將信息滲透在你生活的方方面面來引導你采取下一步行動，例如電子郵件、網站鏈接，或是手機上的應用程序圖標。
使用外部觸發僅僅是邁出的第一步，內部觸發則是核心，它通過用戶記憶存儲中的各種關聯來提醒他們采取下一步行動，負面情緒往往可以充當內部觸發。開發習慣養成類產品的設計者需要揣摩用戶的心理，了解那些有可能成為內部觸發的各種情緒，并且要知道如何利用外部觸發來促使用戶付諸行動。

行動：人們在期待籌賞時的直接反應

觸發之后就是行動。如果他們沒有付諸行動，觸發就未能生效。斯坦福大學的福格博士認為，要讓人行動起來（Behave），三個要素必不可少：動機（M）、能力（A）、觸發（T）。用公式來表示，就是B=MAT。
觸發提醒你采取行動，而動機則決定你是否愿意采取行動。用戶產生使用產品的動機是基于人對于快樂的追求，對痛苦的逃避；對希望有追求，對恐懼有逃避。又因為人都渴望被認同，討厭被排斥。所以，只要你的產品能給用戶快樂，希望和認同，就相當于給了用戶行動的動機。
有了內心的“癢”（觸發），有了想撓癢癢的意愿（動機），還需要用戶能輕松“撓得到”。產品使用的難易程度會直接影響用戶對該產品的使用率。要想成功地簡化某個產品，我們就必須為用戶的使用過程掃清障礙。福格博士總結了影響任務難易程度的6個要素：完成這項活動所需的時間、經濟投入、體力、腦力、他人對該項活動的接受度，以及該項活動與常規活動之間的匹配程度或矛盾程度。在設計產品時，要弄清楚是什么原因阻礙了用戶完成這一活動。用戶究竟是沒時間，還是沒錢？是忙碌一天之后不想再動腦筋，還是產品太難操作？要贏得人心，你首先得讓自己的產品便捷易操作，讓用戶能夠輕松駕馭。
因此，要增加預想行為的發生率，觸發要顯而易見，行為要易于實施，動機要合乎常理。

多變的籌賞：滿足用戶的需求，激發使用欲

在第三階段，你的產品會因為滿足了用戶的需求而激起他們更強烈的使用欲。驅使用戶采取行動的，并不是酬賞本身，而是渴望酬賞時產生的那份迫切需要。上癮模型與普通反饋回路的區別在于，它可以激發人們對某個事物的強烈渴望。我們身邊的反饋回路并不少見，但是可以預見到結果的反饋回路無助于催生人們的內心渴望。
給產品“安裝”多變的酬賞，是公司用來吸引用戶的一個制勝法寶。從根本上講，多變的酬賞在吸引用戶的同時，必須滿足他們的使用需求。那些能秒殺用戶的產品或服務包含的酬賞往往不止一種。那些在多變性上不具備優勢的產品必須經常更新換代才能跟上時代的步伐。

社交籌賞

從產品中通過與他人的互動而獲取的人際獎勵。比如，小伙伴結婚的時候，發個朋友圈，收到了一波又一波的祝福，這就屬于社會化獎勵。我們喜歡我們的“圈子”，享受來自別人的點“贊”，期待他人的“評論”。社交酬賞會讓用戶念念不忘，并期待更多。

獵物獎勵

獲得資源或信息。比如微博，微博一開始吸引人們，是因為人們只要重復一個“滾動”的行為，就能搜索到自己喜歡的有趣信息，這就是狩獵獎勵機制，內容的多變性為用戶提供了不可預測的誘人體驗。

自我獎勵

體驗到的操控感、成就感和終結感。游戲中的“升級”影響的是自我對精通和能力的評價，升級、獲取特權等游戲規則都可以滿足玩家證明自己實力的欲望。甚至是平淡無奇的電子郵件，郵箱中未讀郵件的數量對很多人而言就像是任務，一項有待他們去完成的任務。
多變的酬賞是產品吸引用戶的一個有力工具。洞悉人們為何會對產品形成習慣性依賴，這有助于設計者投其所好地設計產品。

投入：通過用戶對產品的投入，培養“回頭客”

但是，僅僅依靠投其所好并不足以使產品在用戶心目中站穩腳跟。
一個一夜爆紅的產品，往往都有著很好的觸發，也有著易操作的行動，還有著豐富的社交酬賞。但是如果沒有后續引發長時間“投入”的能力，爆款也會隨著時間的推移而失去用戶的注意力。
事實證明，我們對事物的投入越多，就越有可能認為它有價值，也越有可能和自己過去的行為保持一致。最后，我們會改變自己的喜好以避免發生認知失調。這是上癮模型的最后一個階段，也是需要用戶有所投入的一個階段。投入階段與客戶對長期酬賞的期待有關，與及時滿足無關。
當用戶為某個產品提供他們的個人數據和社會資本，付出他們的時間、精力和金錢時，投入即已發生。話說回來，投入并不意味著讓用戶舍得花錢，而是指用戶的行為能提升后續服務質量。添加關注，列入收藏，壯大虛擬資產，了解新的產品功能，凡此種種，都是用戶為提升產品體驗而付出的投入。這些投入會對上癮模型的前三個階段產生影響，觸發會更易形成，行動會更易發生，而酬賞也會更加誘人。
你一定會說，一切皆有套路，那么知道了套路，如何反套路呢？
作為產品經理的你，可以利用上癮模型來比照一下自己的產品：
用戶真正需要什么？你的產品可以緩解什么痛苦？（內部觸發）
你靠什么吸引用戶使用你的產品？（外部觸發）
期待酬賞的時候，用戶可采取的最簡單的操作是什么？如何使該操作最簡化？（行動）
用戶是滿足于所得酬賞，還是想要更多酬賞？（多變的酬賞）
用戶對你的產品做出了哪些“點滴投入”？這些投入是否有助于加載下一個觸發，使產品質量在使用過程中獲得提升？（投入）
如果你是用戶，了解到這些“設計套路”，你就可以采取有針對性的“反設計、反套路”。檢視自己日常的一舉一動：哪些情景下，你會不自覺地點開某個App？什么時候最容易刷手機？其背后的驅動力是什么，是想打發時間，還是想舒緩壓力？通通記錄下來。找到自己的行為規律和內在驅動因素，才能有意識地掌控自己的行為。

文/ 小歐 微信公眾號：中歐國際工商學院
本文改編自《上癮：讓用戶養成使用習慣的四大產品邏輯》一書

你的手為什么就是管不住要去點開它？，首發于Cobub。

1 Ambari簡介

Apache Ambari項目的目的是通過開發軟件來配置、監控和管理hadoop集群，以使hadoop的管理更加簡單。同時,ambari也提供了一個基于它自身RESTful接口實現的直觀、簡單易用的web管理界面。
Ambari允許系統管理員進行以下操作：
1. 提供安裝管理hadoop集群;
2. 監控一個hadoop集群;
3. 擴展ambari管理自定義服務功能.

2 集群所需基礎條件

2.1 操作系統的需求

? Red Hat Enterprise Linux (RHEL) 版本5.x 或者 6.x (64位) ；
? CentOS版本5.x、6.x (64位) 或7.x；
? Oracle Linux版本5.x 或者6.x (64位) ；
本文檔選擇的是CentOS版本 6.5 (64位) ；

2.2 系統基礎軟件的需求

在每一臺主機上都要安裝以下軟件：
（1） yum和rpm (RHEL/CentOS/Oracle Linux)；
（2）zypper（SLES）；
（3）scp，curl，wget；

2.3 JDK的需求

Oracle JDK 1.7.0_79 64-bit (默認)
OpenJDK 7 64-bit (SLES不支持)

3 安裝各項軟件前的先決條件

3.1 ambari和監控軟件所需條件

安裝ambari之前，為了保證ambari各項服務和各項監控服務的正常運行，根據操作系統的不同，需要確定一些已經安裝的軟件的版本，以下列出的軟件版本必須符合要求。即：如果現有的系統上有以下軟件，版本必須與下面列出的版本完全一致，如果沒有的話安裝程序會自行安裝。
圖表3-1軟件先決配置表

3.2 Ambari與HDP版本兼容性

由于軟件版本的升級，各版本之間由于版本之間的兼容性可能會導致一些問題。
表格 3-2 版本兼容性

4 安裝實例說明

本文所選擇的系統與軟件版本，如下表所示：
表格 4-1系統與軟件版本

4.1 安裝Ambari前的操作系統準備

4.1.1 配置主機名
Ambari配置集群信息的時候是通過全限定主機名來確定集群中的機器信息的，所以必須確保主機名無誤。
4.1.2 配置集群信息
在每一臺機器的hosts文件上都要做映射配置，命令如下：
# vi /etc/hosts
然后添加如下內容：
表格 4-2 ip映射信息表

4.1.3 配置ssh免密碼互通
首先，在主節點和其他節點上都執行以下命令，以確保每臺機器都可產生公鑰。

然后一路回車即可.然后將每個節點的公鑰組成一個新的authorized_keys文件,然后將其分發到每個節點中.從而，完成了各個節點的免密登錄操作.
4.1.4 配置NTP時間同步
首先在主節點上做如下操作：
(1) 安裝時間服務器ntp:
#yum install ntp
(2) 修改ntpd配置文件
(3) 開啟時間同步服務器
#sevrice ntpd start
(4) 在其他各個從節點做相同操作,至此ntp同步完成
4.1.5關閉selinux
永久關閉SELinux
# vi /etc/selinux/config
將SELINUX=enforcing改為SELINUX=disabled
重啟生效，重啟命令為：
# reboot
4.1.6關閉iptables防火墻
永久關閉（需要重啟）
# chkconfig iptables off
暫時關閉防火墻服務(需要重啟防火墻)
service iptables stop
查看防火墻狀態
# chkconfig –list|grep iptables
提示：Linux下的其它服務都可以用以上命令執行開啟和關閉操作
重啟生效，重啟命令為：
# reboot

4.2 創建yum本地源

首先檢驗主節點是否安裝httpd服務器，命令如下：
rpm -qa |grep httd
若沒有，則安裝，命令如下：
#yum install httpd
啟動httpd
#service httpd start
chkconfig httpd on
對文件夾與子文件夾內所有文件授予同一權限，命令如下：
chmod –R ugo+rX /var/www/html
打開網絡
vim /etc/sysconfig/network-script/ifcfg-eth0
修改為onboot=yes
安裝成功之后，Apache工作目錄默認在/var/www/html。
配置：
檢查端口是否占用，Apache http服務使用80端口
[root@master ~]$ netstat -nltp | grep 80
如果有占用情況，安裝完畢之后需要修改Apache http服務的端口號：
[root@ master ~]$ vi /etc/httpd/conf/httpd.conf
修改監聽端口，Listen 80為其他端口。
將所下載的安裝文件放在/etc/www/html下，然后啟動
[root@ master ~]$ service httpd start
可以在瀏覽器中查看http://master 看到Apache server的一些頁面信息，表示啟動成功。

5 完全離線安裝Ambari前的準備

離線安裝跟在線安裝的區別在于yum所使用的倉庫的位置不同，即把遠程的倉庫中的安裝包等資源拷貝一份兒放在本地，然后在yum倉庫包文件夾中創建這些資源的本地倉庫包，即可按照在線安裝的方式進行安裝就行了。不過離線安裝需要先解決Ambari的rpm包的依賴性問題，即首先要確保已經安裝了postgresql8.4.3，或者有本地postgresql8.4.3倉庫。

5.1 先決條件

Ambari的離線安裝，需要使用yum，如果是新安裝的操作系統，可能缺少很多必要的條件，以下表格按照從前往后的順序，依次說明，如果已經實現了某些條件，跳過那些條件即可。
因操作系統中本身自帶軟件的復雜性，如在安裝中提示有其他所需軟件或提示現有軟件升級，按照提示解決即可.

5.2 建立本地資源庫

在集群內部某臺機器上安裝http服務即可，然后將提供的tar包或者rpm包放置到那臺機器上的/var/www/html目錄（Apache默認目錄）下解壓即可，最好在這個目錄下新建一個目錄，將所有的ambari的tar包和HDP及HDPUTIL的tar包都放置進去并解壓，如果機器沒有手動安裝PostgreSQL，將提供的上述軟件的軟件包一并放入到本地資源庫中即可。

5.3 設置yum不檢查gpg密鑰

經檢測離線安裝Hadoop集群時會因為yum檢查要安裝的軟件的gpg密鑰而導致錯誤，此時可通過關閉系統的yum gpg檢查來規避錯誤
# vi /etc/yum.conf
設置gpgcheck屬性值為0即可
gpgcheck=0

5.4 安裝ambari服務

# yum –install ambari-server

5.5 ambari設置

# ambari-server setup
運行過后則會出現是否進入ambari-server守護進程,選擇jdk,配置數據庫等信息,可根據系統自身需要進行選擇.
當出現“Ambari Server ‘setup’ completed successfully”，則說明Ambari-server配置成功。需要說明的是，此次安裝選擇的數據庫是PostgreSQL數據庫，其中用戶、數據庫等都是提前默認好的；若選擇MySQL數據庫，則需要在安裝Ambari-server之前建好用戶、賦予權限、建好數據庫等等操作。
然后啟動ambari-server,最后根據需要安裝hadoop生態中的各項服務.

自定義service服務

1 ambari自定義擴展service

從第一部分可知,ambari具有進行二次開發的功能,主要工作就是將自研的組件等集成到ambari中,并對其進行管理監控.本文主要以集成redis為例進行講述.
首先,由于service都是隸屬于stack的,所以要決定自定義一個service屬于哪個stack.,又因為已經安裝了HDP2.5.0具有stack,所以,本文將自定的service放置在HDP2.5.0的stack下.新建service名為:redis-service,其中包含結構圖如下圖所示:

其中configurate中的xml文件主要安裝完成配置該模塊的調用,package中主要問控制service生命周期的python文件,metainfo.xml文件則主要問定義service的一些屬性,metrics.json與widgets.json控制著service的界面圖表顯示.
其中metainfo.xml實例如下:

 2.0
 
 
 REDIS-SERVICE
 Reids
 My Service
 1.0
 
 
 MASTER
 Master
 MASTER
redis
 1
 
 
 PYTHON
 5000
 
 
 
 SALVE
 Slave
 SLAVE
 1+
 
 
 PYTHON
 5000
 
 
 
 
 
 any
 
 
 
 

其次,需要創建 Service 的生命周期控制腳本master.py 和 slave.py。這里需要保證腳本路徑和上一步中 metainfo.xml 中的配置路徑是一致的。這兩個 Python 腳本是用來控制 Master 和 Slave 模塊的生命周期。腳本中函數的含義也如其名字一樣：install 就是安裝調用的接口；start、stop 分別就是啟停的調用；Status 是定期檢查 component 狀態的調用。其中master.py與slave.py的模板為:
Master.py

class Master(Script):
 def install(self, env):
   print "Install Redis Master"
 def configure(self, env):
 print "Configure Redis Master"
   def start(self, env):
 print "Start Redis Master"
   def stop(self, env):
   print "Stop Redis Master"
   def status(self, env): 
 print "Status..."
if __name__ == "__main__":
  Master().execute()

Slave.py

class Slave(Script):
 def install(self, env):
 print "Install Redis Slave"
 def configure(self, env):
 print "Configure Redis Slave"
 def start(self, env):
 print "Start Redis Slave"
 def stop(self, env):
 print "Stop Redis Slave"
 def status(self, env): 
 print "Status..."
if __name__ == "__main__":
 Slave().execute()

再次,將redis的rpm安裝文件放入到HDP安裝包的/var/www/html/ambari/HDP/centos6/目錄下.
再次,重啟ambari-server, 因為 Ambari Server 只有在重啟的時候才會讀取 Service 和 Stack 的配置。命令行執行：ambari-server restart.
最后，登錄 Ambari 的 GUI，點擊左下角的 Action，選擇 Add Service。如下圖：

此時就可以在安裝service列表中看到Redis服務了.然后檢驗該服務是否安裝成功.

2 ambari實現自定義擴展service界面顯示

在第二章的第一節中service自定義中提及metircs.json與widget.json時, 其中Widget 也就是 Ambari Web 中呈現 Metrics 的圖控件，它會根據 Metrics 的數值，做出一個簡單的聚合運算，最終呈現在圖控件中。Widget 則進一步提升了 Ambari 的易用性，以及可配置化。Widget 是顯示 AMS 收集的 Metrics 屬性.
此處緊接著上節,其中metrics.json模板為:

{
  "REDIS-MASTER": {
    "Component": [
      {
        "type": "ganglia",
        "metrics": {
          "default": {
            "metrics/total_connections_received": {
              "metric": "total_connections_received",
              "pointInTime": true,
              "temporal": true
             },
           "metrics/total_commands_processed": {
             "metric": "total_commands_processed",
             "pointInTime": true,
             "temporal": true
             },
           "metrics/used_cpu_sys": {
              "metric": "used_cpu_sys",
              "pointInTime": true,
              "temporal": true
            },
           "metrics/used_cpu_sys_children": {
             "metric": "used_cpu_sys_children",
             "pointInTime": true,
             "temporal": true
            }
            }
            }
      }
      ]
      }
      }

widget.json為:

{
  "layouts": [
    {
      "layout_name": "default_redis_dashboard",
      "display_name": "Standard REDIS Dashboard",
      "section_name": "REDIS_SUMMARY",
      "widgetLayoutInfo": [
        {
         "widget_name": "Redis info",
         "description": "Redis info",
         "widget_type": "GRAPH",
         "is_visible": true,
      "metrics": [
         { 
          "name": "total_connections_received",
          "metric_path": "metrics/total_connections_received",
          "service_name": "REDIS",
          "component_name": "REDIS-MASTER"
         } 
         ],
      "values": [
         {
          "name": "total_connections_received",
          "value": "${total_connections_received}"
         }
         ],
      "properties": {
        "graph_type": "LINE",
        "time_range": "1"
       }
       }
       }

至此,重啟ambari-service,命令如下:

ambari-server restart

3 數據采集及發送

利用shell腳本將redis運行信息數據采集并一次性發送到metrics collector中,腳本如下所示:

#!/bin/sh
url=http://$1:6188/ws/v1/timeline/metrics
while [ 1 ]
do
total_connections_received=$(redis-cli info |grep total_connections_received:| awk -F ':' '{print $2}')
total_commands_processed=$(redis-cli info |grep total_commands_processed:| awk -F ':' '{print $2}')
millon_time=$(( $(date +%s%N) / 1000000 ))
json="{
 \"metrics\": [
 {
 \"metricname\": \"total_connections_received\",
 \"appid\": \"redis\",
 \"hostname\": \"localhost\",
 \"timestamp\": ${millon_time},
 \"starttime\": ${millon_time},
 \"metrics\": {
 \"${millon_time}\": ${total_connections_received}
 }
 },
 {
 \"metricname\": \"total_commands_processed\",
 \"appid\": \"redis\",
 \"hostname\": \"localhost\",
 \"timestamp\": ${millon_time},
 \"starttime\": ${millon_time},
 \"metrics\": {
 \"${millon_time}\": ${total_commands_processed}
 }
}
 ]
}"
echo $json | tee -a /root/my_metric.log
curl -i -X POST -H "Content-Type: application/json" -d "${json}" ${url}
sleep 3
done

運行如下命令（這里要注意的是參數 1 是 Metrics Collector 的所在機器，并不是 Ambari Server所在的機器）：
./metric_sender.sh ambari_collector_host total_connections_received redis
如果過程不出意外,等待2-4分鐘界面上即有數據顯示.通過上面的操作，可以實現將ambari沒有納入到監控管理的軟件進行管理監控。

Ambari安裝及自定義service初步實現，首發于Cobub。

厘清這5個W，我們推送的消息就是用戶所需要的！

1. Why: 我們為什么要推送這條消息？

“為什么”總是放在首位，每條推送消息都要有清晰的目標——讓用戶首次登陸還是讓用戶進行升級體驗？我們不僅要知道推送消息的目標，還需要明確我們期望從用戶那里獲得哪些行為數據。這些行為數據用來衡量推送消息對用戶造成的影響。例如，在用戶首次登錄某職場社交APP后，會收到如下圖的消息，這就是我們為了讓用戶完善個人資料而進行的推送。

2. What：我們要推送什么樣的內容？

推送消息的內容具有以下三個特點：

（1）具有針對性：

有時候一些小細節也能發揮出大作用。還是上面的例子，我們在給用戶推送歡迎消息的時候，在消息前加上用戶的名字，“Hi, XXX，歡迎…”，而不是籠統的直奔主題：“歡迎······…”，加上名字會讓用戶感覺更親切。

（2）確保相關性和及時性：

推送消息必須及時且和用戶高度相關。以網易新聞為例， 推送給用戶的是南京明晨的天氣消息，地理位置體現了相關性，此消息為周五下午推送，為用戶周六出行計劃給予參考提醒，時間恰到好處。

（3）準確快速地直達用戶痛點：

用戶的時間很寶貴，我們推送的消息一定要讓用戶獲得最大價值。不要給用戶推送垃圾消息，或者與用戶需求不相匹配的消息。例如，給沒有車的用戶推送代駕的消息。

3. Who: 我們要給誰推送消息？

推送消息對象不能一刀切，我們需要通過用戶行為數據對用戶進行分群管理，精細化運營。說到用戶行為，這里推薦幾個比較常用的用戶行為分析平臺，如：友盟、百度統計等。但這些SaaS平臺也有問題，原始數據做導出較為困難，自己產品的數據卻不能被我們自己擁有。推薦國內的開源私有化部署方案Cobub Razor，數據私有，后臺搭建也較為簡單。
不同的推送消息，接收對象也不同。
我們根據用戶的行為習慣、興趣偏好等不同，從用戶的需求出發，提供個性化的消息推送。例如一些音樂類APP針對用戶聽音樂的不同風格、喜愛的歌星以及收藏的歌單等推送相關的更新提醒，這樣的精準推送大大提高了用戶打開消息的比例。

4. 我們什么時候推送消息？

（1）一天中的時間：

可以選擇用戶空閑時間，如早上上班前，中午吃飯時，晚飯后，具體選擇哪個推送時間段，可以根據用戶使用應用的時段來確定，總之不要在用戶忙碌或者休息時打擾用戶。

某金融app用戶使用時段

（2）推送頻率：

推送頻率過高會導致兩種結果——用戶點開推送消息后立馬關掉，或者用戶直接將消息忽略掉，看都不看一眼。推送頻率的多少要根據應用的類型而具體確定，一般來講，社交類App可每日推送，資訊類可一周3-4次、工具類一周1-2次。次數不宜過多，否則用戶不但不會打開，而且很可能關掉消息推送，甚至卸載應用。

（3）當地時間：

推送消息需要根據用戶的當地時間確定，這就需要我們根據用戶所在的地理位置來確定——如果你的用戶來自全球各地，那么北京時間下午四點的時候華盛頓是凌晨四點。如果我們統一以北京時間來推送消息，華盛頓的用戶就會被打擾。

5. Where: 我們在什么場景下推送消息？

推送場景也會影響推送消息產生的效果。我們需要考慮推送消息到達時用戶在哪里，他在干什么，或者用戶收到推送消息時用的什么設備等。
我們作為用戶每天都在接收著大量的推送，比如打車app會在周五下班時間段為我推送快車優惠券已入賬等消息；團購類app會在就餐時間推送給我附近餐廳的團購信息。如果用戶收到推送消息時處于被干擾的狀態，那么用戶就不會用心查看推送消息并采取我們期望的行動。

應用內的消息是根據用戶行為來推送，所以相對來說效果會更好一些。不管用戶吃飯、躺沙發，也不管用戶在PC端、移動端，只要我們清楚了解用戶行為，根據他們的行為推送相關消息，用戶就有很大可能采取我們期望的行動。

總結

完美的推送消息必須預先定義5W。通過5W，明確我們推送消息的目標、內容、對象、推送時間和場景，讓用戶看到推送消息帶給用戶的價值。推送是最好的用戶觸點，做一款貼心的符合用戶習慣的產品比天天掛在口頭的用戶體驗更為重要。

完美消息推送的5W法則，首發于Cobub。

這幾年數據分析迅速發展，我們也做了一個微數據分析工具。該產品已成功運行三年，滿足日活百萬的企業。產品結構很簡單，用世上最簡單的語言php，最普遍的數據庫mysql，服務器可以選擇apache也可以選擇nginx，一切看你自己的喜好。

一、微服務架構圖

整個流程圖：
1、SDK上傳數據到服務器，如果安裝redis做緩存，數據會最先進到redis，然后定時抽取數據到DB服務器。有了redis可以大大提高并行數據處理能力。
2、數據庫收集原始數據，存儲過程將數據按照不同維度統計各個指標數據，同時將數據匯總表。
3、前臺報表展示，實時報表、小時報表和天報表數據展示。最好做到讀寫分離。

二、功能架構

功能架構主要包括功能、角色和權限三部分。功能是企業服務，用戶使用的每一個功能，就是企業的每一個服務。角色是用戶操作的歸類，功能與角色的對應關系及權限。了解系統架構的現狀，從功能架構開始。

三、應用架構

應用架構的內容包括現有架構圖、web應用現狀和接口架構。其中，接口是應用層面的關鍵，它是程序之間交互的部分。
主要包括clientdata、usinglog、event和errorlog等接口。
SDK通過接口定時發送數據到后臺。
應用架構羅列出前后端調用關系。

四、數據設計

兩個數據庫，大約一百張表。數據庫的設計依賴業務數據，對業務數據歸類，導致數據設計畫出E_R圖，數據設計完成，最終數據庫設計就出來了。數據庫只要早起設計的號，是可以做到易伸縮、易拆分的。統計類主要分為統計的維度，還有就是用戶、設備、錯誤信息等。
1、數據處理能力
日活百萬，啟動次數大概兩百萬，事件數和頁面訪問量起碼在三百到五百萬之間，平均每小時數據量五十萬。運行過程中，**客戶數據量集中在早晚高峰。根據客戶的特殊情況，會把一些任務安排在閑暇時間段，比如日任務、周任務、月任務等安排在零晨。
好的硬件配置是數據處理的好幫手，更大的內存更快的硬盤絕對可以讓數據流快速執行。
2、數據清洗和讀寫分離
大量原始數據入庫，這些數據處理之后就是垃圾數據了。當所有報表數據都統計之后并寫入各個維度表之后，需要定時把這些數據清除掉。
前臺報表展示數據跟存儲分析數據庫最好分開。

五、物理架構

微服務的物理架構需要的機器很少，一臺機器也能跑起來。分析統計主要是數據處理能力要求很高，數據庫服務器需要兩臺，web端需要一臺足矣。多年運營結果是并發和數據庫處理能力是統計分析的最大瓶頸。

六、繼續優化的方向

1、數據讀寫分離，數據清洗。
2、并發量。

七、客戶

客戶最關心的數據：
每一個客戶最關心的就是用戶表，用戶新增狀況、用戶活躍情況、用戶留存情況。
不同的客戶對用戶要求不同，需要判斷用戶是否是刷機來的，用戶跟設備號及用戶ID（用戶號碼）之間的映射關系。
事件數據也是很重要的，關系轉化率。
頁面訪問跟事件是同等重要。
錯誤數據可以檢測應用存在的Bug。
不同的客戶，不同的使用場景對指標會有不同需求。

運行三年，日活百萬的微服務數據分析架構，首發于Cobub。